ES2392141T3

ES2392141T3 - Codificación y comportamiento cuando se recibe un indicador de sesión de emergencia de ims desde una fuente autorizada

Info

Publication number: ES2392141T3
Application number: ES09759254T
Authority: ES
Inventors: Jan Hendrik Lucas Bakker; Adrian Buckley; Andrew Allen
Original assignee: Research in Motion Ltd
Current assignee: BlackBerry Ltd
Priority date: 2008-06-02
Filing date: 2009-06-02
Publication date: 2012-12-05
Anticipated expiration: 2029-06-02
Also published as: EP2255510A1; EP2615795A3; BRPI0913427B1; US20110095886A1; EP2892204A2; US8305210B2; EP2892204B1; CN102113294A; CA2726555A1; EP2892204A3; JP5499147B2; BRPI0913427A2; WO2009149095A1; EP2615795B1; JP5689989B2; JP2014099909A; JP5244968B2; US20090296688A1; EP2518975B1; JP2011524673A

Abstract

Un método para que un equipo de usuario ("UE" - User Equipment, en inglés) (110) responda a un mensajerelacionada con una emergencia (150) que comprende:recibir un mensaje de respuesta de Protocolo de Iniciación de Sesión ("SIP" - Session Initiation Protocol, eninglés) (150) que contiene un indicador (160) que indica que un mensaje de solicitud de SIP para un diálogo(140), enviado por el UE (110), es una solicitud relacionada con una emergencia; yenviar un mensaje de solicitud de SIP dentro del diálogo (170), conteniendo el mensaje de solicitud de SIPdentro del diálogo (170) información relacionada con una emergencia (180) asociada con el UE (110), donde,antes de recibir el mensaje de respuesta de SIP (150), el UE (110) no sabe que el mensaje de solicitud deSIP para un diálogo (140) es una solicitud relacionada con una emergencia.

Description

Codificación y comportamiento cuando se recibe un indicador de sesión de emergencia de ims desde una fuente autorizada.

ANTECEDENTES El Subsistema de Multimedios de IP (Protocolo de Internet – Internet Protocol, en inglés) (IMS – IP Multimedia Subsystem, en inglés) es una arquitectura estandarizada para proporcionar servicios de multimedios y llamadas de voz sobre IP tanto a equipos de usuario (UE – User Equipment, en inglés) móviles como fijos. El protocolo de Iniciación de Sesión (SIP – Session Initiation Protocol, en inglés) está siendo estandarizado y gobernado en primer lugar por el Grupo de Trabajo de Ingeniería de Internet (IETF – Internet Engineering Task Force, en inglés) como un protocolo para establecer y gestionar llamadas basadas en IMS. Tal como se utiliza en esta memoria, el término “UE” puede referirse a dispositivos móviles tales como teléfonos móviles, asistentes digitales personales, ordenadores de mano o portátiles de regazo y dispositivos similares que tiene capacidades de telecomunicaciones. Tal UE podría consistir en un dispositivo inalámbrico y en su Tarjeta de Circuitos Integrados Universal (UICC – Universal Integrated Circuit Card, en inglés) que incluye una aplicación de Módulo de Identidad de Abonado (SIM Subscriber Identity Module, en inglés), una aplicación de Módulo de Identidad de Abonado Universal (USIM – Universal Subscriber Identity Module, en inglés) o una aplicación de Módulo de Identidad de Usuario Extraíble (R- UIM – Removable User Identity Module, en inglés) o podría consistir en el propio dispositivo sin tal tarjeta. El término “UE” puede también referirse a dispositivos que tienen similares capacidades pero que no son transportables, tales como teléfonos de línea fija, ordenadores de sobremesa o cajas para encima de un televisor. El término “UE” puede también referirse a cualquier componente de hardware o de software que puede terminar una sesión de SIP.

El documento Nokia Siemens Networks et al “Corrections for emergency procedures” Borrador de 3GPP; C1072991_24229CR1997R2_EMC1_REL-8_Procedure, Proyecto de Colaboración de 3ª Generación (3GPP – 3RD Generation Partnership Project, en inglés), Centro de Competencia para Telefonía Móvil; 650, Route des Lucioles; F06921 Sophia-Antipolis Cedex: France, vol. CT WG1, no. Sophia Antipolis, France; 20071112, 12 Noviembre de 2007 (2007-11-12), XP050027161, describe un número de solicitudes de cambio para los estándares de 3GPP en el momento de la sumisión que se refiere a los servicios de emergencia de IMS.

COMPENDIO DE LA INVENCIÓN Aspecto de la presente invención se definen en las reivindicaciones 1 y 3.

BREVE DESCRIPCIÓN DE LOS DIBUJOS Para una comprensión más completa de esta descripción, se hace ahora referencia a la siguiente breve descripción, tomada junto con los dibujos que se acompañan y la descripción detallada, donde números de referencia iguales representan partes iguales.

La Figura 1 es un diagrama ilustrativo de una red de IP que incluye un UE y un PSAP de acuerdo con una realización de la descripción. La Figura 2 es un diagrama ilustrativo de una red de IP que incluye un UE y un PSAP de acuerdo con otra realización de la descripción. La Figura 3 es un diagrama que ilustra un método para que un UE responda a un mensaje relativo a una emergencia de acuerdo con una realización de la descripción. La Figura 4 es un diagrama de un sistema de comunicaciones inalámbrico que incluye un equipo de usuario operable para algunas de las diferentes realizaciones de la descripción. La Figura 5 es un diagrama de bloques de un equipo de usuario operable para algunas de las diferentes realizaciones de la descripción. La Figura 6 es un diagrama de un entrono de software que puede ser implementado en un equipo de usuario operable para algunas de las diferentes realizaciones de la descripción. La Figura 7 es un sistema de cálculo ilustrativo adecuado para algunas de las diferentes realizaciones de la descripción.

DESCRIPCIÓN DETALLADA Resultará evidente desde el principio que aunque algunas implementaciones ilustrativas de una o más de las realizaciones de la presente descripción son proporcionadas a continuación, los sistemas y/o métodos descritos pueden ser implementados utilizando cualquier número de técnicas, ya sean conocidas en la actualidad o que existen. La descripción no debería en modo alguno limitarse a las implementaciones, dibujos y técnicas ilustrativos que se ilustran a continuación, incluyendo los dibujos e implementaciones de ejemplo ilustrados y descritos en esta memoria, sino que pueden ser modificados dentro del alcance de las reivindicaciones adjuntas junto con todo su ámbito de equivalentes.

En una realización se proporciona un método para que un UE responda a un mensaje relacionado con una emergencia enviado al UE. El método comprende que el UE reciba un primer mensaje que contiene un indicador que indica que una llamada relacionada con una emergencia ha sido establecida, reconociendo el UE el indicador como una indicación de que la llamada relacionada con una emergencia se refiere a una emergencia, llamando el UE a la funcionalidad de que la llamada relacionada con una emergencia se refiere a la emergencia, y/o si el UE está conectado a cualquier otra sesión o servicio, éstos serán suspendidos, terminados o mantenidos en ejecución pero puestos en una prioridad menor, es decir, la QoS cambió o bajó puesto que la llamada de emergencia o la devolución de llamada de PSAP tiene una mayor prioridad, y/o enviando el UE un segundo mensaje que contiene información relacionada con una emergencia sobre la propia emergencia.

En otra realización, se proporciona el UE que incluye un procesador configurado para reconocer una llamada de IMS como una llamada relacionada con una emergencia originada por el PSAP cuando se recibe un primer mensaje conteniendo un indicador. El procesador está también configurado para reconocer el indicador como una indicación de que la llamada relacionada con una emergencia se refiere a una emergencia, para llamar a la funcionalidad de que la llamada relacionada con una emergencia se refiere a la emergencia, y/o si el UE está conectado a alguna otra sesión o servicio éstos serán suspendidos, terminados o mantenidos en ejecución pero puestos en una menor prioridad, es decir, la QoS cambió o bajó puesto que la llamada emergencia o la devolución de llamada de PSAP tiene una mayor prioridad, y/o para enviar un segundo mensaje que contiene información relacionada con una emergencia acerca del UE.

En otra realización, se proporciona un método para que un componente de red responda a una llamada relacionada con una emergencia desde un UE. El método comprende el que el componente de red coloque en un primer mensaje hacia el UE un indicador indicando que la llamada fue una llamada relacionada con una emergencia y que el componente de red reciba desde el UE un segundo mensaje conteniendo información relacionada con una emergencia acerca del UE.

En otra realización, se proporciona un componente de red que incluye un procesador configurado, cuando el componente de red recibe una llamada de emergencia desde un UE, para situar en un primer mensaje al UE un indicador que indica que la llamada fue una llamada de emergencia. El procesador está también configurado para recibir un segundo mensaje desde el UE que contiene información relacionada con una emergencia acerca del UE.

Un usuario de un UE, tal como un UE capaz de IMS, puede típicamente realizar una llamada de emergencia marcando el 911 (en Norteamérica), 112 (en la mayor parte de Europa), 999 (en el Reino Unido), 110, 118 ó 119 (en Japón) o algún otro número específico para emergencias. Tal llamada puede ser manejada por un Punto de Respuesta de Seguridad Público (PSAP – Public Safety Answering Point, en inglés), que podría ser un centro o sistema de llamada de emergencia que puede coordinar una respuesta apropiada a la emergencia. Cualquier llamada realizada a un PSAP será denominada en esta memoria llamada de emergencia. En este documento, un PSAP podría ser también un centro de emergencias o centros de emergencias.

En algunos casos, un UE podría no saber que una llamada que se ha realizado era una llamada de emergencia. Por ejemplo, un UE fabricado para su uso en Norteamérica podría estar programado para reconocer que una llamada al 911 es una llamada de emergencia. Si tal UE es llevado a un país en el que se utiliza otro número diferente del 911 para las llamadas de emergencia, y el usuario del UE marca ese otro número de emergencias, el UE podría no reconocer la llamada como una llamada de emergencia. Pueden darse resultados no deseables si el UE no reconoce que una llamada es una llamada de emergencia. Por ejemplo, el UE podría fallar en proporcionar información relevante al PSAP, el UE podría tratar la llamada como una llamada regular y ponerla en suspensión o en espera, la llamada podría ser bloqueada o el UE podría fallar de otro modo en tratar la llamada de manera apropiada. Además, la red puede no aplicar un tratamiento especial, por ejemplo, en una red o celda congestionada, y la llamada de emergencia no reconocida podría no ser sujeta a los procesamientos de llamada de emergencia (por ejemplo, puede no recibir prioridad).

La presente descripción proporciona indicación a un UE de que una llamada que el UE realizó era una llamada de emergencia de IMS incluyendo en un mensaje al UE un indicador de que la llamada fue una llamada de emergencia. El indicador podría ser incluido en un mensaje de SIP que puede pero que no está limitado a un mensaje 2xx de SIP

o 1xx de SIP enviado al UE en respuesta a una solicitud de SIP inicial para diálogo o para una transacción independiente, o un método desconocido (por ejemplo, una solicitud de INVITAR de SIP), o un mensaje similar, que el UE envía en un intento de establecer la llamada de emergencia. A continuación en esta memoria, el término “mensaje de SIP” puede referirse a una solicitud de SIP (incluyendo, por ejemplo, una solicitud de INVITAR de nuevo o una solicitud de renovar Objetivo para una solicitud de SIP de diálogo o inicial para diálogo o para una transacción independiente, o un método desconocido) o una respuesta de SIP. Debe observarse que la solicitud del método de INVITAR de nuevo sólo puede ser enviada cuando se satisfacen las condiciones documentadas en la Solicitud de Grupo de Trabajo de Ingeniería de Internet (IETF – Internet Engineering Task Force, en inglés) para Comentarios (RFC) 3261. El mensaje de SIP que incluye el indicador podría ser enviado por el PSAP o por un componente de una red a través de la cual el PSAP y el UE se comunican entre sí. Ejemplos de tales componentes son la P-CSCF y la E-CSCF.

El indicador relacionado con una emergencia puede ser codificado en SIP utilizando las siguientes alternativas: a) cuerpos de SIP tales como “application/3gpp-ims+xml” han sido utilizado en IMS para indicar información o directivas adicionales a los UAs receptores. Puede extenderse también para indicar al UE que, cuando recibe una solicitud de INVITAR o similar, la solicitud debe ser tomada como una llamada de emergencia o como una devolución de llamada de PSAP y que la funcionalidad asociada con llamadas de tal tipo debe ser invocada. Esta funcionalidad puede incluir pero no estar limitada a alertar al usuario mediante métodos visuales, audibles u otros así como incluir información de ubicación en la respuesta. Puede ser necesario definir un nuevo valor de campo de cabecera de disposición de contenidos. b) Podría definirse una nueva cabecera de SIP o podría mejorarse una cabecera de SIP existente. El propio PSAP o la S-CSCF que maneja la devolución de llamada del PSAP en nombre del PSAP, o bien otro elemento de la red tal como una puerta de enlace de señalización puede introducir un indicador. c) El indicador podría ser un nuevo campo de cabecera de SIP. d) El indicador podría ser un nuevo valor del campo de cabecera de SIP, por ejemplo, una URN de SIP estandarizada que indica la función del PSAP (por ejemplo, rescate de montaña o guardacostas o un 911 general) o una función del centro de emergencias o una función del personal de emergencias. e) El indicador podría ser un campo de nuevo URI. f) El indicador podría ser un nuevo valor del campo de URI, por ejemplo, usuario = psap, donde ‘usuario’ es un campo de URI de SIP y ‘psap’ es un nuevo valor que podría ser introducido en el campo de cabecera de Contacto. g) La URN de SIP estandarizada podría ser dispuesta en la Identidad Afirmada P por el dominio de confianza en el cual residen el PSAP o el centro de emergencias o el personal de emergencias. h) El indicador podría estar contenido en el valor del campo de cabecera de FROM y el valor del campo de cabecera de FROM puede ser afirmado de acuerdo con RFC 4474 ó RFC 3893. Esta solución se basa en certificados.

