ES2775501T3

ES2775501T3 - Procedimientos de compatibilidad de llamadas de emergencia y de localización para un proveedor de servicios de libre transmisión

Info

Publication number: ES2775501T3
Application number: ES15801038T
Authority: ES
Inventors: Stephen William Edge; Randall Coleman Gellens; Farrokh Khatibi
Original assignee: Qualcomm Inc
Current assignee: Qualcomm Inc
Priority date: 2014-11-24
Filing date: 2015-11-10
Publication date: 2020-07-27
Anticipated expiration: 2035-11-10
Also published as: CN107113566A; US20160150574A1; US20180014338A1; KR20170091600A; HUE047306T2; EP3225042B1; AU2015354709B2; AU2015354709A1; KR101825898B1; DK3225042T3; JP6374110B2; EP3225042A1; US9756664B2; BR112017010777B1; US10165395B2; BR112017010777A2; JP2017536768A; CN107113566B; WO2016085647A1

Abstract

Un procedimiento de compatibilidad de llamadas de emergencia en un proveedor de servicios de libre transmisión, OTT, (850), que comprende: recibir (1810) un primer mensaje (214A, 806) que comprende una solicitud de llamada de emergencia desde un equipo de usuario, UE (800), en el que el primer mensaje se transfiere al proveedor de servicios OTT por medio de un operador de red móvil, MNO, de servicio (890) para el UE, y en el que el primer mensaje incluye una dirección para un subsistema multimedia de protocolo de Internet, IP, IMS, (894) para el MNO de servicio; y enviar (1820) un segundo mensaje (808) al IMS en base a la dirección, en el que el segundo mensaje comprende una solicitud para una llamada de emergencia.

Description

DESCRIPCIÓN

Procedimientos de compatibilidad de llamadas de emergencia y de localización para un proveedor de servicios de libre transmisión

INTRODUCCIÓN

[0001] Los modos de realización de la divulgación se refieren a proporcionar compatibilidad para llamadas de emergencia y localización para un proveedor de servicios (SP) de libre transmisión (over-the-top, OTT).

[0002] Los sistemas de comunicación inalámbrica se han desarrollado a través de diversas generaciones, incluyendo un servicio analógico de telefonía inalámbrica de primera generación (1G), un servicio digital de telefonía inalámbrica de segunda generación (2G) (que incluye las redes 2.5G provisionales) y servicios inalámbricos con acceso a Internet/datos de alta velocidad de tercera generación (3G) y cuarta generación (4G).

[0003] Como parte de la evolución 4G, se ha desarrollado la evolución a largo plazo (LTE) por el Proyecto de Colaboración de Tercera Generación (3GPP) como una tecnología de red de acceso por radio para la comunicación inalámbrica de datos de alta velocidad para teléfonos móviles y otros terminales de datos. LTE ha evolucionado a partir del sistema global para comunicaciones móviles (GSM) y de derivados de GSM, tales como las velocidades de transferencia de datos mejoradas para la evolución de GSM (EDGE), el sistema universal de telecomunicaciones móviles (UMTS) y el acceso de paquetes a alta velocidad (HSPA).

[0004] En América del Norte, los sistemas de comunicaciones inalámbricas, tales como los compatibles con GSM, UMTS y LTE, que se emplean por operadores de redes públicas, usan una solución para 911 mejorado, o E911, que vincula a las personas que llaman a emergencias con los recursos públicos apropiados. La solución intenta asociar automáticamente la persona que llama, es decir, el equipo de usuario (UE) de la persona que llama, con una localización específica, tal como una dirección física o coordenadas geográficas. Localizar automáticamente a la persona que llama con elevada exactitud (por ejemplo, con un error de distancia de 50 metros o menos) y proporcionar la localización a un punto de respuesta de seguridad pública (PSAP) puede aumentar la velocidad con la que el lado de seguridad pública puede responder durante emergencias, especialmente donde es posible que la persona que llama no pueda comunicar su localización o no conozca esta localización. Además, conocer la localización aproximada de una persona que llama de emergencia (por ejemplo, la célula de red particular a la que accede el dispositivo de la persona que llama) puede ser esencial para enrutar una llamada de emergencia al PSAP correcto para la localización de la persona que llama.

[0005] Otros proveedores determinados, conocidos como proveedores de servicios (SP) de transmisión libre (Over The Top, OTT), también pueden proporcionar servicios relacionados con voz y datos a los usuarios de dispositivos inalámbricos, pero sin necesariamente poseer o manejar una red inalámbrica pública o actuar como un operador de red virtual móvil (MVNO). Un usuario con un dispositivo inalámbrico puede acceder, a continuación, a los recursos de SP OTT (por ejemplo, uno o más servidores) por medio de algún otro SP de red inalámbrica, por ejemplo, un SP con una red UMTS o LTE, y posiblemente también por medio de Internet. El acceso es típicamente transparente para el SP de la red inalámbrica de servicio (a diferencia del acceso a una red inalámbrica doméstica o MVNO) y se puede producir típicamente por encima de los niveles de la red y del protocolo IP, lo que da lugar al nombre "pasar por alto (over the top)". En este caso, el SP OTT puede proporcionar a un usuario la capacidad de realizar llamadas (o sesiones) de voz y datos y, en algunos casos, la capacidad de realizar una llamada de emergencia.

[0006] Sin embargo, un SP OTT puede tener más dificultades que un operador de red inalámbrica pública para obtener una localización exacta y fiable para una persona que llama de emergencia debido al acceso restringido a la información relacionada con la localización y la falta de recursos con capacidad de localización. Por ejemplo, mientras que una red inalámbrica de servicio puede tener acceso a información relacionada con la célula para una persona que llama de forma inalámbrica (por ejemplo, una ID de célula de servicio para la persona que llama de forma inalámbrica) y puede tener una infraestructura de red que se puede usar para obtener una localización exacta para una persona que llama de forma inalámbrica (por ejemplo, estaciones base que pueden medir señales desde un dispositivo inalámbrico de una persona que llama o cuyas señales se pueden medir por el dispositivo inalámbrico de la persona que llama y un servidor de localización para transformar dichas mediciones en una estimación de localización), un SP OTT puede tener poca o nada de esta infraestructura o información. Esto puede evitar que un SP OTT enrute una llamada de emergencia de una persona que llama de forma inalámbrica al PSAP correcto y/o proporcione una localización exacta de la persona que llama de forma inalámbrica a un PSAP, lo que puede evitar que un SP OTT proporcione servicios de emergencia fiables. Además, un SP OTT no siempre tiene los medios de comunicación para reenviar una llamada de emergencia a un PSAP de destino, incluso cuando se puede conocer el PSAP, o responder a una consulta desde un PSAP en cuanto a la localización de una persona que llama, por ejemplo, en el caso de que un SP OTT carezca de la conectividad necesaria para el PSAP o carezca de autorización para reenviar llamadas de emergencia o proporcionar la localización de la persona que llama. Por tanto, puede haber beneficios al mejorar la compatibilidad de llamadas de servicio de emergencia y de localización para un SP OTT. Se llama la atención al documento WO 2013/135316 (A1), que describe un procedimiento de realización de un traspaso de una continuidad de llamadas de voz de radio única, SRVCC, de una llamada de telecomunicaciones establecida por un equipo de usuario, UE que accede a una red de servicio usando un acceso de paquete conmutado, PD. La red de servicio incluye una red de IMS de servicio y la llamada es una llamada de emergencia no detectada por UE anclada en la red de IMS de servicio. El procedimiento incluye recibir una indicación desde la red de servicio de que la llamada establecida es una llamada de emergencia no detectada por UE anclada en la red de IMS de servicio. Se recibe una solicitud de traspaso de SRVCC para traspasar la llamada desde el acceso de PS a un acceso de conmutación de circuitos, CS. El traspaso de la llamada se inicia de modo que se usa un número de transferencia de sesión de emergencia - radio única, E-STN-SR, y la llamada continúa enrutándose a través de la red de IMS en la que está anclada.

[0007] También se llama la atención al documento "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects: IP Multimedia Subsystem (IMS) emergency sessions (Release 12)", NORMA 3GPP: TS 23.167 DE 3GPP, PROYECTO DE COLABORACIÓN DE TERCERA GENERACIÓN (3GPP), CENTRO DE COMPETENCIA MÓVIL: 650, ROUTE DES LUCIOLES: F-06921 SOPHIA-ANTIPOLIS CEDEX: FRANCIA, (20140922), vol. SA WG2, n.2 V12.0.0.

SUMARIO

[0008] De acuerdo con la presente invención, se proporcionan procedimientos y un aparato para la compatibilidad de llamadas de emergencia, como se expone en las reivindicaciones independientes. Los modos de realización de la invención se reivindican en las reivindicaciones dependientes.

[0009] A continuación se presenta un sumario simplificado en relación con uno o más aspectos y/o modos de realización asociados con los mecanismos divulgados en el presente documento para proporcionar alternativas de transferencia de localización a un proveedor de servicios de libre transmisión (OTT). Como tal, el siguiente sumario no se debe considerar una descripción general extensa en relación con todos los aspectos y/o modos de realización contemplados, ni se debe considerar el siguiente sumario para identificar elementos clave o esenciales en relación con todos los aspectos y/o modos de realización contemplados ni para delinear el alcance asociado con cualquier aspecto y/o modo de realización particular. En consecuencia, el siguiente sumario tiene el único propósito de presentar determinados conceptos en relación con uno o más aspectos y/o modos de realización en relación con los mecanismos divulgados en el presente documento de una forma simplificada para preceder a la descripción detallada presentada a continuación.

[0010] Se divulgan los procedimientos y aparatos para la compatibilidad de llamadas de emergencia y de localización para un proveedor de servicios OTT. Un procedimiento de compatibilidad de llamadas de emergencia en un proveedor de servicios OTT incluye recibir un primer mensaje que comprende una solicitud de llamada de emergencia desde un equipo de usuario (UE), en el que el primer mensaje se transfiere al proveedor de servicios OTT por medio de un operador de red móvil (MNO) de servicio para el UE, y en el que el primer mensaje incluye una dirección para un subsistema multimedia de protocolo de Internet (IP) (IMS) para el MNO de servicio, y enviar un segundo mensaje al IMS en base a la dirección, en el que el segundo mensaje comprende una solicitud para la llamada de emergencia. Un procedimiento de compatibilidad para llamadas de emergencia en una entidad IMS para un MNO de servicio incluye recibir un primer mensaje enviado por un proveedor de servicios OTT que comprende una solicitud de llamada de emergencia para un UE, en el que la solicitud de llamada de emergencia incluye datos de MNO para el UE, y determinar la información de enrutamiento para un punto de respuesta de seguridad pública (PSAP) de destino en base a los datos de MNO.

[0011] Un procedimiento de compatibilidad para llamadas de emergencia en un UE incluye recibir una solicitud para una llamada de emergencia desde un usuario del UE, obtener datos de MNO para un MNO de servicio para el UE, y enviar un primer mensaje que comprende una solicitud para la llamada de emergencia a un proveedor de servicios OTT, en el que la solicitud para la llamada de emergencia incluye los datos de MNO.

[0012] Un aparato para la compatibilidad de llamadas de emergencia en un proveedor de servicios OTT incluye al menos un procesador y un transceptor, el transceptor configurado para recibir un primer mensaje que comprende una solicitud de llamada de emergencia desde un UE, en el que el primer mensaje se transfiere al proveedor de servicios OTT por medio de un MNO de servicio para el UE, y en el que el primer mensaje incluye una dirección para un IMS para el MNO de servicio, y para enviar un segundo mensaje al IMS en base a la dirección, en el que el segundo mensaje comprende una solicitud para la llamada de emergencia.

[0013] Un aparato para la compatibilidad de llamadas de emergencia en una entidad IMS para un MNO de servicio incluye al menos un procesador y un transceptor, el transceptor configurado para recibir un primer mensaje enviado por un proveedor de servicios OTT que comprende una solicitud de llamada de emergencia para un UE, en el que la solicitud de llamada de emergencia incluye datos de MNO para el UE, y en el que el al menos un procesador se configura para determinar la información de enrutamiento para un PSAP de destino en base a los datos de MNO.

[0014] Un aparato para la compatibilidad de llamadas de emergencia en un UE incluye al menos un procesador y un transceptor, el transceptor configurado para recibir una solicitud para una llamada de emergencia desde un usuario del UE, para obtener datos de MNO para un MNO de servicio para el UE, y para enviar un primer mensaje que comprende una solicitud para la llamada de emergencia a un proveedor de servicios OTT, en el que la solicitud para la llamada de emergencia incluye los datos de MNO.

[0015] Un aparato para la compatibilidad de llamadas de emergencia en un proveedor de servicios OTT incluye medios para recibir un primer mensaje que comprende una solicitud de llamada de emergencia desde un UE, en el que el primer mensaje se transfiere al proveedor de servicios OTT por medio de un MNO de servicio para el UE, y en el que el primer mensaje incluye una dirección para un IMS para el MNO de servicio, y medios para enviar un segundo mensaje al IMS en base a la dirección, en el que el segundo mensaje comprende una solicitud para la llamada de emergencia.

[0016] Un aparato para la compatibilidad de llamadas de emergencia en una entidad IMS para un MNO de servicio incluye medios para recibir un primer mensaje enviado por un proveedor de servicios OTT que comprende una solicitud de llamada de emergencia para un UE, en el que la solicitud de llamada de emergencia incluye datos de MNO para el UE, y medios para determinar la información de enrutamiento para un PSAP de destino en base a los datos de MNO.

[0017] Un aparato para la compatibilidad de llamadas de emergencia en un UE incluye medios para recibir una solicitud para una llamada de emergencia desde un usuario del UE, medios para obtener datos de MNO para un MNO de servicio para el UE y medios para enviar un primer mensaje que comprende una solicitud para la llamada de emergencia a un proveedor de servicios OTT, en el que la solicitud para la llamada de emergencia incluye los datos de MNO.

[0018] Un medio no transitorio legible por ordenador para la compatibilidad de llamadas de emergencia en un proveedor de servicios OTT incluye al menos una instrucción para recibir un primer mensaje que comprende una solicitud de llamada de emergencia desde un UE, en el que el primer mensaje se transfiere al proveedor de servicios OTT por medio de un MNO de servicio para el UE, y en el que el primer mensaje incluye una dirección para un IMS para el MNO de servicio, y al menos una instrucción para enviar un segundo mensaje al IMS en base a la dirección, en el que el segundo mensaje comprende una solicitud para la llamada de emergencia.

[0019] Un medio no transitorio legible por ordenador para la compatibilidad de llamadas de emergencia en una entidad IMS para un MNO de servicio incluye al menos una instrucción para recibir un primer mensaje enviado por un proveedor de servicios OTT que comprende una solicitud de llamada de emergencia para un UE, en el que la solicitud de llamada de emergencia incluye datos de MNO para el UE, y al menos una instrucción para determinar la información de enrutamiento para un PSAP de destino en base a los datos de MNO.

[0020] Un medio no transitorio legible por ordenador para la compatibilidad de llamadas de emergencia en un UE incluye al menos una instrucción para recibir una solicitud para una llamada de emergencia desde un usuario del UE, al menos una instrucción para obtener datos de MNO para un MNO de servicio para el UE, y al menos una instrucción para enviar un primer mensaje que comprende una solicitud para la llamada de emergencia a un proveedor de servicios OTT, en el que la solicitud para la llamada de emergencia incluye los datos de MNO.

[0021] Otros objetivos y ventajas asociados con los mecanismos divulgados en el presente documento serán evidentes para los expertos en la técnica, en base a los dibujos adjuntos y la descripción detallada.

BREVE DESCRIPCIÓN DE LOS DIBUJOS

[0022] Una apreciación más completa de los modos de realización de la divulgación y de muchas de las ventajas relacionadas de los mismos se obtendrá fácilmente a medida que la misma se entienda mejor por referencia a la siguiente descripción detallada cuando se considere en relación con los dibujos adjuntos, que se presentan solamente como ilustración y no limitación de la divulgación, y en los que:

La FIG. 1A ilustra una arquitectura de sistema de alto nivel de un sistema de comunicaciones inalámbricas de acuerdo con al menos un aspecto de la divulgación.

La FIG. 1B ilustra una configuración de ejemplo de la arquitectura del sistema de la FIG. 1A para acceso inalámbrico de evolución a largo plazo (LTE) de acuerdo con al menos un aspecto de la divulgación.

La FIG. 2A ilustra interacciones específicas de las entidades de red ilustradas en la FIG. 1A para proporcionar una localización por referencia de acuerdo con al menos un aspecto de la divulgación.

La FIG. 2B ilustra interacciones específicas de las entidades de red ilustradas en la FIG. 1B para proporcionar una localización por referencia de acuerdo con al menos un aspecto de la divulgación.

La FIG. 3 ilustra una arquitectura ejemplar para proporcionar servicios de emergencia de acuerdo con al menos un aspecto de la divulgación.

La FIG. 4 ilustra una arquitectura ejemplar para la compatibilidad de localización por referencia de acuerdo con al menos un aspecto de la divulgación.

La FIG. 5 ilustra una arquitectura ejemplar para la compatibilidad del subsistema multimedia del protocolo de Internet (IP) (IMS) para servicios de emergencia de acuerdo con al menos un aspecto de la divulgación.

La FIG. 6 ilustra otra arquitectura ejemplar para la compatibilidad de IMS para servicios de emergencia de acuerdo con al menos un aspecto de la divulgación.

La FIG. 7 ilustra un flujo de llamadas ejemplar para la localización por valor y la localización por referencia de acuerdo con al menos un aspecto de la divulgación.

La FIG. 8 ilustra otro flujo de llamadas ejemplar para la compatibilidad de IMS de una llamada de emergencia de acuerdo con al menos un aspecto de la divulgación.

La FIG. 9 ilustra otro flujo de llamadas ejemplar para la compatibilidad de IMS de una llamada de emergencia de acuerdo con al menos un aspecto de la divulgación.

La FIG. 10 es un diagrama de bloques simplificado de varios aspectos de muestra de componentes configurados para la compatibilidad de comunicación como se enseña en el presente documento.

La FIG. 11 ilustra un ejemplo de un equipo de usuario (UE) de acuerdo con al menos un aspecto de la divulgación. La FIG. 12 ilustra un dispositivo de comunicación que incluye componentes estructurales para realizar la funcionalidad descrita en el presente documento.

La FIG. 13 ilustra un servidor de acuerdo con un modo de realización de la divulgación.

Las FIGS. 14-20 ilustran flujos ejemplares para localizar un UE de acuerdo con diversos aspectos de la divulgación. Las FIGS. 21 - 27 son otros diagramas de bloques simplificados de varios aspectos de muestra de aparatos configurados para la compatibilidad de comunicación como se enseña en el presente documento.

[0023] Cabe destacar que en los flujos de mensajes y llamadas mostrados en las FIGS. 2A, 2B, 7, 8 y 9, los mensajes y acciones individuales se indican por etiquetas numéricas a las que a veces se hace referencia en la descripción como operaciones o etapas.

DESCRIPCIÓN DETALLADA

[0024] Se divulgan procedimientos y aparatos para la compatibilidad de llamadas de emergencia y de localización para un proveedor de servicios de libre transmisión (OTT). Un equipo de usuario (UE) puede enviar una solicitud para una llamada de emergencia a un proveedor de servicios OTT y puede incluir en la solicitud datos de operador de red móvil (MNO) para un MNO de servicio para el UE. Los datos de MNO pueden incluir la dirección de un subsistema multimedia IP (IMS) para el MNO de servicio. El proveedor de servicios OTT puede reenviar la solicitud de llamada de emergencia al IMS. El IMS puede determinar la información de enrutamiento para la llamada de emergencia y devolver la información de enrutamiento al proveedor de servicios OTT para posibilitar que el proveedor de servicios OTT enrute la llamada de emergencia a un punto de respuesta de seguridad pública (PSAP) o bien puede enrutar la llamada de emergencia por sí mismo al PSAP. La solicitud de llamada enrutada por el IMS o por el proveedor de servicios OTT puede incluir un identificador de referencia que puede posibilitar que el PSAP obtenga una localización para el UE desde el IMS.

[0025] Estos y otros aspectos de la divulgación se divulgan en la siguiente descripción y dibujos relacionados dirigidos a modos de realización específicos de la divulgación. Se pueden concebir modos de realización alternativos sin apartarse del alcance de la divulgación. Además, elementos bien conocidos de la divulgación no se describirán en detalle o se omitirán para no oscurecer los detalles relevantes de la divulgación.

[0026] Las expresiones "ejemplar" y/o "de ejemplo" se usan en el presente documento en el sentido de que "sirve como ejemplo, caso o ilustración". No se debe considerar necesariamente que cualquier modo de realización descrito en el presente documento como "ejemplar" y/o "de ejemplo" sea preferente o ventajoso con respecto a otros modos de realización. Asimismo, el término "modos de realización de la divulgación" no requiere que todos los modos de realización de la divulgación incluyan el rango característico, ventaja o modo de funcionamiento analizado.

[0027] Además, muchos modos de realización se describen en lo que respecta a secuencias de acciones que se van a realizar, por ejemplo, por elementos de un dispositivo informático. Se reconocerá que diversas acciones descritas en el presente documento se pueden realizar por circuitos específicos (por ejemplo, circuitos integrados específicos de la aplicación (ASIC)), por instrucciones de programa ejecutadas por uno o más procesadores, o por una combinación de ambos. Adicionalmente, se puede considerar que estas secuencias de acciones descritas en el presente documento se incorporan por completo dentro de cualquier forma de medio de almacenamiento legible por ordenador que tenga almacenado en el mismo un correspondiente conjunto de instrucciones informáticas que tras su ejecución harán que un procesador asociado realice la funcionalidad descrita en el presente documento. Por tanto, los diversos aspectos de la divulgación se pueden incorporar en un número de diferentes formas, de las que se ha contemplado que todas están dentro del alcance de la materia objeto reivindicada. Además, para cada uno de los modos de realización descritos en el presente documento, la forma correspondiente de cualquiera de dichos modos de realización se puede describir en el presente documento como, por ejemplo, "lógica configurada para" realizar la acción descrita.

[0028] La tabla 1 proporciona un glosario de términos y abreviaturas usados en la presente divulgación:

Tabla 1 - Glosario de térm inos y abreviaturas

[0029] Un dispositivo cliente, denominado en el presente documento equipo de usuario (UE), puede ser móvil o fijo, y se puede comunicar con una red de acceso por radio (RAN). Como se usa en el presente documento, el término "UE" se puede denominar de manera intercambiable "terminal de acceso" o "AT", "dispositivo inalámbrico", "terminal inalámbrico", "dispositivo de abonado", "terminal de abonado", "estación de abonado", "terminal de usuario" o "UT", "terminal móvil", "estación móvil", "terminal", "dispositivo", "dispositivo de usuario" y variaciones de los mismos. En general, los UE se pueden comunicar con una red central por medio de una RAN, y a través de la red central los UE se pueden conectar con redes externas tales como Internet. Por supuesto, otros mecanismos de conexión a la red central y/o Internet también son posibles para los UE, tales como las redes de acceso por cable, las redes wifi (por ejemplo, en base a IEEE 802.11, etc.) y así sucesivamente. Los UE se pueden incorporar por cualquiera de una serie de tipos de dispositivos incluyendo sin limitarse a tarjetas de PC, dispositivos flash compactos, módems externos o internos, teléfonos inalámbricos o por cable, teléfonos inteligentes, ordenadores de tableta, ordenadores portátiles y así sucesivamente. El enlace de comunicación a través del que los UE pueden enviar señales a la RAN se llama canal de enlace ascendente (por ejemplo, canal de tráfico inverso, canal de control inverso, canal de acceso, etc.). Un enlace de comunicación a través del que la RAN puede enviar señales a los UE se llama canal de enlace descendente o de enlace directo (por ejemplo, un canal de radiobúsqueda, un canal de control, un canal de radiodifusión, un canal de tráfico directo, etc.). Como se usa en el presente documento, el término canal de tráfico (TCH) se puede referir a un canal de tráfico de enlace ascendente/inverso o bien de enlace descendente/directo.

[0030] La FIG. 1A ilustra una arquitectura de sistema de alto nivel de un sistema de comunicaciones inalámbricas 100A de acuerdo con un modo de realización de la divulgación. El sistema de comunicaciones inalámbricas 100A contiene un número N de UE etiquetados de 1...N. Los UE 1...N pueden incluir teléfonos celulares, asistentes digitales personales (PDA), localizadores, un ordenador portátil, un ordenador de sobremesa, etc. Por ejemplo, en la FIG. 1A, los UE 1...2 se ilustran como teléfonos de llamadas celulares, los UE 3...5 se ilustran como teléfonos celulares con pantalla táctil o teléfonos inteligentes, y el UE N se ilustra como un ordenador de sobremesa o PC.

[0031] En referencia a la FIG. 1, los UE 1...N se configuran para comunicarse con una red de acceso (por ejemplo, la RAN 120, un punto de acceso 125, etc.) sobre una capa o interfaz física de comunicaciones, mostrada en la FIG.

1A como las interfaces aéreas 104, 106, 108 y/o una conexión directa por cable 102. Las interfaces aéreas 104 y 106 pueden cumplir con un protocolo de comunicaciones celulares dado (por ejemplo, acceso múltiple por división de código (CDMA), evolución de datos optimizada (EVDO), datos en paquetes de alta velocidad mejorada (eHRPD), sistema global para comunicaciones móviles (GSM), velocidades de transferencia de datos mejoradas para evolución de GSM (EDGE), CDMA de banda ancha (WCDMA), evolución a largo plazo (LTE), etc.), mientras que la interfaz aérea 108 puede cumplir con un protocolo de red inalámbrica de área local (WLAN) (por ejemplo, IEEE 802.11, Bluetooth®, etc.). Como se describirá además a continuación, la RAN 120 incluye una pluralidad de puntos de acceso que sirven a los UE sobre interfaces aéreas, tales como las interfaces aéreas 104 y 106. Los puntos de acceso en la RAN 120 se pueden denominar nodos de acceso (AN), puntos de acceso (AP), estaciones base (BS), nodos B, nodos B evolucionados (eNodos B) y así sucesivamente. Estos puntos de acceso pueden ser puntos de acceso terrestre (o estaciones terrestres) o puntos de acceso satelital. La RAN 120 se configura para conectarse a una red central (CN) 140, que también se puede denominar red central de paquetes (PCN) o núcleo de paquetes evolucionado (EPC), que puede realizar una variedad de funciones, incluyendo enrutamiento y conexión de llamadas de conmutación de circuitos (CS) entre los UE a los que se da servicio por la RAN 120 y otros UE u otras entidades distintas de UE a las que se da servicio por la RAN 120 o una RAN diferente o una red enteramente diferente (distinta de RAN), y también puede mediar un intercambio de datos de paquete conmutado (PS) con otras entidades por medio de redes externas tales como Internet 175. La RAN 120 más la CN 140 pueden actuar como una red inalámbrica de servicio para uno o más de los UE 1 a N. El término red inalámbrica en el presente documento se usa de manera intercambiable con el término operador de red móvil (MNO) para referirse a una red inalámbrica y la infraestructura dentro de la red inalámbrica (por ejemplo, la RAN 120 y la CN 140).

[0032] El Internet 175 incluye un número de agentes de enrutamiento y agentes de procesamiento (no mostrados en la FIG. 1A por razones de conveniencia). En la FIG. 1A, el UE N se muestra como conectado a Internet 175 directamente (es decir, por separado de la red central 140, tal como por medio de un DSL o SP por cable de paquete y que puede ser por medio del punto de acceso 125 por sí mismo en un ejemplo (por ejemplo, para un enrutador de wifi)). El Internet 175 puede funcionar de este modo para enrutar comunicaciones de datos con conmutación de paquetes entre el UE N y otros UE que acceden a Internet 175 (por ejemplo, por medio de la red central 140).

[0033] También se muestra en la FIG. 1 el punto de acceso 125 que está separado de la RAN 120. El punto de acceso 125 se puede conectar a Internet 175 independientemente de la red central (CN) 140 (por ejemplo, por medio de un sistema de comunicación óptica tal como FiOS, un módem de cable, etc.). La interfaz aérea 108 puede dar servicio al UE 4 o al UE 5 sobre una conexión inalámbrica local, tal como IEEE 802.11 o Bluetooth en un ejemplo.

[0034] En referencia a la FIG. 1A, se muestra un servidor de localización 170 como conectado a Internet 175, a la CN 140 o a ambas. El servidor de localización 170 se puede implementar como una pluralidad de servidores estructuralmente separados, o de forma alternativa puede corresponder a un único servidor. Como se describirá a continuación con más detalle, el servidor de localización 170 se configura para la compatibilidad de uno o más servicios de localización (por ejemplo, servicios de posicionamiento, servicios de posición por referencia, etc.) para los UE que se pueden conectar al servidor de localización 170 por medio de la CN 140 y/o por medio de Internet 175.

[0035] La FIG. 1A ilustra además un proveedor de servicios (SP) de libre transmisión (OTT) 150. Un SP OTT puede transferir audio, vídeo y/u otro contenido de medios hacia y/o desde uno o más de los UE 1 a N sobre Internet 175 y posiblemente sobre la RAN 120 y la CN 140 de una manera que sea parcial o completamente transparente para Internet 175, la RAN 120 y la CN 140. Un SP OTT típicamente se refiere a un proveedor externo, tal como Skype™, Hulu, Netflix, Google, etc. El SP OTT 150 se puede comunicar con los UE 1...N sobre Internet 175, la CN 140, la RAN 120 y/o el punto de acceso 125. Aunque solo se ilustra un único SP OTT 150 en la FIG. 1A, como es evidente, puede haber un número cualquiera de SP OTT 150 conectados a Internet 175, cada uno correspondiente a un SP OTT diferente. El SP OTT 150 puede tener uno o más servidores, proxies de enrutamiento y/u otras entidades (no mostradas en la FIG. 1A) que pueden realizar las diversas funciones descritas en el presente documento para el SP OTT 150. Lo mismo se puede aplicar para otros SP OTT mencionados más adelante en el presente documento, tales como el SP OTT 350, 450, 550, 650, 750, 850 y 950.

[0036] También se ilustra en la FIG. 1A una red IP de servicios de emergencia (ESInet) y/o un enrutador selectivo (SR) 160. La ESInet 160 puede enrutar llamadas de emergencia basadas en IP realizadas por cualquiera de los UE 1 a N y recibidas por medio de Internet 175, la CN 140 o el SP OTT 150 a un punto de respuesta de seguridad pública (PSAP) adecuado, tal como el PSAP 180. De forma similar, el SR 160 puede enrutar una llamada de emergencia de conmutación de circuito (CS) realizada por cualquiera de los UE 1 a N y recibida por medio de la CN 140 a un PSAP, tal como el PSAP 180. En algunos modos de realización, cualquiera de los UE 1 a N puede originar una llamada de emergencia basada en IP, que se puede transformar por la CN 140 o por el SP OTT 150 en una llamada de emergencia CS y enviarse al SR 160 (por ejemplo, por medio de la red pública de conmutación telefónica, no mostrada en la FIG.

1A) para su enrutamiento a un PSAP con capacidad CS 180. Esto se puede producir cuando hay un SR 160 pero no una ESInet 160 y/o cuando el PSAP 180 es compatible con llamadas de emergencia CS pero no llamadas de emergencia basadas en IP. Se debe entender que en las descripciones del establecimiento de llamadas de emergencia por medio de un SP OTT 150 más adelante en el presente documento, la llamada de emergencia puede comenzar como una llamada de emergencia basada en IP desde un UE (por ejemplo, cualquiera de los UE 1 a N) pero se puede convertir en una llamada de emergencia CS por el SP OTT 150 y enrutarse al PSAP 180 por medio de un SR 160 y no por medio de una ESInet 160.