Como se ha identificado anteriormente, podrían utilizarse varias posibilidades para indicar que una sesión es en realidad una sesión de emergencia. Se ha resaltado que el PSAP podría estar en una red visitada tal como una red de VPLMN y no tener ninguna relación de confianza con la red local tal como una HPLMN (Red de Telefonía Móvil Terrestre Pública Local - Home Public Land Mobile Network, en inglés). Asumiendo que éste es el caso cuando el UE está estableciendo una sesión de emergencia que el UE no reconoce o cuando recibe una solicitud de terminación en un móvil que contiene una indicación en el mensaje de SIP (por ejemplo, respuestas 1xx ó 2xx o una solicitud de refrescar el objetivo de SIP o un mensaje similar) de que la solicitud es una devolución de llamada del PSAP, el PSAP o la red podrían también devolver un testigo que el UE podría almacenar. La red podría proporcionar este testigo cuando el UE se registra en el subsistema de red de núcleo (CN – Core Network, en inglés) de IM. El testigo podría ser almacenado en memoria, la cual podría ser interna o extraíble. En el caso de que la llamada de emergencia del UE se desconecte o de que el UE necesite ser informado de que está solicitando una sesión de emergencia, la red o el PSAP podrían incluir este testigo. Cuando recibe el testigo desde la red, el UE puede compararlo con el testigo compartido. Si los testigos no coinciden, el UE sabe que la llamada no está relacionada con una emergencia.

El campo de cabecera de “prioridad” de SIP puesto en “emergencia” no ha sido utilizado hasta ahora como un indicador fiable para una emergencia [RFC 3261]. La base de UAs de SIP instalada tendrá un tratamiento diferente y divergente para esta cabecera, si es que tiene algún tratamiento.

En el caso de que la devolución de llamada del PSAP o la respuesta de señalización de una llamada de emergencia sea recibida sobre una red de -circuitos Conmutados, la solución puede permitir el mapeo entre un campo de Categoría de Participante Llamante apropiado que es a veces utilizado para llevar la indicación de una llamada de emergencia en sistemas basados en ISUP/TUP (Parte de Usuario de ISDN / Parte de Usuario de Teléfono – ISDN User Part / Telephone User Part, en inglés). Típicamente, la información de señalización de ISUP/TUP no permite una granularidad tan fina como los identificadores de la urn:servicio:sos de emergencia definidos en el RFC 5031.

La Figura 1 ilustra un sistema 10 que incluye uno o más componentes asociados con una red de IMS 120. Un UE 110 puede ser cualquier dispositivo o sistema de usuario final que pueda conectarse a la red de IMS 120. Ejemplos del UE 110 pueden incluir, pero no están limitados a, teléfonos móviles, teléfonos de línea fija, dispositivos inalámbricos de telefonía móvil (que incluyen dispositivos digitales, celulares o de modo dual), asistentes digitales personales, ordenadores portátiles / tabletas / bloc de notas y ordenadores de sobremesa. El UE 110 puede comunicarse por medio de la red de IMS 120 con un PSAP 130, que puede ser un sistema de 911 u otro centro o sistema de llamadas de emergencia.

La red de IMS 120 podría incluir cualquier conjunto de componentes bien conocido, tal como estaciones de base y otros equipos de transmisión y de recepción por radio, que pueda promover una conexión basada en IMS entre el UE 110 y el PSAP 130. Otros componentes que podrían estar presentes en la red de IMS 120 pero que no se muestran incluyen una P-CSCF (Función de Control de Sesión de Llamada mediante Proxy – Proxy Call Session Control Function, en inglés) que puede ser el primer punto de contacto para el UE 110; una S-CSCF (CSCF de servicio – Serving CSCF, en inglés) que pueda llevar a cabo un control de sesión, descarga y subida de perfiles de usuario y otras funciones; una E-CSCF (CSCF de Emergencia – Emergency CSCF, en inglés) que pueda proporcionar funciones de control de sesión para el PSAP 130; y otros componentes bien conocidos para iniciar y mantener sesiones basadas en IMS.

Para realizar una llamada de emergencia, el UE 110 podría enviar una solicitud de SIP inicial para un diálogo o una transacción independiente, o método desconocido (por ejemplo, una solicitud de INVITAR de SIP) 140, o un mensaje de invitación similar, al PSAP 130 a través de la red de IMS 120. El PSAP 130 típicamente responde al mensaje de invitación 140 con un mensaje de respuesta 1xx de SIP ó 2xx de SIP (por ejemplo, 200 OK de SIP) 150,

o un mensaje de respuesta similar. Alternativamente, el PSAP 130 podría transmitir una solicitud de refrescar objetivo (por ejemplo, solicitud de re-INVITAR). Podrían entonces seguirse los procedimientos de SIP estándar para establecer la llamada de emergencia entre el UE 110 y el PSAP 130.

En una realización, el mensaje de respuesta 150 incluye un indicador 160 que indica que la llamada establecida por el UE 110 fue una llamada de emergencia. El indicador 160 puede ser un bit, una marca o algún otro elemento de datos que es reconocible por el UE como designación de que una llamada establecida por el UE 110 fue una llamada de emergencia (por ejemplo, las URNs de servicio de emergencia tal como se especifican en RFC 5031 tal como urn:servicio:sos.control de animales o urn:servicio:sos.policía, si se determina que la llamada que fue establecida puede estar en la categoría de, por ejemplo, una llamada de urn:servicio:sos, una llamada de urn:servicio:sos:control de animales o una llamada de urn:servicio:sos.policía). Cuando el UE 110 recibe el mensaje de respuesta 150 que incluye el indicador 160, el UE 110 identifica que la llamada que realizó era una llamada de emergencia de IMS y puede entonces llevar a cabo las acciones apropiadas y llamar a la funcionalidad para una llamada de emergencia. Una acción de que el UE 110 podría llevar a cabo es indicar al usuario del UE la naturaleza de la llamada original. Esto es, el UE 110 podría alertar al usuario de que la llamada fue una llamada de emergencia. La alerta podría ser un mensaje que aparece en la pantalla de visualización del UE 110, una alerta visual o audible o algún otro tipo de condición de entorno o indicación de la naturaleza de la llamada. Otras acciones llevadas a cabo por el UE 110 pueden llamar a la transmisión de un mensaje de solicitud de SIP 170 tal como un mensaje de ACK de SIP o de PRACK de SIP o cualquier parte de solicitud de SIP subsiguiente del diálogo (incluyendo solicitudes de refrescar objetivo) o solicitud de un nuevo diálogo, donde la solicitud para el diálogo utiliza el campo de cabecera de Objetivo-Diálogo de SIP con un conjunto de valores idéntico al valor del identificador de diálogo correspondiente para la sesión de emergencia. En el caso de enviar una solicitud de un nuevo mensaje de diálogo 170 con el campo de cabecera de Objetivo-Diálogo de SIP relleno, puede indicar al receptor que el emisor conoce la existencia de un diálogo con el receptor, bien debido a que el emisor está del otro lado de ese diálogo, o bien porque tiene acceso a los identificadores de diálogo; el receptor puede entonces autorizar la solicitud basándose en este conocimiento. Sujetos a las limitaciones del SIP, cualquiera de estos mensajes puede incluir información en la solicitud como parte de la información disponible para el PSAP 130 si el receptor es el PSAP 130. Como se ha mencionado, el mensaje 170 podría ser una solicitud de refrescar objetivo de SIP, un mensaje de ACTUALIZAR de SIP, un mensaje de re-INVITAR de SIP 170 ó un mensaje similar (reconocimiento) (por ejemplo PRACK de SIP). El mensaje 170 puede incluir información 180 acerca del UE 110, que se describirá con más detalle a continuación. Debido a las limitaciones en el protocolo de SIP, la información 180 puede ser dividida en varios mensajes de SIP, por ejemplo alguna información puede estar en las solicitudes de PRACK de SIP, alguna en respuestas a solicitudes de PSAP u originadas en la red o en solicitudes de ACTUALIZAR de SIP, y alguna en otras solicitudes de refrescar objetivo de SIP. La información 180 podría estar prevista para el PSAP 130 ó para uno o más componentes en la red de IMS

120. La información 180 podría opcionalmente incluir una marca u otro indicador que indique que cierta información relacionada con una emergencia, tal como una identificación, acceso a red e información de ubicación no debe ser compartida (por ejemplo, con el PSAP 130). Si uno o más indicadores de privacidad son establecidos, la red podría aún ser capaz de utilizar la información relacionada con una emergencia con el propósito de encaminar o para proporcionar una devolución de llamada anónima.

En otra realización podría almacenarse una política en el UE 110. La política o políticas pueden ser utilizadas para determinar si está permitido incluir uno o más indicadores para solicitar privacidad cuando se solicitan sesiones de emergencia, o si se proporciona información relacionada con una emergencia cuando un PSAP realiza una devolución de llamada, o si está permitido solicitar privacidad cuando se proporciona una información relacionada con una emergencia en respuesta a una devolución de llamada por parte del PSAP. La política podría ser consultada cuando el UE 110 desea divulgar información que es sensible a privacidad, tal como, pero que no está limitada a, ubicación. La política podría ser proporcionada por el usuario, proporcionada por el operador, o por ambos. Cuando la información es proporcionada tanto por el usuario como por el operador, el operador podría proporcionar una política por defecto, pero el usuario podría ser capaz de ignorar esta política si así lo desea. La política puede ser almacenada en una memoria que es interna o externa al dispositivo.

Es posible que la política/preferencia pudiese ser establecida de una manera que esté en contra de los requisitos regulatorios del PSAP. Por ejemplo, el UE 110 podría venir de un país en el que puede elegir si proporcionar información relativa al usuario o relativa a un evento, o no, y la política/preferencia puede ser establecida de tal manera que la información pueda ser proporcionada (por ejemplo, con el propósito de determinar el PSAP más cercano), pero podría realizarse una solicitud de que la información no sea divulgada. El UE 110 puede subsiguientemente ir a un país en el que la información de ubicación, por ley, deba ser proporcionada si está disponible. En tales casos, la red podría señalar al UE 110 que se ignore la política/preferencia y que la información debe ser proporcionada. Esta notificación de ignorar podría ser señalada como un testigo en un mensaje desde la red. Por ejemplo, un mensaje de SIP podría contener un testigo que está codificado como una nueva marca de característica, un nuevo parámetro URI, un nuevo cuerpo de XML, un nuevo parámetro de SDP o una característica de codificación similar. El testigo podría también necesitar la propiedad de que pueda ser validado por el UE 110.

Lo que sigue ilustra una posible realización de cómo puede comportarse el UE 110.

El procedimiento básico será

Política / Preferencia establecida

Mensaje recibido desde la red, conteniendo el testigo de ignorar

Consultar preferencia / política

Permitir la entrega de información de ubicación

No está permitido determinar si el testigo se ha recibido

El testigo recibido determina la autenticidad del testigo y si es válido proporciona la

información de ubicación

El testigo recibido, falso, proporciona una indicación a la red de que se ha recibido un

testigo falso, no proporcionar ninguna información de ubicación.

El testigo podría ser transportado en una devolución de llamada desde el PSAP 130, tal como un INVITAR de SIP. Alternativamente, el testigo podría ser proporcionado en el momento en el que el UE 110 se registra en la red 120, tal como en IMS el testigo podría ser proporcionado en un mensaje 200OK de SIP en respuesta a un registro de emergencia. Dentro del 200OK, si el testigo está codificado como una nueva marca de característica, un nuevo parámetro URI o un cuerpo de XML, el testigo podría ser un testigo seguro. En una red de LTE/SAE, el mensaje 200OK podría ser transmitido en respuesta a la solicitud de conectarse a la red o como parte de la secuencia de autenticación del UE 110.

Otra realización es que la política de VPLMN podría emitir en un mensaje de sistema indicando el comportamiento del UE si recibiese una devolución de llamada de emergencia.

El proporcionar la política puede ser llevado a cabo en, pero no estar limitado a uno de los siguientes modos: OMA, DM, CP, OTRA, propietario u otros. Cuando está siendo proporcionado, cualquiera de los siguientes transportes podría ser utilizado: Emisión de Celda, SMS, USSD, MBMS, canuto de IP Genérico u otros.

La política podría ser almacenada en una memoria interna o externa. La memoria externa podría ser, pero no estar limitada a, Tarjeta de PC PCMCIA, Memoria rápida Compacta I CF-I, Memoria Rápida Compacta II CF-II, Medios Inteligentes SM/SMC, Pincho de Memoria MS (MS Memory Stick, en inglés) PRO Duo MSPD, Pincho de Memoria PRO-HG Duo MSPDX, Pincho de Memoria Micro M2 Tarjeta de Multimedios MMC, Tarjeta de Multimedios RS-MMC, Tarjeta MMCmicro MMCmicro, Tarjeta Digital Segura SD, SxS SxS, Almacén de Memoria Rápida Universal UFS, Tarjeta miniSD miniSD, Tarjeta microSD microSD, Tarjeta de Imagen-xD xD, Pincho Inteligente iStick, Módulo de Memoria Rápida de Serie SFM (Serial Flash Module, en inglés), Itarjeta Itarjeta, Tarjeta de NT NT NT+, USIM, R-UIM, etc.

En una realización de la política de información, habría un fichero en la memoria extraíble consistente en ocho bits por cada fichero. El bit 1 (El Bit Menos Significativo) podría ser puesto en 1 para indicar que la información de ubicación debe ser proporcionada, o en 0 para indicar que la información de ubicación no debe ser proporcionada. Los siete dígitos restantes podrían ser reservados (RFU). El fichero de preferencias del usuario podría estar bajo control de PIN (es decir, el usuario podría, después de introducir el PIN, controlar el contenido del fichero), y el fichero del operador podría estar bajo el control ADM (ADMinistrativo), impidiendo que cualquier participante, distinto del administrador (el emisor de la tarjeta, normalmente el portador) altere el contenido del fichero.

En varias realizaciones, la política puede ser implementada en diferentes formatos. Un ejemplo de un formato para la política se proporciona a continuación, pero los formatos no deberían estar limitados por este ejemplo, puesto que se contemplan otros formatos.

/<X>/Política de Ubicación de Emergencia mediante Devolución de llamada por parte del PSAP/ La hoja de política de Ubicación de Emergencia indica si el UE proporciona información de la llamada de emergencia

o no para la devolución de llamada de emergencia.

•: Ocurrencia: Uno

•: Formato: Booleano

•: Tipos de Acceso: Obtener, Reemplazar

•: Valores: 0, 1 0 – El UE proporciona información de emergencia. 1 – El UE no proporciona información de la emergencia. <Nodo>

<Nombre del Nodo> Política de Ubicación de la Emergencia </Nombre del Nodo> <Propiedades de DF>

</Tipo de Acceso>

</Formato de DFF>

<Uno/>

</Ocurrencia>

<Título de DF> Política de Ubicación de Emergencia </DFTítulo>

<MIME>texto/plano</MIME>

</Tipo de DFT>

</Propiedades de DF>

</Nodo>

Como se ha mencionado previamente, cuando el UE 110 recibe el mensaje de respuesta 150 que incluye el indicador 160, el UE 110 podría transmitir información 180 acerca de sí mismo al PSAP 130. Si la política lo permite, una parte de la información 180 que el UE 110 podría incluir en el mensaje de SIP 170 es las identidades públicas de usuario del UE (tales como URI TEL, URI de SIP o Número de ISDN Internacional de Estación de Telefonía Móvil (MSISDN – Mobile Station International ISDN Number, en inglés) o algún otro símbolo identificativos. Incluir tal información puede estar sujeto a políticas o podría estar acompañado por un indicador de que no se comparte información privada con el PSAP o con el centro de emergencias o con elementos de red no fiables. Las identidades públicas de usuario podrían estar en formato de GRUU o pueden contener información suficiente de que es posible una devolución de llamada sobre tecnología de Circuitos Conmutados, por ejemplo, en formato de URI de Tel. El PSAP 130 puede utilizar el identificador para hacer una devolución de llamada al UE 110 si es necesario, como se describe a continuación. Otra porción de información 180 que el UE 110 podría transmitir en el mensaje de reconocimiento 170 es el tipo de acceso que el usuario 110 está utilizando. Por ejemplo, si la llamada de emergencia está siendo realizada sobre una red de área local (LAN – Local Area Network, en inglés) inalámbrica, el UE 110 podría incluir el hecho en la información 180, así como un ID de celda, un ID de línea y/o un ID de nodo de acceso de LAN inalámbrico. Durante el diálogo, los puntos de conexión a la Red de Acceso de Conectividad mediante IP (IP-CAN – IP-Connectivity Access Network, en inglés) del UE puede cambiar (por ejemplo, el UE se conecta a diferentes celdas). El UE puede rellenar la cabecera de Info-Red de Acceso-P en cualquier solicitud o respuesta dentro de un diálogo para lo cual está soportada la transmisión de tal información (por ejemplo, excluyendo solicitudes de ACK (Reconocimiento - ACKnowledgement, en inglés) y solicitudes y respuestas de CANCELAR), con el punto de conexión actual a la IP-CAN (por ejemplo, la información de celda actual).

Si el UE 110 conoce su ubicación geográfica, por ejemplo, mediante el uso de un sistema de posicionamiento global (GPS – Global Positioning System, en inglés), el UE 110 puede incluir su ubicación como otra porción de la información 180, tal como pero que no está limitado a Identidad Global de Celda (CGI – Cell Global IDentity, en inglés), Identificador de Conjunto de Servicios (SSID – Service Set Identifier, en inglés), puntos de referencia tales como marcas terrestres y la potencia de la señal de las celdas adyacentes con correspondientes CGIs. Si el UE 110 no conoce su ubicación geográfica, datos relativos a la ubicación no están incluidos en la información 180. Si un URI (Uniform Resource Identifier, en inglés – Identificador de Recurso Uniforme) de GRUU (Globally Routable UA, en inglés - UA encaminable globalmente), está asociado con el UE 110, el GRUU del UE puede ser incluido como otra porción de la información 180. Dependiendo de los ajustes de privacidad del usuario, el GRUU puede ser un P-GRUU o un T-GRUU, aunque un GRUU Público (P-GRUU, Public GRUU, en inglés) es preferido sobre un GRUU temporal (T-GRUU – Temporary GRUU, en inglés).

Otros elementos que pueden ser incluidos en la información 180 podrían incluir las capacidades del UE 100, siendo la tecnología de acceso por radio utilizada por el UE 110, la vida de la batería del UE 110, la potencia de la señal y la identidad de red (por ejemplo, CGI, SSID, SID). El UE 110 podría también invocar lo que es comúnmente conocido como funcionalidad de llamada electrónica para ser enviada al PSAP 130.

Antes de que la solicitud de emergencia alcance el PSAP 130, podría ser manejado por uno o más componentes en la red de IMS 120. Un componente tal es la P-CSCF. Un componente de red de IMS puede inspeccionar todas las solicitudes con el fin de determinar si se refieren a emergencias. Si se determina que una solicitud está relacionada con una emergencia, basándose en configuraciones y en políticas reguladoras, el componente de red puede determinar rechazar la solicitud o reformatear la solicitud o incluir el indicador de llamada de emergencia 160 en una respuesta de SIP que es enviada al UE 110. Reformatear la solicitud podría ser llevado a cabo si el UE proporciona un T-GRUU y los ajustes de políticas del operador de la red (por ejemplo en la P-CSCF) indican que las identidades públicas de usuario deben ser proporcionadas. En tal caso, el T-GRUU puede ser reemplazado con el GRUU.

Además, el reformateo de mensajes para ser encaminados a los PSAPs podría ser llevado a cabo si el mensaje contiene campos de cabecera de Servicio Preferido P, campos de cabecera de Servicio Afirmado P, campos de cabecera de Aceptación de Contacto que contienen un valor de Identificador de Servicio de Comunicación mediante IMS (ICSI – Ims Communication Service Identifier, en inglés) (codificado como se especifica en el subapartado 7.2A.8.2 en el documento TS 24.229 del 3GPP) y cero o más valores de Identificador de Referencia de Aplicación de IMS (IMS Application Reference Identifier, en inglés) (codificados como se especifica en el subapartado 7.2A.9.2 en el documento TS 24.229 del 3GPP) que están relacionados con la solicitud en una marca de característica g.3gpp.app_ref. Los campos de cabecera de Servicio Preferido P, campos de cabecera de Servicio Afirmado P no deben ser enviados al PSAP o al centro de emergencias. Los campos de cabecera de Aceptación-Contacto deben estar preparados para valores de ICSI y valores de IARI puesto que pueden provocar interacciones cuando se selecciona un agente. Si el campo de cabecera de Aceptación-Contacto contiene marcas de característica de medios g.3gpp.app_ref, ellas y sus valores serán eliminados.

En otras palabras, lo que se denomina “reformateo” puede incluir cambiar el GRUU de un GRUU temporal a un GRUU público. Esto se lleva a cabo porque un GRUU no es válido si el UE está desconectado y tiene que registrarse de nuevo. Un PSAP no puede hacer una devolución de llamada a un GRUU temporal después de que el UE se elimine del registro y se registre de nuevo. Los GRUUs públicos, por otra parte, tienen la propiedad de que son encaminables incluso después de que el UE se elimine del registro y se registre de nuevo (haciendo una devolución de llamada del PSAP a ese GRUU que se complete con mayor probabilidad). “Reformatear” puede incluir también no propagar marcas de característica de ICSI o IARI, campos de cabecera de Servicio Preferido P y/o campos de cabecera de Servicio Afirmado P. La presencia de tales marcas o campos podría desviar el manejo de la solicitud en el PSAP y provocar que la solicitud sea encaminada basándose en servicios soportados en el IE en lugar de, por ejemplo, en la proximidad geográfica y el tipo de servicio solicitados. Puesto que existe típicamente una S-CSCF en la ruta de la sesión entre el UE, la P-CSCF, la E-CSCF y el PSAP, estos servicios que el UE supuestamente soporta no están típicamente activados durante la llamada de emergencia. Así que su señalización como parte de una solicitud de emergencia (incluso cuando el UE no sabía que era una solicitud de emergencia e incluye marcas de característica de ICSI o de IARI, campos de cabecera de Servicio Preferido P y/o campos de cabecera de Servicio Afirmado P porque cree que la solicitud que realiza es una solicitud normal) no sirve para ningún propósito y puede solamente fallar/resultar en encaminar las solicitudes a otros PSAPs distintos de los determinados basándose en la ubicación, en el tipo de emergencia solicitado y en los procedimientos 3261 de RFC. En un escenario de caso peor, si un operador de PSAP registra su soporte para los citados servicios, puede recibir una mayor carga de solicitudes de servicio de emergencia distintas de otros operadores de PSAP, posiblemente produciendo un retardo en la respuesta a la emergencia.

En las realizaciones en las que un componente en la red de IMS 120 rechaza la solicitud de servicio de emergencia, puede responder con un mensaje 3xx de SIP, tal como un mensaje 300 (Múltiples Elecciones), 301 (Movido Permanentemente), 380 (Servicio Alternativo) o una respuesta 4xx de SIP o una respuesta 6xx de SIP. Un SIP 380 (Servicio Alternativo) se utiliza preferiblemente para indicar que el UE debería intentar otra tecnología de acceso tal como CS, o utilizar/crear otro contexto/registro seguro tal como el contexto creado por el registro de emergencia. El mensaje puede ser también utilizado para informar al UE de que no utilice el presente contexto (que podría haber sido creado como resultado de un registro de emergencia).

Los que siguen son casos en los que la red puede estar configurada para rechazar la solicitud: a) la red no es capaz de manejar sesiones de emergencia; b) el subsistema de CN de IM al cual pertenece la P-CSCF no es capaz de manejar sesiones de emergencia; c) debido a política local, la red no maneja sesiones de emergencia; d) la red sólo maneja ciertos tipos de solicitudes de sesiones de emergencia; e) el UE está itinerando; f) la P-CSCF está en una red diferente de la red del operador local del UE; g) la red no soporta sesiones de emergencia bien para la ubicación geográfica en la que el UE está situado o bien en la IP-CAN a la cual está conectado el UE.

Debe observarse que una respuesta de redirección 3xx puede ser válida o encaminable sólo en la red actualmente conectada. Por ejemplo, urn:servicio:sos.control de animales puede ser válido en la libreta de direcciones sólo para algunas redes a las cuales puede conectarse o en las que puede registrarse el UE 110. El uso de una dirección en la libreta de direcciones puede ser condicional para el operador o la región en la cual el UE 110 está conectado o registrado. Una respuesta 3xx urgiendo al UE a utilizar otra dirección para esta solicitud relacionada con una emergencia o una solicitud determinada como no relacionada con una emergencia no debería ser seguida, simplemente cambiando la correspondiente entrada de la libreta de direcciones, si existe, en la libreta de direcciones.