[0037] Los UE 1...N en la FIG. 1A pueden realizar llamadas de emergencia de voz, texto, vídeo u otros datos por medio de Internet 175. Por ejemplo, los UE 1...N pueden realizar una llamada de emergencia de este tipo por medio del SP OTT 150, como se describe además a continuación. La ESInet/SR 160 puede entregar estas llamadas de emergencia de voz, texto, vídeo y datos al PSAP 180, que puede ser, por ejemplo, un centro de llamadas de emergencia. El protocolo usado para entregar estas llamadas de emergencia puede ser el protocolo de inicio de sesión (SIP) definido por el Grupo de trabajo de ingeniería de Internet (IETF). Además, las llamadas de emergencia basadas en SIP se pueden entregar usando el subsistema multimedia IP (IMS) definido por 3GPP, que es compatible con el uso de SIP y puede ser compatible con la CN 140.

[0038] A continuación se proporciona un ejemplo de una implementación específica de protocolo para la RAN 120 y la CN 140 con respecto a la FIG. 1B para ayudar a explicar el sistema de comunicaciones inalámbricas 100A con más detalle en el caso de compatibilidad de acceso a LTE con la RAN 120. En particular, los componentes de la RAN 120 y la CN 140 corresponden a componentes asociados con la compatibilidad de comunicaciones de conmutación de paquetes (PS), con lo que los componentes heredados de conmutación de circuitos (CS) también pueden estar presentes en estas redes pero no se muestran explícitamente en la FIG. 1B.

[0039] Específicamente, la FIG. 1B ilustra una configuración de ejemplo 100B de la RAN 120 y la CN 140 en base a un sistema de paquetes evolucionado (EPS) que es compatible con acceso inalámbrico LTE, de acuerdo con un modo de realización de la divulgación. En el ejemplo de la FIG. 1B, la RAN 120 en la red EPS/LTE se configura con una pluralidad de nodos B evolucionados (eNodos B o eNB) 122, 124 y 126. La CN 140 incluye una pluralidad de entidades de gestión de movilidad (MME) 142 y 144, un centro de localización móvil de servicio mejorado (E-SMLC) 172, una pasarela de servicio (S-GW) 146 y una pasarela de red de datos en paquetes (PDG) 148. En el ejemplo de la FIG. 1B, el servidor de localización 170 es un centro de localización móvil con pasarela (GMLC) compatible con la solución de localización del plano de control de LTE o bien una plataforma de localización de localización segura del plano de usuario (SUPL) (SLP) 170 compatible con la solución de localización SUPL definida por la Open Mobile Alliance (OMA). En algunos modos de realización, el servidor de localización 170 puede ser una función de recuperación de localización (LRF) con una conexión a o una asociación con un GMLC y/o una SLP. Las interfaces de red entre estos componentes, la RAN 120 y el Internet 175 se ilustran en la FIG. 1B y se definen en la tabla 2.

Tabla 2

[0040] Ahora se describirá una descripción de alto nivel de los componentes mostrados en la RAN 120 y la CN 140 de la FIG. 1B. Sin embargo, algunos de estos componentes son bien conocidos en la técnica a partir de diversas especificaciones técnicas (TS) 3GPP, y la descripción contenida en el presente documento no pretende ser una descripción exhaustiva de toda la funcionalidad realizada por estos componentes.

[0041] En referencia a la FIG. 1B, las MME 142 y 144 se configuran para gestionar la señalización del plano de control para los portadores de EPS y para la compatibilidad de movilidad de los UE que acceden a la CN 140. Las funciones de MME incluyen: señalización de estrato de no acceso (NAS), seguridad de señalización NAS, gestión de movilidad para traspasos entre tecnologías e intratecnología, selección de PDG y S-GW, y selección de MME para traspasos con cambio de MME.

[0042] La S-GW 146 es la pasarela que termina la interfaz hacia la RAN 120 para la señalización del plano de usuario. Para cada UE conectado a la CN 140 para un sistema basado en EPS, en un punto dado de tiempo, hay una única S-GW. Las funciones de la S-GW 146, para el S5/S8 basado en IPv6 móvil del proxy (PMIP), incluyen: el punto de anclaje de movilidad, el enrutamiento y reenvío de paquetes y la configuración del punto de código DiffServ (DSCP) en base a un identificador de clase de QoS (QCI) del portador de EPS asociado.

[0043] En referencia a la FIG. 1B, la PDG 148 es la pasarela que termina la interfaz SGi hacia la red de datos en paquetes (PDN), por ejemplo, Internet 175. Si un UE accede a múltiples PDN, puede haber más de una PDG para ese UE. Las funciones de la PDG 148 incluyen: filtrado de paquetes (por inspección profunda de paquetes), adjudicación de direcciones IP del UE, configuración del DSCP en base al QCI del portador de EPS asociado, contabilización del cobro entre operadores, vinculación del portador de enlace ascendente (UL) y enlace descendente (DL) como se define en la TS 23.203 de 3GPP y verificación de vinculación del portador de UL como se define en la Ts 23.203 de 3GPP. La PDG 148 proporciona conectividad PDN tanto a los UE de la red de acceso por radio GSM/EDGE (GERAN)/UTRAN solo como a los UE con capacidad LTE que usan una RAN 120 que puede ser cualquiera de E-UTRAN, GERAN o UTRAN. La PDG 148 proporciona conectividad PDN a los UE con capacidad LTE que usan una RAN 120 que comprende eNB tal como se muestra en la FIG. 1B (que se denomina E-UTRAN) sobre la interfaz S5/S8.

[0044] En referencia a la FIG. 1B, se muestra el GMLC/SLP 170 como conectado a la MME 142, a la PDG 148 en la CN 140 y/o a Internet 175. El g Ml C/SLP 170 puede ser un GMLC o bien una SLP o puede ser una LRF con una conexión a o una asociación con un GMLC o una SLP. Un GMLC 170 (o una LRF 170 con un GMLC asociado o conectado) es compatible con la solución de localización del plano de control de LTE, mientras que una SLP 170 (o una LRF 170 con una SLP asociada o conectada) es compatible con la solución de localización SUPL. En el caso de que el GMLC/SLP 170 sea un GMLC pero no una SLP, el GMLC/SLP 170 se puede conectar a la MME 142 y a una o ambas de la PDG 148 e Internet 175. En el caso de que el GMLC/SLP 170 sea una SLP pero no un g Ml C, el GMLC/SLP 170 se puede o no conectar a la MME 142 y se puede conectar a una o ambas de la PDG 148 e Internet 175. El GMLC/SLP 170 puede posibilitar que una entidad externa, tal como el SP OTT 150, la ESInet 160 o el PSAP 180, envíe una solicitud de localización al GMLC/SLP 170 para cualquiera de los UE 1 a N en la FIG. 1A, puede coordinar la determinación de localización para este UE usando la solución de localización del plano de control 3GPP en el caso de un GMLC, o SUPL en el caso de una SLP, y puede devolver la localización determinada a la entidad externa solicitante. El E-SMLC 172 ilustrado en la FIG. 1B se conecta a la MME 142 y es otro servidor de localización usado para obtener una estimación de localización de UE usando la solución de localización del plano de control de LTE.

[0045] En una solución de localización del plano de control, se accede a un servidor de localización (por ejemplo, el servidor de localización 170 en la FIG. 1A o el GMLC/SLP 170 en la FIG. 1B) por otros elementos, incluyendo los UE, por medio de interfaces de señalización existentes en una red. Toda señalización relacionada con la localización de un UE se transporta explícitamente como señalización en todas las interfaces. En el caso de acceso LTE, la solución de localización del plano de control se define en las TS 23.271 y 36.305 de 3GPP.

[0046] En una solución de localización del plano de usuario, tal como la solución SUPL, un UE y un servidor de localización tal como el GMLC/SLP 170 en la FIG. 1B se comunican al intercambiar datos desde la perspectiva de la red, tal como por medio de IP o TCP/IP. En el caso de la solución SUPL, el GMLC/SLP 170 sería una SLP y se usaría para obtener una localización en lugar de usar el E-SMLC 172. En algunos casos, una red puede emplear tanto una solución de localización del plano de control como una solución de localización del plano de usuario, tal como SUPL. En ese caso, el E-SMLC 172 puede estar presente y el GMLC/SLP 170 puede comprender tanto un GMLC como una SLP. El GMLC y la SLP para el GMLC/SLP 170 también se pueden combinar (por ejemplo, en la misma entidad física) o se pueden conectar entre sí para permitir que ambas soluciones se usen para localizar un UE. Como ya se mencionó, el GMLC/SLP 170 también puede comprender una LRF con una asociación con o una conexión a un GMLC y/o una SLP. Una LRF 170 conectada a o asociada con un GMLC puede ser compatible con la localización del plano de control de forma similar a un GMLC, mientras que una LRF 170 conectada a o asociada con una SLP puede ser compatible con la localización del plano de usuario SUPL de forma similar a una SLP.

[0047] La Alianza para Soluciones de la Industria de Telecomunicaciones (ATIS) está investigando formas de compatibilidad de las llamadas al 9-1 -1 de próxima generación (NG911) que se establen por un UE por medio de un proveedor de servicios OTT, por ejemplo, Skype™. Un problema principal es obtener y proporcionar una localización exacta y fiable de una persona que llama al 911 para posibilitar el enrutamiento de una llamada NG911 por el SP OTT a o hacia el PSAP correcto y para posibilitar el envío por el PSAP de apoyo de seguridad pública a la localización del usuario que llama. Debido a que un SP OTT, tal como el SP OTT 150, a menudo tendrá poca o ninguna información con respecto a la red de acceso usada por el UE que llama, puede ser difícil para el SP OTT hacer uso de procedimientos de posicionamiento terrestre (tales como wifi, ID de célula mejorado (E-CID) y la diferencia de tiempo de llegada observada (OTDOA)) para localizar directamente al UE que llama. Además, cuando un UE que llama está en interiores, la localización del UE usando un sistema de posicionamiento satelital (SPS) tal como el sistema de posicionamiento global (GPS), algún otro sistema satelital de navegación global (GNSS) o por medio de GPS asistido (A-GPS) o GNSS asistido (A-GNSS) por el SP OTT también puede no ser fiable debido a una dificultad inherente en el uso de la localización por SPS en interiores y/o debido a la falta de capacidad de un SP OTT para controlar y/o ayudar al uso de la localización por SPS.

[0048] Una solución que se puede usar por un SP OTT 150 para obtener la localización de un UE que ha iniciado una llamada de emergencia por medio del SP OTT 150 implica que el SP OTT 150 consulte un servidor de localización en la red de acceso (tal como el servidor de localización 170 en la FIG. 1A o el GMLC/SLP 170 en la FIG. 1B) para obtener la localización del UE que llama, si al SP OTT 150 se le puede proporcionar o puede inferir la dirección de este servidor de localización. En otra solución, el UE que inicia la llamada de emergencia puede proporcionar su localización directamente al SP OTT 150 (por ejemplo, en una INVITACIÓN SIP usada para establecer la llamada NG911). Que el UE proporcione su localización directamente a un SP OTT 150 puede ser una solución atractiva porque (a) se podrían restringir los nuevos efectos a las normas (por ejemplo, las normas 3GPP), (b) los efectos de la implementación en las redes RAN y CN del operador de red móvil (MNO) podrían ser bajos o nulos, (c) los UE típicamente son compatibles con una capacidad de localización independiente de todos modos (por ejemplo, una solución ayudada por un proveedor del sistema operativo del UE o un proveedor de chips del UE) y (d) la solución podría encajar bien con las normas NG911 existentes que permiten que el UE suministre la localización de UE en una INVITACIÓN SIP enviada para iniciar una llamada de emergencia.

[0049] Una localización proporcionada por el UE (por ejemplo, incluida en una INVITACIÓN SIP) puede ser por valor (por ejemplo, el UE proporciona sus coordenadas de latitud/longitud directamente) o por referencia. Para la localización por referencia, el UE proporciona un identificador uniforme de recursos (URI) (originalmente obtenido por el UE desde un servidor de localización y denominado en el presente documento "URI de localización") que contiene el nombre o la dirección de un servidor de localización, una referencia única al UE que se puede asignar por el servidor de localización, y una indicación de un protocolo a usar para obtener la localización de UE desde el servidor de localización. Un "URI de localización" se denomina de manera intercambiable en el presente documento "referencia de localización" y "localización por referencia". Un URI de localización puede ser como se define por el IETF en la solicitud de comentarios (RFC) 3986 y 5808 y puede comprender una cadena de caracteres conforme a las reglas en la RFC 3986 que codifican la identificación de un nombre de esquema o nombre de protocolo tal como SIP o HTTP y una identificación de un recurso que puede comprender la identificación (por ejemplo, nombre o dirección de la ruta de Internet) de un servidor de localización más la identificación de un UE.

[0050] La identificación del UE, también denominada en el presente documento "referencia de UE", "referencia de UE local" o "referencia local", puede comprender caracteres que identifiquen el UE con el servidor de localización pero que oculten la verdadera identidad del UE a otras entidades y se puede asignar localmente por el servidor de localización. Un UE puede solicitar y obtener un URI de localización desde un servidor de localización usando un protocolo de configuración de localización tal como el protocolo de entrega de localización habilitada por HTTP (HELD) definido en la RFC 5985 del IETF. Un UE puede transmitir un URI de localización a otra entidad, tal como el SP OTT 150, la ESInet 160 o el PSAP 180 en la FIG. 1A y la FIG. 1B usando un protocolo de transmisión de localización, tal como SIP como se define en la RFC 6442 del IETF. La entidad que recibe un URI de localización para un UE (por ejemplo, el SP OTT 150, la ESInet 160 o el PSAP 180 en la FIG. 1A y la FIG. 1B) puede usar un protocolo de desrreferencia de localización, tal como SIP, HTTP o HELD, para solicitar y recibir la localización del UE (por ejemplo, coordenadas geográficas que pueden comprender una latitud y una longitud (y posiblemente altitud) o una localización cívica que puede comprender una dirección postal o una dirección de domicilio (y posiblemente un número de planta, número de habitación, número de piso, etc.)) desde el servidor de localización. Con la desrreferencia de localización, la entidad que solicita la localización proporciona el URI de localización al servidor de localización, que identifica el UE desde el URI de localización, obtiene una localización para el UE y devuelve la localización a la entidad solicitante.

[0051] La solución de localización por referencia puede ser más atractiva que la solución de localización por valor porque permite más tiempo para que un UE o un servidor de localización obtenga una localización para el UE y se puede usar para obtener más de una localización para el UE en diferentes tiempos. Por ejemplo, la solución de localización por referencia se puede usar por un SP OTT 150 para obtener inicialmente una localización de UE aproximada para ayudar al enrutamiento y en un tiempo posterior para obtener una localización de UE más exacta para el envío del PSAP.

[0052] Una solución de localización por referencia puede tener efectos significativos en un UE y en un servidor de localización, que puede necesitar tanto ser compatible con (a) un protocolo de configuración de localización, tal como HELD, con lo que un UE puede solicitar y un servidor de localización puede proporcionar un URI de localización, como con (b) un medio para que el servidor de localización autentique la identidad del UE cuando se produce la consulta/respuesta en (a). El efecto en (b) puede ser necesario porque el servidor de localización puede necesitar identificar de manera fiable el UE en el tiempo en que se asigna un URI de localización para localizar el UE correcto (por ejemplo, y no algún otro UE) en algún tiempo posterior cuando un cliente (por ejemplo, un SP OTT 150 o un PSAP 180) solicita la localización del UE consultando el servidor de localización con el URI de localización. Algunos protocolos de configuración de localización como HELD normalmente pueden no requerir o ser compatibles con la autenticación en (b) porque una dirección IP del UE para el que se proporciona un URI de localización puede estar disponible para un servidor de localización desde el UE cuando (a) se produce y se puede considerar lo suficientemente fiable como para identificar y localizar el UE en un tiempo posterior cuando el URI de localización se desrreferencia más adelante por un SP OTT 150, una ESInet 160 o un PSAP 180 (por ejemplo, usando HELD).

[0053] Sin embargo, una dirección IP se podría falsificar. Por ejemplo, una entidad que no sea un UE pero que puede interceptar la comunicación IP hacia y desde un UE puede usar un protocolo de configuración de localización para obtener un URI de localización para un UE al enviar una solicitud de localización a un servidor de localización que contiene la dirección IP para el UE. A continuación, la entidad puede (i) hacerse pasar por un SP OTT para obtener la localización para el UE al enviar una solicitud de desrreferencia al servidor de localización que contiene el URI de localización obtenido o bien (ii) iniciar una llamada de emergencia y proporcionar el URI de localización a un SP OTT 150 para provocar el envío de seguridad pública a la localización del UE aunque el UE no haya realizado la llamada de emergencia.

[0054] Además, incluso cuando una dirección IP para un UE sea correcta y cuando una entidad que solicita la localización de UE sea legítima, un servidor de localización puede requerir una identidad diferente para el UE para obtener la localización del UE y/o identificar correctamente al UE en un tiempo posterior. Por ejemplo, si el servidor de localización emplea una solución de localización del plano de control para obtener la localización de un UE (por ejemplo, la solución de localización del plano de control 3GPP para LTE), el servidor de localización puede necesitar una identidad inalámbrica asociada para el UE, tal como un número internacional de abonado móvil (IMSI) o un número temporal de abonado móvil (TMSI), en lugar de la dirección IP del UE. Además, si se necesita identificar más adelante un UE que se localiza para propósitos de cobro o facturación (por ejemplo, para permitir que el SP para el servidor de localización facture el SP OTT 150) o para realizar un seguimiento posterior si una localización obtenida fue por error o para propósitos estadísticos y contables, entonces puede ser necesaria alguna identidad global permanente para el UE que no sea una dirección IP. Para garantizar que el servidor de localización tenga una identidad correcta para el UE y que se proporcione un URI de localización al UE correcto en lugar de a una entidad que se hace pasar por el UE, puede ser necesario el efecto de autenticación en (b) anterior. Los dobles efectos de (a) y (b) pueden hacer que una solución de localización por referencia (por ejemplo, como se define por las RFC del IETF mencionadas anteriormente en el presente documento) sea compleja tanto para los proveedores del UE como para los MNO o sus proveedores de servidores de localización.

[0055] Una solución al problema descrito anteriormente para hacer uso de una localización por referencia sería que una red de acceso de servicio, en lugar de un servidor de localización, proporcione a un UE una localización por referencia después de que el UE (y su identidad) se haya autenticado por la red de acceso. La autenticación de un UE por una red de acceso es una parte típica del funcionamiento de la red inalámbrica que es o puede ser compatible con muchos tipos de redes inalámbricas (por ejemplo, GSM, UMTS, LTE, IEEE 802.11) y, por ende, no puede añadir nuevos efectos a un UE o a una red de acceso. La provisión de una localización por referencia por una red de acceso a un UE se podría producir (i) inmediatamente después de que un UE se haya conectado con éxito a la red de acceso y se haya autenticado, (ii) periódicamente, mientras el UE esté conectado a la red de acceso (por ejemplo, para posibilitar que una localización por referencia previa se reemplace en base a un servidor de localización diferente y/o una referencia de UE local diferente), y/o (iii) a solicitud del UE mientras el UE esté conectado a la red de acceso.

[0056] En un modo de realización, una red de acceso se podría comunicar con un servidor de localización para obtener una localización por referencia para un UE. En este modo de realización, la red de acceso podría actuar como un proxy y obtener una localización por referencia desde el servidor de localización en nombre del UE. El UE y el servidor de localización no necesitarían entonces ser compatibles con un protocolo de configuración de localización para posibilitar que el UE obtenga un URI de localización desde el servidor de localización. En su lugar, el UE obtendría el URI de localización desde la red de acceso y la red de acceso obtendría el URI de localización desde el servidor de localización. Si bien este modo de realización podría añadir una nueva interfaz de servidor de localización de red de acceso, puede evitar la necesidad de la compatibilidad de un protocolo de configuración de localización y autenticación del UE tanto por el UE como por el servidor de localización y, por tanto, puede ser una solución más simple que hacer que el UE consulte directamente el servidor de localización usando un protocolo de configuración de localización tradicional.

[0057] En otro modo de realización, una red de acceso podría asignar una localización por referencia a un UE por sí misma sin la participación de un servidor de localización. Por ejemplo, la red de acceso (por ejemplo, la MME 142) puede crear un URI de localización que incluye la dirección conocida o la identidad conocida (por ejemplo, un nombre de ruta de Internet conocido) de un servidor de localización de destino (por ejemplo, el servidor de localización 170 en la FIG. 1A o el GMLC/SLP 170 en la FIG. 1B), el esquema o protocolo que se va a usar para consultar el servidor de localización desde un cliente y (como una extensión a la dirección o identidad del servidor de localización) una referencia de UE que identifica al UE. En un URI de localización normal, la referencia de UE se puede asignar localmente por el servidor de localización que crea un URI de localización. Con el modo de realización descrito en el presente documento, se puede asignar una referencia de UE por la red de acceso y puede comprender una identificación de UE global, tal como la dirección IP del UE, la IMSI para el UE y/o una identidad para el UE conocida por la red de acceso, tal como una TMSI, una dirección local para el UE asignada por un nodo de red de acceso (por ejemplo, una MME o un SGSN) y/o una dirección de un nodo de red de acceso, o cualquier combinación de los mismos. La referencia de UE puede incluir además una fecha y/u hora de asignación y/o se puede cifrar para proteger la privacidad del usuario (por ejemplo, cuando las claves de cifrado son conocidas por la red de acceso y el servidor de localización, pero no por otras partes). En el caso de que la referencia de UE comprenda una TMSI o una dirección IP, puede no ser necesario el cifrado porque la verdadera identidad del UE (por ejemplo, la IMSI del UE) no está incluida en la referencia de UE y, por tanto, puede no estar disponible para otras partes. El URI de localización también puede estar firmado digitalmente por la red de acceso (por ejemplo, puede incluir una firma digital) de modo que un servidor de localización al que se está consultando el URI de localización pueda conocer que el URI de localización se asignó por la red de acceso. En algunos casos, el URI de localización se puede tanto cifrar como firmar digitalmente, por ejemplo, usando el procedimiento de contador con código de autenticación de mensajes y encadenamiento de bloques cifrados (CCM) del Instituto Nacional de Estándares y Tecnología (NIST) de los Estados Unidos.

[0058] El uso de los modos de realización anteriores solo puede afectar la red de acceso y el servidor de localización. Por ende, un MNO podría migrar desde el segundo modo de realización, en el que una red de acceso asigna un URI de localización sin la participación de un servidor de localización, al primer modo de realización, en el que una red de acceso actúa como un proxy para un servidor de localización sin afectar a otras entidades (por ejemplo, incluyendo los UE). En algunos casos, la migración de MNO podría ser desde el primer modo de realización al segundo modo de realización. En el caso de que la red de acceso sea compatible con LTE y pertenezca a un MNO celular, la localización por referencia para un UE se puede asignar por la MME de servicio para el UE, tal como la MME 142 en la FIG. 1B. La asignación se puede producir como parte de la conexión de red LTE por el UE y/o como parte de una actualización de área de seguimiento por el UE. Una asignación de este tipo podría añadir un nuevo parámetro que contiene un URI de localización asignado a unos pocos mensajes de estrato sin acceso (NAS) usados para la compatibilidad de LTE y puede tener un pequeño efecto tanto para el UE como para la red de acceso (por ejemplo, la MME). El beneficio de esta solución para los MNO y los proveedores de UE puede ser que los efectos para la compatibilidad de la solución pueden ser limitados y se puede ofrecer una solución de localización flexible a los SP OTT que se ajuste a las normas existentes.

[0059] En referencia de nuevo a la FIG. 1A y la FIG. 1B, la FIG. 2A ilustra interacciones específicas de las entidades de red ilustradas en la FIG. 1A y la FIG. 1B en el caso de acceso de LTE, para proporcionar una localización por referencia para una llamada de emergencia OTT de acuerdo con los modos de realización descritos en el presente documento. En referencia a la FIG. 2A, el término "red de acceso" se refiere a la RAN 120 y la CN 140. El nodo de red de acceso 240 puede ser alguna entidad en la red de acceso, tal como un nodo de acceso, un punto de acceso, una estación base, un eNodo B (por ejemplo, el eNB 122, 124 o 126), una femtocélula, una MME (por ejemplo, la MME 142), etc. El nodo de red de acceso puede estar dentro de la Ra N 120 o dentro de la CN 140.

[0060] En 202A, un UE 200 (por ejemplo, que puede corresponder a cualquiera de los UE 1 a N en la FIG. 1A) se conecta a la red de acceso por medio del nodo de red de acceso 240. En 204A, el usuario del UE 200 realiza una llamada de emergencia por medio de una aplicación OTT, por ejemplo, Skype, instalada en el UE 200. En 206A, el UE 200 envía una solicitud de una referencia de localización al nodo de red de acceso 240. En algunos modos de realización, el bloque 206A se puede iniciar por la aplicación OTT, que puede reconocer la solicitud de llamada de emergencia en el bloque 204A y puede solicitar que el UE 200 (por ejemplo, usando una interfaz de programación de aplicaciones (API) a un módem en el UE 200) obtenga una referencia de localización.

[0061] En 208A, el nodo de red de acceso 240 puede enviar opcionalmente una solicitud de referencia de localización al servidor de localización 170 (por ejemplo, el GMLC/SLP 170 o el E-SMLC 172) para una referencia de localización para el UE 200 y recibir de vuelta una respuesta desde el servidor de localización 170 en 212A que contiene una referencia de localización. En este caso, el nodo de red de acceso 240 actúa como un proxy para obtener la referencia de localización desde el servidor de localización 170 en nombre del UE 200 en el bloque 208A. La solicitud/respuesta en el bloque 208A puede usar una conexión segura entre el servidor de localización 170 y el nodo de red de acceso 240 que posibilita que el servidor de localización 170 se dé cuenta de que un nodo de red de acceso, en el que su operador puede ser el mismo que para el servidor de localización 170, está solicitando la referencia de localización. La conexión segura entre el servidor de localización 170 y el nodo de red de acceso 240 puede hacer uso de una relación de confianza entre el servidor de localización 170 y el nodo de red de acceso 240, por ejemplo, una relación en base a que el nodo de red de acceso 240 y el servidor de localización 170 pertenecen al mismo SP o al mismo operador de red, y puede emplear credenciales de seguridad preconfiguradas en cada entidad para posibilitar el establecimiento de la conexión segura. A continuación, el servidor de localización 170 puede asignar y devolver una referencia de localización en el bloque 208A (por ejemplo, que puede incluir una referencia de UE que es local al servidor de localización 170) que más adelante se puede usar (por ejemplo, por el SP OTT 150) para obtener una localización para el UE 200 desde el servidor de localización 170 como se describe más adelante.

[0062] Si bien el bloque 208A añade una nueva interfaz entre el nodo de red de acceso 240 y el servidor de localización 170, evita la necesidad de que el servidor de localización 170 interactúe y autentique el UE 200. En algunos modos de realización, el nodo de red de acceso 240 y el servidor de localización 170 pueden usar uno de SIP, HELD o el protocolo de localización móvil (MLP) definido por la Open Mobile Alliance (OMA) para solicitar y devolver la referencia de localización en 208A. En 212A, el nodo de red de acceso 240 envía la referencia de localización obtenida desde el servidor de localización 170 al UE 200. En algunos modos de realización, el UE 200 (por ejemplo, un módem en el UE 200) puede proporcionar la referencia de localización a la aplicación OTT.

[0063] En algunos modos de realización, en lugar de consultar en el servidor de localización 170 la referencia de localización del UE 200, el nodo de red de acceso 240 puede asignar la referencia de localización por sí mismo sin la participación del servidor de localización 170 como se describe previamente en el presente documento. El nodo de red de acceso 240 puede cifrar la parte de referencia de UE de la referencia de localización y/o firmar digitalmente la referencia de localización como también se describe en el presente documento. En este caso, cualquier clave de cifrado/descifrado y/o claves para una firma digital pueden ser conocidas tanto por el nodo de red de acceso 240 como por el servidor de localización 170, pero no por otras partes.

[0064] Los mensajes en 206A, 208A y 212A se ilustran como opcionales (indicados por las líneas discontinuas) en la FIG. 2A porque no necesitan producirse en los tiempos específicos ilustrados en la FIG. 2A. Por el contrario, como un ejemplo, 206A y 212A (y opcionalmente 208A) se pueden realizar durante la conexión en 202A y posiblemente antes de que el usuario realice una llamada de emergencia en 204A, tal como inmediatamente después de que el UE 200 se haya conectado con éxito al nodo de red de acceso 240 y se haya autenticado, o como parte de un intercambio de mensajes de conexión y/o autenticación entre el UE 200 y el nodo de red de acceso 240. Por ejemplo, el UE 200 puede incluir una solicitud de una referencia de localización en un mensaje enviado al nodo de red de acceso 240 para solicitar, responder o confirmar la conexión del UE 200 o la autenticación del UE 200. De forma similar, el nodo de red de acceso 240 puede incluir una referencia de localización asignada en un mensaje enviado al UE 200 para solicitar, responder o confirmar la conexión del UE 200 o la autenticación del UE 200.

[0065] Como otro ejemplo, 206A y 212A (y opcionalmente 208A) se pueden realizar periódicamente mientras el UE 200 está conectado al nodo de red de acceso 240, y no en respuesta a que el usuario realice una llamada de emergencia. Por ejemplo, 206A, 212A y posiblemente 208A se pueden realizar siempre que el UE 200 y el nodo de red de acceso 240 necesiten interactuar para la compatibilidad de movilidad del UE 200. En otro ejemplo, 206A, 212A, y posiblemente 208A, se pueden realizar siempre que el UE 200 cambie a un nuevo nodo de red de acceso (por ejemplo, cambie desde un nodo de red de acceso previo al nodo de red de acceso 240 o desde el nodo de red de acceso 240 a un nuevo nodo de red de acceso). Aún como otro ejemplo, 206A y 212A pueden corresponder a alguna otra interacción existente entre el UE 200 y el nodo de red de acceso 240, tal como una actualización de área de seguimiento para LTE o una actualización de área de enrutamiento para GPRS y/o UMTS. De forma alternativa, como se ilustra en la FIG. 2A, 206A y 212A pueden comprender nuevos mensajes usados solo para obtener la referencia de localización.

[0066] En algunos modos de realización, antes de enviar la referencia de localización al UE 200 en 212A, el nodo de red de acceso 240 puede autenticar la identidad del UE 200 (no mostrado en la FIG. 2A). Dicha autenticación puede garantizar que la referencia de localización se devuelva en 212A al UE 200 correcto. Además, dicha autenticación del UE 200 puede formar una parte normal de la compatibilidad de acceso del UE 200 con los servicios proporcionados por el nodo de red de acceso 240 (por ejemplo, tal como la compatibilidad de la conexión y la movilidad de red para el UE 200), y puede no añadir efectos adicionales al UE 200 o al nodo de red de acceso 240 únicamente con el propósito de devolver una referencia de localización en 212A.