Dos ejemplos pueden ilustrar casos en los que la red rechaza la solicitud debido a que el tipo de solicitud de sesión de emergencia no está soportado. En el primer ejemplo, el 5031 de RFC define urn:servicio:sos.animal-control como sigue: El control de animales típicamente hace que se cumplan leyes y ordenanzas pertenecientes al control y a la gestión de animales, investiga casos de abuso de animales, educa a la comunidad en la posesión responsable de mascotas y en el cuidado de la vida salvaje, y proporciona alojamiento y cuidados de animales sin techo, entre otros servicios relacionados con los animales. En algunas jurisdicciones, una solicitud a urn:servicio:sos.control de

animales puede no estar clasificada como una emergencia en el sentido de que está sujeta a procedimientos de emergencia de la red y del operador (por ejemplo, permitir o impedir una solicitud a un urn:servicio:sos.control de animales cuando el UE no se registra o tiene credenciales insuficientes). Si está así configurada la red podría rechazar con una indicación de que la llamada no es realmente una emergencia o podría rechazar con una indicación de que la llamada no es una emergencia y ofrecer la ejecución de etapas alternativas tal como ofrecer un URI diferente para contactar y/o una dirección de red de CS diferente tal como una secuencia de dígitos. Debe observarse que, puesto que las URNs de servicios de emergencia no son encaminables y no son números E.164, el UE puede no ser capaz de continuar ante la falta de conocimiento de direcciones o números encaminables. En esas jurisdicciones, resultaría inapropiado si el UE ejecutase procedimientos de emergencia (tal como se especifica en el documento TS 24.008 de 3GPP) y el UE no debería contactar automáticamente, por ejemplo, “911” o “112” cuando se recibe un rechazo al contactar, por ejemplo, con la urn:servicio:sos.control de animales.

Debe observarse que es posible que un UE provisto de CS haya recibido una lista de números de emergencias de CS locales (por ejemplo, haya recibido un resultado del procedimiento de Actualización de Ubicación). Un UE podría indicar el tipo de servicio de emergencia solicitado en una solicitud de emergencia de CS y ser conectado al PSAP solicitado utilizando procedimientos del documento TS 24.008 de 3GPP. Por ejemplo, existe la siguiente tabla:

Tabla 10.5.135d/3GPP TS 24.008: Elemento de información de Categoría de Servicio

Valor de Categoría de Servicio de Emergencia (octeto 3) El significado del Valor de Categoría de Emergencia se deriva de los siguientes ajustes (por favor, véase el apartado 9 del documento TS 22.101 de 3GPP):

Bit 1: Policía

Bit 2: Ambulancia

Bit 3: Bomberos

Bit 4: Guardia Marina

Bit 5: Rescate de Montaña

Bits 6, 7, 8 son de reserva y están puestos en “0” La estación de telefonía móvil puede poner uno o más bits en “1”. Si más de un bit es puesto en “1”, se requiere el encaminamiento a un centro de Emergencias combinado (por ejemplo ambulancia y bomberos en Japón). Si el MSC no puede encontrar una coincidencia ente la categoría de servicio recibida y alguno de los centros de emergencia, encaminará la llamada a un centro de emergencia por defecto definido por el operador. Si ningún bit está puesto en “1”, el MSC encaminará la llamada de Emergencia a un centro de emergencias por defecto definido por el operador.

No obstante, actualmente no existe ningún mapeo para urn:servicio:sos:control de animales. Un mapeo para algún otro servicio de emergencia tal como el definido en el 5031 de RFC (por ejemplo, urn:servicio:sos.policía) puede ser llevado a cabo poniendo el correspondiente bit en el Valor de Categoría de Emergencia (por ejemplo urn:servicio:sos.policía mapea al Bit 1 del Valor de Categoría de Servicio de Emergencias, urn:servicio:sos.ambulancia mapea al Bit 2 del Valor de Categoría de Servicio de Emergencia, urn:servicio:sos.fuego mapea al Bit 3 del Valor de Categoría de Servicio de Emergencia, urn:servicio:sos. Marina mapea al Bit 4 del Valor de Categoría de Servicio de Emergencia, urn:servicio:sos:montaña mapea al Bit 5 del Valor de Categoría de Servicio de Emergencia). urn:servicio:sos.control de animales, urn:servicio:sos.médico, urn:servicio:sos.venenos, urn:servicio:sos.gas y otros podrían mapear a un Valor de Categoría de Servicio de Emergencia sin que ningún bit esté puesto en “1”, haciendo que la llamada sea encaminada a un centro de emergencia por defecto definido por el operador. Alternativamente, para solicitudes para las cuales no hay ningún PSAP soportado en la red, el UE podría ser instruido para realizar una solicitud de SIP normal (utilizando procedimientos del documento TS 24.228 de 3GPP) o estableciendo una llamada de CS normal (utilizando procedimientos del documento TS 24.008 de 3GPP). La red podría cumplir esto no indicando una dirección alternativa que no puede ser mapeada a un Valor de Categoría de Servicio de Emergencia (es decir, no una de las URNSs urn:servicio:sos para la cual existe un mapeo estandarizado). Cuando una solicitud de emergencia es recibida por el PSAP pero el PSAP no puede manejar la solicitud y devuelve un 380 de SIP o un mensaje similar, si existe un mapeo en el UE desde la URN dada a un Valor de Categoría de Servicio de Emergencias, se establecerá automáticamente una llamada a ese número E.164 de PSAP de CS.

En el segundo ejemplo, la P-CSCF puede determinar que la solicitud de emergencia está hecha a urn:servicio:sos.policía. No obstante, por ejemplo en Holanda, contactar con la policía no garantiza por definición la activación de procedimientos de emergencia. Por el contrario, existe un número especial diferente del “112”: 09008844. Otros ejemplos son “19” Policía (Albania), “100” (Policía y Bomberos (ciudades griegas)), “100” (Ambulancia y Bomberos (Bélgica)), “112” (Policía y Ambulancia (Italia)), “112” (llamada de emergencia en general, todas las categorías (Suecia)), “115” (Bomberos (Italia)), “144” (Ambulancia (Austria)), “*377” (comisaría de policía local o Departamento de oficina de Seguridad Ciudadana, asistencia en carretera que no es emergencia en Texas). Tal número puede ser un servicio Premium. Podría ser inapropiado si el UE contactase automáticamente, por ejemplo, “911” o “112” si la red rechaza la llamada a urn:servicio:sos.policía, y podría resultar inapropiado si la red contactase automáticamente, por ejemplo, 0900-8844 como una llamada regular cuando el usuario, sin saberlo, puede recibir entonces automáticamente cargos de Premium. La P-CSCF podría proporcionar etapas alternativas tales como proporcionar una secuencia de dígitos, por ejemplo, 0900-8844, en una respuesta 3xx de SIP. No obstante, la secuencia de dígitos puede ser parte de un mensaje que identifica que la secuencia de dígitos debe ser mostrada y/o que un mensaje de texto debe ser mostrado para indicar la naturaleza de la llamada que fue realizada y la naturaleza del número proporcionado.

En una realización, la P-CSCF tiene listas configurables con identificadores de servicio de emergencia de interlocutores local e itinerante que indican el manejo por identificador de servicio de emergencia. Cuando rechaza la solicitud, una lista configurable de URIs de servicios de emergencia alternativos puede ser incluida en la respuesta, por ejemplo, señalada como parte del campo de cabecera de Contacto de SIP. Estos servicios de emergencia alternativos pueden ser anotados con información alfanumérica que puede ser desplegada, por ejemplo, cuando están señalados como parte del campo de cabecera de Contacto de SIP. Los servicios de emergencia alternativos pueden ser también identificados utilizando un cuerpo de XML con elementos de XML y atributos de XML, siendo mostrados sólo si se requiere.

En otra realización más, la P-CSCF no rechazará la solicitud para un tipo de servicio de emergencia no soportado (tal como urn:servicio:sos.venenos) sino que la prepara para enviarla a la S-CSCF de red local del usuario utilizando procedimientos normales (en lugar de enviarla a una E-CSCF). La S-CSCF de la red local del usuario debe entonces ser configurada para manejar el valor de URI de Solicitud no encaminable. La red de IMS puede ser también configurada para tener en cuenta usuarios itinerantes que solicitan una sesión con urn:servicio:sos.policía, de manera que el servicio solicitado por un UE que puede estar dando la vuelta al mundo, puede aún ser manejado de una manera oportuna y efectiva. La red de IMS podría proporcionar una indicación en un mensaje de SIP al UE de que la llamada ha sido determinada como una llamada no de emergencia y que su manejo será diferente. La indicación podría ser una marca y/o información alfanumérica. Posibles codificaciones de este tipo de indicador se dan en este documento.

Volviendo al caso en el que un componente de red de IMS determina que el UE 110 ha iniciado una llamada de emergencia sin reconocerla como tal, en algunas realizaciones la red de IMS 120 incluye el indicador de llamada de emergencia 160 en una respuesta de SIP que es enviada al UE 110. En este caso, el indicador 160 es proporcionado durante la fase de señalización de establecimiento de llamada. En otras realizaciones, el indicador de llamada de emergencia 160 es incluido en un mensaje que se origina en el PSAP 130. La red de IMS 120 transfiere a continuación el mensaje desde el PSAP 130 hasta el UE 110.

En otras realizaciones, si un componente de red de IMS 120 incluye el indicador de llamada de emergencia 160 en la respuesta de SIP que es enviada al UE 110, el UE 110 puede abortar la señalización actual e inicial procedimientos de establecimiento de llamada de emergencia regulares, que pueden implicar iniciar una llamada sobre una red de Circuitos Conmutados, si es capaz y está disponible, o después de iniciar procedimientos de registro de emergencia, o de enviar una solicitud de INVITAR de SIP que contiene un indicador que indica que la solicitud de INVITAR de SIP es una solicitud de llamada relacionada con una emergencia y que contiene información relacionada con una emergencia sobre sí misma.

Una información que es similar a la información 180 que el UE 110 incluye en el mensaje de SIP 170 podría ser incluida por el UE 110 en un mensaje enviado bajo diferentes circunstancias. Esto se ilustra en la Figura 2, donde el UE 110, la red de IMS 120, y el PSAP 130 están de nuevo presentes. No obstante, en este caso el PSAP 130 inicia una devolución de llamada al UE 110. Como es bien conocido en el sector, después de que se termina una llamada de emergencia, el PSAP 130 puede situar una devolución de llamada al UE 110 por varias razones. Por ejemplo, si la llamada de emergencia parece haber terminado anormalmente, el PSAP 130 podría llamar al UE 110 de nuevo para determinar si el usuario del UE desea proporcionar cualquier información adicional. Alternativamente, el PSAP 130 podría devolver la llamada al usuario para pedir información que fue inadvertidamente no solicitada en la llamada inicial. Otras razones para una devolución de llamada desde el PSAP 130 hasta un llamante de emergencia después de la terminación de una llamada de emergencia pueden ser familiares para un experto en la materia.

El PSAP 130 podría iniciar la devolución de llamada enviando un mensaje de INVITAR de SIP 210, o un mensaje similar, al UE 110 a través de la red de IMS 120. En una realización, el mensaje de INVITAR de SIP 210 contiene un indicador 220 que indica que el mensaje de INVITAR de SIP 210 se refiere a una devolución de llamada de emergencia. El indicador 220 podría ser substancialmente similar al indicador 160 de la Figura 1 ó podría ser algún otro tipo de indicador. El UE 110 puede reconocer que el indicador 220 es una indicación de una devolución de llamada de emergencia desde el PSAP 130 y puede responder al indicador 220 apropiadamente llamando a la funcionalidad de devolución de llamada de emergencia, sujeta a políticas. En una realización, la respuesta del UE 110 a la recepción del indicador 220 es substancialmente similar a la respuesta de que el UE 110 tenía a la recepción del indicador 160 de la Figura 1.

Por ejemplo, una acción que el UE 110 podría llevar a cabo cuando reconoce el indicador 220 es indicar visual o audiblemente la naturaleza de la sesión al usuario. Esto es, el UE 110 podría alertar al usuario de que la llamada entrante es una devolución de llamada de emergencia. La alerta podría ser un mensaje que aparece en la pantalla de visualización del UE 110 ó algún otro tipo de indicación de la naturaleza de la llamada. Otras acciones llevadas a cabo por el UE 110 pueden implicar transmitir una respuesta 2xx ó 1xx de SIP (por ejemplo respuesta 200(OK) de SIP) 230, o un mensaje similar, que incluye información 240 acerca del UE 110, sujeto a políticas. Alternativamente, debido a limitaciones en el SIP, la información 240 puede ser transmitida sobre varios mensajes de SIP o mensajes de red (por ejemplo, información de identidad de CAN de IP proporcionada al UE puede no ser completamente fiable y por ello un mecanismo basado en provisión de red (por ejemplo, utilizando Control de Política y Tarificación (PCC

– Policy Control and Charging, en inglés)) puede proporcionar tal información) o dentro de una solicitud de refrescar objetivo tal como una solicitud de INVITAR DE NUEVO de SIP o una solicitud de ACTUALIZAR o parcialmente en una solicitud de PRACK de SIP. La información 240 podría ser substancialmente similar a la información 180 que el UE 110 proporcionó cuando recibió el indicador 160 de la Figura 1.