[0067] En 214A, el UE 200 envía una solicitud de llamada de emergencia, que incluye la referencia de localización del UE 200, al SP OTT 150. En algunos modos de realización, se puede transferir la solicitud de llamada de emergencia por el UE 200 al SP OTT 150 por medio del nodo de red de acceso 240 y/o por medio de la red de acceso para el nodo de red de acceso 240. Aunque no se ilustra en la FIG. 2A, el UE 200 podría obtener la referencia de localización desde un nodo de red de acceso 240 para una primera red de acceso perteneciente a un primer operador de red (que también puede poseer el servidor de localización 170) y/o conforme a una primera tecnología de acceso por radio (RAT), y enviar la solicitud de llamada de emergencia que contiene la referencia de localización al SP OTT 150 por medio de una segunda red de acceso perteneciente a un segundo operador de red y/o conforme a una segunda RAT. De ese modo, la referencia de localización se puede compartir y/o puede ser válida para redes de acceso múltiple, múltiples RAT y/o múltiples operadores de red y puede posibilitar que el UE 200 use la misma referencia de localización después del traspaso a una nueva RAT o a una nueva red y/o cuando accede a varias redes o varias RAT al mismo tiempo. Por ejemplo, el UE 200 podría obtener la referencia de localización desde una estación base u otro nodo de servicio (por ejemplo, una MME) perteneciente a una red de acceso celular perteneciente a un operador de red A, y enviar la solicitud de llamada de emergencia, incluyendo la referencia de localización, a un punto de acceso wifi en una red de acceso WLAN perteneciente a un operador de red B (donde el operador A puede o no ser el mismo que el operador B), que reenviaría la solicitud de llamada de emergencia al SP OTT 150.

[0068] En 216A, el SP OTT 150 envía una solicitud de localización (o una solicitud de desrreferencia de localización), que incluye la referencia de localización recibida desde el nodo de red de acceso 240 en 214A, al servidor de localización 170. El SP OTT 150 puede identificar el servidor de localización 170 (por ejemplo, identificar una dirección o un nombre de ruta para el servidor de localización 170) del contenido de la referencia de localización recibida en 214A. El servidor de localización 170 puede verificar que la referencia de localización recibida en 216A sea válida verificando que la referencia de localización corresponde a una referencia de localización previamente asignada por el servidor de localización 170 (por ejemplo, asignada como parte del bloque 208A si se produce el bloque 208A). Por ejemplo, el servidor de localización 170 puede verificar que la referencia de UE en la referencia de localización se asignó previamente por el servidor de localización 170 para identificar el UE 200. De forma alternativa, si se asignó la referencia de localización recibida en 216A por el nodo de red de acceso 240 y no por el servidor de localización 170 (por ejemplo, tal como se produce si el bloque 208A no está presente), el servidor de localización 170 puede verificar que el nodo de red de acceso 240 haya asignado la referencia de localización al verificar cualquier firma digital, si está presente en la referencia de localización, y/o al descifrar la parte de referencia de UE de la referencia de localización y verificando que la parte de referencia de UE descifrada se ajusta correctamente a cualquier regla de formato o codificación para una referencia de UE válida.

[0069] En 218A, el servidor de localización 170 (o un GMLC asociado con o conectado al servidor de localización 170 en el caso de que el servidor de localización 170 sea una LRF) puede enviar una solicitud de localización al nodo de red de acceso 240 para la localización del UE 200 y puede incluir una identificación para el UE 200 en la solicitud de localización que puede ser (i) una identificación para el UE 200 recibida anteriormente en 208A si se produce 208A y el servidor de localización 170 había asignado la referencia de localización recibida en 216A o (ii) parte o la totalidad de una referencia de UE o el UE descifrado referenciado recibido como parte de una referencia de localización en 216A si el nodo de red de acceso 240 en lugar del servidor de localización 170 hubiera asignado la referencia de localización. A continuación, el nodo de red de acceso 240 puede obtener una estimación de localización para el UE 200 (como se identifica por el servidor de localización 170 en 218A) desde otra entidad (no mostrada en la FIG. 2A). Por ejemplo, el nodo de red de acceso 240 puede solicitar una estimación de localización desde otro servidor de localización (por ejemplo, el E-SMLC 172) u otra entidad con capacidad de localización (por ejemplo, la RAN 120) o desde una estación base o AP que da servicio al UE 200, De forma alternativa, el nodo de red de acceso 240 ya puede tener información de localización para el UE 200 por sí mismo (por ejemplo, si el nodo de red de acceso 240 es una estación base o AP wifi que da servicio al UE 200). A continuación, el nodo de red de acceso 240 puede devolver la estimación de localización para el UE 200 al servidor de localización 170 (o a un GMLC asociado con o conectado al servidor de localización 170 en el caso de que el servidor de localización 170 sea una LRF) como parte de 218A. En algunos modos de realización, el bloque 218a se puede producir cuando el servidor de localización 170 emplea una solución de localización del plano de control para obtener la localización del UE 200.

[0070] En lugar de, o además de, consultar en el nodo de red de acceso 240 la localización del UE 200 en 218A, el servidor de localización 170 puede consultar el UE 200 directamente en 222A. Por ejemplo, 222A se puede producir si el servidor de localización 170 es una SLP SUPL, o una LRF conectada a o asociada con una SLP, donde la SLP inicia una sesión de localización del plano de usuario SUPL en 222A con el UE 200 para obtener mediciones relacionadas con la localización desde el UE 200 (por ejemplo, mediciones de satélites GPS o GNSS y/o mediciones de estaciones base y/o AP en la red de acceso para el UE 200) que el servidor de localización 170 puede usar para determinar una localización para el UE 200. Por ejemplo, el UE 200 puede proporcionar mediciones de GPS y de diferencia de tiempo de llegada observada (OTDOA) al servidor de localización 170. OTDOA es un procedimiento de multilateración en el que el UE 200 mide la diferencia de tiempo entre señales específicas de pares de estaciones base e informa las diferencias de tiempo medidas al servidor de localización 170, que a continuación calcula la localización del UE 200. De forma alternativa, el servidor de localización 170 (o una SLP asociada con o conectada al servidor de localización 170 en el caso de que el servidor de localización 170 sea una LRF) puede iniciar una sesión SUPL con el UE 200 en 222A para obtener una localización del UE 200 desde el UE 200 en el que el UE 200 obtiene la localización de mediciones relacionadas con la localización, tales como mediciones de GPS, GNSS y/u OTDOA. En 224A, el servidor de localización 170 envía la localización del UE 200, como se obtuvo en 218A y/o en 222A, al SP OTT 150. En algunos modos de realización, el SP OTT 150 y el servidor de localización 170 pueden emplear uno de SIP, HELD o MLP en 216A y 224A para solicitar y devolver la localización del UE 200. En algunos de estos modos de realización donde se usa SIP o HELD, el uso de SIP o HELD se puede definir como parte de la referencia de localización.

[0071] Los flujos de mensajes en de 216A a 224A se pueden producir en los tiempos ilustrados en la FIG. 2A para posibilitar que el SP OTT 150 obtenga la localización del UE 200 para ayudar al enrutamiento de la llamada de emergencia (por ejemplo, al determinar un PSAP 180 con una cobertura de servicios de emergencia que incluya la localización del UE 200) y/o para proporcionar la localización del UE 200 a la ESInet 160 o el PSAP 180. Los flujos de mensajes en de 216A a 224A son opcionales porque se pueden producir, de forma alternativa, o adicionalmente, después de que se configura la llamada de emergencia iniciada en 204A (es decir, después de 228A) si el SP OTT 150 recibe una solicitud de localización para el UE 200 desde el PSAP 180 y necesita consultar el servidor de localización 170 para obtener y devolver la localización actual del UE 200 (no mostrado en la FIG. 2A). Además, se pueden producir flujos de mensajes análogos a de 216A a 224A (en lugar de o además de los flujos de mensajes en de 216A a 224A) para posibilitar que la ESInet 160 o el PSAP 180 soliciten directamente la localización del UE 200 desde el servidor de localización 170. Estos flujos de mensajes análogos pueden ser idénticos o casi idénticos a de 216A a 224A, excepto que la ESInet 160 o el pSa P 180 pueden reemplazar al SP OTT 150 en los flujos de mensajes en lo que respecta a enviar la solicitud de localización en 216A y recibir la respuesta de localización en 224A.

[0072] Volviendo a la llamada de servicio de emergencia mostrada en la FIG. 2A, en 226A, el SP OTT 150 enruta la llamada de emergencia a la ESInet 160 apropiada, o posiblemente a un SR 160 si el SP OTT convierte la llamada en una llamada de emergencia CS. La ESInet 160 (o un SR 160) enruta la llamada de emergencia al PSAP 180 apropiado. Las solicitudes de llamada de emergencia enviadas en 226A pueden incluir la referencia de localización del Ue 200 obtenida en 214A. El SP OTT 150 puede usar la localización del UE 200 obtenido en 224A, si se realiza, para enrutar la llamada de emergencia iniciada en 204A a la ESInet 160 apropiada (o al SR 160). La ESInet 160 puede usar la referencia de localización del UE 200 recibida en la solicitud de llamada de emergencia para obtener una localización para el UE 200 desde el servidor de localización 170 realizando etapas análogas a de 216A a 224A como ya se ha descrito. A continuación, la ESInet 160 puede usar esta localización obtenida para enrutar la llamada de emergencia al PSAP 180 apropiado.

[0073] En 228A, las diversas entidades de red (por ejemplo, el UE 200, el SP OTT 150, la ESInet 160 y el PSAP 180) realizan el resto del establecimiento de la llamada de emergencia. En 232A, el PSAP 180 envía una solicitud de localización, incluyendo la referencia de localización recibida en 226A, al servidor de localización 170. El servidor de localización 170 usa la referencia de localización para buscar la localización del UE 200 (por ejemplo, buscar la localización obtenida previamente en 218A y/o 222A) y responde con la localización del UE 200. De forma alternativa, el servidor de localización 170 puede obtener la localización del UE 200 realizando etapas (no mostradas en la FIG.

2A) que son las mismas que las ilustradas en 218A y/o 222A.

[0074] En referencia de nuevo a la FIG. 1B, la FIG. 2B ilustra interacciones específicas de las entidades ilustradas en la FIG. 1B para proporcionar una localización por referencia para una llamada de emergencia OTT de acuerdo con los modos de realización descritos en el presente documento. Las interacciones en la FIG. 2B son similares a las descritas para la FIG. 2A, pero se refieren específicamente a un UE 200 con acceso LTE. Por el contrario, las interacciones descritas en asociación con la FIG. 2A se pueden aplicar a un UE 200 con cualquier tipo de acceso inalámbrico o por cable, incluyendo, pero sin limitarse a, un acceso LTE.

[0075] En 202B, el UE 200 se conecta a una red de servicio con capacidad LTE y, como parte del procedimiento de conexión, envía una solicitud de conexión NAS a la MME 142 de servicio. La solicitud de conexión NAS incluye una solicitud de una referencia de localización en algunos modos de realización. En 204B, la MME 142 puede enviar opcionalmente una solicitud de referencia de localización al GMLC/SLP 170. El GMLC/SLP 170 puede ser un GMLC si la localización del UE 200 se va a obtener usando una solución de localización del plano de control, puede ser una SLP si la localización del UE 200 se va a obtener usando SUPL, puede ser un GMLC y una SLP combinados si cualquiera o ambos de la localización del plano de control y la SUPL se van a usar para obtener una localización para el UE 200, o puede ser una LRF con una conexión a o una asociación con un GMLC y/o una SLP. Cuando se realiza 204B, la MME 142 actúa como un proxy para obtener la referencia de localización del GMLC/SLP 170 en nombre del UE 200. Si bien esto añade una nueva interfaz entre la MME 142 y el GMLC/SLP 170, evita la necesidad de que el UE 200 obtenga la referencia de localización del GMLC/SLP 170 y evita la necesidad de que el GMLC/SLp 170 autentique el UE 200 como parte de una solicitud del UE 200 para obtener una referencia de localización.

[0076] La solicitud/respuesta en el bloque 204B puede usar una conexión segura entre el GMLC/SLP 170 y la MME 142 que posibilita que el GMLC/SLP 170 se dé cuenta de que una MME (por ejemplo, perteneciente al mismo operador o SP que el GMLC/SLP 170) está solicitando la referencia de localización. La conexión segura entre el GMLC/SLP 170 y la MME 142 puede hacer uso de una relación de confianza entre el GMLC/SLP 170 y la MME 142, por ejemplo, una relación en base a que la MME 142 y el GMLC/SLP 170 pertenecen al mismo SP o al mismo operador de red, y puede emplear credenciales de seguridad preconfiguradas en cada entidad para posibilitar el establecimiento de la conexión segura. A continuación, el GMLC/SLP 170 puede asignar y devolver una referencia de localización (por ejemplo, que puede incluir una referencia de UE que es local para el GMLC/SLP 170) que más adelante permitirá que el GMLC/SLP 170 proporcione una localización para el UE 200 a otra entidad, por ejemplo, en los bloques 214B y 232B descritos a continuación. En algunos modos de realización, la MME 142 y el GMLC/SLP 170 pueden usar uno de SIP, HELD o el protocolo de localización móvil (MLP) definido por OMA para solicitar y devolver la referencia de localización en 204B.

[0077] En 206B, la MME 142 envía la referencia de localización obtenida desde el GMLC/SLP 170 al UE 200 en un mensaje de aceptación de conexión NAS. La solicitud de conexión NAS en 202B y la aceptación de conexión NAS en 206B pueden ser como se define en la TS 23.401 y la TS 24.301 de 3GPP, con la adición de un parámetro de solicitud de referencia de localización en una solicitud de conexión NAS y/o un parámetro de referencia de localización en una aceptación de conexión NAS. En algunos modos de realización, los bloques 204B y 206B solo se pueden realizar cuando la solicitud de conexión NAS en 202B contiene una solicitud de una referencia de localización. En otros modos de realización, los bloques 204B y 206B se pueden realizar cuando la solicitud de conexión NAS en 202B no contiene una solicitud de una referencia de localización.

[0078] De forma alternativa, en lugar de consultar en el GMLC/SLP 170 la referencia de localización del UE 200 en 204B, la MME 142 puede asignar la referencia de localización por sí misma sin la participación del GMLC/SLP 170 como se describe anteriormente. La MME 142 puede incluir la dirección conocida del GMLC/SLP 170 en la referencia de localización, una identificación del protocolo que se va a usar para consultar el GMLC/SLP 170 desde un cliente y una referencia de UE para identificar el UE 200 (por ejemplo, la dirección IP del UE 200, la IMSI del UE 200, la TMSI del UE 200, una dirección local para el UE 200 asignada por la MME 142, una dirección de la MME 142 o cualquier combinación de las mismas). La MME 142 puede cifrar la referencia de UE para proteger la privacidad del usuario. En este caso, las claves de cifrado serán conocidas por la MME 142 y el GMLC/SLP 170, pero no por otras partes. La MME 142 también puede firmar digitalmente la referencia de localización de modo que el GMLC/SLP 170 conozca que la referencia de localización se asignó por la MME 142, o al menos se asignó por alguna entidad gestionada por el operador o el SP para el GMLC/SLP 170.

[0079] Además de o en lugar de obtener la referencia de localización en 206B, el UE 200 puede obtener la referencia de localización después de que el usuario del UE 200 inicie una llamada de emergencia (208B), periódicamente mientras el UE 200 está conectado a la MME 142, y/o durante alguna otra interacción entre el UE 200 y la MME 142, como se analiza anteriormente con referencia a la FIG. 2A.

[0080] En lugar de enviar la solicitud de conexión NAS en 202B y la aceptación de conexión NAS en 206B para obtener una referencia de localización, el UE 200 puede enviar una solicitud de actualización de área de seguimiento NAS en 202B y, después de obtener o asignar una referencia de localización (por ejemplo, en 204B), la MME 142 puede enviar una aceptación de actualización de área de seguimiento NAS en 206B que contiene la referencia de localización. La solicitud de actualización de área de seguimiento NAS en 202B y la aceptación de actualización de área de seguimiento NAS en 206B pueden ser como se define en la TS 23.401 y la TS 24.301 de 3GPP con la adición de una solicitud de referencia de localización en una solicitud de actualización de área de seguimiento NAS y/o una referencia de localización en una aceptación de actualización de área de seguimiento NAS.

[0081] En algunos modos de realización, antes de enviar la referencia de localización al UE 200 en una aceptación de conexión NAS o una aceptación de actualización de área de seguimiento NAS en 206B, la MME 142 puede autenticar la identidad del UE 200 (no mostrado en la FIG. 2B). Dicha autenticación puede garantizar que la referencia de localización se devuelva en 206B al UE 200 correcto. Además, dicha autenticación del UE 200 puede formar una parte normal de la compatibilidad de una conexión de UE 200 o una actualización de área de seguimiento de UE 200 por el UE 200 y la MME 142, y puede no añadir efectos adicionales al UE 200 o la MME 142 únicamente con el propósito de devolver una referencia de localización en 206B.

[0082] Para redes de acceso que son compatibles con GSM o UMTS en lugar de LTE, el procedimiento de la FIG.

2B se puede usar para la compatibilidad de una llamada de emergencia OTT como se describe en el presente documento para una red LTE pero con el E-SMLC 172 reemplazado por una RAN GSM o UMTS y la MME 142 reemplazada por un nodo de compatibilidad de GPRS de servicio (SGSN). En ese caso, el UE 200 enviaría una solicitud de conexión GPRS o bien una solicitud de actualización de área de enrutamiento GPRS al SGSN en 202B que puede contener una solicitud de una referencia de localización, y el SGSN respondería con una aceptación de conexión GPRS o bien una aceptación de actualización de área de enrutamiento GPRS, respectivamente, en 206B. En este caso, la solicitud de conexión GPRS o la solicitud de actualización de área de enrutamiento GPRS en 202B y la aceptación de conexión GPRS o la aceptación de actualización de área de enrutamiento GPRS en 206B pueden ser como se define en la TS 24.008 de 3GPP, con la adición de una solicitud de referencia de localización en una solicitud de conexión GPRS o solicitud de actualización de área de enrutamiento GPRS y/o una referencia de localización en una aceptación de conexión GPRS o solicitud de actualización de área de enrutamiento GPRS.

[0083] En 208B, el usuario del UE 200 realiza una llamada de emergencia por medio de una aplicación OTT, tal como Skype™, instalada en el UE 200. En 212B, el UE 200 envía una solicitud de llamada de emergencia, incluyendo la referencia de localización obtenida en 206B, al SP OTT 150. Por ejemplo, el UE 200 puede enviar la solicitud de llamada de emergencia al SP OTT 150 por medio del eNB 124, la S-GW 146, la PDG 148 e Internet 175. En un modo de realización, el UE 200 podría obtener la referencia de localización desde la MME 142 como se describe anteriormente y enviar la solicitud de llamada de emergencia que contiene la referencia de localización al SP OTT 150 en 212B por medio de una red de acceso diferente a la red de acceso que contiene la MME 142 y que está asociada con el GMLC/SLP 170. Por ejemplo, la red de acceso diferente puede ser compatible con una RAT diferente a LTE (por ejemplo, wifi). De ese modo, la referencia de localización se puede compartir entre diferentes redes de acceso y posiblemente entre diferentes RAT en el UE 200. Por ejemplo, el UE 200 podría enviar la solicitud de llamada de emergencia, incluyendo la referencia de localización, al SP OTT 150 por medio de un punto de acceso a WLAN.

[0084] En 214B, el SP OTT 150 envía una solicitud de localización, incluyendo la referencia de localización obtenida en 212b , al GMLC/SLP 170. El SP OTT 150 puede identificar el Gm Lc /SLP 170 (por ejemplo, identificar una dirección o un nombre de ruta para el GMLC/SLP 170) del contenido de la referencia de localización recibida en 212B. El GMLC/SLP 170 puede verificar que la referencia de localización recibida en 214B sea válida verificando que la referencia de localización corresponde a una referencia de localización previamente asignada por el GMLC/SLP 170 (por ejemplo, asignada como parte del bloque 204B si se produce el bloque 204B). Por ejemplo, el GMLC/SLP 170 puede verificar que la referencia de UE en la referencia de localización se asignó previamente por el GMLC/SLP 170 para identificar el UE 200. De forma alternativa, si la referencia de localización recibida en 214B se asignó por la MME 142 y no por el GMLC/SLP 170 (por ejemplo, como se produce si el bloque 204B no está presente), el GMLC/SLP 170 puede verificar que la MME 142 haya asignado la referencia de localización al (i) verificar cualquier firma digital, si está presente en la referencia de localización, (ii) descifrar la parte de referencia de UE de la referencia de localización y verificar que la parte de referencia de UE descifrada se ajusta correctamente a cualquier regla de formato o codificación para una referencia de UE válida, y/o (iii) verificar que la referencia de localización se ajusta a las reglas de formato conocidas (por ejemplo, contiene una referencia de UE en la que su longitud y/o contenido de caracteres se ajusta a las reglas conocidas).

[0085] Si se está utilizando la solución de localización de plano de control (lo que significa que el GMLC/SLP 170 es o contiene un GMLC o es una LRF conectada a o asociada con un GMLC), entonces se realizan los flujos de mensajes en de 216B a 226B (como se indica por el recuadro de líneas discontinuas). Específicamente, en 216B, el GMLC 170 envía una solicitud de localización para el UE 200 a la MME 142. El GMLC 170 puede determinar la dirección o identidad de la MME 142 para enviar correctamente la solicitud en 216B del contenido de la referencia de UE en la referencia de localización recibida en 214B (por ejemplo, si la MME 142 o el GMLC 170 incluían la dirección o identidad de la MME 142 en la referencia de localización). De forma alternativa, el GMLC 170 puede consultar en un servidor de abonado doméstico (HSS) para el UE 200 la dirección de la MME 142 (no mostrada en la FIG. 2B) usando un identificador (por ejemplo, la IMSI) para el UE 200 recibido en 214B en la parte de referencia de UE de la referencia de localización. El GMLC incluye una identidad para el UE 200 en la solicitud de localización enviada en 216B que se incluyó en la parte de referencia de UE de la referencia de localización recibida en 214B o bien se recibió previamente en 204B y se almacenó por el GMLC 170 en el caso de que el GMLC 170 asignara la referencia de localización.

[0086] En 218B, la MME 142 envía una solicitud de localización para el UE 200 al E-SMLC 172 y puede incluir cualquier identidad para el UE 200 recibida en 216B o ya conocida por la MME 142. En 222B, el E-SMLC 172 puede iniciar una sesión de localización de protocolo de posicionamiento LTE (LPP) de 3GPP con el UE 200 y, como parte de esta sesión, puede enviar una solicitud de localización al UE 200, que responde con información de localización. La información de localización proporcionada por el UE 200 puede comprender mediciones de localización por GPS, mediciones de localización por GNSS, mediciones OTDOA, mediciones de ID de célula mejorada (ECID), mediciones de localización por wifi, mediciones de localización por Bluetooth (BT) o cualquier combinación de estas, o puede contener una estimación de localización para el UE 200 obtenida por el UE 200. Cuando la información de localización comprende mediciones de localización pero no una estimación de localización, el E-SMLC 172 puede calcular una estimación de localización para el UE 200 de estas mediciones. En lugar de, o además de, 222B, el E-SMLC 172 puede enviar una solicitud de localización (no mostrada en la FIG. 2B) a un eNB de servicio para el UE 200 (por ejemplo, el eNB 124 en la FIG. 2B) para obtener una estimación de localización o mediciones a partir de las que el E-SMLC 172 puede determinar una estimación de localización para el UE 200. En 224B, el E-SMLC 172 puede enviar una respuesta de localización, incluyendo la localización del UE 200, a la MME 142. En 226B, la MME 142 envía una respuesta de localización, que incluye la localización del UE 200 recibida en 224B, al GMLC 170.

[0087] De forma alternativa, si se está utilizando la solución de localización del plano de usuario SUPL (lo que significa que el GMLC/SLP 170 es o contiene una SLP o es una LRF asociada con o conectada a una SLP), entonces los flujos de mensajes pueden no realizarse en de 216B a 226B, y en su lugar (o posiblemente además), se establece una sesión SUPL entre la SLP 170 y el UE 200 en 228B. La SLP 170 puede obtener la localización del UE 200 por medio de la sesión SUPL (por ejemplo, de las mediciones por GPS, GNSS, OTDOA, ECID, wifi y/o BT obtenidas por el UE 200). Los flujos de mensajes en de 216B a 228B se ilustran con líneas discontinuas porque en algunos modos de realización se realizan los flujos de mensajes en de 216B a 226B o bien se realiza el flujo de mensajes en 228B, pero no ambos. En 232B, el GMLC/SLP 170 envía la estimación de localización del UE 200 al SP OTT 150.

[0088] Los flujos de mensajes en de 214B a 232B (por ejemplo, (a) de 214B a 226B y 232B o bien (b) 214B, 228B y 232B) se pueden producir en los tiempos ilustrados en la FIG. 2B para posibilitar que el SP OTT 150 obtenga la localización del UE 200 para ayudar a enrutar la llamada de emergencia (por ejemplo, determinando un PSAP 180 con una cobertura de servicios de emergencia que incluya la localización del UE 200) y/o para proporcionar la localización del UE 200 a la ESInet 160 o el PSAP 180. Los flujos de mensajes en de 214B a 232B se pueden producir de forma alternativa, o adicionalmente, después de configurar la llamada de emergencia iniciada en 208B (es decir, después de 236B) si el SP OTT 150 recibe una solicitud de localización para el UE 200 desde el PSAP 180 y necesita consultar el GMLC/SLP 170 para obtener y devolver la localización actual del UE 200 (no mostrado en la FIG. 2B). Además, se pueden producir flujos de mensajes análogos a de 214B a 232B (en lugar de o además de los flujos de mensajes en de 214B a 232B) para posibilitar que la ESInet 160 o el PSAP 180 soliciten directamente la localización del UE 200 desde el GMLC/SLP 170. Estos flujos de mensajes análogos pueden ser idénticos o casi idénticos a de 214B a 232B, excepto que la ESInet 160 o el pSa P 180 pueden reemplazar al SP OTT 150 en los flujos de mensajes en lo que respecta a enviar la solicitud de localización en 214B y recibir la respuesta de localización en 232B.

[0089] Volviendo a la llamada de servicio de emergencia mostrada en la FIG. 2B, en 234B, el SP OTT 150 enruta la llamada de emergencia a la ESInet 160 apropiada o posiblemente a un SR 160 si el SP OTT 150 necesita convertir la llamada en una llamada de emergencia CS. A continuación, la ESInet 160 (o un SR 160) enruta la llamada de emergencia al PSAP 180 apropiado. Estas solicitudes de llamada de emergencia enviadas en 234B pueden incluir la referencia de localización del UE 200 obtenida en 212B. El SP OTT 150 puede usar la localización del UE 200 obtenida en 232B, si se realiza, para enrutar la llamada de emergencia iniciada en 208B a la ESInet 160 apropiada (o el SR 160). La ESInet 160 puede usar la referencia de localización del UE 200 recibida en la solicitud de llamada de emergencia para obtener una localización para el UE 200 desde el GMLC/SLP 170 realizando bloques análogos a de 214B a 232B como se describe anteriormente. A continuación, la ESInet 160 puede usar esta localización obtenida para enrutar la llamada de emergencia al PSAP 180 apropiado.

[0090] En 236B, las diversas entidades de red (por ejemplo, el UE 200, el SP OTT 150, la ESInet 160 y el PSAP 180) realizan el resto del establecimiento de la llamada de emergencia. En 238B, el PSAP 180 envía una solicitud de localización, que incluye la referencia de localización recibida en 234B, al GMLC/SLP 170. El GMLC/SLP 170 usa la referencia de localización para buscar la localización del UE 200 (por ejemplo, buscar la localización obtenida previamente en 226B y/o 228B) y responde con la localización del UE 200. De forma alternativa, el GMLC/SLP 170 puede obtener la localización del UE 200 realizando bloques (no mostrados en la FIG. 2B) que son los mismos que los ilustrados en de 216B a 226B y/o 228B.

[0091] La FIG. 3 ilustra una arquitectura ejemplar para proporcionar servicios de emergencia sobre un proveedor de servicios OTT que muestra soluciones de localización alternativas de acuerdo con al menos un aspecto de la divulgación. La arquitectura ilustrada en la FIG. 3 incluye un UE 300 (que puede corresponder al UE 200), una red de acceso 320 (que puede corresponder a la RAN 120), una red central de paquetes 340 (que puede corresponder a la red central 140), un SP OTT 350 (que puede corresponder al SP OTT 150), una ESInet/SR 360 (que puede corresponder a la ESInet/SR 160), un servidor de localización de emergencia (ELS) 370 (que puede corresponder al E-SMLc 172, el GMLC/SLP 170 o el servidor de localización 170), una red IP 375 (que puede corresponder a Internet 175), una red doméstica 385 que puede ser una red doméstica para el UE 300 y un PSAP 380 (que puede corresponder al PSAP 180).

[0092] La FIG. 3 muestra diversas soluciones alternativas, marcadas S1, S2, S3, S3a, S3b, S4 y S5, para transferir la localización de un UE 300 que ha pedido un servicio de emergencia (por ejemplo, una llamada de voz de emergencia, una sesión de mensajes de texto de emergencia) hacia o desde un SP OTT 350. Para cada solución, el SP OTT puede ser responsable de la petición y el enrutamiento de una llamada de servicio de emergencia a la red de servicios de emergencia (por ejemplo, a un ESInet o directamente a un PSAP).

[0093] Para la solución S1, el UE 300 puede impulsar una localización adecuada para su enrutamiento (y posiblemente su envío) al SP OTT 350. La localización puede ser una localización por valor (LbyV) o bien una localización por referencia (LbyR) y se puede obtener desde un servidor de localización (por ejemplo, el ELS 370) o se puede determinar únicamente por el UE 300 en el caso de localización por valor. En el caso de localización por referencia, el UE 300 puede enviar una solicitud de una referencia de localización al servidor de localización, y a continuación enviar la referencia de localización recibida (en forma de un URI de localización) al SP OTT 350. A continuación, el SP OTT 350 puede realizar una desrreferencia (por ejemplo, usando HELD) solicitando un valor de localización al servidor de localización (por ejemplo, el ELS 370) que asignó el URI de localización.

[0094] Con la solución S2, el SP OTT 350 puede consultar en el UE 300 la localización del UE 300, por ejemplo, después de recibir una petición de llamada de servicio de emergencia desde el UE 300 en un mensaje de INVITACIÓN SIP. La consulta puede usar señalización en servicio (por ejemplo, una solicitud por medio de un mensaje de INFORMACIÓN SIP) o señalización fuera de servicio (por ejemplo, una solicitud por medio de una ruta de señalización o datos separada). El UE 300 puede devolver la localización al SP OTT 350 usando medios análogos a la solicitud, por ejemplo, señalización en llamada si la solicitud usó señalización en llamada. La información de localización que se devuelve puede ser la misma que para la solución S1, por ejemplo, una LByV o bien una LbyR.

[0095] Con la solución S3, después de recibir una petición de llamada de servicio de emergencia desde el UE 300 (por ejemplo, en una INVITACIÓN SIP), el SP OTT 350 puede consultar el ELS 370 que puede estar en, o asociado con, la red de acceso 320 o la PCN 340, por ejemplo. El SP OTT 350 puede en algunos casos determinar la red de acceso 320, la PCN 340 y/o el ELS 370 usando la dirección IP del UE o un identificador para la red de acceso 320 o la PCN 340 proporcionada por el UE 300 al SP OTT 350. Por ejemplo, en el caso de la dirección IP, se pueden configurar alcances conocidos de direcciones IP o subcampos particulares en una dirección IP por el SP OTT 350 (por ejemplo, en un servidor de llamadas) y correlacionarlos con redes de acceso y PCN particulares. En las variantes S3a y S3b de la solución S3, el SP OTT 350 puede enviar una solicitud de localización para el UE 300 a la red de acceso 320 y la PCN 340, respectivamente, para reenviarla a un servidor de localización (por ejemplo, el ELS 370).