Una porción de la información 240 que el UE 110 podría enviar al PSAP 130 es la identidad pública de usuario del UE o algún otro símbolo de identificación. Otra porción de información 240 que el UE 110 podría transmitir en el mensaje 200OK de SIP 230 es el tipo de acceso que el UE 110 utilizado por la llamada de emergencia original. Por ejemplo, si la llamada de emergencia fue realizada sobre una LAN inalámbrica, el UE 110 podría incluir el hecho en la información 240, así como un ID de celda, un ID de línea y/o un ID de nodo de acceso de LAN inalámbrica.

Si el UE 110 conoce su ubicación geográfica, mediante el uso de un sistema de GPS por ejemplo, el UE 110 puede incluir su ubicación como otra porción de la información 240. Si el UE 110 no conoce su ubicación geográfica, los datos relativos a ubicación no están incluidos en la información 240. Si un GRUU está asociado con el UE 110, el GRUU del UE puede ser incluido como otra porción de la información 240.

En una realización alternativa, el PSAP 130 podría establecer una llamada de Circuitos Conmutados (CS – Circuit Switched, en inglés) y una puerta de enlace de CS podría entonces convertir la llamada y la señalización en tecnología de paquetes conmutados si la llamada de CS es encaminada a la puerta de enlace de CS. Activada por la llamada entrante desde el PSAP 130, la puerta de enlace de CS podría iniciar la devolución de llamada sobre tecnología de paquetes conmutados enviando un mensaje de INVITAR de SIP 210 ó un mensaje similar, al UE 110 a través de la red de IMS 120.

La Figura 3 ilustra una realización de un método 300 para que un UE responda a un mensaje relacionada con una emergencia enviado al UE. En el bloque 310, el UE recibe un mensaje que contiene un indicador que indica que la llamada relacionada con una emergencia ha sido realizada. En algunos casos, la llamada relacionada con una emergencia puede haber sido realizada por el UE sin que el UE sepa que la llamada era relativa a una emergencia. En otros casos, la llamada relacionada con una emergencia podría ser una devolución de llamada desde un PSAP al UE en respuesta a una llamada de emergencia previa desde el UE. En el bloque 320, el UE reconoce el indicador como una indicación de que su primer mensaje (solicitud de SIP inicial de una transacción de diálogo o independiente, o método desconocido o mensaje similar) se refiere a una emergencia. Opcionalmente, en el bloque 330, el UE proporciona una indicación visual, audible u otra al usuario del UE de que la emergencia relacionada con una emergencia se refiere a una emergencia. En el bloque 340, el UE envía un mensaje que contiene información relacionada con una emergencia acerca de sí misma.

La descripción descrita en esta memoria podría ser implementada como una o más modificaciones a la Especificación Técnica del Proyecto de Generación de Tercera Generación (Third Generation Partnership Project (3GPP) Technical Specification (TS), en inglés) 24.229 “Internet Protocol (IP) Multimedia Call Control Protocol Based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3”. Adiciones y modificaciones propuestas al TS 24.229, de acuerdo con varias realizaciones de la presente descripción, se proporcionan a continuación.

La siguiente adición al documento TS 24.229 de 3GPP aplica a la solicitud de INVITAR de SIP inicial en el caso de inicio en el UE de una iniciación de llamada:

En el caso de que el UE reciba una respuesta 380 (Servicio Alternativo) a una solicitud de INVITAR la respuesta que contiene un cuerpo de XML que incluye un elemento <servicio alternativo> con el atributo “alternativo” del elemento hijo <tipo> que contiene uno o más URIs de servicio de emergencia, el UE puede intentar una llamada normal tal como se describe en el subapartado 5.1.3.1 utilizando un URI de servicio de emergencia o utilizando un establecimiento de llamada de acuerdo con los procedimientos descritos en el documento TS 24.008 de 3GPP [8]. El comportamiento del UE es específico para una implementación si el atributo “alternativo” del elemento hijo <tipo> está ausente o no contiene ningún URI de servicio de emergencia.

La siguiente modificación al documento TS 24.229 de 3GPP aplica a un servicio de emergencia general: La P-CSCF almacenará una lista configurable de identificadores de servicio de emergencia local, es decir, números de emergencia y la URN de servicio de emergencia, que son válidos para el operador al cual pertenece la P-CSCF. Además de ello, la P-CSCF almacenará una lista configurable de identificadores de servicio de emergencia de interlocutores itinerantes. Las listas configurables con identificadores de servicio de emergencia de interlocutores local e itinerante indicarán el manejo por cada identificador de servicio de emergencia. Cuando el manejo indicó que la solicitud será rechazada, puede incluirse una lista configurable de URIs de servicio de emergencia alternativo en la respuesta.

La siguiente adición al documento TS 24.229 de 3GPP se aplica al tratamiento general para todos los diálogos y las transacciones independientes excluyendo el método de REGISTRO después del registro de la emergencia:

Si la P-CSCF detecta el URI de Solicitud de la solicitud inicial para un diálogo o una transacción independiente o un método desconocido hace coincidir un tipo no soportado de emergencia con los identificadores de servicio de emergencia de VPLMN o HPLMN, la P-CSCF:

-: responderá a la solicitud de INVITAR con una respuesta 380 (Servicio Alternativo);

-: asumirá que el UE soporta la versión 1 del Esquema de XML para el cuerpo de XML del subsistema de CN de IM si no está indicado el soporte del cuerpo de XML de IMS de 3GPP en la cabecera de Aceptación; e

-: incluirá en la respuesta 380 (Servicio Alternativo):

-: un campo de cabecera de Tipo de Contenido con el valor puesto en el tipo de MIME asociado del cuerpo de XML de IMS de 3GPP tal como se describe en el subapartado 7.6.1.

El cuerpo contendrá:

a) un elemento <servicio alternativo>, puesto en los parámetros del servicio alternativo; b) si la cabecera de Aceptación indica soporte para la versión 2 del Esquema de XML para el cuerpo de XML del subsistema de IM CN

- entonces, un elemento hijo de <tipo> con un atributo “alternativo” puesto en la lista de URIS de servicio de emergencia alternativo, - o si no, un elemento hijo de <tipo>, puesto en “emergencia”;

c) un elemento hijo <razón> puesto en una razón configurable por el operador.

Lo que sigue, adición alternativa al documento TS 24.229 de 3GPP aplica al tratamiento general para todos los diálogos y transacciones independientes excluyendo el método de REGISTRO tras el registro de emergencia:

Si la P-CSCF detecta que el URI de Solicitud de la solicitud inicial de diálogo, o de una transacción independiente, o de un método desconocido coincide con un tipo de emergencia no soportado en los identificadores de servicio de emergencia de VPLMN o de HPLMN, la P-CSCF:

-: responderá a una solicitud de INVITAR con una respuesta 380 (Servicio Alternativo);

-: asumirá que el UE soporta la versión 1 del Esquema de XML para el cuerpo de XML del subsistema de CN de IM si no se indica ningún soporte para el cuerpo de XML de IMS de 3GPP en la cabecera de aceptación; e

-: incluirá en la respuesta 380 (Servicio Alternativo):

-: un campo de cabecera de Contenido con el valor puesto en el tipo de MIME asociado del cuerpo de XML de IMS de 3GPP tal como se describe en el subapartado 7.6.1.

El cuerpo contendrá:

a) un elemento <servicio alternativo>, puesto en los parámetros del servicio alternativo; b) un elemento hijo <tipo> con un atributo “alternativo” puesto en una lista de URIs de servicio de emergencia alternativos, c) un elemento hijo <razón>, puesto en una razón configurable por el operador.

La siguiente modificación al documento TS 24.229 de 3GPP aplica al tratamiento general para todas las transacciones de diálogos e independientes excluyendo el método de REGISTRO para un registro que no es de emergencia: Si la P-CSCF recibe una solicitud inicial para un diálogo, o una transacción independiente, o un método desconocido, para un usuario registrado la P-CSCF inspeccionará el URI de Solicitud independiente de los valores de posibles entradas en las cabeceras de Ruta recibidas para identificadores de servicio de emergencia conocidos, es decir, números de emergencia y la URN de servicio de emergencia de estas listas configurables. Si la P-CSCF detecta que el URI de Solicitud de la solicitud inicial para un diálogo o una transacción independiente, o un método desconocido coincide con uno de los identificadores de servicio de emergencia en cualquiera de estas listas, la P-CSCF:

0) determinará la ubicación geográfica del UE. Procedimientos específicos para una tecnología de acceso se describen en cada anexo específico para tecnología de acceso. Si la P-CSCF no es capaz de manejar sesiones de emergencia o debido a política local no maneja sesiones de emergencia o sólo maneja cierto tipo de solicitud de sesión de emergencia o la CAN de IP a la cual está conectado el UE

o en la que el UE está itinerando o la P-CSCF está en una red diferente de la red del operador local del UE, entonces la P-CSCF:

-: rechazará la solicitud devolviendo una respuesta 380 (Servicio Alternativo) al UE;

-: asumirá que el UE soporta la versión 1 del Esquema de XML para el cuerpo de XML del subsistema de IM CN si no se indica un soporte para el cuerpo de XML de IMS de 3GPP en la cabecera de Aceptación; e

-: incluirá en la respuesta 380 (Servicio Alternativo):

El cuerpo contendrá:

a) un elemento <servicio alternativo>, puesto en los parámetros del servicio alternativo; b) si la cabecera de Aceptación indica soporte para la versión 2 del Esquema de XML para el cuerpo de XML del subsistema de CN de IM

-: entonces un elemento hijo de <tipo> con un atributo “alternativo” puesto en una lista de URIs de servicio de emergencia alternativo, y

-: si la solicitud inicial para un diálogo o una transacción independiente, o método desconocido fuese para un tipo de emergencia soportado, el elemento hijo <tipo> es puesto en “emergencia” para indicar que era una llamada de emergencia soportada,

-: si no, un elemento hijo <tipo> es puesto en “emergencia”;

c) un elemento hijo <razón>, puesto en una razón configurable por un operador; y d) un elemento hijo <acción>, puesto en “registro de emergencia” si la solicitud incluyese una URN de servicio de emergencia en el URI de Solicitud.

NOTA 1: Itinerar es cuando un UE está en un área geográfica que está fuera del área geográfica de servicio del subsistema de CN de IM local. NOTA 1a: sip:911@exemple.com;user=phone podría ser un UTI de servicio de emergencia alternativo. “urn:servicio:sos.control de animales” podría ser un tipo de llamada de emergencia no soportada. NOTA 2: La URN de llamada de emergencia en el URI de solicitud indica para la red que el intento de llamada de emergencia es reconocido por el UE.

La siguiente modificación alternativa al documento TS 24.229 de 3GPP aplica al tratamiento general para todas las transacciones de diálogo o individuales excluyendo el método de REGISTRO para un registro que no es de emergencia:

Si a P-CSCF recibe una solicitud inicial para un diálogo o una transacción independiente, o un método desconocido, para un usuario registrado la P-CSCF inspeccionará el URI de Solicitud independiente de valores de posibles entradas a las cabeceras de Ruta recibidas para identificadores de servicio de emergencia conocidos, es decir, números de emergencia y la URN de emergencia de estas listas configurables. Si la P-CSCF detecta que el URI de Solicitud de la solicitud inicial para un diálogo o una transacción independiente, o un método desconocido coincide con uno de los identificadores de servicio de emergencia de cualquiera de estas listas, la P-CSCF:

0) determinará la ubicación geográfica del UE. Se describen procedimientos específicos de tecnología de acceso en cada anexo específico de tecnología de acceso. Si la P-CSCF no es capaz de manejar sesiones de emergencia o debido a que la política local no maneja sesiones de emergencia o sólo maneja cierto tipo de solicitud de sesión de emergencia o la CAN de IP a la cual el UE está conectado

-: rechazará la solicitud devolviendo una respuesta 380 (Servicio Alternativo) al UE:

-: Asumirá que el UE soporta la versión 1 del Esquema de XML para el cuerpo del subsistema de CN de IM si no está indicado el soporte del cuerpo de XML de IMS de 3GPP en la cabecera de aceptación; e

-: incluirá en la respuesta 380 (Servicio Alternativo):

-: un campo de cabecera de Tipo de Contenido con el valor puesto en el tipo de MIME asociado del cuerpo de XML de IMS de 3GPP tal como se describe en el subapartado

7.6.1.

El cuerpo contendrá:

a) un elemento <servicio alternativo>, puesto en los parámetros del servicio alternativo; b) un elemento hijo <tipo> con un atributo “alternativo” puesto en una lista de URIs de servicio de emergencia alternativo, y

-: si la solicitud inicial para diálogo o una transacción independiente, o método desconocido fuese para un tipo de emergencia soportado, el elemento hijo <tipo> es puesto en “emergencia” para indicar que fue una llamada de emergencia soportada;

c) un elemento hijo <razón>, puesto en una razón configurable para un operador; y d) un elemento hijo <acción>, puesto en “registro de emergencia” si la solicitud incluyese una URN de servicio de emergencia en el URI de Solicitud.