[0096] Con la solución S4, después de recibir una petición de llamada de servicio de emergencia desde el UE 300 (por ejemplo, en una INVITACIÓN SIP), el SP OTT 350 puede consultar en un servidor de localización o servicio de localización en la red doméstica 385 el UE 300. Se puede hacer referencia al UE 300 usando una identidad pública global (por ejemplo, SIP URI, MSISDN, etc.). El SP OTT 350 puede determinar la red doméstica 385 y el servidor de localización o servicio de localización en la red doméstica 385 usando la identidad pública global. La red doméstica 385 puede conocer la localización general del UE 300 (por ejemplo, de información recibida desde la PCN 340 para la compatibilidad de itinerancia) y/o puede localizar el UE 300 directamente (por ejemplo, usando SUPL).

[0097] Con la solución S5, un PSAP 380 o la ESInet/SR 360 puede consultar en el SP OTT 350 una localización del UE 300 necesaria para el enrutamiento o el envío. El SP OTT 350 puede usar una de las otras alternativas de solución (S1, S2, S3, S3a, S3b, S4) para obtener una localización por valor (por ejemplo, localización geográfica o localización cívica) para el UE 300 o una localización por referencia para el UE 300 y a continuación puede devolver esto al PSAP 380 o la ESInet/SR 360. Si se devuelve una localización por referencia, el PSAP 380 o la ESInet/SR 360 necesitaría consultar el servidor de localización (por ejemplo, el ELS 370) que asignó la localización por referencia en la red de acceso 320 o la PCN 340 para obtener la localización del UE 300.

[0098] Las soluciones de localización por referencia descritas previamente en asociación con las FIGS. 1A, 1B, 2A y 2B se pueden emplear en combinación con las soluciones S1, S2 y S5 descritas previamente para la FIG. 3. Estas soluciones de localización por referencia pueden reducir los efectos para un UE tal como el UE 200 y el UE 300 y para un servidor de localización tal como el servidor de localización 170 y el ELS 370 para obtener una referencia de localización como se describe previamente. Sin embargo, las soluciones pueden no abordar otros aspectos de la compatibilidad de llamadas de emergencia de un SP OTT 150 o un SP OTT 350, tales como enrutar una llamada de emergencia a un PSAP (por ejemplo, un PSAP 180 o un PSAP 380) y posibilitar que un PSAP solicite y obtenga una localización para un UE 200 o un UE 300 que se puede usar para el envío del PSAP. Para abordar estos otros aspectos de la compatibilidad de llamadas de emergencia, a continuación se describen otras soluciones de localización que pueden diferir en algunos sentidos de las soluciones de localización descritas en asociación con las FIGS. 1A-2B. Estas otras soluciones de localización pueden proporcionar extensiones a las soluciones S1 y S2 descritas previamente, por ejemplo, que pueden posibilitar que se proporcione información relacionada con la localización al SP OTT 350 además de o en lugar de una LbyV o una LByR. Para las soluciones S1 y S2 de la FIG. 3, se supone que el servidor de localización (ELS) 370 se usa para proporcionar una localización por valor o una localización por referencia para el UE 300. El ELS 370 puede corresponder a uno de varios servidores de localización diferentes en diferentes arquitecturas de red (por ejemplo, el ELS 370 podría ser un E-SMLC 172, un GMLC 170, un SLP 170 o una LRF). Asociar el ELS 370 con una LRF puede ser en particular útil puesto que una LRF se define para la compatibilidad de una interfaz externa para la desrreferencia de localización (por ejemplo, en la TS 23.167 de 3GPP y en la norma ATIS-0700015 de ATIS) y podría tener acceso a la capacidad de determinación de localización dentro de la PCN 340 y/o la AN 320 usando una solución de localización del plano de control y/o una solución de localización del plano de usuario.

[0099] Las soluciones S1 y S2 de la FIG. 3 se pueden considerar complementarias entre sí y ambas podrían ser compatibles. Por ejemplo, la solución S1 se puede usar cuando el UE 300 detecte que un usuario está pidiendo una llamada de emergencia y tiene tiempo para obtener alguna información de localización antes de enviar una solicitud de llamada de emergencia al SP OTT 350. La solución S2 se puede usar cuando el UE 300 no detecte que un usuario está pidiendo una llamada de emergencia o no tiene tiempo suficiente para obtener información de localización antes de enviar una solicitud de servicio de emergencia al SP OTT 350.

[0100] Es posible que las mejoras para las soluciones S1 y S2 de la FIG. 3 necesiten resolver varios conjuntos de problemas cuando son compatibles con la localización y el enrutamiento por un MNO de servicio en nombre de una llamada de emergencia que se envió inicialmente por un UE 300 a un SP OTT 350. Estos diversos conjuntos de problemas se describen y ejemplifican a continuación.

Conjunto de problemas 1: PSAP heredados

[0101] Puede haber problemas asociados con la compatibilidad de la localización y el enrutamiento para una llamada de emergencia que necesita enviarse a un PSAP heredado 380, cuando el PSAP heredado 380 no es compatible con una ESInet 360 (por ejemplo, sino que en su lugar puede ser compatible con un SR 360). Un problema puede ser que un PSAP heredado 380 no pueda recuperar una localización para un UE 300 desde un SP OTT 350 usando la interfaz E2 definida en la norma conjunta TIA y ATIS J-STD-036, que se puede producir si el SP OTT 350 está en un país diferente al UE 300 y el PSAP 380 o si el PSAP 380 no tiene una relación de comunicación con el SP OTT 350. Téngase en cuenta que la interfaz E2 se usa comúnmente para la recuperación de localización por un PSAP heredado en el caso de una llamada de emergencia iniciada por medio de una red inalámbrica pública en América del Norte donde la llamada de emergencia se enruta a un PSAP heredado. Un segundo problema puede ser que no sea posible que un SP OTT 350 pueda enviar una LbyV a un PSAP heredado 380 como parte de la señalización de llamada (por ejemplo, si la llamada de emergencia para un UE 300 se enruta a través de un SR 360 que usa un tronco MF para alcanzar el PSAP 380). Un tercer problema puede ser que un PSAP heredado 380 (o una ALI asociada con un PSAP heredado 380) normalmente puede no ser compatible con la desrreferencia de una LbyR en el caso de que el SP OTT 350 proporcione una LbyR en lugar de una LbyV al PSAP 380.

[0102] Los tres problemas anteriores pueden significar que cualquier mejora de las soluciones S1 y S2 en base solo a la provisión de una LbyV o una LbyR a un SP OTT 350 puede no ser compatible con la provisión de una localización que se puede enviar a un PSAP heredado 380, cuando el PSAP heredado 380 no es compatible con una ESInet 360 (por ejemplo, sino que solo es compatible con un SR 360).

Conjunto de problemas 2: localización del plano de control en un MNO de servicio

[0103] Con la solución de localización del plano de control 3GPP para el acceso a LTE o HSPA (por ejemplo, como se define en las TS 23.271, 25.305 y 36.305 de 3GPP), necesita conocerse la identidad de la m Me de servicio o la SGSN de servicio actual, para un UE 300 que está haciendo una llamada de emergencia, en una LRF o un GMLC para enrutar una solicitud de una localización de UE 300 a la MME de servicio o la SGSN de servicio correcta. Para llamadas de emergencia que se establecen por un MNO de servicio sin la participación de un SP OTT (por ejemplo, como se describe en ATIS-0700015), esta información se puede mantener actualizada en la LRF y el GMLC (que se están usando para la compatibilidad de la localización del UE 300 que realiza la llamada de emergencia) por la MME de servicio o la SGSN de servicio cuando el UE 300 establece una conexión de PDN de emergencia o un contexto de PDP de emergencia (por ejemplo, como parte del establecimiento de la llamada de emergencia), y por la MME o la SGSN nueva o previa cuando se produce el traspaso. Sin embargo, para una llamada de emergencia que se establece a través de un SP OTT 350, el MNO de servicio puede no darse cuenta de la llamada de emergencia y, por tanto, la LRF (y el GMLC) puede no mantener actualizada la identidad de la MME de servicio o la SGSN de servicio. Sin esta información, es posible que un GMLC no pueda enrutar una solicitud de localización a la MME de servicio o la SGSN de servicio correcta. Esto significa que cuando se da servicio a una solicitud de desrreferencia de localización para un UE 300 desde un SP OTT 350, es posible que un ELS 370 (por ejemplo, la LRF) no pueda usar una solución del plano de control para obtener la localización del UE 300, excepto posiblemente en el caso de un abonado local cuando el ELS 370 tenga información suficiente para consultar esta información desde un HSS.

Conjunto de problemas 3: localización del plano de usuario en un MNO de servicio

[0104] Cuando un UE 300 accede a un SP OTT 350 por medio de una VPN que es intermedia entre el MNO de servicio (por ejemplo, la PCN 340) y el SP OTT 350, la dirección IP del UE 300 que se ve por el SP OTT 350 se puede haber asignado por la VPN y, por tanto, puede diferir de cualquier dirección IP asignada al UE por el MNO de servicio (por ejemplo, la PCN 340). Si un SLP en el MNO de servicio (por ejemplo, el ELS 370) solo acepta solicitudes de localización entrantes en nombre de los UE con direcciones IP conocidas o asignadas por el MNO de servicio, esto podría prevenir el uso de la localización SUPL por el MNO de servicio si la dirección IP que asignó la VPN se incluye en una solicitud de localización enviada al MNO de servicio (por ejemplo, enviada al ELS 370) por el SP OTT 350. Se puede producir un problema similar para un UE itinerante 300 en el que su dirección IP se asigna por la red doméstica 385 (por ejemplo, donde la pasarela de PDN para el acceso a LTE está en la red doméstica 385). Sin embargo, en este caso, se podría configurar un MNO de servicio (por ejemplo, un SLP en el MNO de servicio) con las direcciones IP (por ejemplo, alcances de direcciones) asignadas por socios de itinerancia, tales como la red doméstica 385, caso en el que el uso de la localización del plano de usuario (por ejemplo, SUPL) todavía podría ser posible.

Conjunto de problemas 4: enrutamiento de una llamada de emergencia a un PSAP

[0105] Si bien es posible que un SP OTT 350 pueda enrutar una llamada de emergencia desde un UE 300 a un PSAP 380 (por ejemplo, por medio de una red IP 375 o por medio de la PSTN) si se conoce la dirección o identidad correcta para el PSAP 380 (por ejemplo, un URL de SIP o DN de teléfono), algunos SP OTT 350 pueden carecer de la capacidad de correlacionar una localización geográfica para un UE 300 con la dirección o identidad de un PSAP 380 en el que su área de servicio incluye la localización de la dirección del UE 300. Por ejemplo, esta falta de capacidad se puede producir si el SP OTT 350 está en un país diferente a tanto el UE 300 como el PSAP 380 y no tiene la capacidad de obtener información de enrutamiento para los PSAP en otros países, por ejemplo, usando el protocolo LoST definido por el IETF. En algunos casos, incluso si la dirección o identidad del PSAP 380 se conoce por el SP OTT 350, puede que no sea posible que el SP OTT 350 reenvíe una llamada de emergencia para un UE 300 al PSAP 380 debido a restricciones en la entrada de llamadas de emergencia en el lado del PSAP 380.

[0106] Los conjuntos de problemas 1 a 4 descritos y ejemplificados anteriormente se pueden resolver por mejoras particulares a las soluciones S1 y S2 mencionadas anteriormente como se describe a continuación.

[0107] La FIG. 4 ilustra una arquitectura ejemplar para la compatibilidad de localización por referencia para servicios de emergencia sobre un proveedor de servicios OTT de acuerdo con al menos un aspecto de la divulgación. La arquitectura ilustrada en la FIG. 4 incluye un UE 400 (que puede corresponder al UE 200 o el UE 300), una red de acceso 420 (que puede corresponder a la RAN 120 o la AN 320), un IMS 440 (que puede corresponder a parte de la red central 140 o parte de la PCN 340), un SP OTT 450 (que puede corresponder al SP OTT 150 o el SP OTT 350), una ESInet 460 con capacidad NENA i3 (que puede corresponder a la ESInet 160 o la ESInet 360), una ESN 462 heredada, Internet 475, una PSTN 485 y un MNO de servicio 490 (que puede corresponder a la CN 140 combinada con la AN 120 o a la PCN 340 combinada con la AN 320). El IMS 440 incluye una LRF 448 (que puede corresponder al servidor de localización 170 o el ELS 370), una MGc F 441, una P-CSCF 442, una E-CSCF 443, una IBc F 444 y una S-CSCF 445. La LRF 448 puede estar conectada a una RDF 446 y un LS 470 (que puede corresponder al servidor de localización 170 o al GMLC/SLP 170). La ESInet i3460 incluye una BCF 464, un ESRP 466, una ECRF 468 y un PSAP 480 con capacidad NENA i3 (que puede corresponder al PSAP 180 o el PSAP 380). La ESN heredada 462 incluye una ALI 461, un SR 463 (que puede corresponder al SR 160 o el SR 360) y un PSAP heredado 482 (que puede corresponder al PSAP 180 o el SAP 380). Las diversas entidades mostradas en la FIG. 4 son bien conocidas en la técnica y se definen en las TS de 3GPP (por ejemplo, las TS 23.401,23.167, 23.228), en la norma ATIS 0700015 y en la norma NENA i3.

[0108] Con la compatibilidad de LbyR normal, mostrada en la FIG. 4 para la solución S1, el UE 400 envía una solicitud de llamada de emergencia 401 al SP OTT 450 que contiene una LbyR. A continuación, el SP OTT 450 desrreferencia la LbyR enviando una consulta de localización 402 a un ELS (por ejemplo, la LRF 448 en el MNO de servicio 490) indicada por la LbyR recibida en la solicitud de llamada de emergencia 401. El ELS (mostrado como una LRF 448 en la FIG. 4) obtiene una localización para el UE 400 y devuelve la información de localización y/o enrutamiento al SP OTT 450. A continuación, el SP OTT 450 enruta la llamada de emergencia al PSAP (el PSAP heredado 482 en el mensaje 403A o bien el PSAP 480 con capacidad NENA i3 en el mensaje 403B) en base a la información de enrutamiento o la localización recibida desde la LRF 448 y que contiene la LByR recibida originalmente. A continuación, el PSAP 480/482 puede enviar una consulta 404A (para el PSAP 482) o 404B (para el PSAP 480) al ELS (por ejemplo, la LRF 448) en un tiempo posterior para una localización que se puede enviar usando la LbyR recibida. Como se analiza para el conjunto de problemas 1 anterior, una consulta de localización 404A puede no ser posible para un PSAP heredado 482 a menos que el PSAP sea compatible con una ESInet.

[0109] La solución de LbyR básica descrita anteriormente en asociación con la FIG. 4 se puede mejorar para las soluciones S1 y S2 de la FIG. 3 para superar los problemas descritos anteriormente para los conjuntos de problemas 2 y 3. Específicamente, se puede dar formato a un URI de localización que se asigna por el MNO de servicio 490 (por ejemplo, por la LRF 448) como una LbyR para un UE 400 para que contenga la siguiente información:

a) una dirección IP local para el UE 400 si el MNO de servicio 490 va a usar la localización del plano de usuario para localizar el UE 400 y si se asignó una dirección IP local al UE 400 por el MNO de servicio 490;

b) una identidad local de una MME de servicio (por ejemplo, la MME 142) o una SGSN de servicio si el MNO de servicio 490 va a usar la localización del plano de control para localizar el UE 400; y

c) una identidad para el UE 400 (por ejemplo, una MSISDN, IMSI o una ID local asignada por la MME o la SGSN de servicio) si el MNO de servicio 490 va a usar la localización del plano de control para localizar el UE 400.

[0110] La información anterior en (a), (b) y (c) se puede incluir como la parte de la LbyR normalmente usada como referencia local para el UE 400 y permitiría la asignación de LbyR por la AN 420 o una PCN en el MNO de servicio 490 en lugar de por un ELS tal como la LRF 448 (por ejemplo, como se describe previamente en asociación con las FIGS. 1A-2B), lo que puede simplificar la implementación. El formato de esta información puede ser específico para el MNO de servicio 490 (por ejemplo, puede no estar estandarizado). Un ELS (por ejemplo, la LRF 448) en el MNO de servicio 490 que recibe un URI de localización de este tipo en una solicitud de desrreferencia, tal como la solicitud 402, para una LbyR de un SP OTT 450 y conoce las reglas de formato para la LbyR puede extraer la información en (a)-(c) anterior y usarla para pedir la localización del plano de control o bien del plano de usuario del UE 400. Un beneficio adicional es que el ELS no necesita mantener información para la llamada de emergencia del UE 400 o bien el UE 400 puede responder a cada solicitud de desrreferencia (por ejemplo, la solicitud 402) en base únicamente a la información incluida en cada dicha solicitud.

[0111] La mejora anterior, como se describe en asociación con la FIG. 4, se denomina en el presente documento "LbyR mejorada" y se ilustra más adelante en el presente documento usando figuras adicionales, pero puede no resolver todos los problemas del conjunto de problemas 2 anterior. Por ejemplo, aunque la LbyR para el UE 400 puede contener la identidad de la MME de servicio actual o la SGSN de servicio actual para el UE 400, la información puede quedar desactualizada cuando el UE 400 se traspasa a una nueva MME o SGSN de servicio, a menos que el UE 400 envíe nueva información (por ejemplo, una nueva LbyR) al SP OTT 450 (por ejemplo, en una INFORMACIÓN SIP), que a continuación la reenvía al PSAP 480 o 482.

[0112] La compatibilidad de IMS es otra mejora de las soluciones S1 y S2 de la FIG. 3 que se puede usar para resolver todos los problemas descritos anteriormente para los conjuntos de problemas 1,2, 3 y 4. Con la compatibilidad de IMS, el MNO de servicio puede ofrecer la compatibilidad como una LRF, como se describe a continuación en asociación con la FIG. 5, o bien como una E-CSCF, como se describe más adelante en asociación con la FIG. 6.

[0113] La FIG. 5 ilustra una arquitectura ejemplar para la compatibilidad de la LRF de IMS para servicios de emergencia sobre un proveedor de servicios OTT de acuerdo con al menos un aspecto de la divulgación. De forma similar a la arquitectura ilustrada en la FIG. 4, la arquitectura ilustrada en la FIG. 5 incluye un UE 500 (que puede corresponder al UE 200, el UE 300 o el UE 400), una red de acceso 520 (que puede corresponder a la rAn 120, la AN 320 o la AN 420), un IMS 540 (que puede corresponder a parte de la red central 140, parte de la PCN 340 o el IMS 440), un SP Ot T 550 (que puede corresponder al SP Ot T 150, el SP OTT 350 o el Sp OTT 450), una ESInet 560 con capacidad NENA i3 (que puede corresponder a la ESInet 160, la ESInet 360 o la ESInet 460), una ESN heredada 562, Internet 575, una PSTN 585 y un MNO de servicio 590 (que puede corresponder a la CN 140 combinada con la AN 120, la PCN 340 combinada con la AN 320 o el MNO 490). El IMS 540 incluye una LRF 548 (que puede corresponder al servidor de localización 170, el ELS 370 o la LRF 448), una MGCF 541, una P-CSCF 542, una E-CSCF 543, una IBCF 544 y una S-CSCF 545. El LRF 548 se puede conectar a una RDF 546 y un LS 570 (que puede corresponder al servidor de localización 170, el GMLC/SLP 170 o el LS 470). La ESInet i3560 incluye una BCF 564, un ESRP 566, una ECRF 568 y un PSAP 580 con capacidad NENA i3 (que puede corresponder al PSAP 180, el PSAP 380 o el PSAP 480). La ESN heredada 562 incluye una ALI 561, un SR 563 (que puede corresponder al SR 160, el SR 360 o el SR 463) y un PSAP heredado 582 (que puede corresponder al Ps A p 180, el PSAP 380 o el PSAP heredado 482). En cuanto a la FIG. 4, las diversas entidades mostradas en la FIG. 5 son bien conocidas en la técnica.

[0114] Con la compatibilidad de LRF, mostrada en la FIG. 5 para la solución S1 de la FIG. 3, una llamada de emergencia desde el UE 500 al PSAP 580 o el PSAP 582 se puede establecer de forma similar a la llamada de emergencia desde el UE 400 al PSAP 480 o el PSAP 482 descrita en asociación con la FIG. 4, y con los mensajes 401, 402, 403A, 403B, 404A y 404B en la FIG. 4 correspondiente a los mensajes 501, 502A, 503A, 503B, 504A y 504B, respectivamente, en la FIG. 5. Sin embargo, en el caso de la compatibilidad de LRF mostrada en la FIG. 5, la interacción entre el SP OTT 550 y la LRF 548 en la consulta 502A y la respuesta 502B no usa la desrreferencia de localización como en la FIG. 4 sino que en su lugar hace uso de una capacidad de LRF para la compatibilidad de tanto la recuperación de localización como el enrutamiento de una llamada de emergencia. El SP OTT 550 recibe inicialmente una dirección de la LRF 548 en el MNO de servicio 590 desde el UE 500 en la solicitud de llamada de emergencia 501 (que el UE 500 puede obtener desde la AN de MNO de servicio 520 o una PCN en el MNO de servicio 590, por ejemplo, en conexión de red). A continuación, el SP OTT 550 se comporta de forma similar a una E-CSCF (por ejemplo, para la norma ATIS-0700015) y reenvía la solicitud de llamada de emergencia en forma de una INVITACIÓN SIP 502A a la LRF 548, que obtiene información de localización y enrutamiento de forma similar a la descrita para una LRF en ATIS-00700015 para la interfaz de Ml. A continuación, la LRF 548 devuelve la información de localización y enrutamiento al SP OTT 550 en forma de un 300 múltiples opciones de SIP 502B (por ejemplo, como se produce en la interfaz de Ml en ATIS-0700015). A continuación, el SP OTT 550 enruta la solicitud de llamada de emergencia al PSAP (el PSAP heredado 582 en la solicitud 503A o bien el PSAP 580 con capacidad NENA i3 en la solicitud 503B) usando la información de enrutamiento y que contiene la información de localización recibida en la respuesta 502B. La información de localización recibida en la respuesta 502B puede contener una LbyV, una LbyR, una ESRK o ESRD más MSISDN y puede corresponder al identificador de referencia definido en ATIS-0700015. Para las últimas tres alternativas (es decir, LbyR, ESRK o ESRD más MSISDN), el PSAP 580/582 típicamente enviaría una consulta 504A (para el PSAP 582) o una consulta 504B (para el PSAP 580) a la LRF 548 en un tiempo posterior para una localización que se puede enviar para el UE 500.

[0115] La FIG. 5 muestra la ruta y la dirección del mensaje de solicitud de llamada de emergencia inicial (por ejemplo, una INVITACIÓN SIP) 501 desde el UE 500 al SP OTT 550, la ruta a la LRF 548 (para la INVITACIÓN SIP 502A reenviada) y de vuelta al SP OTT 550 (para el 300 múltiples opciones de SIP 502B) y la ruta y dirección desde el SP OTT 550 al PSAP 580/582 para la solicitud de llamada de emergencia 503A y 503B reenviada. Se puede usar Internet 575 para transmitir la solicitud de llamada inicial 501 desde el MNO de servicio 590 al SP OTT 550 y para transmitir la solicitud de llamada 503B reenviada desde el SP OTT 550 a la ESInet 560, mientras que la PSTN 585 se puede usar para transmitir una solicitud de llamada CS 503A desde el SP OTT 550 al SR 563 para llegar al PSAP heredado 582. La FIG. 5 también muestra la ruta y la dirección para una solicitud de localización 504A o 504B para el UE 500 enviada por el PSAP heredado 582 o el PSAP de NENA i3580, respectivamente, a la LRF 548.

[0116] La FIG. 6 ilustra una arquitectura ejemplar para la compatibilidad de la E-CSCF de IMS para servicios de emergencia sobre un proveedor de servicios OTT de acuerdo con al menos un aspecto de la divulgación. De forma similar a la arquitectura ilustrada en las FIGS. 4 y 5, la arquitectura ilustrada en la FIG. 6 incluye un UE 600 (que puede corresponder al UE 200, el UE 300, el UE 400 o el UE 500), una red de acceso 620 (que puede corresponder a la RAN 120, la AN 320, la An 420 o la An 520), un IMS 640 (que puede corresponder a parte de la red central 140, parte de la PCN 340, el iMs 440 o el IMS 540), un SP OTT 650 (que puede corresponder al SP OTT 150, el SP Ot T 350, el SP OTT 450 o la OTT 550), una ESInet con capacidad NENA i3660 (que puede corresponder a la ESInet 160, la ESInet 360, la ESInet 460 o la ESInet 560), una eSn heredada 662, Internet 675, una PSTN 685 y un MNO de servicio 690 (que puede corresponder a la CN 140 combinada con la AN 120, la PCN 340 combinada con la AN 320, el MNO 490 o el MNO 590). El IMS 640 incluye una LRF 648 (que puede corresponder al servidor de localización 170, el ELS 370, la LRF 448 o la LRF 548), una MGCF 641, una P-CSCF 642, una E-CSCF 643, una IBCF 644 y una S-CSCF 645. La LRF 648 se puede conectar a una RDF 646 y un LS 670 (que puede corresponder al servidor de localización 170, el GMLC/SLP 170, el LS 470 o el LS 570). La ESInet i3660 incluye una BCF 664, un ESRP 666, una ECRF 668 y un PSAP 680 con capacidad NENA i3 (que puede corresponder al pSa P 180, el PSAP 380, el PSAP 480 o el PSAP 580). La ESN heredada 662 incluye una ALI 661, un SR 663 (que puede corresponder al SR 160, el SR 360, el SR 463 o el SR 563) y un PSAP heredado 682 (que puede corresponder al PSAP 180, el PSAP 380, el PSAP heredado 482 o el PSAP heredado 582). En cuanto a las FIGS. 4 y 5, las diversas entidades mostradas en la FIG. 6 son bien conocidas en la técnica.

[0117] Con la compatibilidad de la E-CSCF, mostrada en la FIG. 6 para la solución S1 de la FIG. 3, el SP OTT 650 recibe una dirección de la E-CSCF 643 en el MNO de servicio 690 en la solicitud de llamada de emergencia 601 enviada desde el UE 600 (que el UE 600 puede obtener desde la AN de MNO de servicio 620 o la PCN en el MNO de servicio 690, por ejemplo, en la conexión de red). A continuación, el SP OTT 650 se comporta de forma similar a una S-CSCF y reenvía la solicitud de servicios de emergencia usando un INVITACIÓN SIP 602 estándar a la E-CSCF 643, que a continuación reenvía la solicitud de llamada 604A o 604B a un PSAP 680 o 682, respectivamente, después de haber enviado una solicitud 603A a la LRF 648 para obtener cualquier información de enrutamiento y localización en una respuesta 603B necesaria para realizar el reenvío. La compatibilidad de E-CSCF ejemplificada en la FIG. 6 puede mejorar la probabilidad de una transferencia exitosa de llamada (o servicio) a un PSAP 680/682 a costa de una mayor participación del MNO de servicio 690.

[0118] De forma similar a la FIG. 5, la FIG. 6 muestra la ruta y la dirección del mensaje de solicitud de llamada de emergencia inicial (por ejemplo, una INVITACIÓN SIP) 601 desde el UE 600 al SP OTT 650, la ruta de la solicitud de llamada reenviada 602 a la E-CSCF 643, y la ruta y dirección al PSAP 680 o 682 de la solicitud de llamada reenviada 604A o 604B, respectivamente, con asistencia de localización y enrutamiento solicitada por la E-CSCF 643 en la solicitud 603A y devuelta por la LRF 648 en la respuesta 603B. La solicitud 603A a la LRF 648 y la respuesta 603B desde la LRF 648 pueden ser como se define para la solución en ATIS-0700015, por ejemplo, comprendiendo la solicitud 603A una INVITACIÓN SIP y comprendiendo la respuesta 603B un mensaje 300 múltiples opciones de SIP. La FIG. 6 también muestra la ruta y la dirección para una solicitud de localización 605a o 605B para el UE 600 enviada por el PSAP heredado 682 o el PSAP de NENA i3680, respectivamente, a la LRF 648.

[0119] Tanto las soluciones de la LRF 648 como de la E-CSCF 643 descritas en asociación con las FIGS. 5 y 6, respectivamente, pueden requerir algunos cambios en una LRF y una RDF, y en una E-CSCF para la solución de la E-CSCF de la FIG. 6, en comparación con la solución de llamada de emergencia de IMS definida por 3GPP (por ejemplo, en la TS 23.167 de 3GPP) y en ATIS-0700015, pero también podrían reutilizar la funcionalidad existente de estas soluciones estándar.

[0120] Para cada solución descrita anteriormente con referencia a las FIGS. 5 y 6, un UE (por ejemplo, el UE 500 o 600) proporcionaría al SP OTT (por ejemplo, el SP OTT 550 o 650) determinada información para (i) posibilitar el enrutamiento de llamadas de emergencia desde el SP OTT a la entidad correcta en el MNO de servicio (una LRF o bien una E-CSCF) y (ii) posibilitar que el SP OTT proporcione información suficiente al MNO de servicio para posibilitar o ayudar a que el MNO de servicio obtenga la localización de UE y sea compatible con el enrutamiento de llamadas. Parte de la información proporcionada por el UE al SP OTT puede provenir de lo que normalmente conoce el UE, mientras que es posible que otra información se tenga que proporcionar al UE por la AN (por ejemplo, la AN 520 o 620) o por la PCN en el MNO de servicio (por ejemplo, el m No 590 o 690), por ejemplo, en la conexión de UE, en el traspaso a una nueva MME o SGSN, y/o siempre que se produzca una actualización de área de seguimiento o área de enrutamiento a una nueva MME o SGSN. La información que se puede proporcionar por el UE al SP OTT en una solicitud de llamada de emergencia para el UE se muestra en la tabla 3 (columna 1) junto con la fuente probable de cada elemento de información (columna 2), la aplicabilidad a la localización del plano de usuario (UP) o del plano de control (CP) para el UE (columna 3), y posibles encabezados de SIP que se podrían usar para transferir cada elemento al SP OTT (y desde allí al MNO de servicio) cuando se usa SIP entre el UE y el SP OTT (columna 4).

Tabla 3

[0121] La LRF 548 o la E-CSCF 643 en el MNO de servicio 590 o 690 puede necesitar mantener información de estado después de recibir la INVITACIÓN SIP 502A o 602 inicial, respectivamente, desde el SP OTT 550 o 650, en asociación con la solución en la FIG. 5 o la FIG. 6, respectivamente, para mantener la llamada en el caso de una E-CSCF 643 o para responder a cualquier solicitud de localización posterior desde el PSAP 580/582 o una ESInet 560 en el caso de una LRF 548. En el caso de la LRF 548, esto significa conocer cuándo ha finalizado la llamada de emergencia. Además, puesto que una MME de servicio o una SGSN de servicio para el UE 500 o 600 puede cambiar, la E-CSCF 643 o la LRF 548 puede necesitar conocer la nueva dirección (o ID) de MME o de SGSN de servicio cuando se usa la localización del plano de control. Para una LRF 548, estos objetivos se pueden lograr si la LRF 548 se abona por separado a la notificación de acontecimientos desde el SP OTT 550 para la terminación de la llamada y, cuando se usa la localización del plano de control, para el cambio de la MME o la SGSN de servicio. Para una E-CSCF 643, la notificación de un cambio en la dirección de MME o SGSN de servicio puede ser posible con una actualización de INFORMACIÓN SIP desde el SP OTT 650. El UE 500 o 600 puede mantener actualizado al SP OTT 550 o 650, respectivamente, con cualquier nueva identidad de MME o SGSN de servicio usando una INFORMACIÓN SIP (por ejemplo, cuando el SP OTT usa SIP) o usando algún mensaje de SP OTT patentado.

[0122] Ambas soluciones ilustradas en las FIGS. 5 y 6 pueden transferir la misma información mostrada en la tabla 3 desde el UE 500 o el UE 600 al SP OTT 550 o el SP OTT 650, respectivamente, excepto que la dirección en el MNO de servicio proporcionada al SP OTT 550 o 650 por el UE 500 o 600, respectivamente, podría ser una dirección para la LRF 548 para la solución de LRF de la FIG. 5 y una dirección para la E-CSCF 643 para la solución de E-CSCF de la FIG. 6. Esta transferencia de información casi idéntica desde el UE 500 o 600 al SP OTT 550 o 650, respectivamente, puede permitir que ambas soluciones (para las FIGS. 5 y 6) sean compatibles como parte de una solución común por los UE 500 y 600 y por los SP OTT 550 y 650, lo que puede permitir que un MNO de servicio 590 o 690 decida cuál de las dos soluciones usar y pueden ser compatibles con la migración de una solución a otra sin afectar la compatibilidad de los UE 500 y 600 y los SP OTT 550 y 650. Las figuras descritas a continuación ejemplifican con más detalle la solución basada en LRF de la FIG. 5 y la solución basada en E-CSCF de la FIG. 6.

[0123] La FIG. 7 ilustra un flujo de mensajes ejemplar para la compatibilidad de localización por valor y localización por referencia mejorada de acuerdo con al menos un aspecto de la divulgación. El flujo de mensajes ilustrado en la FIG. 7 se puede realizar en las arquitecturas ilustradas en las FIGS. 3 y 4 y puede corresponder a y extender las interacciones para la compatibilidad de la localización por referencia descrita en asociación con la FIG. 4. El flujo de mensajes en la FIG. 7 también o en su lugar se puede realizar en las arquitecturas ilustradas en las FIGS. 1A y 1B y puede complementar y extender las interacciones descritas en asociación con las FIGS. 2A y 2B para la compatibilidad de la localización por referencia. Como consecuencia, el UE 700 en la FIG. 7 puede corresponder a cualquiera de los UE 1 a N de la FIG. 1A, el UE 200, el UE 300 o el UE 400. De forma similar, el SP OTT 750 puede corresponder al SP OTT 150, el SP OTT 350 o el s P OTT 450. De forma similar, la AN/PCN 792 puede corresponder a la AN 420 más la parte de PCN del MNO 490, la AN 320 más la PCN 340 o a la AN 120 más la Cn 140 y puede incluir el nodo de red de acceso 240. De forma similar, el ELS 794 puede corresponder a la LRF 448, el ELS 370, el GMLC/SLP 170 o el servidor de localización 170. De forma similar, el SR 763 puede corresponder al SR 463, el SR 360 o el SR 160. De forma similar, la ESInet 760 puede corresponder a la ESInet 460, la ESInet 360 o la ESInet 160. De forma similar, el PSAP i3780 puede corresponder al PSAP i3480, el PSAP 380 o el PSAP 180. De forma similar, el PSAP heredado 782 puede corresponder al PSAP heredado 482, el PSAP 380 o el PSAP 180. De forma similar, el MNO de servicio 790 puede corresponder al MNO de servicio 490.

[0124] El flujo de llamadas mostrado en la FIG. 7 se puede aplicar directamente a la solución S1 en la FIG. 3, por ejemplo, puede proporcionar más detalles de las interacciones necesarias para la compatibilidad de la solución S1. Un flujo de llamadas correspondiente a la solución S2 en la FIG. 3 puede ser casi el mismo que el flujo de llamadas mostrado en la FIG. 7 excepto que la solicitud de llamada de emergencia en 706 no llevaría una LbyV o una LbyR (como se describe a continuación para la FIG. 7) y el SP OTT 750 consultaría al UE 700 una LbyV o una LbyR después de 706. Además, con la solución S2 en la FIG. 3, el UE 700 puede no detectar que el usuario ha iniciado una llamada de emergencia en 706 (por ejemplo, puede no reconocer que el usuario marcó un número de emergencia tal como "911") y puede enviar una solicitud de llamada normal al SP OTT 750 en 706 y no una solicitud de llamada de emergencia. A continuación, el SP OTT 750 puede reconocer que la solicitud de llamada enviada en 706 es para una llamada de emergencia (por ejemplo, puede reconocer que los números marcados son para un número de emergencia tal como "911") y puede solicitar una LbyR o una LbyV al UE 700 antes de continuar con 708. Las otras operaciones mostradas en la FIG. 7, cuando se usa la solución S2 de la FIG. 3, a continuación se pueden producir como se describe a continuación.

[0125] Las interacciones mostradas en la FIG. 7 se aplican a un UE 700 que inicia una llamada de emergencia por medio de un SP OTT 750 en circunstancias donde el UE 700 está accediendo a un MNO de servicio 790 (por ejemplo, está accediendo al SP OTT 750 por medio del MNO de servicio 790). En 702 en la FIG. 7, si una LbyR se va a usar por el UE 700 para la compatibilidad de una llamada de emergencia, el UE 700 puede solicitar una LbyR a la AN o la PCN de servicio 792. Por ejemplo, esto se puede producir cuando el UE 700 detecta que el usuario está iniciando una llamada de emergencia o se puede producir cuando el UE 700 se conecta al MNO de servicio 790 o accede al MNO de servicio por algún otro motivo (por ejemplo, para la compatibilidad de movilidad del UE 700).

[0126] En 704, en respuesta a 702, o cuando se producen determinadas condiciones (por ejemplo, el UE 700 se conecta a la AN/PCN 792, realiza una actualización de área de seguimiento o enrutamiento a una nueva MME o SGSN en la AN/PCN 792, o se produce un traspaso a una nueva MME o SGSN), la AN o la PCN 792 envía una LbyR o una LbyR actualizada al UE 700. la LbyR se puede determinar por la AN o la PCN 792 u obtener desde un ELS 794 (por ejemplo, una LRF). En algunos modos de realización, los bloques 702 y 704 pueden corresponder al bloque 202A en la FiG. 2A o a los bloques 202B y 206B, respectivamente en la FIG. 2B. En estos modos de realización, la AN/PCN 792 puede asignar por sí misma la LbyR que se devuelve al UE 700 en 704 o puede obtener la LbyR desde el ELS 794 de forma similar al bloque 204B en la FiG. 2B (no mostrado en la FIG. 7).

[0127] En 706, en respuesta a que el UE 700 detecta que el usuario del UE 700 ha iniciado una llamada de emergencia (por ejemplo, si el UE 700 detecta que el usuario ha marcado los números "911"), el UE 700 envía una solicitud de llamada de emergencia al SP OTT 750 e incluye la LbyV o la LbyR obtenida en 704. La solicitud de llamada de emergencia puede ser una INVITACIÓN SIP o puede ser un mensaje para algún otro protocolo específico para el SP OTT 750. El bloque 706 puede corresponder al bloque 214A en la FIG. 2A, el bloque 212B en la FiG. 2B o el envío de la solicitud de llamada de emergencia 401 en la FIG. 4.

[0128] En 708, si se recibe una LbyR en 706, el SP OTT 750 desrreferencia la LbyR enviando una solicitud de localización (por ejemplo, una solicitud de localización con formato de acuerdo con el protocolo HELD si se hace referencia a HELD en la LbyR) al ELS 794 e incluye la LbyR en la solicitud. El SP OTT 750 puede determinar el ELS 794 (por ejemplo, determinar una dirección, un FQDN o un URL para el ELS 794) de la información en la LbyR recibida en 706. El bloque 708 puede corresponder al bloque 216A en la FIG. 2A, el bloque 214B en la FIG. 2B o el envío de una consulta de localización 402 en la FIG. 4.

[0129] En 710, el ELS 794 usa la información incluida en la LbyR recibida en 708 (por ejemplo, una identidad de UE local o global y una ID de MME/SGSN de servicio para la localización del plano de control o una dirección IP de UE local para la localización del plano de usuario) para obtener la localización actual del UE 700, por ejemplo, usando una solución de localización del plano de control o del plano de usuario. El bloque 710 puede corresponder a los bloques 218A y/o 222A en la FIG. 2A o a los bloques de 216B a 226B o bien al bloque 228B en la FIG. 2b .

[0130] En 712, el ELS 794 devuelve la localización actual del UE 700 al SP OTT 750 y/o devuelve información de enrutamiento para el UE 700 determinada de la localización del UE 700. El bloque 712 puede corresponder al bloque 224A en la FIG. 2A o al bloque 232B en la FIG. 2B. Los bloques 708-712 se muestran como opcionales y no se pueden realizar si el SP OTT 750 recibe una LbyV en 706.

[0131] Después de 712, si solo se devolvió una localización para el UE 700 en 712, el SP OTT 750 determina el PSAP de destino usando la localización de UE (por ejemplo, usando una consulta LoST, no mostrada en la FIG. 7). De otro modo, el SP OTT 750 puede usar cualquier información de enrutamiento devuelta en 712 para determinar el PSAP. Cuando el SP OTT 750 determina un pSa P heredado 782, el SP OTT 750 puede reenviar la llamada usando CS al enviar un mensaje IAM de ISUP a un SR 763 para el PSAP 782.

[0132] En 716A, el SR 763 reenvía la llamada al PSAP heredado 782.

[0133] En 718A, se realiza el resto del establecimiento de la llamada. A continuación, los bloques 714B, 716B y 718B no se realizan.

[0134] Cuando el SP OTT 750 determina un PSAP i3780 en lugar de un PSAP heredado 782 después de 712, los bloques 714A, 716A y 718A no se realizan. En su lugar, el SP OTT 750 reenvía la llamada a la ESInet 760 enviando una INVITACIÓN SIP que contiene la LbyV o la LbyR recibida en 706 y posiblemente contiene cualquier localización para el UE 700 recibida en 712 si se produce 712.

[0135] Después de 714B y antes de 716B, si se proporciona una LbyR en 714B, la ESInet 760 puede consultar al ELS 794 la localización actual del UE 700 para ayudar en el enrutamiento (no mostrado en la FIG. 7). A continuación, la ESInet 760 reenvía la llamada al PSAP i3780 en 716B.

[0136] En 718B, se realiza el resto del establecimiento de la llamada. Los bloques 714A y 716A y los bloques 714B y 716B pueden corresponder al bloque 226A en la FIG. 2A, el bloque 234B en la FIG. 2B o al envío de mensajes 403A y 403B, respectivamente, en la FIG. 4. El bloque 718A y el bloque 718B pueden corresponder cada uno al bloque 228A en la FiG. 2A o el bloque 236B en la FIG. 2B.

[0137] En 720, si se recibió una LbyR para el UE 700 en 716B, el PSAP i3780 desrreferencia la LbyR enviando una solicitud de localización al ELS 794 indicado en la LbyR e incluye la LbyR en la solicitud. El bloque 720 puede corresponder al envío de la consulta 404B en la FIG. 4.

[0138] En 722, el ELS 794 usa la información incluida en la LbyR recibida en 720 (por ejemplo, una identidad local o global para el UE 700 y una ID de MME/SGSN de servicio para la localización del plano de control o una dirección IP de UE local para la localización del plano de usuario) para obtener la localización actual del UE 700, por ejemplo, usando una solución de localización del plano de control o del plano de usuario. El bloque 722 puede ser similar a o el mismo que los bloques 218A y/o 222A en la FIG. 2A o a los bloques de 216B a 226B o bien al bloque 228B en la FIG. 2B en lo que respecta a determinar una localización para el UE 700.

[0139] En 724, el ELS 794 devuelve la localización actual del UE 700 al PSAP i3780. Los bloques 720 y 724 pueden corresponder al bloque 232A en la FIG. 2A o al bloque 238B en la FIG. 2B.

[0140] La FIG. 8 ilustra un flujo de llamadas ejemplar para la compatibilidad de la LRF de IMS para una llamada de emergencia por medio de un SP OTT como se describe anteriormente con referencia a la FIG. 5, de acuerdo con al menos un aspecto de la divulgación, y puede extender las interacciones para la compatibilidad de la LRF de IMS descrita previamente en asociación con la FIG. 5. El flujo de llamadas ilustrado en la FIG. 8 se puede realizar usando la arquitectura ilustrada en la FIG. 5, la FIG. 3, la FIG. 1B o la FIG. 1A. Como consecuencia, el UE 800 en la FIG. 8 puede corresponder a cualquiera de los UE 1 a N de la FIG. 1A, el UE 200, el UE 300 o el UE 500. De forma similar, el SP OTT 850 puede corresponder al SP OTT 150, el SP OTT 350 o el SP OTT 550. De forma similar, la AN/PCN 892 puede corresponder a la AN 520 más la parte de PCN del MNO 590, la AN 320 más la PCN 340 o a la AN 120 más la CN 140 y puede incluir el nodo de red de acceso 240. De forma similar, el IMS 894 puede corresponder al IMS 540, un IMS dentro de la PCN 340 o un IMS dentro de la CN 140. De forma similar, el destino CS intermedio 863 puede corresponder al SR 563, el SR 360 o el SR 160. De forma similar, la ESInet 860 puede corresponder a la ESInet 560, la ESInet 360 o la ESInet 160. De forma similar, el PSAP i3 880 puede corresponder al PSAP i3580, el PSAP 380 o el PSAP 180. De forma similar, el PSAP heredado 882 puede corresponder al PSAP heredado 582, el PSAP 380 o el PSAP 180. De forma similar, el MNO de servicio 890 puede corresponder al MNO de servicio 590.

[0141] La FIG. 9 ilustra un flujo de llamadas ejemplar para la compatibilidad de la E-CSCF de IMS para una llamada de emergencia por medio de un SP OTT como se describe anteriormente con referencia a la FIG. 6, de acuerdo con al menos un aspecto de la divulgación, y puede extender las interacciones para la compatibilidad de la E-CSCF de IMS descrita previamente en asociación con la FIG. 6. El flujo de llamadas ilustrado en la FIG. 9 se puede realizar usando la arquitectura ilustrada en la FIG. 6, la FIG. 3, la FIG. 1B o la FIG. 1A. Como consecuencia, el UE 900 en la FIG. 9 puede corresponder a cualquiera de los UE 1 a N de la FIG. 1A, el UE 200, el UE 300 o el UE 600. De forma similar, el SP OTT 950 puede corresponder al SP OTT 150, el SP OTT 350 o el SP OTT 650. De forma similar, la AN/PCN 992 puede corresponder a la AN 620 más la parte de PCN del MNO 690, la AN 320 más la PCN 340 o a la AN 120 más la CN 140 y puede incluir el nodo de red de acceso 240. De forma similar, el IMS 994 puede corresponder al IMS 640, un IMS dentro de la PCN 340 o un IMS dentro de la CN 140. De forma similar, el SR 963 puede corresponder al SR 663, el SR 360 o el SR 160. De forma similar, la ESInet 960 puede corresponder a la ESInet 660, la ESInet 360 o la ESInet 160. De forma similar, el PSAP i3980 puede corresponder al PSAP i3680, el PSAP 380 o el PSAP 180. De forma similar, el PSAP heredado 982 puede corresponder al PSAP heredado 682, el PSAP 380 o el PSAP 180. De forma similar, el MNO de servicio 990 puede corresponder al MNO de servicio 690.

[0142] Los flujos de llamadas ilustrados en las FIGS. 8 y 9 son similares, y desde la perspectiva de entidades fuera del IMS 894/994 (por ejemplo, el UE 800/900 y el SP Ot T 850/950) se pueden ver como parte de una única solución común. Aunque el IMS 894/994 se comporta de manera diferente en los flujos de llamadas en las FIGS. 8 y 9, las interacciones entre el IMS 894/994 y el SP OTT 850/950 en ambos flujos de llamadas pueden cumplir con la definición del IETF de SIP (por ejemplo, en la RFC del IETF 3261) y, por lo tanto, ambos podrían ser compatibles con un SP OTT 850/950 que actúa como un proxy de SIP. En ese caso, es posible que el SP OTT 850/950 no necesite conocer con antelación si el MNO de servicio 890/990 (o el IMS 894/994 en el MNO de servicio 890/990) va a emplear la compatibilidad de la LRF de IMS como en la FIG. 8 o la compatibilidad de la E-CSCF de IMS como en la FIG. 9. En su lugar, el SP OTT 850/950 puede simplemente reaccionar de acuerdo con las reglas de SIP preconfiguradas, dependiendo de si se proporciona compatibilidad de la LRF de IMS o la E-CSCF de IMS. Esto puede posibilitar que el MNO de servicio 890/990 migre desde la compatibilidad de la LRF de IMS a la compatibilidad de la E-CSCF de iMs o viceversa sin que se requieran cambios en la compatibilidad desde el UE 800/900 o desde el SP OTT 850/950. También puede posibilitar que la OTT 850/950 reciba compatibilidad de la LRF de IMS de acuerdo con la FIG. 8 desde uno o más MNO (por ejemplo, el MNO 890) y reciba compatibilidad de la E-CSCF de IMS de acuerdo con la FIG. 9 desde uno o más de otros MNO (por ejemplo, el MNO 990) para llamadas de emergencia que se pueden originar por diferentes UE (por ejemplo, el u E 800 y el u E 900) que acceden al SP OTT 850/950 desde uno de estos MNO.

[0143] Los flujos de llamadas en las FIGS. 8 y 9 se aplican a la solución S1 en la FIG. 3. Para la solución S2 en la FIG. 3, los flujos de llamadas podrían ser casi los mismos, excepto que la solicitud de llamada de emergencia descrita a continuación en 806/906 en cada flujo de llamadas no incluiría algunos o todos los datos de UE y/o los datos de MNO. En su lugar, el SP OTT 850/950 consultaría en el UE 800/900 los datos de UE y/o los datos de MNO después de 806/906 (por ejemplo, enviando una INFORMACIÓN SIP que contiene la solicitud al UE 800/900 y devolviendo el UE 800/900 los datos de UE y/o los datos de MNO solicitados en una OK SIP o en un INFORMACIÓN SIP). Para la solución S2, es posible que el SP OTT 850/950 también necesite consultar en el UE 800/900 los datos de MNO actualizados que el UE 800/900 envía en 826 en la FIG. 8 y 920 en la FIG. 9. Sin embargo, esta solicitud se podría combinar implícita o explícitamente con la solicitud (mencionada anteriormente) para los datos de UE y los datos de MNO enviados inicialmente al UE 800/900 después de 806/906.

[0144] Además, con la solución S2 de la FIG. 3, el UE 800/900 puede no detectar que el usuario ha iniciado una llamada de emergencia antes de 806/906 en las FIGS. 8 y 9 (por ejemplo, puede no reconocer que el usuario marcó un número de emergencia tal como "911") y puede enviar una solicitud de llamada normal al SP OTT 850/950 en 806/906 en las FIGS. 8 y 9 y no una solicitud de llamada de emergencia. A continuación, el SP OTT 850/950 puede reconocer que la solicitud de llamada enviada en 806/906 es para una llamada de emergencia (por ejemplo, puede detectar que los números marcados son para un número de emergencia tal como "911") y puede solicitar datos de MNO y/o datos de UE del UE 800/900 antes de continuar con 808/908 mostrado en las FIGS. 8 y 9. Las otras operaciones en las FIGS. 8 y 9 que no se modifican como se acaba de describir para la solución S2 de la FIG. 3 se pueden producir como se describe a continuación.

[0145] Las interacciones mostradas en la FIG. 8 se pueden aplicar a un UE 800 que inicia una llamada de emergencia por medio de un SP OTT 850 en circunstancias donde el UE 800 está accediendo a un MNO de servicio 890 (por ejemplo, está accediendo al SP OTT 850 por medio del MNO de servicio 890). En 802 en la FIG. 8, el UE 800 puede solicitar datos desde la AN o la PCN 892 en el MNO de servicio 890 para la compatibilidad de una llamada de emergencia usando un SP OTT 850. Por ejemplo, esto se puede producir cuando el UE 800 detecta que el usuario está iniciando una llamada de emergencia. El bloque 802 es opcional y puede no siempre producirse.

[0146] En 804, en respuesta a 802, o cuando se producen determinadas condiciones (por ejemplo, el UE 800 se conecta a la AN/PCN 892, realiza una actualización del área de seguimiento o área de enrutamiento a una nueva MME o SGSN o se produce el traspaso a una nueva MME o SGSN), la AN o la PCN 892 envía datos de MNO al UE 800. Los datos de MNO pueden incluir (i) una dirección de IMS para el MNO de servicio 890 (por ejemplo, la dirección de una LRF en el IMS 894), (ii) si se puede usar la localización del plano de control, una identidad para una MME de servicio actual o una SGSN de servicio actual para el UE 800, (iii) si se puede usar la localización del plano de usuario, una dirección IP asignada por el MNO para el UE 800, y/o (iv) una identidad global (por ejemplo, IMSI o MSISDN) para el UE 800 o bien una identidad local para el UE 800 asignada por la MME de servicio o la SGSN de servicio para el UE 800.

[0147] En 806, en respuesta a que el UE 800 detecta que el usuario del UE 800 ha iniciado una llamada de emergencia (por ejemplo, si el UE 800 detecta que el usuario ha marcado los números "911"), el UE 800 envía una solicitud de llamada de emergencia al SP OTT 850 e incluye los datos de MNO obtenidos en 804 y posiblemente datos adicionales del UE conocidos por el UE 800. Los datos de UE pueden incluir una identidad global para el UE 800 (por ejemplo, una IMSI o un MSISDN) y posiblemente una dirección IP asignada por el MNO para el UE 800 si no se recibe en 804. La solicitud de llamada de emergencia en 806 puede ser una INVITACIÓN SIP o puede ser un mensaje para algún otro protocolo específico para el SP OTT 850. El bloque 806 puede corresponder al envío de la solicitud de llamada de emergencia 501 en la FIG. 5.

[0148] En 808, en base a la recepción en 806 de una dirección de IMS en el MNO de servicio 890 (por ejemplo, donde la dirección de IMS puede ser parte de los datos de MNO recibidos en 806 y puede ser una dirección de la LRF incluida en el encabezado de ruta de una INVITACIÓN SIP enviada en 806), el SP OTT 850 envía una INVITACIÓN SIP al IMS 894 (por ejemplo, a una LRF en el IMS 894) indicado por la dirección de IMS en el MNO de servicio 890. La INVITACIÓN SIP incluye los datos de MNO y cualquier dato de UE recibido en 806, indica una llamada de emergencia e incluye la identidad y posiblemente la localización (por ejemplo, el país) del SP OTT 850. La INVITACIÓN SIP podría ser una copia parcial o completa de cualquier INVITACIÓN SIP recibida en 806. El bloque 808 puede corresponder al envío de la INVITACIÓN SIP 502A en la FIG. 5.

[0149] En algunos casos, la INVITACIÓN SIP enviada en 808 se puede recibir en primer lugar en una función de control de bordes (por ejemplo, una IBCF) en el IMS 894 del MNO de servicio por seguridad antes de reenviarse a una LRF en el IMS 894 (no mostrado en la FIG. 8). El IMS 894 (por ejemplo, una LRF o una IBCF en el IMS 894) puede verificar en primer lugar que la INVITACIÓN SIP enviada en 808 proviene de un SP OTT válido, por ejemplo, usando datos preconfigurados en base a alguna relación comercial entre el MNO de servicio 890 y el SP OTT 850, y posiblemente usando una conexión IP segura entre el SP OTT 850 y el IMS 894 del MNO de servicio para transferir la INVITACIÓN SIP en 808. En algunos casos, en 810, el IMS 894 (por ejemplo, una LRF en el IMS 894) usa los datos de MNO y cualquier dato de UE enviado en 808 para obtener una localización para el UE 800, por ejemplo, usando una solución de localización del plano de control o el plano de usuario. En algunos otros casos, el bloque 810 no se produce y el IMS 894 puede determinar una localización (por ejemplo, una localización aproximada) para el UE 800 de otros datos recibidos en la INVITACIÓN SIP en 808, tales como una LbyV incluida por el UE 800 en la solicitud de llamada de emergencia enviada en 806 y transferida por el SP OTT 850 al IMS 894 en 808.

[0150] A continuación, el IMS 894 (por ejemplo, una RDF en el IMS 894) determina un PSAP de destino 880/882, o una ruta hacia un PSAP de destino 880/882, correspondiente a la localización del UE 800 y deriva un URI de enrutamiento (que también se puede denominar URI de ruta) para posibilitar el enrutamiento de llamadas desde el SP OTT 850 a o hacia el PSAP de destino 880/882. El URI de enrutamiento puede incluir la dirección o identidad del PSAP 880/882 o de un destino intermedio 863 (por ejemplo, un SR en el caso de un PSAP heredado 882 o un punto de entrada a una ESlnet 860 para un PSAP 880 con capacidad i3) y puede depender de la identidad del SP OTT 850 y/o la localización del SP OTT 850 (por ejemplo, si la localización está en el mismo país que el MNO de servicio 890 o está en un país diferente). El IMS 894 (por ejemplo, una LRF en el IMS 894) también determina un identificador (ID) de referencia para posibilitar una solicitud de localización posterior para el UE 800 desde una ESInet 860 o desde el PSAP 880/882 en un tiempo posterior. El ID de referencia puede ser (i) una ESRK o (ii) un ESRD más MSISDN en el caso de un PSAP heredado 882, o bien puede ser (iii) un URI de localización en el caso de un PSAP 880 con capacidad i3.

[0151] En 812, el IMS 894 (por ejemplo, una LRF en el IMS 894) devuelve el URI de enrutamiento y el ID de referencia al SP OTT 850 en un mensaje 300 múltiples opciones de SIP. Téngase en cuenta que el IMS 894 puede no devolver una localización (por ejemplo, LbyV) al SP OTT 850 si la identidad del SP OTT 850 no se validó por completo, o si la relación comercial con el SP OTT 850 solo permite la compatibilidad de enrutamiento por el MNO de servicio 890. El bloque 812 puede corresponder al envío del 300 múltiples opciones de SIP 502B en la FIG. 5.

[0152] En 814, si el IMS 894 (por ejemplo, una LRF en el IMS 894) puede necesitar usar la localización del plano de control, el IMS 894 envía un mensaje de ABONO SIP al SP OTT 850 para abonarse a la notificación de cambios en los datos de MNO (por ejemplo, cambio de MME de servicio o dirección de SGSN de servicio). El IMS 894 también puede enviar un mensaje de ABONO SIP separado al SP OTT 850 para abonarse a la notificación de terminación de la llamada (no mostrado en la FIG. 8).

[0153] En 816, si se produce 814, el SP OTT 850 devuelve un mensaje 200 OK (no mostrado en la FIG. 8) al IMS 894 y a continuación un mensaje de NOTIFICACIÓN para cada mensaje de ABONO recibido que lleva los datos de MNO actuales en el caso de abono a los datos de MNO en 814 y/o estado actual de la llamada en caso de abono a la terminación de la llamada.

[0154] Después de 812 (y posiblemente después de 816 si se produce 816), el SP OTT 850 determina si el PSAP de destino es un PSAP heredado 882 o un PSAP 880 con capacidad i3 del contenido del URI de enrutamiento o ID de referencia devuelto en 812. En el caso de un PSAP heredado 882, el SP OTT 850 puede reenviar la llamada usando CS a o hacia el PSAP 882. En un modo de realización, el SP OTT 850 envía un mensaje IAM de ISUP en 818A a un destino CS intermedio 863 (por ejemplo, un SR) indicado en el URI de ruta recibido en 812. El SP OTT 850 también incluye cualquier ESRK o Es Rd más MSISDN en el ID de referencia recibido en 812 en el IAM de ISUP. El bloque 818A puede corresponder al envío de la solicitud 503A en la FIG. 5.

[0155] En 820A, el destino CS intermedio 863 reenvía la llamada al PSAP heredado 882 e incluye la ESRK o el ESRD más MSIs Dn recibido en 818A.

[0156] En 822A, se realiza el resto del establecimiento de la llamada. A continuación, los bloques 818B, 820B y 822B no se realizan.

[0157] Cuando el SP OTT 850 determina un PSAP i3880 en lugar de un PSAP heredado 882 después de 812, los bloques 818A, 820A y 822A no se realizan. En su lugar, el SP OTT 850 reenvía la llamada a o hacia el PSAP 880. En un modo de realización, el SP OTT 850 reenvía la llamada en 818B a una ESInet 860 indicada por el URI de enrutamiento recibido en 812 enviando una INVITACIÓN SIP que contiene el URI de localización recibido en el ID de referencia en 812. El bloque 818B puede corresponder al envío de la solicitud 503B en la FIG. 5.

[0158] En 820B, la ESInet 860 reenvía la llamada al PSAP i3880 e incluye el URI de localización recibido en 818B.

[0159] En 822B, se realiza el resto del establecimiento de la llamada.

[0160] En 824, si hay un cambio en los datos de MNO (por ejemplo, el UE 800 se traspasa a una nueva SGSN o MME) y si el MNO de servicio 890 puede usar la localización del plano de control para el Ue 800, la AN o la PCN 892 envía nuevos datos de MNO al UE 800 (por ejemplo, la identidad para una nueva MME o SGSN de servicio para el UE 800 y una nueva identidad local para el UE 800 en la nueva MME o SGSN de servicio). El envío de los nuevos datos de MNO en 824 puede ser automático siempre que los datos de MNO cambien (por ejemplo, sin el conocimiento de la AN o la PCN 892 en el MNO de servicio 890 de que hay una llamada de emergencia para el UE 800 por medio de un SP OTT 850 en curso) o se puede activar por el UE 800 que ha enviado previamente una solicitud de datos de MNO en 802.

[0161] En 826, el UE 800 reenvía los nuevos datos de MNO al SP OTT 850, por ejemplo, usando un mensaje de INFORMACIÓN SIP cuando se usa SIP entre el UE 800 y el SP OTT 850.

[0162] En 828, si el IMS 894 se abonó a la notificación de cambios en los datos de MNO en 814, el SP OTT 850 envía los nuevos datos de MNO al IMS 894 (por ejemplo, una LRF en el IMS 894) en un mensaje de NOTIFICACIÓN SIP. Los nuevos datos de MNO se almacenan para su uso futuro por el IMS 894. Por ejemplo, los nuevos datos de MNO se pueden usar más adelante en el bloque 832A o en el bloque 832B para ayudar a obtener una localización para el UE 800.

[0163] En 830A, en el caso de un PSAP heredado 882, el PSAP 882 o una entidad asociada con el PSAP 882 tal como una ALI (por ejemplo, la ALI 561) puede enviar un mensaje ESPOSREQ de interfaz E2 (por ejemplo, como se define en la norma conjunta TIA/ATIS J-STD-036) al IMS 894 (por ejemplo, una LRF) indicado por la Es RK o el ESRD recibido en 820A para solicitar la localización del UE 800 e incluye la ESRK o bien el ESRD más MSISDN recibido en 820A. El bloque 830A puede corresponder al envío de la consulta 504A en la FIG. 5.

[0164] En 832A, el IMS 894 (por ejemplo, una LRF) usa la ESRK o el MSISDN recibido en 830A para identificar el UE 800 y usa cualquier dato de UE recibido en 808 y/o los datos de MNO recibidos en 808 u 828, si se produce 828, para obtener una localización para el UE 800 usando una solución de localización del plano de control o del plano de usuario.

[0165] En 834A, el IMS 894 (por ejemplo, una LRF) devuelve la localización al PSAP 882 (o a una entidad asociada con el PSAP 882, tal como una ALI).

[0166] En 830B, en el caso de un PSAP 880 con capacidad i3, el PSAP i3880 desrreferencia el URI de localización recibido en 820B enviando una solicitud de localización al IMS 894 (por ejemplo, una LRF en el IMS 894) indicada en el URI de localización y llevando el URI de localización. El bloque 830B puede corresponder al envío de la consulta 504B en la FIG. 5.