NOTA 1: Itinerar es cuando un UE está en un área geográfica que está fuera del área geográfica de servicio del subsistema de CN de IM local. NOTA 2: La URN de servicio de emergencia en el URI de solicitud indica para la red que el intento de llamada de emergencia es reconocido por el UE.

La siguiente modificación al documento TS 24.229 de 3GPP aplica a casos anormales:

Si el subsistema de CN de IM al cual pertenece la P-CSCF no es capaz de manejar sesiones de emergencia

o debido a que la política local no maneja sesiones de emergencia o sólo maneja cierto tipo de solicitud de sesión de emergencia o no soporta sesiones de emergencia para ninguna ubicación geográfica del UE o la CAN de IP a la cual está conectado el UE, la P-CSCF no enviará la solicitud de INVITAR. La P-CSCF:

-: asumirá que el UE soporta la versión 1 del Esquema de XML para el cuerpo de XML de subsistema de CN de IM si no se indica ningún soporte para el cuerpo de XML de IMS de 3GPP en la cabecera de Aceptación; e

-: incluirá en la respuesta 380 (Servicio Alternativo):

-: un campo de cabecera de Tipo Contenido con el valor ajustado al tipo de MIME asociado del cuerpo de XML de IMS de 3GPP tal como se describe en el subapartado 7.6.1.

El cuerpo contendrá:

-: entonces, un elemento hijo <tipo> con un atributo “alternativo” puesto en una lista de URIs de servicio de emergencia alternativo, y

- si la solicitud inicial de una transacción de diálogo o independiente, o un método desconocido fuese para un tipo de emergencia soportado, el elemento hijo <tipo> es puesto en “emergencia” para indicar que fue una llamada de emergencia soportada,

-: si no, un elemento hijo <tipo> es puesto en “emergencia”;

NOTA 1: URN de servicio de emergencia en el URI de solicitud indica a la red que el intento de llamada de emergencia es reconocido por el UE. NOTA 1a: sip:911@ejemplo.com;usuario=teléfono podría ser un URI de servicio de emergencia alternativo. “urn:servicio:sos.control de animales” podría ser un tipo de llamada de emergencia no soportada. NOTA 2: Algunas redes sólo permiten solicitudes de sesión con un URI de Solicitud que contiene una URN de servicio de emergencia, es decir, una URN de servicio con un tipo de servicio de alto nivel de “sos” como se especifica en la draft-ietf-ecrit-service-urn [69].

La siguiente modificación alternativa al documento TS 24.229 de 3GPP aplica a casos anormales:

o debido a que la política local no maneja sesiones de emergencia o sólo maneja cierto tipo de solicitud de sesión de emergencia o no soporta sesiones de emergencia para cualquier ubicación geográfica del UE está situado o la CAN de IP a la cual está conectado el UE, la P-CSCF no enviará la solicitud de INVITAR. La P-CSCF:

-: asumirá que el UE soporta la versión 1 del Esquema XML para el cuerpo de XML de subsistema de CN de IP si el soporte para el cuerpo de XML de IMS de 3GPP en la cabecera de Aceptación no está indicado; e

-: incluirá en la respuesta 380 (Servicio Alternativo):

-: un campo de cabecera de Tipo de Contenido con el valor puesto en tipo MIME asociado del cuerpo XML de IMS de 3GPP tal como se describe en el subapartado 7.6.1.

El cuerpo contendrá:

a) un elemento <servicio alternativo> puesto en los parámetros del servicio alternativo; b) un elemento hijo <tipo> con un atributo “alternativo” puesto en una lista de URIs de servicio de emergencia alternativo, y

-: si la solicitud inicial de diálogo, o transacción independiente, o método desconocido fuese para un tipo de emergencia, el elemento hijo <tipo> es puesto en “emergencia” para indicar que era una llamada de emergencia soportada;

NOTA 1: URN de servicio de emergencia en el URI de solicitud indica a la red que el intento de llamada de emergencia es reconocido por el UE. NOTA 2: Algunas redes sólo permiten solicitudes de sesión con un URI de Solicitud que contiene una URN de servicio de emergencia, es decir, una URN de servicio con un tipo de servicio de alto nivel de “sos” tal como se especifica en draft-ietf-ecrit-service-urn [69].

Podría realizarse la siguiente modificación al Esquema de XML del cuerpo de XML del subsistema de CN de IM de 3GPP para implementar una o más de las realizaciones descritas en esta memoria: El elemento <acción> contiene el atributo “alternativo” y sólo el valor de “registro de emergencia” en el presente documento. El atributo “alternativo” puede ser puesto en una lista de URIs de servicio de emergencia alternativos.

Las siguientes dos adiciones al documento TS 24.229 de 3GPP aplican a procedimientos genéricos aplicables a todos los sistemas excluyendo el control de REGISTRO:

Mediante la generación de una solicitud inicial de un diálogo, o una transacción independiente, o un control desconocido, excluyendo ACK y CANCELAR, el UE incluirá la cabecera de Aceptación con “aplicación/sdp”, el tipo de MIME asociado con el cuerpo XML de IMS de 3GPP (véase el subapartado 7.6.1) y cualquier otro tipo de MIME el UE desea y es capaz de aceptar.

En el caso de que el UE reciba una respuesta 380 (Servicio Alternativo) a una solicitud inicial de una transacción de diálogo o independiente o de un método desconocido, la respuesta incluyendo un cuerpo XML del subsistema de CN de IM tal como se describe en el subapartado 7.6 que incluye un elemento <servicio alternativo> con el elemento hijo <tipo> puesto en “emergencia”, el UE intentará una llamada de emergencia tal como se describe en el subapartado

5.1.6.

Si la respuesta 1xx ó 2xx a una solicitud inicial de diálogo o una transacción independiente o un método desconocido, contiene un indicador de sesión de emergencia, entonces el UE enviará un método de solicitud de INVITAR de nuevo al RFC 3261 [26], y:

1) el UE indicará la naturaleza de la sesión del usuario;

NOTA 17: El UE no cambia la cabecera de “DE” para incluir una identidad de usuario pública o el URI de tel asociado con la identidad de usuario pública, en esta versión de la especificación.

2) si está disponible para el UE, y si está definido para el tipo de acceso tal como se especifica en el subapartado 7.2A.4, el UE incluirá una cabecera de Info de Red de Acceso P y contendrá un identificador de ubicación tal como el id de celda, id de línea o la identidad del nodo de acceso de la I-WLAN;

NOTA 18: La especificación de emergencia de IMS en el documento TS 23.167 de 3GPP [4B] describe varios métodos de cómo puede el UE obtener su información de ubicación de la red de acceso o de un servidor. Tales métodos no están en el ámbito de esta especificación.

3) el UE insertará una Identidad Preferida P que incluye la identidad pública del usuario o el URI de tel asociado con la identidad de usuario pública tal como se describe en el subapartado 4.2;

4) si el UE tiene su información de ubicación disponible, entonces el UE la incluirá de la siguiente manera:

-: si el UE conoce el URI que señala a donde la ubicación del UE está almacenada, incluirá el URI en la cabecera de ubicación geográfica de acuerdo con draft-ietf-sip-location-conveyance [89]; o bien

-: si la información de la ubicación geográfica del UE está disponible para el UE, incluirá su información de ubicación geográfica como objeto de ubicación PIDF de acuerdo con el RFC 4119 [90] e incluirá el objeto de ubicación en un cuerpo de mensaje con el tipo de contenido aplicación/pidf+xml de acuerdo con draft-ietf-sip-location-conveyance [89]. La cabecera de ubicación geográfica es puesta en un ID de Contenido de acuerdo con draft-ietf-sip-location-conveyance [89]; y

5) si el UE no tiene ninguna ubicación geográfica disponible, el UE no incluirá ninguna información de ubicación geográfica tal como se especifica en draft-ietf-sip-location-conveyance [89]; y

6) si un valor de GRUU público (pub gruu en inglés) ha sido salvado asociado con la identidad de usuario pública y el UE no indica privacidad de la Identidad Afirmada P, entonces el UE insertará el valor de GRUU público en la cabecera del contacto tal como se especifica en draft-ietf-sip-gruu [93]; si no, el UE incluirá el puerto del servidor protegido en la dirección en la cabecera del contacto.

NOTA 19: De acuerdo con el RFC 3261 [26], una solicitud de INVITAR de nuevo no puede ser enviada mientras que otra transacción de INVITAR está en progreso en cualquier dirección. NOTA 20: No es necesario que esta solicitud de INVITAR de nuevo cambie los parámetros de la sesión. NOTA 21: Se sugiere que los UEs sólo utilicen la opción de proporcionar un URI cuando la parte de dominio pertenece al proveedor de la P-CSCF o la S-CSCF actual. Esto es un problema por el cual el operador de red necesita proporcionar un guiado al usuario final. Un URI que sólo puede resolverse para el UE que está haciendo la llamada de emergencia no es deseable. NOTA 22: Durante el diálogo, los puntos de conexión a la CAN de IP del UE pueden cambiar (por ejemplo el UE se conecta a diferentes celdas). El UE rellenará la cabecera de Info de Red de Acceso P en cualquier solicitud (excepto solicitudes de ACK y solicitudes de CANCELAR) o respuesta (excepto respuestas de CANCELAR) dentro de un diálogo con el punto de conexión actual a la CAN de IP (por ejemplo, la información de celda actual).

Aplicar privacidad, incluyendo eliminar información de ubicación y de red de acceso, si el PSAP está dentro del dominio de confianza de la red, puede ser llevado a cabo por los elementos de red de IMS tales como E-CSCF, IBCF y otros. Puede resultar preferido que se solicite privacidad de “sesión” (es decir, campo de cabecera de Privacidad puesto en incluir el valor de “sesión” puesto que el campo de cabecera de Info de Red de Acceso P está presente en la mayoría de los mensajes de SIP). Puede resultar preferido que la E-CSCF reciba una ubicación tal que pueda determinar el PSAP más aplicable y la utilice en el encaminamiento de la solicitud al PSAP o al centro de respuesta de emergencias. Requerimientos de privacidad de acuerdo con el RFC 4244 pueden aplicar también pero actualmente ningún procedimiento prevé incluir información de historia en una solicitud de servicios de emergencia. Las siguientes dos adiciones al documento TS 24.229 de 3GPP aplican a Procedimientos en la E-CSCF:

Cuando la E-CSCF recibe una solicitud de diálogo solicitando privacidad o una transacción independiente solicitando privacidad o cualquier solicitud o respuesta relativa a un diálogo solicitando privacidad o una transacción solicitando privacidad originada en el UE, y si la política del operador local permite la solicitud por parte del usuario de supresión de identificadores de usuario pública e información de ubicación, la E-CSCF:

-: aplicará cualquier privacidad solicitada por el RFC 3323 [33] relativa a privacidad y RFC 3325 [34] a la cabecera de Identidad Asserted P;

-: si existe, eliminará el campo de cabecera de INFO RED de ACCESO P;

-: si existe, eliminará la ubicación del objeto del cuerpo del mensaje y eliminará tipo de contenido application(piedf+xml del campo de cabecera de Tipo de Contenido;

-: y si existe, eliminará el campo de cabecera de localización geográfica.

NOTA: Las políticas del operador (por ejemplo requerimientos de soporte de comunicaciones de emergencia) pueden ignorar la solicitud de supresión por parte del usuario.

6) seleccionar, basándose en la información de ubicación y opcionalmente en el tipo de servicio de emergencia:

-: un PSAP conectado a la red del subsistema de CN de IM y añadir el URI del PSAP a la cabecera de Ruta más alta; o

NOTA 3: Si el usuario no solicitase privacidad, la E-CSCF transporta la cabecera de Info de Red de Acceso P que contiene el identificador de la ubicación, si está definido para el tipo de acceso tal como se especifica en el subapartado 7.2A.4, al PSAP,

-: un PSAP en la PSTN, añadir el URI de la BGCF a la cabecera de Ruta más alta y añadir un URI del PSAP en el formato de URI tel a la Solicitud de URI con una entrada utilizada en el dominio de PSTN/CS para dirigir al PSAP;

NOTA 4: Si el usuario no solicitase privacidad, la E-CSCF transporta la cabecera de Info de Red de Acceso P que contiene el identificador de la ubicación, si está definido para el tipo de acceso tal como se especifica en el subapartado 7.2A.4 hacia la MGCF. La MGCF puede trasladar la información de ubicación si está incluida en INVITAR (es decir, tanto la información de ubicación geográfica en la PIDF-LO como el identificador de ubicación en la cabecera de Info de Red de Acceso P) en señalización de ISUP, véase el documento TS 29.163 de 3GPP [11B].