[0167] En 832B, el IMS 894 (por ejemplo, una LRF) usa el URI de localización recibido en 830B para identificar el UE 800 y usa cualquier dato de UE recibido en 808 y/o los datos de MNO recibidos en 808 u 828, si se produce 828, para obtener una localización para el UE 800 usando una solución de localización del plano de control o del plano de usuario.

[0168] En 834B, el IMS 894 (por ejemplo, una LRF) devuelve la localización al PSAP 880.

[0169] Se pueden producir bloques similares a o los mismos que 830B, 832B y 834B después de 818B para posibilitar que la ESInet 860 obtenga una localización para el UE 800 desde el IMS 894 (por ejemplo, desde una LRF en IMS 894) y, en base a la localización, enrutar la emergencia llame en 820B al PSAP 880 correcto. En ese caso, la ESInet 860 (por ejemplo, un ESRP en la ESInet 860 tal como el ESRP 566) puede enviar una solicitud de localización del UE 800 al IMS 894 en un bloque similar a o el mismo que 830B y puede recibir una localización del UE 800 desde el IMS 894 en un bloque similar a o el mismo que 834B.

[0170] Las interacciones mostradas en la FIG. 9 se pueden aplicar a un UE 900 que inicia una llamada de emergencia por medio de un SP OTT 950 en circunstancias donde el UE 900 está accediendo a un MNO de servicio 990 (por ejemplo, está accediendo al SP OTT 950 por medio del MNO de servicio 990). En 902 en la FIG. 9, el UE 900 puede solicitar datos desde la AN o la PCN 992 en el MNO de servicio 990 para la compatibilidad de una llamada de emergencia usando un SP OTT 950. Por ejemplo, esto se puede producir cuando el UE 900 detecta que el usuario está iniciando una llamada de emergencia. La operación 902 es opcional y puede no producirse siempre.

[0171] En 904, en respuesta a 902, o cuando se producen determinadas condiciones (por ejemplo, el UE 900 se conecta a la AN/PCN 992, realiza una actualización del área de seguimiento o el área de enrutamiento a una nueva MME o SGSN en la AN/PCN 992, o se produce un traspaso a una nueva MME o SGSN), la AN o la PCN 992 envía datos de MNO al UE 900. Los datos de MNO pueden incluir (i) una dirección de IMS para el MNO de servicio 990 (por ejemplo, la dirección de una E-CSCF en el IMS 994), (ii) si se puede usar la localización del plano de control, una identidad para una MME de servicio actual o una SGSN de servicio actual para el UE 900, (iii) si se puede usar la localización del plano de usuario, una dirección IP asignada por el MNO para el UE 900, y/o (iv) una identidad global (por ejemplo, IMSI o MSISDN) para el UE 900 o bien una identidad local para el UE 900 asignada por la MME de servicio o la SGSN de servicio para el UE 900.

[0172] En 906, en respuesta a que el UE 900 detecta que el usuario del UE 900 ha iniciado una llamada de emergencia (por ejemplo, si el UE 900 detecta que el usuario ha marcado los números "911"), el UE 900 envía una solicitud de llamada de emergencia al SP OTT 950 e incluye los datos de MNO obtenidos en 904 y posiblemente datos adicionales del UE conocidos por el UE 900. Los datos de UE pueden incluir una identidad global para el UE 900 (por ejemplo, una IMSI o un MSISDN) y posiblemente una dirección IP asignada por el MNO para el UE 900 si no se recibe en 904. La solicitud de llamada de emergencia en 906 puede ser una INVITACIÓN SIP o puede ser un mensaje para algún otro protocolo específico para el SP OTT 950. El bloque 906 puede corresponder al envío de la solicitud de llamada de emergencia 601 en la FIG. 6.

[0173] En 908, en base a la recepción de una dirección de IMS como parte de los datos de MNO recibidos en 906 (por ejemplo, cuando la dirección de IMS es una dirección de la E-CSCF en un encabezado de ruta de una INVITACIÓN SIP recibida en 906), el SP OTT 950 envía un INVITACIÓN SIP al IMS 994 (por ejemplo, a una E-CSCF en el IMS 994) indicada por la dirección de IMS en el MNO de servicio 990. La INVITACIÓN s Ip enviada en 980 incluye los datos de MNO y cualquier dato de UE recibido en 906, indica una llamada de emergencia e incluye la identidad y posiblemente la localización (por ejemplo, el país) del SP OTT 950. La INVITACIÓN SIP enviada en 908 podría ser una copia parcial o completa de cualquier INVITACIÓN SIP recibida en 906. El bloque 908 puede corresponder al envío de la INVITACIÓN SIP 602 en la FIG. 6.

[0174] En algunos casos, la INVITACIÓN SIP enviada en 908 se puede recibir en primer lugar en una función de control de bordes (por ejemplo, una IBCF) en el IMS 994 de MNO de servicio por seguridad antes de reenviarse a una E-CSCF en el IMS 994 (no mostrado en la FIG. 9). El IMS 994 (por ejemplo, una E-CSCF o una IBCF en el IMS 994) puede verificar que la INVITACIÓN SIP enviada en 908 provenga de un SP OTT 950 válido, por ejemplo, usando datos preconfigurados en base a alguna relación comercial entre el MNO de servicio 990 y el SP OTT 950, y posiblemente usando una conexión IP segura entre el SP OTT 950 y el IMS 994 de MNO de servicio para transferir la INVITACIÓN SIP en 908. En algunos casos en 910, el IMS 994 (por ejemplo, una LRF en IMS 994) puede usar los datos de MNO y cualquier dato de UE recibido en 908 para obtener una localización para el UE 900, por ejemplo, usando una solución de localización del plano de control o del plano de usuario. En algunos otros casos, el bloque 910 no se produce y el IMS 994 puede determinar una localización (por ejemplo, una localización aproximada) para el UE 900 de otros datos recibidos en la INVITACIÓN SIP en 908, tales como una LbyV incluida por el UE 900 en la solicitud de llamada de emergencia enviada en 906 y transferida por el SP OTT 950 al IMS 994 en 908.

[0175] En 911, que puede seguir a 908 o 910 si se produce 910, el IMS 994 (por ejemplo, una RDF en el IMS 994) determina un PSAP de destino 980/982, o una ruta hacia un PSAP de destino 980/982, correspondiente a la localización del UE 900 (por ejemplo, como se obtiene en 910) y determina un URI de enrutamiento (también denominado URI de ruta) para posibilitar el enrutamiento de llamadas desde el IMS 994 a o hacia el PSAP de destino 980/982. El URI de enrutamiento puede indicar (i) la dirección o identidad del PSAP 980/982 o (ii) la dirección o identidad de un destino intermedio tal como un SR 963 en el caso de un PSAP heredado 982 o un punto de entrada a una ESInet 960 en el caso de un PSAP 980 con capacidad i3. Como parte de la determinación de un PSAP de destino 980/982 en 911, o una ruta hacia un PSAP de destino 980/982, el IMS 994 (por ejemplo, una LRF en el IMS 994) determina un identificador (ID) de referencia para posibilitar una solicitud de localización posterior para el UE 900 desde una ESInet 960 o el PSAP 980/982 en un tiempo posterior. El ID de referencia puede ser (i) una ESRK o (ii) un ESRD más MSISDN en el caso de un PSAP heredado 982, o bien (iii) un URI de localización en el caso de un PSAP 980 con capacidad i3. El IMS 994 (por ejemplo, una E-CSCF en el IMS 994) también determina en 911 si el PSAP de destino es un PSAP heredado 982 o un PSAP 980 con capacidad i3 (por ejemplo, del contenido del URI de enrutamiento o el ID de referencia que se determinó en 911).

[0176] En algunas implementaciones, la localización del UE 900 en 910 cuando se produce 910 y la determinación de un PSAP de destino, o una ruta hacia un PSAP de destino, en 911, incluyendo la determinación del URI de enrutamiento y el ID de referencia en 911, se puede realizar por una LRF (por ejemplo, la LRF 648), posiblemente ayudada por una RDF (por ejemplo, la RDF 646), en el IMS 994 (por ejemplo, si el IMS 994 corresponde al IMS 640 en la FIG. 6). En estas implementaciones, la INVITACIÓN SIP enviada en 908 se puede recibir por una E-CSCF (por ejemplo, la E-CSCF 643) en el IMS 994 y a continuación reenviarse a la LRF (por ejemplo, la LRF 648) en el IMS 994 por la E-CSCF. A continuación, la LRF (por ejemplo, la LRF 648) en el IMS 994 puede obtener una localización para el UE 900 en 910 si se produce 910, determinar un PSAP de destino en 911, incluyendo la determinación del URI de enrutamiento y el ID de referencia y devolver el URI de enrutamiento y el ID de referencia determinados de vuelta a la E-CSCF (por ejemplo, la E-CSCF 643) en el IMS 994 en un mensaje 300 múltiples opciones de SIP. Aunque no se muestra en la FIG. 9, esta interacción entre una E-CSCF (por ejemplo, la E-CSCF 643) y una LRF (por ejemplo, la LRF 648) en el IMS 994 puede corresponder al envío de la solicitud 603A y la respuesta 603B entre la E-c Sc F 643 y la LRF 648 que se describieron en asociación con la FIG. 6.

[0177] En el caso de determinar un PSAP heredado 982 en 911, el IMS 994 (por ejemplo, una MGCF en el IMS 994) puede reenviar la llamada usando CS en 912A a o hacia el PSAP 982. En un modo de realización, el IMS 994 envía un mensaje IAM de ISUP en 912A a un SR 963 indicado en el URI de enrutamiento determinado después de 908 o 910 (si se produce 910). El IMS 994 también incluye en el IAM de ISUP cualquier ESRK o ESRD más Ms ISDN indicado en el ID de referencia determinado en 911.

[0178] En 914A, el SR 963 reenvía la llamada al PSAP heredado 982 e incluye la ESRK o el ESRD más MSISDN recibido en 912A.

[0179] En 916A, el resto del establecimiento de la llamada se realiza entre el UE 900, el SP OTT 950, el IMS 994, el SR 963 y el PSAP heredado 982. A continuación, los bloques 912B, 914B y 916B no se realizan.

[0180] Cuando el IMS 994 determina un PSAP i3980 en lugar de un PSAP heredado 982 en 911, los bloques 912A, 914A y 916A no se realizan. En su lugar, en 912B, el IMS 994 (por ejemplo, una E-CSCF en el iMs 994) reenvía la llamada de emergencia a o hacia el PSAP 980. En un modo de realización, el IMS 994 reenvía la llamada de emergencia a una ESInet 960 indicada por el URI de enrutamiento determinado en 911 enviando una INVITACIÓN SIP que contiene el URI de localización desde el ID de referencia determinado en 911.

[0181] En 914B, la ESInet 960 reenvía la llamada de emergencia al PSAP i3980 e incluye el URI de localización recibido en 912B.

[0182] En 916B, el resto del establecimiento de la llamada se realiza entre el UE 900, el SP OTT 950, el IMS 994, la ESInet 960 y el PSAP i3980.

[0183] En 918, si hay un cambio en los datos de MNO (por ejemplo, el UE 900 se traspasa a una nueva SGSN o MME en el MNO de servicio 990) y si el MNO de servicio 990 puede usar la localización del plano de control para el UE 900, la AN o la PCN 992 proporciona nuevos datos de MNO al UE 900 (por ejemplo, la identidad para una nueva MME de servicio o una nueva SGSN de servicio para el UE 900 y una identidad local para el UE 900 en la nueva MME o SGSN de servicio). El envío de estos nuevos datos de MNO puede ser automático siempre que los datos de MNO cambien (por ejemplo, sin que la AN o la PCN 992 en el MNO de servicio 990 conozca que una llamada de emergencia para el UE 900 por medio de un SP OTT 950 está en curso), o se puede activar por el UE 900 que ha enviado previamente una solicitud en 902.

[0184] En 920, el UE 900 reenvía los nuevos datos de MNO al SP OTT 950, por ejemplo, usando un mensaje de INFORMACIÓN SIP cuando se usa SIP entre el UE 900 y el SP OTT 950.

[0185] En 922, el SP OTT 950 reenvía los nuevos datos de MNO al IMS 994 (por ejemplo, a una E-CSCF en el IMS 994), por ejemplo, usando un mensaje de INFORMACIÓN SIP. Los datos de MNO se almacenan para uso futuro por el IMS 994 (por ejemplo, por una Lr F en el IMS 994).

[0186] En 924A, en el caso de un PSAP heredado 982, el PSAP 982 o una entidad asociada con el PSAP 982 (por ejemplo, una ALI tal como la ALI 661) puede enviar un mensaje ESPOSREQ de interfaz E2 (por ejemplo, como se define en la norma de TIA/ATIS J-St D-036) al IMS 994 (por ejemplo, una LRF en el IMS 994) como se indica por la ESRK o el ESRD recibido en 914A para solicitar la localización del UE 900 e incluye la ESRK o bien el ESRD más MSISDN recibido en 914A. El bloque 924A puede corresponder al envío de la solicitud de localización 605A en la FIG.

6.

[0187] En 926A, el IMS 994 (por ejemplo, una LRF en el IMS 994) usa la ESRK o el MSISDN recibido en 924A para identificar el UE 900 y usa cualquier dato de UE recibido en 908 y/o los datos de MNO recibidos en 908 o 922, si se produce 922, para obtener una localización para el UE 900 usando una solución de localización del plano de control o del plano de usuario.

[0188] En 928A, el IMS 994 (por ejemplo, una LRF en el IMS 994) devuelve la localización del UE 900 al PSAP heredado 982 (o a una entidad asociada con el PSAP 982, tal como una ALI).

[0189] En 924B, en el caso de un PSAP 980 con capacidad i3, el PSAP i3980 desrreferencia el URI de localización recibido en 914B enviando una solicitud de localización al IMS 994 (por ejemplo, una LRF en el IMS 994) indicada en el URI de localización y llevando el URI de localización. El bloque 924B puede corresponder al envío de la solicitud de localización 605B en la FIG. 6.

[0190] En 926B, el IMS 994 (por ejemplo, una LRF en el IMS 994) usa el URI de localización recibido en 924B para identificar el UE 900 y usa cualquier dato de UE recibido en 908 y/o los datos de MNO recibidos en 908 o 922, si se produce 922, para obtener una localización para el UE 900 usando una solución de localización del plano de control o del plano de usuario.

[0191] En 928B, el IMS 994 (por ejemplo, una LRF en el IMS 994) devuelve la localización del UE 900 al PSAP 980 con capacidad i3.

[0192] Se pueden producir bloques similares a o los mismos que 924B, 926B y 928B después de 912B para posibilitar que la ESInet 960 obtenga una localización para el UE 900 desde el IMS 994 (por ejemplo, desde una LRF en IMS 994) y, en base a la localización, enrutar la emergencia llame en 914B al PSAP 980 correcto. En ese caso, la ESInet 960 (por ejemplo, un ESRP en la ESInet 860 tal como el ESRP 666) puede enviar una solicitud de localización del UE 900 al IMS 994 en un bloque similar a o el mismo que 924B y puede recibir una localización del UE 900 desde el IMS 994 en un bloque similar a o el mismo que 928B.

[0193] Cabe destacar que los procedimientos y técnicas descritos en asociación con las FIGS. 4-9 pueden depender de que el UE que inició la llamada de emergencia envíe cualquier actualización de una LbyR (por ejemplo, para las FIGS. 4 y 7) o cualquier actualización de los datos de MNO (por ejemplo, como en 826 en la FIG. 8 y 920 en la FIG.

9) al SP OTT para que el UE posibilite que el SP OTT reenvíe la actualización a un PSAP o a una entidad de IMS, tal como una LRF (por ejemplo, como en 828 en la FIG. 8) o una E-CSCF (por ejemplo, como en 922 en la FIG. 9). Sin embargo, en modos de realización alternativos, se puede enviar una LbyR actualizada o datos de MNO actualizados (por ejemplo, que pueden resultar después de que el UE que inició la llamada de emergencia se traspase a una nueva SGSN o una nueva MME) a un PSAP o a una entidad de IMS en el MNO de servicio (tal como una LRF o una E-CSCF) por la AN o la PCN en el MNO de servicio (por ejemplo, por una MME o una SGSN en la AN o la PCN) en lugar de por el UE. Esto se puede producir, por ejemplo, si una entidad de IMS en el MNO de servicio para el UE que inició la llamada de emergencia o una entidad asociada con este (por ejemplo, un GMLC) envía una solicitud para cualquier LbyR actualizada o datos de MNO actualizados a una entidad en la AN o la PCN de MNO de servicio (por ejemplo, a una MME o una SGSN) después de detectar que el UE está iniciando una llamada de emergencia (por ejemplo, después de 708, 808 y 908 en cada una de las FIGS. 7, 8 y 9, respectivamente). Con estos modos de realización alternativos, es posible que no se necesite enviar la LbyR actualizada o los datos de MNO actualizados por el UE que inició la llamada de emergencia al SP OTT y por el SP OTT a un PSAP o a una entidad de IMS tal como una LRF o una E-CSCF.

[0194] La FIG. 10 ilustra varios componentes de muestra (representados por los bloques correspondientes) que se pueden incorporar en un aparato 1002, un aparato 1004 y un aparato 1006 (correspondientes a, por ejemplo, un dispositivo de usuario, tal como el UE 200, 300, 400, 500, 600, 700, 800 o 900, un nodo de red de acceso, tal como el nodo de red de acceso 240, y una entidad de red, tal como el SP OTT 150, el servidor de localización 170, etc., respectivamente) para la compatibilidad de las operaciones como se enseña en el presente documento. Se apreciará que estos componentes se pueden implementar en diferentes tipos de aparatos en diferentes implementaciones (por ejemplo, en un ASIC, en un SoC, etc.). Los componentes ilustrados también se pueden incorporar en otros aparatos en un sistema de comunicación. Por ejemplo, otros aparatos en un sistema pueden incluir componentes similares a los descritos para proporcionar una funcionalidad similar. Además, un aparato dado puede contener uno o más de los componentes. Por ejemplo, un aparato puede incluir múltiples componentes de transceptor que posibilitan que el aparato funcione en múltiples portadoras y/o se comunique por medio de diferentes tecnologías.

[0195] Cada uno del aparato 1002 y el aparato 1004 incluye al menos un dispositivo de comunicación inalámbrica (representado por los dispositivos de comunicación 1008 y 1014 (y el dispositivo de comunicación 1020 si el aparato 1004 es un retransmisor)) para comunicarse con otros nodos por medio de al menos una RAT designada. Cada dispositivo de comunicación 1008 incluye al menos un transmisor (representado mediante el transmisor 1010) para transmitir y codificar señales (por ejemplo, mensajes, indicaciones, información y así sucesivamente) y al menos un receptor (representado por el receptor 1012) para recibir y decodificar señales (por ejemplo, mensajes, indicaciones, información, pilotos y así sucesivamente). De forma similar, cada dispositivo de comunicación 1014 incluye al menos un transmisor (representado por el transmisor 1016) para transmitir señales (por ejemplo, mensajes, indicaciones, información, pilotos y así sucesivamente) y al menos un receptor (representado por el receptor 1018) para recibir señales (por ejemplo, mensajes, indicaciones, información y así sucesivamente). Si el aparato 1004 es una estación de retransmisión, cada dispositivo de comunicación 1020 puede incluir al menos un transmisor (representado por el transmisor 1022) para transmitir señales (por ejemplo, mensajes, indicaciones, información, pilotos y así sucesivamente) y al menos un receptor (representado por el receptor 1024) para recibir señales (por ejemplo, mensajes, indicaciones, información y así sucesivamente).

[0196] Un transmisor y un receptor pueden comprender un dispositivo integrado (por ejemplo, incorporado como un circuito transmisor y un circuito receptor de un único dispositivo de comunicación) en algunas implementaciones, pueden comprender un dispositivo transmisor separado y un dispositivo receptor separado en algunas implementaciones, o se pueden realizar de otras maneras en otras implementaciones. Un dispositivo de comunicación inalámbrica (por ejemplo, uno de múltiples dispositivos de comunicación inalámbrica) del aparato 1004 también puede comprender un módulo de escucha de red (NLM) o similar para realizar diversas mediciones.

[0197] El aparato 1006 (y el aparato 1004 si no es una estación de retransmisión) incluye al menos un dispositivo de comunicación (representado por el dispositivo de comunicación 1026 y, opcionalmente, 1020) para comunicarse con otros nodos. Por ejemplo, el dispositivo de comunicación 1026 puede comprender una interfaz de red que se configura para comunicarse con una o más entidades de red por medio de una red de retorno inalámbrica o cableada. En algunos aspectos, el dispositivo de comunicación 1026 se puede implementar como un transceptor configurado para la compatibilidad de comunicación de señal inalámbrica o cableada. Esta comunicación puede implicar, por ejemplo, enviar y recibir: mensajes, parámetros u otros tipos de información. En consecuencia, en el ejemplo de la FIG. 10, se muestra que el dispositivo de comunicación 1026 comprende un transmisor 1028 y un receptor 1030. De forma similar, si el aparato 1004 no es una estación de retransmisión, el dispositivo de comunicación 1020 puede comprender una interfaz de red que se configura para comunicarse con una o más entidades de red por medio de una red de retorno inalámbrica o cableada. Como con el dispositivo de comunicación 1026, se muestra que el dispositivo de comunicación 1020 comprende un transmisor 1022 y un receptor 1024.

[0198] Los aparatos 1002, 1004 y 1006 también incluyen otros componentes que se pueden usar junto con las operaciones relacionadas con la localización del SP OTT y el UE como se enseña en el presente documento. El aparato 1002 incluye un sistema de procesamiento 1032 y un módulo de posicionamiento 1054 para proporcionar funcionalidad relacionada con, por ejemplo, operaciones de dispositivo de usuario para la compatibilidad de operaciones relacionadas con la localización del SP OTT y el UE como se enseña en el presente documento, y para proporcionar otra funcionalidad de procesamiento. El aparato 1004 incluye un sistema de procesamiento 1034 y un módulo de posicionamiento 1056 para proporcionar funcionalidad relacionada con, por ejemplo, operaciones de nodo de red de acceso para la compatibilidad de operaciones relacionadas con la localización del SP OTT y el UE como se enseña en el presente documento, y para proporcionar otra funcionalidad de procesamiento. El aparato 1006 incluye un sistema de procesamiento 1036 y un módulo de posicionamiento 1058 para proporcionar funcionalidad relacionada con, por ejemplo, operaciones de red para la compatibilidad de operaciones relacionadas con la localización del SP OTT y el UE como se enseña en el presente documento, y para proporcionar otra funcionalidad de procesamiento.

[0199] Los aparatos 1002, 1004 y 1006 incluyen además componentes de memoria 1038, 1040 y 1042 (por ejemplo, incluyendo cada uno un dispositivo de memoria), respectivamente, para mantener información (por ejemplo, información indicativa de recursos reservados, umbrales, parámetros y así sucesivamente). Además, los aparatos 1002, 1004 y 1006 incluyen los dispositivos de interfaz de usuario 1044, 1046 y 1048, respectivamente, para proporcionar indicaciones (por ejemplo, indicaciones sonoras y/o visuales) a un usuario y/o para recibir entrada de usuario (por ejemplo, tras la actuación del usuario de un dispositivo de detección tal como un teclado, una pantalla táctil, un micrófono y así sucesivamente).

[0200] Por conveniencia, se muestra que los aparatos 1002, 1004 y/o 1006 en la FIG. 10 incluyen diversos componentes que se pueden configurar de acuerdo con los diversos ejemplos descritos en el presente documento. Sin embargo, se apreciará que los bloques ilustrados pueden tener diferentes funcionalidades en diferentes diseños.

[0201] Los componentes de la FIG. 10 se pueden implementar de diversas maneras. En algunas implementaciones, los componentes de la FIG. 10 se pueden implementar en uno o más circuitos tales como, por ejemplo, uno o más procesadores y/o uno o más ASIC (que pueden incluir uno o más procesadores). Aquí, cada circuito puede usar y/o incorporar al menos un componente de memoria para almacenar información o código ejecutable usado por el circuito para proporcionar esta funcionalidad. Por ejemplo, parte o toda la funcionalidad representada por los bloques 1008, 1032, 1038, 1044 y 1054 se puede implementar por un procesador y componente(s) de memoria del aparato 1002 (por ejemplo, por la ejecución de un código apropiado y/o por la configuración apropiada de los componentes de procesador). De forma similar, parte o toda la funcionalidad representada por los bloques 1014, 1020, 1034, 1040, 1046 y 1056 se puede implementar por un procesador y componente(s) de memoria del aparato 1004 (por ejemplo, por la ejecución de un código apropiado y/o por la configuración apropiada de los componentes de procesador). Además, parte o toda la funcionalidad representada por los bloques 1026, 1036, 1042, 1048 y 1058 se puede implementar por un procesador y componente(s) de memoria del aparato 1006 (por ejemplo, por la ejecución de un código apropiado y/o por la configuración apropiada de los componentes de procesador). Por ejemplo, los módulos de posicionamiento 1054, 1056 y 1058 pueden ser módulos ejecutables almacenados en la memoria, o pueden ser componentes de hardware/firmware acoplados a los sistemas de procesamiento 1032, 1034 y 1036.

[0202] La FIG. 11 es un diagrama de bloques que ilustra componentes ejemplares de un UE 1100 de acuerdo con al menos un aspecto de la divulgación. El UE 1100 puede corresponder a o representar cualquiera de los UE 1 a N en la FIG. 1A, el UE 200, el UE 300, el UE 400, el UE 500, el UE 600, el UE 700, el UE 800 o el UE 900. Las diversas características y funciones ilustradas en el diagrama de cajas de la FIG. 11 se pueden conectar entre sí usando un bus común (no mostrado en la FIG. 11) o se pueden conectar (como se muestra en la FIG. 11) por medio del/de los procesador(es) 1130. Los expertos en la técnica reconocerán que otras conexiones, mecanismos, rasgos característicos, funciones o similares se pueden proporcionar y adaptar como sea necesario para a

de forma operativa un dispositivo inalámbrico portátil real. Además, también se reconoce que uno o más de los rasgos característicos o funciones ilustrados en el ejemplo de la FIG. 11 se pueden subdividir adicionalmente, o se pueden combinar dos o más de los rasgos característicos o funciones ilustrados en la FIG. 11.

[0203] El UE 1100 puede incluir uno o más transceptores de Bluetooth 1114a que se pueden conectar a una o más antenas 1112. El transceptor de Bluetooth 1114a comprende dispositivos, hardware y/o software adecuados para comunicarse con y/o detectar señales a/desde un punto de acceso Bluetooth (por ejemplo, el AP 125 en la FIG. 1A). Adicionalmente o de forma alternativa, el UE 1100 puede incluir uno o más transceptores inalámbricos de red de área amplia (WAN) 1114b que se pueden conectar a una o más antenas 1112. El/los transceptor(es) WAN 1114b comprende(n) dispositivos, hardware y/o software adecuados para comunicarse con y/o detectar señales a/desde las WAN-WAP (puntos de acceso inalámbrico), y/o directamente con otros dispositivos inalámbricos dentro de un red (por ejemplo, dispositivos en la RAN 120 en la FIG. 1A). En un aspecto, el/los transceptor(es) WAN 1114b puede(n) ser adecuado(s) para comunicarse con un sistema LTE, un sistema WCDMA, un sistema CDMA2000, un TDMA, un GSM o cualquier otro tipo de tecnologías de red inalámbrica de área amplia. Adicionalmente o de forma alternativa, el UE 1100 puede incluir uno o más transceptores WLAN 1114c que pueden estar conectados a una o más antenas 1112. El/los transceptor(es) WLAN 1114c comprende(n) dispositivos, hardware y/o software adecuados para comunicarse y/o detectar señales a/desde las WLAN-WAP, y/o directamente con otros dispositivos inalámbricos dentro de una red (por ejemplo, un AP wifi 125 en la FIG. 1A). En un aspecto, el/los transceptor(es) WLAN 1114c puede(n) comprender un sistema de comunicación wifi (802.11x) adecuado para comunicarse con uno o más puntos de acceso inalámbrico; sin embargo, en otros aspectos, el transceptor WLAN 1114c puede comprender otro tipo de red de área local o red de área personal. Adicionalmente o de forma alternativa, el UE 1100 puede incluir un receptor de SPS 1114d. El receptor de SPS 1114d se puede conectar a una o más antenas 1112 para recibir señales de satélite (por ejemplo, para GPS o algún otro GNSS). El receptor de SPS 1114d puede comprender cualquier hardware y/o software adecuado para recibir y procesar señales del SPS. El receptor de SPS 1114d solicita información y operaciones como sea apropiado de los otros sistemas, y realiza los cálculos necesarios para determinar la posición del dispositivo móvil 1100 usando mediciones obtenidas por cualquier algoritmo de SPS adecuado. Adicionalmente o de forma alternativa, se puede usar cualquier otro tipo de tecnología de red inalámbrica, por ejemplo, banda ultraancha, ZigBee, USB inalámbrico, etc.

[0204] El UE 1100 puede incluir uno o más sensores 1120. El uno o más sensores 1120 pueden recopilar datos sobre el usuario, incluyendo datos sobre la posición, el movimiento, la orientación, el entorno, las actividades o la biometría del usuario. Los sensores pueden incluir, por ejemplo, sensores virtuales tal como un podómetro 1122a y sensores físicos tales como un acelerómetro 1122b, un giroscopio 1122c, un sensor biométrico 1120d y/o un número cualquiera de sensores diversos 1122n (por ejemplo, termómetro, barómetro, higrómetro).

[0205] El UE 1100 incluye uno o más procesadores 1130. El/los procesador(es) 1130 se puede(n) conectar al/a los transceptor(es) de Bluetooth 1114a, el/los transceptor(es) WAN 1114b, el/los transceptor(es) WLAN 1114c, el receptor de SPS 1114d y el uno o más sensores 1120. El procesador 1130 puede ser un procesador multinúcleo y, aunque se ilustra como una única unidad, puede incluir uno o más microprocesadores, microcontroladores y/o procesadores de señales digitales que proporcionan funciones de procesamiento, así como otras funcionalidades de cálculo y control.

[0206] El/los procesador(es) 1130 se puede(n) acoplar a la memoria 1140, que almacena datos e instrucciones de software para ejecutar la funcionalidad programada dentro del UE 1100. La memoria 1140 puede estar integrada en el/los procesador(es) 1130 (por ejemplo, dentro del mismo paquete de circuito integrado), y/o la memoria 1140 puede ser memoria externa al/a los procesador(es) 1130 y estar funcionalmente acoplada sobre un bus de datos. La memoria 1140 puede incluir un número cualquiera de módulos de aplicaciones nativas 1142a...1142n y una serie de módulos suministrados externamente por actualización aérea o cualquier otro medio y un número cualquiera de módulos de datos 1144a...1144n. Se debería apreciar que la organización del contenido de la memoria como se muestra en la FIG. 11 es meramente ejemplar y, como tal, la funcionalidad de los módulos y/o estructuras de datos se puede combinar, separar y/o estructurarse de diferentes maneras dependiendo de la implementación del UE 1100. La memoria 1140 puede almacenar código de programa (por ejemplo, en uno o más de los módulos de aplicaciones de 1142a a 1142n) que se puede ejecutar en el/los procesador(es) 1130 para posibilitar que el UE 1100 realice algunos o todos de los diversos procedimientos y técnicas descritos en el presente documento.

[0207] El UE 1100 también puede incluir un módulo de posicionamiento 1180 configurado para realizar operaciones de dispositivo de usuario para la compatibilidad del SP OTT y la localización relacionada con el UE, como se describe en el presente documento. El módulo de posicionamiento 1180 puede ser un módulo ejecutable almacenado en la memoria 1140 y que se ejecuta en el/los procesador(es) 1130, o puede ser un componente de hardware o firmware acoplado al/a los procesador(es) 1130.

[0208] Si bien los módulos mostrados en la FIG. 11 se ilustran en el ejemplo como contenidos en la memoria 1140, se reconoce que en determinadas implementaciones dichos procedimientos se pueden proporcionar o de otro modo organizarse de forma operativa usando otros o mecanismos adicionales. Por ejemplo, cualquiera de los módulos de aplicaciones 1142a...1142n se puede proporcionar en el firmware. El/los procesador(es) 1130 puede(n) incluir cualquier forma de lógica adecuada para realizar al menos las técnicas proporcionadas en el presente documento. Por ejemplo, el/los procesador(es) 1130 se puede(n) configurar de forma operativa en base a las instrucciones en la memoria 1140 para iniciar selectivamente una o más rutinas que aprovechan los datos de movimiento para su uso en otras partes del UE 1100.

[0209] El UE 1100 puede incluir una interfaz de usuario 1150 que proporciona cualquier sistema de interfaz adecuado, tal como un micrófono/altavoz 1152, un panel táctil 1153, un teclado 1154, una pantalla 1156, una cámara 1158 y sensores de proximidad 1159 que permite la interacción del usuario con el UE 1100. El micrófono/altavoz 1152 proporciona servicios de reconocimiento de voz y/o comunicación de voz usando el/los transceptor(es) WAN 1114b y/o el/los transceptor(es) WLAN 1114c. El teclado 1154 comprende cualquier botón adecuado para la entrada de usuario. La pantalla 1156 comprende cualquier pantalla adecuada, tal como, por ejemplo, una pantalla LCD retroiluminada, y puede incluir además una pantalla táctil para modalidades adicionales de entrada de usuario. Además, cualquier funcionalidad de entrada tal como la funcionalidad demostrada por el micrófono/altavoz 1152, la cámara 1158 o el teclado 1154 también se puede considerar una entrada de sensor análoga a las entradas del uno o más sensores 1120.

[0210] El UE 1100 incluye además una fuente de alimentación 1160, por ejemplo, una batería, para suministrar energía a los diversos componentes del UE 1100. Sin embargo, se apreciará que el UE 1100 puede no incluir todos los elementos ilustrados y lo más probable es que incluya solo un subconjunto de elementos en base a los requisitos del dispositivo y las consideraciones de diseño.

[0211] Como se indica anteriormente, el uno o más sensores 1120 pueden recopilar datos sobre el usuario, incluyendo datos sobre la posición, la orientación, el movimiento, el entorno, las actividades o la biometría del usuario. Los sensores pueden incluir, por ejemplo, un podómetro 1122a (que puede ser un dispositivo discreto o un módulo funcional en base a datos de otros sensores), un acelerómetro 1122b, un giroscopio 1122c, un sensor biométrico 1120d y/o un número cualquiera de sensores diversos 1122n. Además, el/los transceptor(es) de Bluetooth 1114a, el/los transceptor(es) WAN 1114b, el/los transceptor(es) WLAN 1114c y/o el receptor de SPS 1114d se puede(n) utilizar como sensores en la medida en que se puedan usar para generar datos en la posición, el movimiento, el entorno y/o las actividades del usuario. En consecuencia, cuando la presente descripción se refiere al uno o más sensores 1120 en general, o a las lecturas de sensores o los datos de sensor, se debe entender que el/los transceptor(es) de Bluetooth 1114a, el/los transceptor(es) WAN 1114b, el/los transceptor(es) WLAN 1114c y/o el receptor de SPS 1114d se pueden considerar sensores, y los datos obtenidos de los mismos se pueden considerar lecturas de sensores o datos de sensor.

[0212] En un modo de realización, el sensor biométrico 1122d incluye un sensor para identificar a un usuario. Por ejemplo, el sensor biométrico 1122d puede ser un sensor para reconocimiento de voz, reconocimiento de huellas dactilares, reconocimiento de huellas palmares, reconocimiento facial o reconocimiento de iris. El sensor biométrico 1122d puede ser un sensor dedicado específicamente diseñado para reconocimiento de voz, reconocimiento de huellas dactilares, reconocimiento de huellas palmares, reconocimiento facial y/o reconocimiento de iris. En otro contexto posible, el micrófono/altavoz 1152 se usa como un sensor para el reconocimiento de voz. En otro contexto posible, el teclado 1154 se usa como un sensor para el reconocimiento de huellas digitales y/o el reconocimiento de huellas palmares. Aún en otro contexto posible, la cámara 1158 se usa como un sensor para el reconocimiento facial y/o el reconocimiento del iris.

[0213] Como se indica anteriormente, el/los procesador(es) 1130 se puede(n) acoplar a la memoria 1140, que almacena datos e instrucciones de software para ejecutar la funcionalidad programada dentro del UE 1100. La memoria 1140 puede incluir un número cualquiera de módulos de aplicaciones 1142a...1142n y un número cualquiera de módulos de datos 1144a...1144n. En un modo de realización, uno o más de los módulos de aplicaciones 1142a...1142n, por ejemplo, el módulo de aplicación 1142a, utiliza datos detectados recopilados de uno o más del podómetro 1122a, el acelerómetro 1122b, el giroscopio 1122c, los sensores biométricos 1120d y/o los sensores diversos 1122n. Los datos detectados se pueden almacenar en uno o más de los módulos de datos 1144a...módulo de datos 1144n, por ejemplo, el módulo de datos 1144a.

[0214] En consecuencia, un modo de realización de la divulgación puede incluir un UE (por ejemplo, el UE 1100) que incluye la capacidad de realizar las funciones descritas en el presente documento. Como se apreciará por los expertos en la técnica, los diversos elementos lógicos se pueden incorporar en elementos discretos, en módulos de software ejecutados en un procesador o en cualquier combinación de software y hardware para lograr la funcionalidad divulgada en el presente documento. Por ejemplo, el procesador 1130, la memoria 1140, la interfaz de usuario 1150 y el módulo de posicionamiento 1180 se pueden usar de forma cooperativa para cargar, almacenar y ejecutar las diversas funciones divulgadas en el presente documento y, por tanto, la lógica para realizar estas funciones se puede distribuir en diversos elementos. De forma alternativa, la funcionalidad se podría incorporar en un componente discreto. Por lo tanto, los rasgos característicos del aparato 1100 en la FIG. 11 se han de considerar meramente ilustrativas y la divulgación no se limita a los rasgos característicos o disposición ilustrados.

[0215] La comunicación inalámbrica entre el UE 1100 y la RAN 120/MME 142 se puede basar en diferentes tecnologías, tales como LTE, CDMA, WCDMA, acceso múltiple por división de tiempo (TDMA), acceso múltiple por división de frecuencia (FDMA), multiplexado por división ortogonal de frecuencia (OFDM), GSM u otros protocolos que se pueden usar en una red de comunicaciones inalámbricas o en una red de comunicaciones de datos. Como se analiza anteriormente y se conoce en la técnica, las transmisiones de voz y/o datos se pueden transmitir a los UE 1100 desde la RAN 120 usando una variedad de redes y configuraciones. En consecuencia, las ilustraciones proporcionadas en el presente documento no pretenden limitar los modos de realización de la divulgación y están meramente para asistir en la descripción de los aspectos de los modos de realización de la divulgación.

[0216] La FIG. 12 ilustra un dispositivo de comunicación 1200 que incluye componentes estructurales para realizar la funcionalidad. El dispositivo de comunicación 1200 puede corresponder a cualquiera de los dispositivos de comunicación indicados anteriormente, incluyendo pero sin limitarse al UE 1100, cualquier componente de la RAN 120 (por ejemplo, los eNodos B 122-126), cualquier componente de la red central 140 (por ejemplo, la MME 142 o 144, el E-SMLC 172, la S-GW 146, la PDG 148, el ELS 370/794, la E-CSCF 443/543/643, la LRF 448/548/648), cualquier componente acoplado a la red central 140 y/o Internet 175 (por ejemplo, el servidor de localización 170, el GMLC/SLP 170, la ESInet 160, el PSAP 180) y así sucesivamente. Por tanto, el dispositivo de comunicación 1200 puede corresponder a cualquier dispositivo electrónico que se configure para comunicarse con (o facilitar la comunicación con) una o más entidades sobre el sistema de comunicaciones inalámbricas 100A de la FIG. 1A o usando la configuración particular 100B de la FIG. 1B.

[0217] En referencia a la FIG. 12, el dispositivo de comunicación 1200 incluye los circuitos transceptores configurados para recibir y/o transmitir información 1205. En un ejemplo, si el dispositivo de comunicación 1200 corresponde a un dispositivo de comunicaciones inalámbricas (por ejemplo, el UE 1100, uno de los eNB 122-126, etc.), los circuitos transceptores configurados para recibir y/o transmitir información 1205 pueden incluir una interfaz de comunicaciones inalámbricas (por ejemplo, Bluetooth, wifi, 2G, CDMA, WCDMA, 3G, 4G, LTE, etc.) tal como un transceptor inalámbrico y hardware asociado (por ejemplo, una antena de RF, un MÓDEM, un modulador y/o demodulador, etc.). En otro ejemplo, los circuitos transceptores configurados para recibir y/o transmitir información 1205 pueden corresponder a una interfaz de comunicaciones por cable (por ejemplo, una conexión en serie, una conexión USB o Firewire, una conexión de Ethernet a través de la que se puede acceder a Internet 175, etc.). Por tanto, si el dispositivo de comunicación 1200 corresponde a algún tipo de servidor basado en la red (por ejemplo, la S-GW 146, la PDG 148, la MME 142/144, el E-SMLC 172, el servidor de localización 170, el ELS 370/794, la E-CSCF 443/543/643, la LRF 448/548/648, etc.), los circuitos transceptores configurados para recibir y/o transmitir información 1205 pueden corresponder a una tarjeta Ethernet, en un ejemplo, que conecta el servidor basado en la red a otras entidades de comunicación por medio de un protocolo Ethernet. En otro ejemplo, los circuitos transceptores configurados para recibir y/o transmitir información 1205 pueden incluir hardware sensorial o de medición, por el que el dispositivo de comunicación 1200 pueda supervisar su entorno local (por ejemplo, un acelerómetro, un sensor de temperatura, un sensor de luz, una antena para supervisar señales de RF locales, etc.). Los circuitos transceptores configurados para recibir y/o transmitir información 1205 también pueden incluir un software que, cuando se ejecuta, permite que el hardware asociado de los circuitos transceptores configurados para recibir y/o transmitir información 1205 realice su(s) función/funciones de recepción y/o transmisión. Sin embargo, los circuitos transceptores configurados para recibir y/o transmitir información 1205 no corresponden solo al software, y los circuitos transceptores configurados para recibir y/o transmitir información 1205 dependen al menos en parte del hardware estructural para lograr su funcionalidad.

[0218] En referencia a la FIG. 12, el dispositivo de comunicación 1200 incluye además al menos un procesador configurado para procesar la información 1210. Las implementaciones de ejemplo del tipo de procesamiento que se puede realizar por el al menos un procesador configurado para procesar la información 1210 incluyen pero no se limitan a realizar determinaciones, establecer conexiones, realizar selecciones entre diferentes opciones de información, realizar evaluaciones relacionadas con los datos, interactuar con sensores acoplados al dispositivo de comunicación 1200 para realizar operaciones de medición, convertir la información de un formato a otro (por ejemplo, entre protocolos diferentes tales como .wmv a .avi, etc.) y así sucesivamente. Por ejemplo, el al menos un procesador configurado para procesar la información 1210 puede incluir un procesador de propósito general, un DSP, un ASIC, una matriz de puertas programables in situ (FPGA) u otro dispositivo de lógica programable, puertas discretas o lógica de transistores, componentes de hardware discretos o cualquier combinación de los mismos diseñada para realizar las funciones descritas en el presente documento. Un procesador de propósito general puede ser un microprocesador, pero, como alternativa, el al menos un procesador configurado para procesar la información 310 puede ser cualquier procesador, controlador, microcontrolador o máquina de estados convencional. Un procesador también se puede implementar como una combinación de dispositivos informáticos (por ejemplo, una combinación de un DSP y un microprocesador, una pluralidad de microprocesadores, uno o más microprocesadores junto con un núcleo de DSP o cualquier otra configuración de este tipo). El al menos un procesador configurado para procesar la información 1210 también puede incluir software que, cuando se ejecuta, permite que el hardware asociado del al menos un procesador configurado para procesar la información 1210 realice su(s) función/funciones de procesamiento. Sin embargo, el al menos un procesador configurado para procesar la información 1210 no corresponde solo al software, y el al menos un procesador configurado para procesar la información 1210 depende al menos en parte del hardware estructural para lograr su funcionalidad.

[0219] En referencia a la FIG. 12, el dispositivo de comunicación 1200 incluye además memoria configurada para almacenar información 1215. En un ejemplo, la memoria configurada para almacenar información 1215 puede incluir al menos una memoria no transitoria y un hardware asociado (por ejemplo, un controlador de memoria, etc.). Por ejemplo, la memoria no transitoria incluida en la memoria configurada para almacenar información 1215 puede corresponder a RAM, memoria flash, memoria de solo lectura (ROM), ROM programable borrable (EPROM), ROM programable borrable eléctricamente (EEPROM), registros, disco duro, un disco extraíble, un CD-ROM o cualquier otra forma de medio de almacenamiento conocido en la técnica. La memoria configurada para almacenar información 1215 puede incluir también software que, cuando se ejecuta, permite al hardware asociado de la memoria configurada almacenar la información 1215 para realizar su(s) función/funciones de almacenamiento. Sin embargo, la memoria configurada para almacenar información 1215 no corresponde solo al software, y la memoria configurada para almacenar información 1215 depende al menos en parte del hardware estructural para lograr su funcionalidad.

[0220] En referencia a la FIG. 12, el dispositivo de comunicación 1200 incluye además opcionalmente circuitos de salida de interfaz de usuario configurados para presentar información 1220. En un ejemplo, los circuitos de salida de interfaz de usuario configurados para presentar la información 1220 pueden incluir al menos un dispositivo de salida y hardware asociado. Por ejemplo, el dispositivo de salida puede incluir un dispositivo de salida de vídeo (por ejemplo, una pantalla de visualización, un puerto que pueda llevar información de vídeo tal como USB, HDMI, etc.), un dispositivo de salida de audio (por ejemplo, altavoces, un puerto que pueda llevar información de audio, tal como un conector de micrófono, USB, HDMI, etc.), un dispositivo de vibración y/o cualquier otro dispositivo por el que se pueda dar formato a la información para su emisión o se emita realmente por un usuario u operador del dispositivo de comunicación 1200. Por ejemplo, si el dispositivo de comunicación 1200 corresponde al UE 1100 como se muestra en la FIG. 11, los circuitos de salida de interfaz de usuario configurados para presentar la información 1220 pueden incluir la pantalla 1056 y/o el altavoz 1052. En otro ejemplo, los circuitos de salida de interfaz de usuario configurados para presentar la información 1220 se pueden omitir para determinados dispositivos de comunicación, tales como dispositivos de comunicación de red que no tienen un usuario local (por ejemplo, conmutadores o enrutadores de red, servidores remotos, etc.). Los circuitos de salida de interfaz de usuario configurados para presentar la información 1220 también pueden incluir software que, cuando se ejecuta, permite que el hardware asociado de los circuitos de salida de interfaz de usuario configurados para presentar la información 1220 realicen su(s) función/funciones de presentación. Sin embargo, los circuitos de salida de interfaz de usuario configurados para presentar la información 1220 no corresponden solo al software, y los circuitos de salida de interfaz de usuario configurados para presentar la información 1220 dependen al menos en parte del hardware estructural para lograr su funcionalidad.

[0221] En referencia a la FIG. 12, el dispositivo de comunicación 1200 incluye además opcionalmente circuitos de entrada de interfaz de usuario configurados para recibir la entrada de usuario local 1225. En un ejemplo, los circuitos de entrada de interfaz de usuario configurados para recibir la entrada de usuario local 325 pueden incluir al menos un dispositivo de entrada de usuario y hardware asociado. Por ejemplo, el dispositivo de entrada de usuario puede incluir botones, una pantalla táctil, un teclado, una cámara, un dispositivo de entrada de audio (por ejemplo, un micrófono o un puerto que pueda llevar información de audio, tal como un conector de micrófono, etc.) y/o cualquier otro dispositivo por el que se pueda recibir información desde un usuario u operador del dispositivo de comunicación 1200. Por ejemplo, si el dispositivo de comunicación 1200 corresponde al UE 1100 como se muestra en la FIG. 11, los circuitos de entrada de interfaz de usuario configurados para recibir la entrada de usuario local 1225 pueden incluir el panel táctil 1153, el teclado 1154, el micrófono 1152, etc. En otro ejemplo, los circuitos de entrada de interfaz de usuario configurados para recibir la entrada de usuario local 1225 se pueden omitir para determinados dispositivos de comunicación, tales como dispositivos de comunicación de red que no tienen un usuario local (por ejemplo, conmutadores o enrutadores de red, servidores remotos, etc.). Los circuitos de entrada de interfaz de usuario configurados para recibir la entrada de usuario local 1225 también pueden incluir software que, cuando se ejecuta, permite que el hardware asociado de los circuitos de entrada de interfaz de usuario configurados para recibir la entrada de usuario local 1225 realice su(s) función/funciones de recepción de entrada. Sin embargo, los circuitos de entrada de interfaz de usuario configurados para recibir la entrada de usuario local 1225 no corresponden solo al software, y los circuitos de entrada de interfaz de usuario configurados para recibir la entrada de usuario local 1225 dependen al menos en parte del hardware estructural para lograr su funcionalidad.

[0222] En referencia a la FIG. 12, si bien los componentes estructurales configurados de 1205 a 1225 se muestran como bloques separados o distintos en la FIG. 12, que están acoplados entre sí por medio de un bus de comunicación asociado 1230, se apreciará que el hardware y/o software por el que los componentes estructurales configurados respectivos de 1205 a 1225 realizan su funcionalidad respectiva se pueden solapar en parte. Por ejemplo, cualquier software usado para facilitar la funcionalidad de los componentes estructurales configurados de 1205 a 1225 se puede almacenar en la memoria no transitoria asociada con la memoria configurada para almacenar información 1215, de modo que los componentes estructurales configurados de 1205 a 1225 realicen cada uno su funcionalidad respectiva (es decir, en este caso, ejecución de software) basado en parte en la operación del software almacenado por la memoria configurada para almacenar información 1215. Asimismo, el hardware que está directamente asociado con uno de los componentes estructurales configurados de 1205 a 1225 se puede pedir prestado o usar por otros componentes estructurales configurados de 1205 a 1225 de vez en cuando. Por ejemplo, el al menos un procesador configurado para procesar información 1210 puede dar formato a los datos en un formato apropiado antes de transmitirse por los circuitos transceptores configurados para recibir y/o transmitir información 1205, de modo que los circuitos transceptores configurados para recibir y/o transmitir información 1205 realizan su funcionalidad (es decir, en este caso, transmisión de datos) basado en parte en la operación del hardware estructural asociado con el al menos un procesador configurado para procesar información 1210.

[0223] En consecuencia, los diversos componentes estructurales de 1205 a 1225 están destinados a pedir un aspecto que se implementa al menos parcialmente con hardware estructural, y no están destinados a correlacionarse a implementaciones solo de software que son independientes de hardware y/o a interpretaciones funcionales no estructurales. Otras interacciones o cooperación entre los componentes estructurales de 1205 a 1225 serán claras para un experto en la técnica a partir de una revisión de los aspectos descritos a continuación con más detalle.

[0224] Los diversos modos de realización también se pueden implementar en cualquiera de una variedad de dispositivos de servidor disponibles comercialmente, tales como el servidor 1300 ilustrado en la FIG. 13. En un ejemplo, el servidor 1300 puede corresponder a una configuración de ejemplo de la MME 142, el SP OTT 150/350/450/550/650/750/850/950, ESInet 160, E-SMLC 172, servidor de localización/GMLC/SLP 170, el ELS 370/794, la E-CSCF 443/543/643, la LRF 448/548/648 y el PSAP 180 descritos anteriormente. En la FIG. 13, el servidor 1300 incluye un procesador 1301 acoplado a la memoria volátil 1302 y una memoria no volátil de gran capacidad, tal como una unidad de disco 1303. El servidor 1300 también puede incluir una unidad de disco flexible, una unidad de disco compacto (CD) o disco DVD 1306 acoplada al procesador 1301. El servidor 1300 también puede incluir puertos de acceso a red 1304 acoplados al procesador 1301 para establecer conexiones de datos con una red 1307, tal como una red de área local acoplada a otros ordenadores y servidores del sistema de radiodifusión o a Internet. En contexto con la FIG. 12, se apreciará que el servidor 1300 de la FIG. 13 ilustra una implementación de ejemplo del dispositivo de comunicación 1200, con lo que la lógica configurada para transmitir y/o recibir la información 1205 corresponde a los puertos de acceso a red 1304 usados por el servidor 1300 para comunicarse con la red 1307, la lógica configurada para procesar la información 1210 corresponde al procesador 1301, y la configuración lógica para almacenar la información 1215 corresponde a cualquier combinación de la memoria volátil 1302, la unidad de disco magnético 1303 y/o la unidad de disco óptico 1306. La lógica opcional configurada para presentar la información 1220 y la lógica opcional configurada para recibir la entrada del usuario local 1225 no se muestran explícitamente en la FIG. 13 y pueden o no estar incluidas en el mismo. Por tanto, la FIG. 13 ayuda a demostrar que el dispositivo de comunicación 1200 se puede implementar como un servidor, además de una implementación de UE como en la FIG.

11. En consecuencia, un modo de realización de la divulgación puede incluir un servidor (por ejemplo, el servidor 1300) que incluye la capacidad de realizar las funciones descritas en el presente documento, tales como las funciones descritas con referencia a la MME 142, SP OTT 150, ESInet 160, E-SMLC 172, servidor de localización/GMLC/SLP 170, el ELS 370/794, la E-CSCF 443/543/643, la LRF 448/548/648 y el PSAP 180, por ejemplo.

[0225] La FIG. 14 ilustra un flujo ejemplar para localizar un UE realizado por un nodo de red de acceso que da servicio al UE, tal como cualquier componente de la RAN 120 o la CN 140 en las FIGS. 1A y 1B. Por ejemplo, el nodo de red de acceso puede corresponder a la MME 142.

[0226] En 1410, el nodo de red de acceso recibe un primer mensaje desde el UE, tal como en 206A de la FIG. 2A o 202B de la FIG. 2B. Por ejemplo, cuando el nodo de red de acceso corresponde a una MME que es compatible con LTE, los primeros mensajes pueden ser una solicitud de conexión NAS o una solicitud de actualización de área de seguimiento NAS. Cuando el nodo de red de acceso corresponde a una SGSN que es compatible con UMTS, el primer mensaje puede ser una solicitud de conexión GPRS o una solicitud de actualización de área de enrutamiento GPRS.

[0227] En 1420, el nodo de red de acceso determina una referencia de localización para el UE. La referencia de localización puede ser para un servidor de localización, tal como el servidor de localización 170 en la FIG. 1A o el GMLC/SLP 170 en la FIG. 1B, que pertenece a un operador para el nodo de red de acceso, y posibilita que se localice el UE. La referencia de localización para el UE puede incluir la dirección del servidor de localización y una referencia de UE del UE. La referencia de UE se puede asignar por el servidor de localización y puede incluir una dirección IP, una IMSI, una TMSI, una dirección del nodo de red de acceso o cualquier combinación de los mismos. La referencia de UE también puede ser cifrada.

[0228] Como se analiza anteriormente con referencia a 208A de la FIG. 2A o 204B de la FIG. 2B, la determinación en 1420 puede incluir enviar una solicitud de una referencia de localización para el UE al servidor de localización y recibir la referencia de localización para el UE desde el servidor de localización. De forma alternativa, como se analiza anteriormente, el nodo de red de acceso puede generar la referencia de localización para el UE por sí mismo. En ese caso, el nodo de red de acceso puede firmar digitalmente la referencia de localización para el UE para indicar que la referencia de localización para el UE se generó por el nodo de red de acceso para el operador.

[0229] En 1430, el nodo de red de acceso envía un segundo mensaje al UE, tal como en 212A de la FIG. 2A o 206B de la FIG. 2B. El segundo mensaje puede incluir la referencia de localización. Cuando el nodo de red de acceso corresponde a una MME que es compatible con LTE, los segundos mensajes pueden ser una aceptación de conexión NAS o una aceptación de actualización de área de seguimiento NAS. Cuando el nodo de red de acceso corresponde a una SGSN que es compatible con UMTS, los segundos mensajes pueden ser una aceptación de conexión GPRS o una aceptación de actualización de área de enrutamiento GPRS.

[0230] El UE puede incluir la referencia de localización para el UE en una solicitud de llamada de servicios de emergencia enviada a un SP OTT, tal como el SP OTT 150. El UE puede enviar la solicitud de llamada de servicios de emergencia al SP OTT por medio de una red de acceso diferente a la red de acceso del nodo de red de acceso. El SP OTT puede obtener la localización del UE del servidor de localización en base a la referencia de localización.

[0231] Aunque no se muestra, el flujo ilustrado en la FIG. 14 puede incluir además autenticar el UE antes de enviar el segundo mensaje. Adicionalmente, el flujo ilustrado en la FIG. 14 puede incluir además determinar periódicamente una nueva referencia de localización para el UE mientras el UE está conectado al nodo de red de acceso y enviar la nueva referencia de localización al UE.

[0232] La FIG. 15 ilustra un flujo ejemplar para localizar un UE realizado en un servidor de localización, tal como el servidor de localización 170 en la FIG. 1A o el GMLC/SLP 170 en la FIG. 1B.

[0233] En 1510, el servidor de localización recibe una solicitud de una referencia de localización para el UE desde un nodo de red de acceso que da servicio al UE, tal como en 208A de la FIG. 2A o 204B de la FIG. 2B.

[0234] En 1520, el servidor de localización envía la referencia de localización para el UE al nodo de red de acceso, tal como en 208A de la FIG. 2A o 204B de la FIG. 2B. La referencia de localización puede incluir una dirección del servidor de localización y una referencia local para el UE.

[0235] En 1530, el servidor de localización recibe una solicitud de localización para una localización del UE desde una entidad de red distinta del nodo de red de acceso, tal como en 216A de la FIG. 2A o 214B de la FIG. 2B. La solicitud de localización puede incluir la referencia de localización para el UE. La otra entidad de red puede ser una entidad de red que pertenece a un SP OTT, un proveedor de ESInet o un PSAP, por ejemplo.

[0236] En 1540, el servidor de localización puede determinar una estimación de localización para el UE, tal como en 218a de la FIG. 2A o 216B-226B o 228B de la FIG. 2B. Cuando el servidor de localización corresponde a un SLP, determinar la estimación de localización para el UE puede incluir establecer una sesión SUPL con el UE. Cuando el servidor de localización corresponde a un GMLC, determinar la estimación de localización para el UE puede incluir determinar la estimación de localización usando una solución de localización del plano de control. En ese caso, determinar la estimación de localización usando la solución de localización del plano de control puede incluir enviar una solicitud de localización al nodo de red de acceso y recibir una respuesta de localización desde el nodo de red de acceso que contiene la estimación de localización, como en 218A de la FIG. 2A o 216B-226B de la FIG. 2B.

[0237] En 1550, el servidor de localización envía la estimación de localización para el UE a la entidad de red, tal como en 224A de la FIG. 2A o 232B de la FIG. 2B.

[0238] El UE incluye la referencia de localización en una solicitud de llamada de servicios de emergencia enviada a un SP OTT. En un modo de realización, el UE puede enviar la solicitud de llamada de servicios de emergencia al SP OTT por medio de una red de acceso para un operador diferente al operador para el servidor de localización.

[0239] La FIG. 16 ilustra un flujo ejemplar para localizar un UE realizado en un servidor de localización, tal como el servidor de localización 170 en la FIG. 1A o el GMLC/SLP 170 en la FIG. 1B.

[0240] En 1610, el servidor de localización recibe una solicitud de localización para una localización del UE desde una entidad de red distinta de un nodo de red de acceso que da servicio al UE, tal como en 216A de la FIG. 2A o 214B de la FIG. 2B. La solicitud de localización puede incluir una referencia de localización para el UE. La referencia de localización puede incluir una referencia de UE para el UE. La referencia de UE puede ser una dirección IP, una IMSI, una TMSI, una dirección del nodo de red de acceso o cualquier combinación de los mismos. La otra entidad de red puede ser una entidad de red que pertenece a un SP OTT, un proveedor de ESInet o un PSAP, por ejemplo.

[0241] En 1620, el servidor de localización autentica la referencia de localización para el UE. La referencia de localización puede incluir una firma digital, caso en el que, autenticar la referencia de localización puede incluir autenticar la firma digital.

[0242] En 1630, el servidor de localización determina una estimación de localización para el UE en base a la referencia de UE en la referencia de localización para el UE, tal como en 218A de la FIG. 2A o 216B-226B o 228B de la FIG. 2B. En un modo de realización, la referencia de UE se puede cifrar, caso en el que, determinar una estimación de localización para el UE puede incluir descifrar la referencia de UE cifrada. Cuando el servidor de localización corresponde a un SLP, determinar la estimación de localización para el UE puede incluir establecer una sesión SUPL con el UE. Cuando el servidor de localización corresponde a un GMLC, determinar la estimación de localización para el UE puede incluir determinar la estimación de localización usando una solución de localización del plano de control. En ese caso, determinar la estimación de localización usando la solución de localización del plano de control puede incluir enviar una solicitud de localización al nodo de red de acceso y recibir una respuesta de localización desde el nodo de red de acceso que contiene la estimación de localización, como en 218A de la FIG. 2A o 216B-226B de la FIG. 2B.

[0243] En 1640, el servidor de localización envía la estimación de localización para el UE a la otra entidad de red, tal como en 224A de la FIG. 2A o 232B de la FIG. 2B.

[0244] El UE puede incluir la referencia de localización para el UE en una solicitud de llamada de servicios de emergencia enviada a un SP OTT, tal como el SP OTT.

[0245] La FIG. 17 ilustra un flujo ejemplar para localizar un UE que realiza una llamada realizada por el UE, tal como el UE 1100. La llamada puede ser una llamada de emergencia.

[0246] En 1710, el UE envía un primer mensaje a un nodo de red de acceso que da servicio al UE. Cuando el nodo de red de acceso corresponde a una MME que es compatible con LTE, los primeros mensajes pueden ser una solicitud de conexión NAS o una solicitud de actualización de área de seguimiento NAS. Cuando el nodo de red de acceso corresponde a una SGSN que es compatible con UMTS, el primer mensaje puede ser una solicitud de conexión GPRS o una solicitud de actualización de área de enrutamiento GPRS.

[0247] En 1720, el UE recibe un segundo mensaje desde el nodo de red de acceso que incluye una referencia de localización para el UE. La referencia de localización puede ser para un servidor de localización, tal como el servidor de localización 170 en la FIG. 1A o el GMLC/SLP 170 en la FIG. 1B, que pertenece a un operador para el nodo de red de acceso y puede posibilitar que se localice el UE para la llamada. La referencia de localización para el UE puede incluir la dirección del servidor de localización y una referencia de UE del UE. Cuando el nodo de red de acceso corresponde a una MME que es compatible con LTE, los primeros mensajes pueden ser una solicitud de conexión NAS o una solicitud de actualización de área de seguimiento NAS. Cuando el nodo de red de acceso corresponde a una SGSN que es compatible con UMTS, el primer mensaje puede ser una solicitud de conexión GPRS o una solicitud de actualización de área de enrutamiento GPRS. Aunque no se ilustra en la FIG. 17, el flujo puede incluir además autenticar el UE al nodo de red de acceso antes de recibir el segundo mensaje.