NOTA 5: La E-CSCF puede solicitar información de ubicación e información de encaminamiento de la LRF. La E-CSCF puede, por ejemplo, enviar el identificador de ubicación a la LRF y la LRF mapea el identificador de ubicación en la correspondiente información de ubicación geográfica que la LRF envía a la E-CSCF. La LRF puede invocar una RDF para convertir la información de ubicación en un URI de PSAP/EC correcto. Tanto la información de ubicación como el URI del PSAP son devueltos a la E-CSCF. NOTA 6: El modo en el que la E-CSCF determina la dirección del siguiente salto cuando la dirección del PSAP es un URI tel depende de la implementación.

7) Si el usuario no solicitase privacidad y si la E-CSCF recibe un número de referencia de la LRF, la E-CSCF incluirá el número de referencia en la cabecera de Identidad Asserted de P;

NOTA 7: El número de referencia se utiliza en la comunicación entre el PSAP y la LRF.

La Figura 4 ilustra un sistema de comunicación inalámbrica que incluye una realización del UE 110. El UE 110 es operable para aspectos de implementación de la descripción, pero la descripción no debe estar limitada a estas implementaciones. Aunque ilustrado como un teléfono móvil, el UE 110 puede tomar varias formas que incluyen un aparato de mano inalámbrico, un localizador, un asistente digital personal (PDA – Personal Digital Assistant, en inglés), un ordenador portátil, un ordenador de tableta o un ordenador portátil de regazo. Muchos dispositivos adecuados combinan algunas o todas estas funciones. En algunas realizaciones de la descripción, el UE 110 no es un dispositivo de cálculo de propósito general como un ordenador portátil, portátil de regazo o de tableta, sino que es un dispositivo de comunicación para propósito especial tal como un teléfono móvil, un dispositivo manual inalámbrico, un localizador o un PDA. En otra realización, el UE 110 puede ser un portátil, un portátil de regazo u otro dispositivo de cálculo. El UE 110 puede soportar actividades especializadas tales como juegos, control de inventario, control de trabajo y/o funciones de gestión de tareas, y otros.

El UE 110 incluye un visualizador 402. El UE 110 incluye también una superficie táctil, un teclado u otras teclas de introducción de datos llamadas de manera general 404 para la introducción de datos por parte del usuario. El teclado puede ser un teclado alfanumérico completo o reducido tal como QWERTY, Dvorak, AZERTY y tipos secuenciales, o un teclado numérico tradicional con letras del alfabeto asociadas con un teclado numérico de teléfono. Las teclas de introducción de datos pueden incluir una rueda de seguimiento, una tecla de salida con guardado de datos o de escape, una bola de seguimiento y otras teclas de navegación o funcionales, que pueden ser presionadas hacia dentro para proporcionar otra función de introducción de datos. El UE 110 puede presentar opciones para la selección por parte del usuario, controles para que el usuario los accione y/o cursores u otros indicadores para que el usuario los dirija. El UE 110 puede también aceptar introducción de datos por parte del usuario, incluyendo números para marcar o varios valores de parámetros para configurar la operación del UE 110. El UE 110 puede también ejecutar una o más aplicaciones de software o de firmware en respuesta a órdenes del usuario. Estas aplicaciones pueden configurar el UE 110 para que lleve a cabo varias funciones personalizadas en respuesta a una interacción por parte del usuario. Adicionalmente, el UE 110 puede ser programado y/o configurado de manera inalámbrica desde una estación de base inalámbrica, un punto de acceso inalámbrico o un UE 110 asociado.

Entre las diferentes aplicaciones ejecutables por el UE 110 está un navegador por la Red, que permite que el visualizador 402 muestre una página de la Red. La página de la Red puede ser obtenida por medio de comunicación inalámbricas con un nodo de acceso a red inalámbrica, una torre celular, un UE 110 asociado o cualquier otra red o sistema de comunicación inalámbrico 400. La red 400 está acoplada a una red fija 408, tal como al Internet. Por medio del enlace inalámbrico y de la red fija, el UE 110 tiene acceso a información en varios servidores, tales como un servidor 410. El servidor 410 puede proporcionar contenido que puede ser mostrado en el visualizador 402. Alternativamente, el UE 110 puede acceder a la red 400 a través de un UE 110 asociado que actúa como un intermediario, en un tipo de soporte o tipo de salto de conexión.

La Figura 5 muestra un diagrama de bloques del UE 110. Aunque se representa una variedad de componentes conocidos de los UEs 110, en una realización un subconjunto de los componentes listados y/o de los componentes adicionales no listados puede ser incluido en el UE 110. El UE 110 incluye un procesador de señal digital (DSP – Digital Signal Processor, en inglés) 502 y una memoria 504. Como se muestra, el UE 110 puede incluir también una antena y una unidad de extremo frontal 506, un transceptor de radiofrecuencia (RF – Radio Frequency, en inglés) 508, y una unidad de procesamiento de banda de base 510, un micrófono 512, un micrófono auricular 514, un puerto de cascos 516, una interfaz de entrada/salida 518, una tarjeta de memoria extraíble 520, un puerto de bus de serie universal (USB – Universal Serial Bus, en inglés) 522, un subsistema de comunicación inalámbrica de corto alcance 524, una alerta 526, un teclado numérico 528, un visualizador de cristal líquido (LCD – Liquid Crystal Display, en inglés), que puede incluir una superficie táctil 530, un controlador de LCD 532, una cámara de dispositivo de carga acoplado (CCD – Charge Coupled Device, en inglés) 534, un controlador de cámara 536 y un sensor de sistema de localización global (GPS – Global Positioning System, en inglés) 538. En una realización, el UE 110 puede incluir otro tipo de visualizador que no proporciona una pantalla táctil. En una realización, el DSP 502 puede comunicarse directamente con la memoria 504 sin pasar a través de la interfaz de entrada/salida 518.

El DSP 502 ó alguna otra forma de controlador o de unidad de procesamiento central operan para controlar los diferentes componentes del UE 110 de acuerdo con un software o firmware almacenado en la memoria 504 o almacenado en la memoria contenida dentro del propio DSP 502. Además del software o firmware incorporado, el DSP 502 puede ejecutar otras aplicaciones almacenadas en la memoria 504 o que le son proporcionadas a través de medios portadores de información tales como medios de almacenamiento de datos portátiles como la tarjeta de memoria extraíble 520 ó a través de comunicaciones de red fijas o inalámbricas. El software de aplicación puede comprender un conjunto compilado de instrucciones legibles mediante una máquina que configuran el DSP 502 para proporcionar la deseada funcionalidad, o el software de aplicación puede ser instrucciones de software de alto nivel para que sean procesadas por un intérprete o compilador para configurar indirectamente el DSP 502.

La antena y la unidad de extremo frontal 506 puede ser proporcionada para convertir entre señales controlas y señales eléctricas, permitiendo que el UE 110 envíe y reciba información de una red celular o de alguna otra red de comunicaciones inalámbricas disponible o de un UE 110 asociado. En una realización, la antena y la unidad de acceso frontal 506 puede incluir múltiples antenas para soportar la formación de haz y/o de operaciones de múltiple entrada múltiple salida (MIMO – Múltiple Input Múltiple Output, en inglés). Como es conocido para los expertos en la materia, las operaciones de MIMO pueden proporcionar diversidad espacial, lo que puede ser utilizado para solucionar condiciones de canal difíciles y/o aumentar el rendimiento del canal. La antena y la unidad de acceso frontal 506 pueden incluir componentes de sintonización de antena y/o de acoplamiento de impedancia, amplificadores de potencia de RF y/o amplificadores de bajo ruido.

El transceptor de RF 508 proporciona desviación de frecuencia, que convierte señales de RF recibidas en banda de base y que convierte señales de transmisión de banda de base en RF. En algunas descripciones puede entenderse que un transceptor de radio o un transceptor de RF incluyen otra funcionalidad de procesamiento de señal tal como modulación/desmodulación, codificación / descodificación, entrelazado / desentrelazado, difusión / concentración, transformación de Fourier Rápida inversa (IFFT – Inverse Fast Fourier Transforming, en inglés) / transformación de Fourier rápida (FFT – Fast Fourier Transforming, en inglés), añadido / eliminación de prefijo cíclico y otras funciones de procesamiento de señal. En aras de la claridad, la descripción aquí separa la descripción de este procesamiento de señal de la etapa de RF y/o de radio y conceptualmente asigna este procesamiento de señal a la unidad de procesamiento de banda de base 510 analógica y/o al DSP 502 o a otra unidad de procesamiento central. En algunas realizaciones, el Transceptor de RF 508, porciones de la Antena y de la y de la Unidad de Extremo Frontal 506 y la unidad de procesamiento de banda de base 510 pueden ser combinadas en una o más unidades de procesamiento y/o circuitos integrados para una aplicación específica (ASICs – Application Specific Integrated Circuits, en inglés).

La unidad de procesamiento de banda de base 510 analógica puede proporcionar varios procesamientos analógicos de entradas y salidas, por ejemplo, procesamiento analógico de entradas desde el micrófono 512 y de los cascos 516 y salidas al auricular 514 y a los cascos 516. Para ese fin, la unidad de procesamiento de banda de base analógica 510 puede tener puertos para conectar al micrófono 512 incorporado y el altavoz auricular 514 que permite que el UE 110 sea utilizado como un teléfono celular. La unidad de procesamiento de banda de base analógica 510 puede incluir también un puerto para conectarse a unos cascos o a otra configuración de micrófono y altavoz de manos libres. La unidad de procesamiento de banda de base analógica 510 puede proporcionar conversión de digital a analógico en una dirección de señal y conversión de analógico a digital en la dirección de señal opuesta. En algunas realizaciones, al menos algunas de las funcionalidades de la unidad de procesamiento de banda de base analógica 510 pueden ser proporcionadas mediante componentes de procesamiento digital, por ejemplo, mediante el DSO 502 o mediante otras unidades de procesamiento central.

El DSP 502 puede llevar a cabo modulación / desmodulación, codificación / descodificación, entrelazado / desentrelazado, difusión / concentración, transformación de Fourier rápida inversa (IFFT – Inverse Fast Fourier Transforming, en inglés) / transformación de Fourier rápida (FFT – Fast Fourier Transforming, en inglés), añadido/eliminación de prefijo cíclico y otras funciones de procesamiento de señal asociadas con las comunicaciones inalámbricas. En una realización, por ejemplo en una aplicación de tecnología de acceso múltiple por división de código (CDMA – Code Division Multiple Access, en inglés), para una función de transmisor el DSP 502 puede llevar a cabo modulación, codificación, entrelazado y difusión y para que una función de receptor el DSP 502 pueda llevar a cabo concentración, desentrelazado, descodificación y desmodulación. En otra realización, por ejemplo en una aplicación de tecnología de acceso múltiple por división de frecuencia ortogonal (OFDMA – Orthogonal Function Frequency División Múltiple Access, en inglés), para la función de transmisor el DSP 502 puede llevar a cabo modulación, codificación, entrelazado, transformación de Fourier rápida inversa y adición de prefijo cíclico y para una función de receptor el DSP 502 puede llevar a cabo eliminación de prefijo cíclico, transformación de Fourier rápida, desentrelazado, descodificación y desmodulación. En otras aplicaciones de tecnología inalámbrica, otras funciones de procesamiento de señal y combinaciones de funciones de procesamiento de señal pueden ser llevadas a cabo por el DSP 502.

El DSP 502 puede comunicarse con una red inalámbrica por medio de la unidad de procesamiento de banda de base analógica 510. En algunas realizaciones, la comunicación puede proporcionar conectividad de Internet, permitiendo que un usuario obtenga acceso a contenido en la Internet y enviar y recibir correo electrónico o mensajes de texto. La interfaz de entrada/salida 518 interconecta el DSP 502 y varias memorias e interfaces. La memoria 504 y la tarjeta de memoria extraíble 520 pueden proporcionar software y datos para configurar la operación del DSP 502. Entre las interfaces pueden estar la interfaz de USB 522 y el subsistema de comunicación inalámbrica de corto alcance 524. La interfaz de USB 522 puede ser utilizada para cambiar el UE 110 y puede permitir también que el UE 110 funcione como un dispositivo periférico para intercambiar información con un ordenador personal o con otro sistema de ordenador. El subsistema de comunicación inalámbrica de corto alcance 524 puede incluir un puerto de infrarrojos, una interfaz de Bluetooth, una interfaz inalámbrica que cumple el estándar IEEE 802.11 o cualquier otro subsistema de comunicación inalámbrica de corto alcance, que pueda permitir al UE 110 comunicarse de manera inalámbrica con otros UEs y/o estaciones de base inalámbricas cercanos.

La interfaz de entrada/salida 518 puede también conectar el DSP 502 a la alerta 526 que, cuando es activada, hace que el UE 110 proporcione un aviso al usuario, por ejemplo, dando una llamada, interpretando una melodía o vibrando. La alerta 526 puede servir como mecanismo para alertar al usuario de alguno de los diferentes eventos tales como una llamada entrante, un nuevo mensaje de texto y un recordatorio de cita vibrando en silencio o interpretando una melodía preasignada específica para un llamante particular.