[0248] En 1730, el UE recibe una solicitud para la llamada desde un usuario del UE.

[0249] En 1740, el UE envía una solicitud para la llamada a un SP OTT, tal como el SP OTT 150. La solicitud para la llamada puede incluir la referencia de localización para el UE. En un modo de realización, la solicitud de llamada se envía por el UE al SP OTT por medio de una red de acceso diferente de la red de acceso para el nodo de red de acceso.

[0250] Aunque no se ilustra en la FIG. 17, el flujo puede incluir además recibir periódicamente una nueva referencia de localización para el UE desde el nodo de red de acceso mientras el UE está conectado al nodo de red de acceso.

[0251] La FIG. 18 ilustra un flujo ejemplar para la compatibilidad de llamadas de emergencia en un proveedor de servicios OTT, tal como el SP o Tt 150. En un modo de realización, el flujo ilustrado en la FIG. 18 se puede realizar por, o hacer que se realice por, el módulo de posicionamiento 1058.

[0252] En 1810, el SP OTT 150 recibe un primer mensaje que comprende una solicitud de llamada de emergencia desde un UE, tal como cualquiera de los UE 200, 300, 400, 500, 600, 700, 800, 900, 1002 y 1100, como en 806 y 906. El primer mensaje se transfiere al SP OTT 150 por medio de un MNO de servicio para el UE, tal como el m No de servicio 790, 890 o 990. El primer mensaje incluye una dirección para un IMS, tal como el IMS 894 o 994, para el MNO de servicio.

[0253] En 820, el SP OTT 150 envía un segundo mensaje al IMS en base a la dirección, como en 808 y 908. El segundo mensaje puede ser una solicitud para la llamada de emergencia. El primer mensaje, el segundo mensaje o ambos mensajes pueden ser una INVITACIÓN SIP.

[0254] Aunque no se ilustra en la FIG. 18, el flujo puede incluir además recibir un tercer mensaje desde el IMS que comprende información de enrutamiento para un PSAP de destino, como en 812, y enviar un cuarto mensaje a o hacia el PSAP en base a la información de enrutamiento. El tercer mensaje puede ser un mensaje 300 múltiples opciones de SIP, y el cuarto mensaje puede ser una solicitud para la llamada de emergencia. La dirección para el IMS puede ser para una LRF. La información de enrutamiento puede incluir un ID de referencia, caso en el que, el flujo puede incluir además el ID de referencia en el cuarto mensaje, donde el ID de referencia posibilita que el PSAP obtenga una localización para el UE desde la LRF.

[0255] El IMS puede enviar un quinto mensaje a o hacia un PSAP de destino, donde el quinto mensaje puede ser una solicitud de llamada de emergencia para el UE. La dirección para el IMS puede ser para una E-CSCF. El IMS incluye un identificador de referencia en el quinto mensaje, donde el identificador de referencia posibilita que el PSAP obtenga una localización para el UE desde el IMS.

[0256] La FIG. 19 ilustra un flujo ejemplar para la compatibilidad de llamadas de emergencia en una entidad IMS, tal como el IMS 894 o 994, para un MNO de servicio, tal como el MNO de servicio 890 o 990. En un aspecto, la entidad IMS puede ser una LRF. En un modo de realización, el flujo ilustrado en la FIG. 19 se puede realizar por, o hacer que se realice por, el módulo de posicionamiento 1058.

[0257] En 1910, la entidad IMS recibe un primer mensaje enviado por un proveedor de servicios OTT, tal como el SP OTt 150, como en 808 y 908, comprendiendo el primer mensaje una solicitud de llamada de emergencia para un UE. La solicitud de llamada de emergencia incluye datos de MNO para el UE. El primer mensaje puede ser un mensaje de INVITACIÓN SIP.

[0258] En 1920, la entidad IMS determina la información de enrutamiento para un PSAP de destino en base a los datos de MNO, como en 911 de la FIG. 9.

[0259] Aunque no se ilustra en la FIG. 19, en un modo de realización, el flujo puede incluir además enviar un segundo mensaje al proveedor de servicios OTT que comprende la información de enrutamiento, donde la información de enrutamiento posibilita que el proveedor de servicios OTT enrute la llamada de emergencia a o hacia el PSAP de destino. En ese caso, la información de enrutamiento puede ser un ID de referencia y la dirección o identidad del PSAP o bien de un destino intermedio. El segundo mensaje puede ser un mensaje 300 múltiples opciones de SIP.

[0260] En un modo de realización, el flujo puede incluir además recibir un tercer mensaje que comprende el ID de referencia desde otra entidad, identificar el UE en base al ID de referencia, obtener una localización para el UE y enviar un cuarto mensaje a la otra entidad que comprende la localización. El ID de referencia puede ser una ESRK, un ESRD más un MSISDn o un URI de localización. La localización del UE se puede obtener usando una solución de localización del plano de control o una solución de localización del plano del usuario. En un aspecto, la otra entidad puede ser el PSAP, una ALI o una ESInet.

[0261] En un modo de realización, el flujo puede incluir además enviar un segundo mensaje a o hacia el PSAP en base a la información de enrutamiento, donde el segundo mensaje comprende una solicitud para la llamada de emergencia. En este caso, la entidad IMS puede ser una CSCF de emergencia.

[0262] La FIG. 20 ilustra un flujo ejemplar para la compatibilidad de llamadas de emergencia en un UE, tal como cualquiera de los UE 200, 300, 400, 500, 600, 700, 800, 900, 1002 y 1100. En un modo de realización, el flujo ilustrado en la FIG. 20 se puede realizar por, o hacer que se realice por, el módulo de posicionamiento 1054.

[0263] En 2010, el UE recibe una solicitud para una llamada de emergencia desde un usuario del UE.

[0264] En 2020, el UE obtiene datos de MNO para un MNO de servicio para el UE, como en 802/804 y 902/904.

[0265] En 2030, el UE envía un primer mensaje que comprende una solicitud para la llamada de emergencia a un proveedor de servicios OTT, tal como el SP OTT 150, como en 806 y 906. La solicitud para la llamada de emergencia incluye los datos de MNO. Los datos de MNO pueden incluir una dirección para un IMS para el MNO de servicio, una identidad para una entidad de gestión de movilidad de servicio actual o una SGSN para el UE, una dirección IP asignada de MNO de servicio para el UE, una identidad global o una identidad local para el UE, o alguna combinación de las mismas.

[0266] El proveedor de servicios OTT envía un segundo mensaje al IMS en base a la dirección para el IMS, donde el segundo mensaje comprende una solicitud para la llamada de emergencia e incluye los datos de MNO. El IMS determina la información de enrutamiento para la llamada de emergencia en base a los datos de MNO. En este modo de realización, el flujo incluye además recibir una solicitud para una estimación de localización o para mediciones de localización de acuerdo con una solución de localización del plano de usuario o una solución de localización del plano de control, donde la estimación de localización o las mediciones de localización posibilitan que el IMS obtenga una localización para el UE, en el que la localización para el UE posibilita que el IMS determine la información de enrutamiento o proporcione al PSAP la localización.

[0267] El IMS puede enviar un tercer mensaje al proveedor de servicios OTT que comprende la información de enrutamiento. El proveedor de servicios OTT envía un cuarto mensaje a o hacia un PSAP de destino, donde el PSAP se determina en base a la información de enrutamiento. En este caso, la dirección para el IMS es una dirección para una LRF.

[0268] El IMS puede enviar un quinto mensaje a o hacia un PSAP de destino, donde el quinto mensaje comprende una solicitud para la llamada de emergencia y en el que el PSAP se determina en base a la información de enrutamiento. La dirección para el IMS puede ser una dirección para una E-CSCF.

[0269] La FIG. 21 ilustra un aparato de nodo de red de acceso 2100 de ejemplo representado como una serie de módulos funcionales interrelacionados. Un módulo para recibir 2110 puede corresponder al menos en algunos aspectos a, por ejemplo, un dispositivo de comunicación, tal como el dispositivo de comunicación 1014 en la FIG. 10, o un sistema de procesamiento, tal como el sistema de procesamiento 1034, opcionalmente junto con el módulo de posicionamiento 1056, como se analiza en el presente documento. Un módulo para determinar 2120 puede corresponder al menos en algunos aspectos a, por ejemplo, un sistema de procesamiento, tal como el sistema de procesamiento 1034, opcionalmente junto con el módulo de posicionamiento 1056, como se analiza en el presente documento. Un módulo para enviar 2130 puede corresponder al menos en algunos aspectos a, por ejemplo, un dispositivo de comunicación, tal como el dispositivo de comunicación 1014 en la FIG. 10, o un sistema de procesamiento, tal como el sistema de procesamiento 1034, opcionalmente junto con el módulo de posicionamiento 1056, como se analiza en el presente documento.

[0270] La FIG. 22 ilustra un aparato servidor de localización 2200 de ejemplo representado como una serie de módulos funcionales interrelacionados. Un módulo para recibir 2210 puede corresponder al menos en algunos aspectos a, por ejemplo, un dispositivo de comunicación, tal como el dispositivo de comunicación 1026 en la FIG. 10, o un sistema de procesamiento, tal como el sistema de procesamiento 1036, opcionalmente junto con el módulo de posicionamiento 1058, como se analiza en el presente documento. Un módulo para enviar 2220 puede corresponder al menos en algunos aspectos a, por ejemplo, un dispositivo de comunicación, tal como el dispositivo de comunicación 1026 en la FIG. 10, o un sistema de procesamiento, tal como el sistema de procesamiento 1036, opcionalmente junto con el módulo de posicionamiento 1058, como se analiza en el presente documento. Un módulo para recibir 2230 puede corresponder al menos en algunos aspectos a, por ejemplo, un dispositivo de comunicación, tal como el dispositivo de comunicación 1026 en la FIG. 10, o un sistema de procesamiento, tal como el sistema de procesamiento 1036, opcionalmente junto con el módulo de posicionamiento 1058, como se analiza en el presente documento. Un módulo para determinar 2240 puede corresponder al menos en algunos aspectos a, por ejemplo, un sistema de procesamiento, tal como el sistema de procesamiento 1036, opcionalmente junto con el módulo de posicionamiento 1058, como se analiza en el presente documento. Un módulo para enviar 2250 puede corresponder al menos en algunos aspectos a, por ejemplo, un dispositivo de comunicación, tal como el dispositivo de comunicación 1026 en la FIG. 10, o un sistema de procesamiento, tal como el sistema de procesamiento 1036, opcionalmente junto con el módulo de posicionamiento 1058, como se analiza en el presente documento.

[0271] La FIG. 23 ilustra un aparato servidor de localización 2300 de ejemplo representado como una serie de módulos funcionales interrelacionados. Un módulo para recibir 2310 puede corresponder al menos en algunos aspectos a, por ejemplo, un dispositivo de comunicación, tal como el dispositivo de comunicación 1026 en la FIG. 10, o un sistema de procesamiento, tal como el sistema de procesamiento 1036, opcionalmente junto con el módulo de posicionamiento 1058, como se analiza en el presente documento. Un módulo para autenticar 2320 puede corresponder al menos en algunos aspectos a, por ejemplo, un sistema de procesamiento, tal como el sistema de procesamiento 1036, opcionalmente junto con el módulo de posicionamiento 1058, como se analiza en el presente documento. Un módulo para determinar 2330 puede corresponder al menos en algunos aspectos a, por ejemplo, un sistema de procesamiento, tal como el sistema de procesamiento 1036, opcionalmente junto con el módulo de posicionamiento 1058, como se analiza en el presente documento. Un módulo para enviar 2340 puede corresponder al menos en algunos aspectos a, por ejemplo, un dispositivo de comunicación, tal como el dispositivo de comunicación 1026 en la FIG. 10, o un sistema de procesamiento, tal como el sistema de procesamiento 1036, opcionalmente junto con el módulo de posicionamiento 1058, como se analiza en el presente documento.

[0272] La FIG. 24 ilustra un aparato de equipo de usuario 2400 de ejemplo representado como una serie de módulos funcionales interrelacionados. Un módulo para enviar 2410 puede corresponder al menos en algunos aspectos a, por ejemplo, un dispositivo de comunicación, tal como el dispositivo de comunicación 1008 en la FIG. 10, o un sistema de procesamiento, tal como el sistema de procesamiento 1032, opcionalmente junto con el módulo de posicionamiento 1054, como se analiza en el presente documento. Un módulo para recibir 2420 puede corresponder al menos en algunos aspectos a, por ejemplo, un dispositivo de comunicación, tal como el dispositivo de comunicación 1008 en la FIG. 10, o un sistema de procesamiento, tal como el sistema de procesamiento 1032, opcionalmente junto con el módulo de posicionamiento 1054, como se analiza en el presente documento. Un módulo para recibir 2430 puede corresponder al menos en algunos aspectos a, por ejemplo, un dispositivo de comunicación, tal como el dispositivo de comunicación 1008 en la FIG. 10, o un sistema de procesamiento, tal como el sistema de procesamiento 1032, opcionalmente junto con el módulo de posicionamiento 1054, como se analiza en el presente documento. Un módulo para enviar 2440 puede corresponder al menos en algunos aspectos a, por ejemplo, un dispositivo de comunicación, tal como el dispositivo de comunicación 1008 en la FIG. 10, o un sistema de procesamiento, tal como el sistema de procesamiento 1032, opcionalmente junto con el módulo de posicionamiento 1054, como se analiza en el presente documento.

[0273] La FIG. 25 ilustra un aparato proveedor de servicios OTT 2500 de ejemplo representado como una serie de módulos funcionales interrelacionados. Un módulo para recibir 2510 puede corresponder al menos en algunos aspectos a, por ejemplo, un dispositivo de comunicación, tal como el dispositivo de comunicación 1026 en la FIG. 10, o un sistema de procesamiento, tal como el sistema de procesamiento 1036, opcionalmente junto con el módulo de posicionamiento 1058, como se analiza en el presente documento. Un módulo para enviar 2520 puede corresponder al menos en algunos aspectos a, por ejemplo, un dispositivo de comunicación, tal como el dispositivo de comunicación 1026 en la FIG. 10, o un sistema de procesamiento, tal como el sistema de procesamiento 1036, opcionalmente junto con el módulo de posicionamiento 1058, como se analiza en el presente documento.

[0274] La FIG. 26 ilustra un aparato de entidad IMS 2600 de ejemplo representado como una serie de módulos funcionales interrelacionados. Un módulo para recibir 2610 puede corresponder al menos en algunos aspectos a, por ejemplo, un dispositivo de comunicación, tal como el dispositivo de comunicación 1026 en la FIG. 10, o un sistema de procesamiento, tal como el sistema de procesamiento 1036, opcionalmente junto con el módulo de posicionamiento 1058, como se analiza en el presente documento. Un módulo para determinar 2620 puede corresponder al menos en algunos aspectos a, por ejemplo, un sistema de procesamiento, tal como el sistema de procesamiento 1036, opcionalmente junto con el módulo de posicionamiento 1058, como se analiza en el presente documento.

[0275] La FIG. 27 ilustra un aparato de equipo de usuario 2700 de ejemplo representado como una serie de módulos funcionales interrelacionados. Un módulo para recibir 2710 puede corresponder al menos en algunos aspectos a, por ejemplo, un dispositivo de comunicación, tal como el dispositivo de comunicación 1008 en la FIG. 10, o un sistema de procesamiento, tal como el sistema de procesamiento 1032, opcionalmente junto con el módulo de posicionamiento 1054, como se analiza en el presente documento. Un módulo para obtener 2720 puede corresponder al menos en algunos aspectos a, por ejemplo, un dispositivo de comunicación, tal como el dispositivo de comunicación 1008 en la FIG. 10, o un sistema de procesamiento, tal como el sistema de procesamiento 1032, opcionalmente junto con el módulo de posicionamiento 1054, como se analiza en el presente documento. Un módulo para enviar 2730 puede corresponder al menos en algunos aspectos a, por ejemplo, un dispositivo de comunicación, tal como el dispositivo de comunicación 1008 en la FIG. 10, o un sistema de procesamiento, tal como el sistema de procesamiento 1032, opcionalmente junto con el módulo de posicionamiento 1054, como se analiza en el presente documento.

[0276] La funcionalidad de los módulos de las FIGS. 21 - 27 se puede implementar de diversas maneras coherentes con las enseñanzas en el presente documento. En algunos diseños, la funcionalidad de estos módulos se puede implementar como uno o más componentes eléctricos. En algunos diseños, la funcionalidad de estos bloques se puede implementar como un sistema de procesamiento que incluye uno o más componentes procesadores. En algunos diseños, la funcionalidad de estos módulos se puede implementar usando, por ejemplo, al menos una parte de uno o más circuitos integrados (por ejemplo, un ASIC). Como se analiza en el presente documento, un circuito integrado puede incluir un procesador, software, otros componentes relacionados o alguna combinación de los mismos. Por tanto, la funcionalidad de diferentes módulos se puede implementar, por ejemplo, como subconjuntos diferentes de un circuito integrado, como subconjuntos diferentes de un conjunto de módulos de software, o una combinación de los mismos. Además, se apreciará que un subconjunto dado (por ejemplo, de un circuito integrado y/o de un conjunto de módulos de software) puede proporcionar al menos una parte de la funcionalidad para más de un módulo.

[0277] Además, los componentes y funciones representados por las FIGS.21 - 27, así como otros componentes y funciones descritos en el presente documento, se pueden implementar usando cualquier medio adecuado. Dichos medios también se pueden implementar, al menos en parte, usando una estructura correspondiente, como se enseña en el presente documento. Por ejemplo, los componentes descritos anteriormente junto con los componentes "módulo para" de las FIGS. 21 - 27 también pueden corresponder a una funcionalidad "medios para" designada de forma similar. Por tanto, en algunos aspectos, uno o más de dichos medios se pueden implementar usando uno o más de componentes de procesador, circuitos integrados u otra estructura adecuada, como se enseña en el presente documento.

[0278] Los expertos en la técnica apreciarán que la información y las señales se pueden representar usando cualquiera de una variedad de tecnologías y técnicas diferentes. Por ejemplo, los datos, instrucciones, comandos, información, señales, bits, símbolos y segmentos a los que se puede haber hecho referencia a lo largo de la descripción anterior se pueden representar por tensiones, corrientes, ondas electromagnéticas, campos o partículas magnéticas, campos o partículas ópticas o cualquier combinación de los mismos.

[0279] Además, los expertos en la técnica apreciarán que los diversos bloques lógicos, módulos, circuitos y etapas de algoritmo ilustrativos, descritos en relación con los modos de realización divulgados en el presente documento, se pueden implementar como hardware electrónico, software informático o combinaciones de ambos. Para ilustrar claramente esta intercambiabilidad de hardware y software, anteriormente se han descrito diversos componentes, bloques, módulos, circuitos y etapas ilustrativos, en general, en lo que respecta a su funcionalidad. Que dicha funcionalidad se implemente como hardware o software depende de la aplicación particular y de las restricciones de diseño impuestas en el sistema global. Los expertos en la técnica pueden implementar la funcionalidad descrita de diferentes maneras para cada aplicación en particular, pero no se debe interpretar que dichas decisiones de implementación suponen apartarse del alcance de la presente divulgación.

[0280] Los diversos bloques lógicos, módulos y circuitos ilustrativos descritos en relación con los modos de realización divulgados en el presente documento se pueden implementar o realizar con un procesador de propósito general, un procesador de señales digitales (DSP), un circuito integrado específico de la aplicación (ASIC), una matriz de puertas programables in situ (FPGA) u otro dispositivo de lógica programable, lógica de transistores o de puertas discretas, componentes de hardware discretos o con cualquier combinación de los mismos diseñada para realizar las funciones descritas en el presente documento. Un procesador de propósito general puede ser un microprocesador pero, como alternativa, el procesador puede ser cualquier procesador, controlador, microcontrolador o máquina de estados convencional. Un procesador también se puede implementar como una combinación de dispositivos informáticos, por ejemplo, una combinación de un DSP y un microprocesador, una pluralidad de microprocesadores, uno o más microprocesadores junto con un núcleo de DSP o cualquier otra configuración de este tipo.

[0281] Los procedimientos, las secuencias y/o los algoritmos descritos en relación con los modos de realización divulgados en el presente documento se pueden incorporar directamente en hardware, en un módulo de software ejecutado por un procesador o en una combinación de los dos. Un módulo de software puede residir en una memoria RAM, una memoria flash, una memoria ROM, una memoria EPROM, una memoria EEPROM, registros, un disco duro, un disco extraíble, un CD-ROM o cualquier otra forma de medio de almacenamiento conocido en la técnica. Un medio de almacenamiento ejemplar se acopla al procesador de modo que el procesador pueda leer información de, y escribir información en, el medio de almacenamiento. Como alternativa, el medio de almacenamiento puede estar integrado en el procesador. El procesador y el medio de almacenamiento pueden residir en un ASIC. El ASIC puede residir en un terminal de usuario (por ejemplo, un UE). Como alternativa, el procesador y el medio de almacenamiento pueden residir como componentes discretos en un terminal de usuario.

[0282] En uno o más modos de realización ejemplares, las funciones descritas se pueden implementar en hardware, software, firmware o cualquier combinación de los mismos. Si se implementan en software, las funciones se pueden almacenar en, o transmitir por, un medio legible por ordenador como una o más instrucciones o código. Los medios legibles por ordenador incluyen tanto medios de almacenamiento informáticos como medios de comunicación que incluyen cualquier medio que facilite la transferencia de un programa informático de un lugar a otro. Un medio de almacenamiento puede ser cualquier medio disponible al que se pueda acceder por un ordenador. A modo de ejemplo y no de limitación, dichos medios legibles por ordenador pueden comprender RAM, ROM, EEPROM, CD-ROM u otros dispositivos de almacenamiento en disco óptico, almacenamiento en disco magnético u otros dispositivos de almacenamiento magnético, o cualquier otro medio que se pueda usar para transportar o almacenar el código de programa deseado en forma de instrucciones o estructuras de datos y al que se pueda acceder por un ordenador. Además, cualquier conexión recibe apropiadamente la denominación de medio legible por ordenador. Por ejemplo, si el software se transmite desde un sitio web, un servidor u otra fuente remota, usando un cable coaxial, un cable de fibra óptica, un par trenzado, una línea digital de abonado (DSL) o tecnologías inalámbricas tales como infrarrojos, radio y microondas, entonces el cable coaxial, el cable de fibra óptica, el par trenzado, la DSL o las tecnologías inalámbricas, tales como infrarrojos, radio y microondas, se incluyen en la definición de medio. Los discos, como se usan en el presente documento, incluyen el disco compacto (CD), el disco láser, el disco óptico, el disco versátil digital (DVD), el disco flexible y el disco Blu-ray, donde algunos discos reproducen normalmente los datos magnéticamente, mientras que otros discos reproducen los datos ópticamente con láseres. Las combinaciones de los anteriores también se deben incluir dentro del alcance de los medios legibles por ordenador.

[0283] Aunque la divulgación anterior muestra modos de realización ilustrativos de la divulgación, cabe destacar que se pueden realizar diversos cambios y modificaciones en el presente documento sin apartarse del alcance de la divulgación como se define en las reivindicaciones adjuntas. Las funciones, etapas y/o acciones de las reivindicaciones de procedimiento, de acuerdo con los modos de realización de la divulgación, descritos en el presente documento, no necesitan realizarse en ningún orden particular. Además, aunque los elementos de la divulgación se pueden describir o reivindicar en singular, se contempla el plural a menos que se indique explícitamente la limitación al singular.

Claims

REIVINDICACIONES

1. Un procedimiento de compatibilidad de llamadas de emergencia en un proveedor de servicios de libre transmisión, OTT, (850), que comprende:

recibir (1810) un primer mensaje (214A, 806) que comprende una solicitud de llamada de emergencia desde un equipo de usuario, UE (800), en el que el primer mensaje se transfiere al proveedor de servicios OTT por medio de un operador de red móvil, MNO, de servicio (890) para el UE, y en el que el primer mensaje incluye una dirección para un subsistema multimedia de protocolo de Internet, IP, IMS, (894) para el MNO de servicio; y

enviar (1820) un segundo mensaje (808) al IMS en base a la dirección, en el que el segundo mensaje comprende una solicitud para una llamada de emergencia.

2. El procedimiento de la reivindicación 1, en el que el primer mensaje, el segundo mensaje, o ambos mensajes comprenden un mensaje de INVITACIÓN de protocolo de inicio de sesión, SIP, (808).

3. El procedimiento de la reivindicación 1, que comprende además:

recibir un tercer mensaje (812) desde el IMS (894) que comprende información de enrutamiento para un punto de respuesta de seguridad pública, PSAP, de destino (880); y

enviar un cuarto mensaje a o hacia el PSAP en base a la información de enrutamiento, en el que el cuarto mensaje comprende una solicitud para una llamada de emergencia.

4. El procedimiento de la reivindicación 3, en el que el tercer mensaje comprende un mensaje 300 múltiples opciones de protocolo de inicio de sesión, SIP, y/o en el que la dirección para el IMS (894) es para una función de recuperación de localización, LRF, en el que la información de enrutamiento incluye un identificador, ID, de referencia y en el que el procedimiento comprende además:

incluir el ID de referencia en el cuarto mensaje, en el que el ID de referencia posibilita que el PSAP obtenga una localización para el UE (800) desde la LRF.

5. El procedimiento de la reivindicación 1, en el que el IMS (894) envía un quinto mensaje a o hacia un PSAP de destino, en el que el quinto mensaje comprende una solicitud de llamada de emergencia para el UE (800), en el que la dirección para el IMS (894) es para una función de control de sesión de llamadas de emergencia, E-CSCF, y/o en el que el IMS (894) incluye un identificador de referencia en el quinto mensaje, en el que el identificador de referencia posibilita que el PSAP obtenga una localización para el UE (800) desde el IMS.

6. Un procedimiento de compatibilidad de llamadas de emergencia en una entidad de subsistema multimedia IP, IMS, (894) para un operador de red móvil, MNO, de servicio (890), que comprende:

recibir (1910) un primer mensaje (808) enviado por un proveedor de servicios de libre transmisión, OTT, (850) que comprende una solicitud de llamada de emergencia para un equipo de usuario, UE (800), en el que la solicitud de llamada de emergencia incluye datos de MNO para el UE; y

determinar (1920) la información de enrutamiento para un punto de respuesta de seguridad pública, PSAP, de destino (880) en base a los datos de MNO.

7. El procedimiento de la reivindicación 6, que comprende además:

enviar un segundo mensaje (812) al proveedor de servicios OTT (850) que comprende la información de enrutamiento, en el que la información de enrutamiento posibilita que el proveedor de servicios OTT enrute la llamada de emergencia a o hacia el PSAP de destino (880),

en el que el segundo mensaje (812) comprende un mensaje 300 múltiples opciones de protocolo de inicio de sesión, SIP, y/o

en el que la entidad IMS es una función de recuperación de localización (LRF), y/o

en el que la información de enrutamiento comprende un identificador, ID, de referencia y la dirección o identidad del PSAP (880) o bien de un destino intermedio, y caso en el que, el procedimiento comprende además: recibir un tercer mensaje que comprende el ID de referencia desde otra entidad;

identificar el UE en base al ID de referencia;

obtener una localización para el UE; y

enviar un cuarto mensaje a la otra entidad que comprende la localización, en el que el ID de referencia comprende una clave de enrutamiento de servicios de emergencia, ESRK, números de enrutamiento de servicios de emergencia, ESRD, más un número de directorio internacional de abonados de estación móvil, MSISDN, o un identificador universal de recursos, URI, de localización y/o, en el que la localización del UE (800) se obtiene usando una solución de localización del plano de control o una solución de localización del plano de usuario, en el que la otra entidad es el PSAP (880), una identificación de localización automática, ALI, o una red IP de servicios de emergencia, ESInet (860)).

8. El procedimiento de la reivindicación 6, que comprende además:

enviar un segundo mensaje a o hacia el PSAP en base a la información de enrutamiento, en el que el segundo mensaje comprende una solicitud para la llamada de emergencia, en el que la entidad IMS (894) es una función de control de sesión de llamadas de emergencia, CSCF.

9. Un procedimiento de compatibilidad de llamadas de emergencia en un equipo de usuario, UE 800), que comprende:

recibir (2010) una solicitud para una llamada de emergencia desde un usuario del UE (800);

obtener (2020) los datos de operador de red móvil, MNO, para un MNO de servicio (890) para el UE; y enviar (2030) un primer mensaje (806) que comprende una solicitud para la llamada de emergencia a un proveedor de servicios de libre transmisión, OTT, (850), en el que la solicitud para la llamada de emergencia incluye los datos de MNO.

10. El procedimiento de la reivindicación 9, en el que los datos de MNO comprenden una dirección para un subsistema multimedia de protocolo de Internet, IP, IMS, (894), para el MNO de servicio, una identidad para una entidad de gestión de movilidad de servicio actual o un nodo de compatibilidad de servicio general de paquetes vía radio de servicio, SGSN) para el UE, una dirección IP asignada de MNO de servicio para el UE, una identidad global o una identidad local para el UE, o cualquier combinación de los mismos.

11. El procedimiento de la reivindicación 10, en el que el proveedor de servicios OTT (850) envía un segundo mensaje (808) al IMS en base a la dirección para el IMS, en el que el segundo mensaje comprende una solicitud para la llamada de emergencia e incluye los datos de MNO.

12. El procedimiento de la reivindicación 11, en el que el IMS (894) determina la información de enrutamiento para la llamada de emergencia en base a los datos de MNO.

13. El procedimiento de la reivindicación 12, que comprende además:

recibir una solicitud para una estimación de localización o para mediciones de localización de acuerdo con una solución de localización del plano de usuario o una solución de localización del plano de control, en el que la estimación de localización o las mediciones de localización posibilitan que el IMS obtenga una localización para el UE, en el que la localización para el UE posibilita que el IMS determine la información de enrutamiento o proporcione al PSAP la localización para el UE, y/o

en el que el IMS envía un tercer mensaje al proveedor de servicios OTT que comprende la información de enrutamiento, en el que el proveedor de servicios OTT envía un cuarto mensaje a o hacia un punto de respuesta de seguridad pública, PSAP, de destino (880), en el que el PSAP se determina en base a la información de enrutamiento, y/o

en el que la dirección para el IMS es una dirección para una función de recuperación de ubicación, LRF.

14. El procedimiento de la reivindicación 12, en el que el IMS (894) envía un quinto mensaje a o hacia un PSAP de destino, en el que el quinto mensaje comprende una solicitud para la llamada de emergencia, y en el que el PSAP se determina en base a la información de enrutamiento.

15. Un aparato (2500) para la compatibilidad de llamadas de emergencia en un proveedor de servicios de libre transmisión, OTT (850), que comprende:

al menos un procesador; y

un transceptor (2510, 2520) acoplado al al menos un procesador y configurado para:

recibir un primer mensaje (806) que comprende una solicitud de llamada de emergencia desde un equipo de usuario, UE, en el que el primer mensaje se transfiere al proveedor de servicios OTT por medio de un operador de red móvil, MNO, de servicio para el UE, y en el que el primer mensaje incluye una dirección para un subsistema multimedia de protocolo de Internet, IP, IMS, para el MNO de servicio; y

enviar un segundo mensaje (808) al IMS en base a la dirección, en el que el segundo mensaje comprende una solicitud para la llamada de emergencia.