El teclado 528 se acopla al DSP 502 a través de la interfaz 518 para proporcionar un mecanismo para que el usuario realice selecciones, introduzca información y si no proporcione una entrada al UE 110. El teclado 528 puede ser un teclado alfanumérico completo o reducido tal como QWERTY, Dvorack, AZERTY y tipos secuenciales, o un teclado numérico tradicional con letras del alfabeto asociadas con un teclado numérico de teléfono. Las teclas de introducción de datos pueden incluir una rueda de seguimiento, una tecla de salida grabando o de escape, una bola de seguimiento y otras teclas de navegación o funcionales, que pueden ser presionadas hacia dentro para proporcionar otra función de introducción de datos. Otro mecanismo de introducción de datos puede ser el LCD 530, que puede incluir capacidad de pantalla táctil y también mostrar texto y/o gráficos al usuario. El controlador de LCD 532 acopla el DSP 502 al LCD 530.

La cámara de CCD 534, si está equipada, permite al UE 110 tomar fotografías digitales. El DSP 502 se comunica con la cámara de CCD 534 por medio del controlador de cámara 536. En otra realización, puede emplearse una cámara que opera de acuerdo con una tecnología distinta de las cámaras de Dispositivo Acoplado de Carga. El sensor de GPS 538 está acoplado al DSP 502 para descodificar señales de sistema de posicionamiento global, permitiendo por ello que el UE 110 determine su posición. Varios periféricos diferentes de éstos pueden ser también incluidos para proporcionar funciones adicionales, por ejemplo, recepción de radio y televisión.

La Figura 6 ilustra un entorno de software 602 que puede ser implementado por el DSP 502. El DSP 502 ejecuta activadores de sistema operativo 604 que proporcionan una plataforma desde la cual opera el resto del software. Los activadores del sistema operativo 604 proporcionan activadores para el hardware del nodo con interfaces estandarizadas que es accesible para el software de aplicación. Los activadores del sistema operativo 604 incluyen servicios de gestión de aplicación (“AMS”) 606 que transfieren el control entre aplicaciones que se ejecutan en el UE

110. También mostradas en la Figura 6 están una aplicación de navegador de Red 608, una aplicación de ejecución de medios 610 y applets de Java 612. La aplicación de navegador de Red 608 configura el UE 110 para operar como un navegador de Red, permitiendo al usuario introducir información en formas y selecciona enlaces para obtener y visualizar páginas de la Red. La aplicación de reproducción de medios 610 configura el UE 110 para obtener y reproducir medios de audio o audiovisuales. Los applets de Java 612 configuran el UE 110 para proporcionar juegos, utilidades y otra funcionalidad. Un componente 614 podría proporcionar la funcionalidad descrita en esta memoria.

El UE 110 y otros componentes descritos anteriormente podrían incluir un componente de procesamiento que es capaz de ejecutar instrucciones relativas a las acciones descritas anteriormente. La Figura 7 ilustra un ejemplo de un sistema 1300 que incluye un componente de procesamiento 1310 adecuado para implementar una o más realizaciones descritas en esta memoria. Además del procesador 1310 (que puede denominarse unidad de procesador central o CPU – Central Processor Unit, en inglés), el sistema 1300 podría incluir dispositivos de conectividad de red 1320, memoria de acceso aleatorio (RAM – Random Access Memory, en inglés) 1330, memoria de sólo lectura (ROM – Read Only Memory, en inglés) 1340, almacén secundario 1350 y dispositivos de entrada/salida (I/O) 1360. En algunos casos, algunos de estos componentes pueden no estar presentes o pueden ser combinados en varias combinaciones con otro o con otros componentes no mostrados. Estos componentes podrían ser situados en una única entidad física o en más de una entidad física. Cualquier acción descrita como tomada por el procesador 1310 podría ser tomada por el procesador 1310 solo o por el procesador 1310 junto con uno o más componentes mostrados o no mostrados en el dibujo.

El procesador 1310 ejecuta instrucciones, códigos, programas de ordenador o rutinas a los que podría acceder desde los dispositivos de conectividad de red 1320, RAM 1330, ROM 1340 ó almacén secundario 1350 (que podría incluir varios sistemas basados en disco tales como disco duro, disco flexible o disco óptico). Aunque sólo se muestra un procesador 1310, pueden existir múltiples procesadores. Así, aunque pueden explicarse instrucciones como siendo ejecutadas por un procesador, las instrucciones pueden ser ejecutadas simultáneamente, en serie o si no mediante uno o múltiples procesadores. El procesador 1310 puede ser implementado como uno o más microprocesadores de CPU.

Los dispositivos de conectividad de red 1320 pueden tomar la forma de módems, bancos de módems, dispositivos de interfaz de datos distribuidos mediante fibra (FDDI – Fiber Distributed Data Interface, en inglés), dispositivos de red de área local inalámbrica (WLAN – Wireless Local Area Network, en inglés), dispositivos transceptores de radio tales como acceso múltiple por división de código (CDMA – Code Division Multiple Access, en inglés) y/o dispositivos transceptores de radio de sistema global para comunicaciones móviles ( GSM – Global System for Mobile communications, en inglés) y otros dispositivos bien conocidos para conectarse a redes. Estos dispositivos de conectividad de red 1320 pueden permitir que el procesador 1310 se comunique con la Internet o con una o más redes de telecomunicaciones o con otras redes desde las cuales el procesador 1310 podría recibir información o a las cuales el procesador 1310 podría enviar información.

Los dispositivos de conectividad de red 1320 podrían incluir también uno o más componentes 1325 capaces de transmitir y/o de recibir datos de manera inalámbrica en la forma de ondas electromagnéticas, tales como señales de radiofrecuencia o señales de frecuencia de microondas. Alternativamente, los datos pueden propagarse en o sobre la superficie de conductores eléctricos, en cables coaxiales, en guías de ondas, en medios ópticos tales como fibra óptica o en otros medios. El componente transceptor 1325 podría incluir unidades de recepción y de transmisión separadas o un único transceptor. La información transmitida o recibida por el transceptor 1325 puede incluir datos que han sido procesados por el procesador 1310 ó instrucciones que deben ser ejecutadas por el procesador 1310. Tal información puede ser recibida desde y enviada hacia una red en forma, por ejemplo, de una señal de banda de base de datos de ordenador o una señal embebida en una onda portadora. Los datos pueden ser ordenados de acuerdo con diferentes secuencias como puede ser deseable bien para procesar o para generar los datos o transmitir o recibir los datos. La señal de banda de base, la señal embebida en la onda portadora u otros tipos de señales actualmente utilizadas o desarrolladas a continuación en esta memoria pueden denominarse medio de transmisión y pueden ser generadas de acuerdo con varios métodos bien conocidos para un experto en la materia.

La RAM 1330 podría ser utilizada para almacenar datos volátiles y quizás para almacenar instrucciones que son ejecutadas por el procesador 1310. La ROM 1340 es un dispositivo de memoria no volátil que típicamente tiene una capacidad de memoria menor que la capacidad de memoria del almacén secundario 1350. La ROM 1340 podría ser utilizada para almacenar instrucciones y quizás datos que son leídos durante la ejecución de las instrucciones. El acceso tanto a la RAM 1330 como a la ROM 1340 es típicamente más rápido que al almacén secundario 1350. El almacén secundario 1350 es típicamente comprendido por uno o más activadores de disco o activadores de cinta y podría ser utilizado para el almacenamiento no volátil de datos o como un dispositivo de almacenamiento de datos de desbordamiento si la RAM 1330 no es suficientemente grande para guardar todos los datos de trabajo. El almacén secundario 1350 puede ser utilizado para almacenar programas que están cargados en la RAM 1330 cuando tales programas son seleccionados para su ejecución.

Los dispositivos de I/O 1360 pueden incluir visualizadores de cristal líquido (LCDs – Liquid Crystal Displays, en inglés), visualizadores de pantalla táctil, teclados, teclados numéricos, conmutadores, marcadores, ratón, bolas de seguimiento, reconocedores de voz, lectores de tarjeta, lectores de cinta de papel, impresoras, monitores de video u otros dispositivos de introducción de datos bien conocidos. También, el transceptor 1325 podría ser considerado un componente de los dispositivos de I/O 1360 en lugar de o además de ser un componente de los dispositivos de conectividad de red 1320. Algunos o todos los dispositivos de I/O 1360 pueden ser substancialmente similares a varios componentes representados en el dibujo descrito previamente del UE 110, tal como el visualizador 402 y la entrada 404.

La siguiente Especificación Técnica (TS – Technical Specification, en inglés)) del Proyecto de Colaboración de 3ª Generación es incorporada en esta memoria como referencia: TS 24.229 V7.8.0 (2007-12).

Claims

REIVINDICACIONES

1.

Un método para que un equipo de usuario (“UE” – User Equipment, en inglés) (110) responda a un mensaje relacionada con una emergencia (150) que comprende:

recibir un mensaje de respuesta de Protocolo de Iniciación de Sesión (“SIP” – Session Initiation Protocol, en inglés) (150) que contiene un indicador (160) que indica que un mensaje de solicitud de SIP para un diálogo (140), enviado por el UE (110), es una solicitud relacionada con una emergencia; y enviar un mensaje de solicitud de SIP dentro del diálogo (170), conteniendo el mensaje de solicitud de SIP dentro del diálogo (170) información relacionada con una emergencia (180) asociada con el UE (110), donde, antes de recibir el mensaje de respuesta de SIP (150), el UE (110) no sabe que el mensaje de solicitud de SIP para un diálogo (140) es una solicitud relacionada con una emergencia.
2.

El método de la reivindicación 1, en el que cuando recibe el mensaje de respuesta de SIP (150), el método comprende también:

proporcionar una indicación al usuario de que el mensaje de solicitud de SIP para un diálogo (140) es una solicitud relacionada con una emergencia.
3.

Un equipo de usuario (“UE” – User Equipment, en inglés) (110) que comprende:

un componente configurado de tal manera que el UE (110) recibe un mensaje de respuesta de SIP (150) conteniendo un indicador (160) que indica que un mensaje de solicitud de SIP para un diálogo (140), enviado por el UE (110) es una solicitud relacionada con una emergencia, y tal que el UE (110) envía, en respuesta al mensaje de respuesta de SIP (150) una solicitud de SIP dentro del diálogo (170), conteniendo el mensaje de solicitud de SIP dentro del diálogo (170) información relacionada con una emergencia (180) asociada con el UE (110), donde el UE (110), antes de recibir el mensaje de respuesta de SIP (150) no sabe que el mensaje de solicitud de SIP para un diálogo (140) es una solicitud relacionada con una emergencia.
4.

El UE (110) de la reivindicación 3, en el que el UE (110) está configurado para, cuando recibe el mensaje de respuesta de SIP (150), proporcionar una información al usuario de que el mensaje de solicitud de SIP para un diálogo (140) es una solicitud relacionada con una emergencia.
5.

El método o el UE (110) de cualquiera de las reivindicaciones precedentes, en el que la información relacionada con una emergencia (180) asociada con el UE (110) contenida en el mensaje de solicitud de SIP dentro del diálogo

(170) comprende al menos uno de:

una identidad de UE; una ubicación de UE; o información de red de acceso del UE.
6.

El método o el UE (110) de cualquiera de las reivindicaciones precedentes, en el que el mensaje de respuesta de SIP (150) es uno de una respuesta 1xx ó 200 (OK) de SIP.
7.

El método o el UE (110) de cualquiera de las reivindicaciones precedentes, en el que el mensaje de solicitud de SIP dentro del diálogo (170) es uno de:

un ACK de SIP; un PRACK de SIP; un refrescar objetivo de SIP; un ACTUALIZAR de SIP; y una solicitud de INVITAR DE NUEVO de SIP.
8.

El método o el UE (110) de la reivindicación 5 cuando la información relacionada con una emergencia (180) comprende una identidad de UE, en el que la identidad del UE es un identificador de recurso uniforme de agente de usuario encaminable globalmente (“GRUU” – Globally Routable User agent Uniform resource identifier, en inglés).
9.

El método o el UE (110) de cualquiera de las reivindicaciones precedentes, que comprende también incluir en un campo de localización geográfica del mensaje de solicitud de SIP dentro del diálogo (170) un Identificador de Recurso Uniforme (“URI” – Uniform Resource Identifier, en inglés) que señala a la ubicación del UE.
10.

El método o el UE (110) de cualquiera de las reivindicaciones precedentes, que comprende también si la información de ubicación geográfica del UE (110) está disponible para el UE (110), incluir la información de

ubicación geográfica como un objeto de ubicación de PIDF en un cuerpo de mensaje del mensaje de solicitud de SIP dentro del diálogo (170).
11.

El método o el UE (110) de cualquiera de las reivindicaciones precedentes, que incluye también en un campo de

5 cabecera de contacto del mensaje de solicitud de SIP dentro del diálogo (170) un valor de GRUU pública asociado con una identidad pública de usuario.
12. El método o el UE (110) de cualquiera de las reivindicaciones precedentes, en el que la información de red de acceso del UE está incluida en un campo de cabecera de Info de Red de Acceso P en el mensaje de solicitud de SIP

10 dentro del diálogo (170) y comprende uno de un identificador de ubicación, un identificador de celda o una identidad de un nodo de acceso de I-WLAN.