ES2440344T3 - Sistema y método para gestionar llamadas de emergencia - Google Patents

Sistema y método para gestionar llamadas de emergencia Download PDF

Info

Publication number
ES2440344T3
ES2440344T3 ES12172479.3T ES12172479T ES2440344T3 ES 2440344 T3 ES2440344 T3 ES 2440344T3 ES 12172479 T ES12172479 T ES 12172479T ES 2440344 T3 ES2440344 T3 ES 2440344T3
Authority
ES
Spain
Prior art keywords
sip
emergency
request
request message
message
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES12172479.3T
Other languages
English (en)
Inventor
Jan Hendrick Bakker
Adrian Buckley
Andrew Allen
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
BlackBerry Ltd
Original Assignee
BlackBerry Ltd
Research in Motion Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US12/131,785 external-priority patent/US8478226B2/en
Application filed by BlackBerry Ltd, Research in Motion Ltd filed Critical BlackBerry Ltd
Application granted granted Critical
Publication of ES2440344T3 publication Critical patent/ES2440344T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/50—Connection management for emergency connections
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/42348—Location-based services which utilize the location information of a target
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H04W4/029—Location-based management or tracking services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/90—Services for handling of emergency or hazardous situations, e.g. earthquake and tsunami warning systems [ETWS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2242/00—Special services or facilities
    • H04M2242/04—Special services or facilities for emergency applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/42025—Calling or Called party identification service
    • H04M3/42034—Calling party identification service
    • H04M3/42059—Making use of the calling party identifier
    • H04M3/42068—Making use of the calling party identifier where the identifier is used to access a profile
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/006—Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/08—Upper layer protocols
    • H04W80/10—Upper layer protocols adapted for application session management, e.g. SIP [Session Initiation Protocol]

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Multimedia (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Emergency Management (AREA)
  • Environmental & Geological Engineering (AREA)
  • Public Health (AREA)
  • Health & Medical Sciences (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Alarm Systems (AREA)

Abstract

Un método para que un componente de red gestione información relativa a una emergencia, que comprende: recibir de un equipo de usuario (UE) un mensaje de Protocolo de Iniciación de Sesión (SIP) de petición de undiálogo SIP, conteniendo dicho mensaje de petición SIP un Identificador de Recurso Uniforme de Petición(URI); inspeccionar la Petición URI del mensaje de petición SIP para hallar un identificador que coincida con unidentificador del servicio de emergencia en una lista configurable almacenada por el componente de la red;si la petición URI coincide con un identificador del servicio de emergencia de la lista configurable: enviar desde el componente de la red al UE un mensaje de respuesta SIP que contiene un campo deencabezamiento Identidad-Confirmada-P con un indicador que indica que el mensaje de petición SIPde diálogo SIP, enviado por el UE, era una petición relativa a una emergencia; y recibir desde el UE, en respuesta al mensaje de respuesta SIP, un mensaje de petición SIP dentro delmismo diálogo SIP, conteniendo el mensaje de petición SIP dentro del mismo diálogo SIP informaciónrelativa a la emergencia asociada con el UE que comprende la posición del UE.

Description

Sistema y método para gestionar las llamadas de emergencia
ANTECEDENTES
El Subsistema Multimedia (IMS) IP (Protocolo de Internet) es una arquitectura normalizada para proporcionar servicios multimedia y de llamadas de voz sobre IP a usuarios tanto de equipo móvil como de equipo fijo (UE). El Protocolo de Inicio de Sesión (SIP) ha sido normalizado y dirigido principalmente por el Grupo de Trabajo de Ingeniería de Internet (IETF) como protocolo para configurar y gestionar las 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 personales digitales, ordenadores de mano o portátiles y dispositivos similares que disponen de capacidad de telecomunicación. Tal UE podría consistir en un dispositivo inalámbrico y su Tarjeta de Circuito Integrado Universal (UICC) asociada, que incluye una aplicación de Módulo de Identidad de Abonado (SIM), una aplicación de Módulo de Identidad de Abonado Universal (USIM) o un Módulo Extraíble de Identidad de Usuario (R-UIM) o podría consistir en el propio dispositivo sin una tarjeta. El término “UE” puede también referirse a dispositivos que tienen capacidades similares pero que no son transportables, tales como teléfonos de línea fija, ordenadores de sobremesa o descodificadores. El término “UE” también puede referirse a cualquier componente de hardware o software que pueda finalizar una sesión SIP.
El documento Redes Nokia Siemens y otros “Corrections emergency procedures” Borrador 3GPP; Procedimiento C1-072991_24229CR1997R2_EMC1_REL-8_, Proyecto de Asociación de Tercera Generación (3GPP), Centro de Competencia de Móviles; 650, Route Des Lucioles; F-06921 Sophia-Antipolis Cedex; Francia, vol. CT WG1, no. Sophia Antipolis, Francia; 20071112, 12 de noviembre de 2007 (2007-11-12), describe una serie de peticiones de cambio de las normas 3GPP en el momento de la presentación que están relacionadas con los servicios de emergencia IMS.
SUMARIO DE LA INVENCIÓN
Los aspectos de la presente invención se definen en las reivindicaciones 1, 19, 27 y 28.
BREVE DESCRIPCIÓN DE LOS DIBUJOS
Para mayor comprensión de esta descripción, se hace referencia a la siguiente descripción abreviada, en relación con los dibujos y la descripción detallada que se acompañan, en donde números de referencia similares representan elementos similares. La figura 1 es un diagrama de una red IP ilustrativa que incluye un UE y un PSAP de acuerdo con una realización de la descripción. La figura 2 es un diagrama de una red IP ilustrativa 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 relacionado con 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 por alguna de las diversas realizaciones de la descripción. La figura 5 es un diagrama de bloques de un equipo de usuario operable por alguna de las diversas realizaciones de la descripción. La figura 6 es un diagrama de un entorno de software que puede ser ejecutado en un equipo de usuario operable por alguna de las diversas realizaciones de la descripción. La figura 7 es un sistema de ordenador ilustrativo adecuado para algunas de las diversas realizaciones de la descripción.
DESCRIPCIÓN DETALLADA
Debe entenderse desde el principio que, aunque se proporcionan a continuación ejecuciones ilustrativas de una o más realizaciones de la presente descripción, los sistemas y/o los métodos descritos pueden ejecutarse utilizando cualquier variedad de técnicas, tanto conocidas en la actualidad como existentes. La descripción no debe en modo alguno limitarse a las ejecuciones, dibujos y técnicas ilustrativas que figuran a continuación, sino que puede modificarse dentro del alcance de las reivindicaciones subordinadas adjuntas junto con todo el alcance de las equivalentes.
En una realización, se proporciona un equipo de usuario. El equipo de usuario incluye un componente, responsable de hacer una llamada de emergencia que resulta rechazada, configurado dicho componente para recibir un mensaje que contiene información que asocia la llamada de emergencia con un centro combinado de emergencia.
En otra realización, se proporciona un componente de red que incluye un componente, tal que tras recibir una llamada de emergencia de un equipo de usuario, configurado dicho componente para determinar si la llamada de
emergencia está relacionada con un centro combinado de emergencias y para enviar al equipo de usuario un mensaje que contiene información que identifica que la llamada de emergencia está relacionada con un centro combinado de emergencias.
Un usuario de un UE, por ejemplo un UE con capacidad IMS, puede hacer normalmente una llamada de emergencia marcando el 911 (en Norte América), el 112 (en la mayor parte de Europa), 999 (en el Reino Unido), 110, 118 o 119 (en Japón), o algún otro número específico de emergencia. Dicha llamada puede ser gestionada por un Punto de Respuesta de Seguridad Pública (PSAP), que podría ser un centro o sistema de llamadas de emergencia que puede coordinar una respuesta apropiada a la emergencia. En esta memoria nos referiremos a cualquier llamada hecha a un PSAP como una llamada de emergencia. En este documento, un PSAP podría ser también un centro o centros de emergencias.
En algunos casos, un UE podría no saber que una llamada realizada, fuera una llamada de emergencia. Por ejemplo, un UE fabricado para ser utilizado en Norte América podría estar programado para reconocer una llamada al 911 como una llamada de emergencia. Si tal UE se lleva a un país donde se utiliza un número diferente del 911 para las llamadas de emergencia, y el usuario del UE marca ese otro número de emergencia, el UE podría no reconocer la llamada como una llamada de emergencia. Pueden darse resultados no deseados si el UE no reconoce que la llamada es una llamada de emergencia. Por ejemplo, el UE podría fallar al proporcionar información importante al PSAP, el UE podría tratar la llamada como una llamada normal y retenerla o colocarla en espera, la llamada podría ser bloqueada, o el UE podría de otro modo no tratar la llamada de la forma adecuada. Además, la red puede no aplicar un tratamiento especial, por ejemplo, en una red o célula congestionada, y la llamada de emergencia no reconocida puede no ser sometida a los procedimientos para las llamadas de emergencia (por ejemplo, puede no obtener prioridad).
La presente descripción proporciona una indicación a un UE de que una llamada realizada por el UE era una llamada de emergencia IMS, al incluir en un mensaje al UE un indicador de que la llamada era una llamada de emergencia. El indicador podría estar incluido en un mensaje SIP que puede ser, pero no limitado a, un mensaje SIP 2xx o SIP 1xx enviado al UE en respuesta a una petición inicial SIP para un diálogo u operación autónoma, o un método desconocido (por ejemplo, una petición SIP INVITE), o un mensaje similar, que el UE envía al intentar establecer la llamada de emergencia. En lo sucesivo, el término “mensaje SIP” puede hacer referencia a una petición SIP (incluyendo, por ejemplo, una petición de re-INVITE o una petición de refresco de Objetivo de diálogo o una petición inicial SIP de diálogo u operación autónoma, o un método desconocido) o una respuesta SIP. Debe tenerse en cuenta que la petición de método re-INVITE sólo se puede enviar cuando se cumplen las condiciones documentadas en la Petición de Comentarios (RFC) 3261 del Grupo de Trabajo de Ingeniería de Internet (IETF). El mensaje 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í. P-CSCF y E-CSCF son ejemplos de tales componentes.
El indicador relacionado con la emergencia puede estar codificado en SIP utilizando las siguientes alternativas: a) se han utilizado cuerpos de textos SIP tales como “aplicación/3gpp-ims+xml” en IMS para indicar información adicional
o directivas al recibir UAs. Puede ampliarse también para indicar al UE que, tras recibir un INVITE o petición similar, la petición debe tomarse como una llamada de emergencia o devolución de llamada PSAP y que debe invocarse la funcionalidad asociada con llamadas de tal tipo. Esta funcionalidad puede incluir, sin limitación, la alerta al usuario mediante métodos visuales, audibles o de otro tipo, así como información de posición en la respuesta. Puede ser necesario definir un nuevo valor del campo del encabezamiento contenido-disposición. b) Podría definirse un nuevo encabezamiento SIP o podría mejorarse un encabezamiento SIP ya existente. El mismo PSAP o el S-CSCF que gestiona la devolución de llamada PSAP en nombre del PSAP u otro elemento de la red, como por ejemplo una pasarela de señalización, pueden introducir un indicador. c) El indicador podría ser un nuevo campo de encabezamiento SIP. d) El indicador podría ser un nuevo valor del campo del encabezamiento SIP, por ejemplo, un SIP URN que indique la función PSAP (por ejemplo, rescate de montaña o guardacostas o 911 en general) o una función del centro de emergencias o una función del personal de emergencias. e) El indicador podría ser un nuevo campo URI. f) El indicador podría ser un nuevo valor de campo URI, por ejemplo, usuario = psap, donde ‘usuario’ es un campo SIP URI y ‘psap’ es el nuevo valor que podría colocarse en el campo de encabezamiento del Contacto. g) El SIP URN normalizado podría colocarse en el P-Identidad-Establecida por el dominio de confianza en el que reside el PSAP o el centro de emergencias o el personal de emergencias. h) El indicador podría estar contenido en el valor del campo del encabezamiento FROM y el valor del campo del encabezamiento FROM puede ser establecido de acuerdo con RFC 4474 o RFC 3893. Esta solución se basa en certificados.
Como se ha identificado anteriormente, se pueden utilizar diferentes posibilidades para indicar que una sesión es en realidad una sesión de emergencia. Se ha subrayado que el PSAP podría estar en una red visitada, como por ejemplo una red VPLMN y que no tiene relación fiable con la red doméstica, tal como una HPLMN (Red Móvil Terrestre Pública Doméstica). Suponiendo éste caso, en el que el UE está estableciendo una sesión de emergencia, que el UE no reconoce o en el que al recibir una petición finalizada móvil, que contiene una indicación en el mensaje SIP (por ejemplo, respuestas 1xx o 2xx o una petición de refresco del objetivo SIP o un mensaje similar), que la petición es una devolución de llamada PSAP, el PSAP o la red podría también devolver una marca que el UE almacenaría. La red podría proporcionar esta marca cuando el UE se registra con el subsistema de red de núcleo
(CN) IM. La marca podría almacenarse en la memoria, que podría ser interna o extraíble. En el caso de que la llamada de emergencia del UE se desconectara o que el UE necesitara que se le informe de que está solicitando una sesión de emergencia, la red o el PSAP podrían incluir esta marca. Tras recibir la marca de la red, el UE puede compararlo con la marca compartida. Si las marcas no coinciden, el UE sabe que la llamada no es de emergencia.
El campo de encabezamiento ‘prioritario’ SIP establecido en “emergencia” aún no se ha utilizado como indicador fiable para las llamadas de emergencia (RFC 3261). La base instalada de las SIP UAs tendrá un tratamiento diferente y divergente para este encabezamiento, en el caso de que exista tal tratamiento. En el caso de que se reciba la devolución de llamada del PSAP o la respuesta de señalización de llamada de emergencia en una red de Conmutada de Circuitos, la solución puede tener en cuenta mapear entre los campos adecuados de Llamada-Grupo-Categoría que se utiliza a veces para acarrear la indicación de una llamada de emergencia en sistemas basados en ISUP/TUP (Parte de Usuario ISDN/Parte de Usuario de Teléfono). Habitualmente, la información de señalización ISUP/TUP no tiene en cuenta una meticulosidad tan delicada como los identificadores de emergencia urn:service:sos definidos en RFC 5031.
La figura 1 ilustra un sistema 10 que incluye uno o más componentes asociados con una red IMS 120. Un UE 110 puede ser cualquier dispositivo de usuario final o sistema que se pueda conectar a la red IMS 120. Algunos ejemplos de UE 110 pueden incluir, sin limitación, teléfonos móviles, teléfonos de línea fija, dispositivos móviles inalámbricos (incluyendo dispositivos digitales, celulares o de modo dual), asistentes personales digitales, ordenadores portátiles/tableta/de bolsillo y ordenadores de sobremesa. El UE 110 puede comunicarse a través de la red IMS 120 con un PSAP 130, que puede ser un sistema 911 u otro centro o sistema de llamadas de emergencia.
La red IMS 120 podría incluir cualquier conjunto de componentes bien conocidos, tales como estaciones base y otro equipamiento de transmisión y recepción de radio, que pudiera favorecer una conexión basada en IMS entre el UE 110 y el PSAP 130. Otros componentes que podrían estar presentes en la red IMS 120, pero que no se muestran, incluyen un P-CSCF (Función de Control de Sesión de Llamada Proxy), que puede ser el primer punto de contacto para el UE 110; un S-CSCF (CSCF Servidor), que puede realizar el control de la sesión, la descarga y la subida de perfiles de usuario y otras funciones; un E-CSCF (CSCF de Emergencia) que puede proporcionar funciones de control de sesión para el PSAP 130; y otros componentes bien conocidos para iniciar y mantener las sesiones basadas en IMS.
Para hacer una llamada de emergencia, el UE 110 podría enviar una petición inicial SIP de diálogo u operación autónoma o un método desconocido 140 (por ejemplo, una petición SIP INVITE) o un mensaje de invitación similar, al PSAP 130 a través de la red IMS 120. El PSAP 130 normalmente responde al mensaje de invitación 140 con un mensaje de respuesta 150 SIP 1xx o SIP 2xx (por ejemplo, SIP 200 OK), o un mensaje de respuesta similar. Alternativamente, el PSAP 130 podría transmitir una petición de refresco de objetivo (por ejemplo, petición re-INVITE). Se podrían entonces seguir los procedimientos 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 realizada por el UE 110 era una llamada de emergencia. El indicador 160 puede ser un bit, un indicador o cualquier otro elemento de datos que fuera reconocible por el UE como indicación de que una llamada realizada por el UE 110 era una llamada de emergencia (por ejemplo, servicios de emergencia URNs como los especificados en RFC 5031, tales como urn:service:sos, urn:service:sos.animal-control o urn:service:sos.police, si se determina que la llamada efectuada pudiera ser considerada como, por ejemplo, una llamada urn:service:sos, una llamada urn:service:sos.animalcontrol o una llamada urn:service:sos.police). Cuando el UE 110 recibe el mensaje de respuesta 150 que incluye el indicador 160, el UE 110 identifica que la llamada realizada era una llamada de emergencia IMS y puede entonces adoptar las medidas apropiadas e invocar la funcionalidad de una llamada de emergencia. Una medida que el UE 110 podría adoptar sería indicar al usuario del UE la naturaleza de la llamada original. Es decir, el UE 110 podría alertar al usuario de que la llamada era una llamada de emergencia. La alerta podría ser un mensaje que aparezca en la pantalla del UE 110, una alerta visual o audible, u otro tipo de condición o indicación ambiental sobre la naturaleza de la llamada. Otras medidas adoptadas por el UE 110 pueden implicar transmitir un mensaje 170 de petición SIP, tal como un mensaje SIP ACK o SIP PRACK o cualquier otra parte sucesiva de petición SIP de diálogo (incluyendo peticiones de refresco de objetivo), o petición de nuevo diálogo, en el que la petición de diálogo utiliza el campo de encabezamiento Objetivo-Diálogo SIP con un valor establecido idéntico al valor de identificación de diálogo correspondiente a la sesión de emergencia. En el caso de enviar una petición de nuevo mensaje 170 de diálogo con campo de encabezamiento Objetivo-Diálogo SIP establecido, puede indicar al destinatario que el emisor sabe que existe un diálogo con el destinatario, bien porque el emisor está al otro lado del diálogo, bien porque tiene acceso a los identificadores de diálogo y el destinatario puede entonces autorizar la petición en función de este conocimiento. Sometido a las limitaciones de SIP, cualquiera de estos mensajes puede incluir información en la petición, como parte de la información disponible para el PSAP 130 si el destinatario es el PSAP 130. Como se ha mencionado, el mensaje 170 podría ser una petición de refresco objetivo SIP, un SIP UPDATE, un mensaje 170 SIP re-INVITE o un mensaje similar (de reconocimiento) (por ejemplo, SIP PRACK). El mensaje 170 puede incluir información 180 sobre el UE 110, que se describirá con detalle posteriormente. Debido a limitaciones en el protocolo
SIP, se puede difundir la información 180 sobre varios mensajes SIP, por ejemplo, parte de la información puede estar en las peticiones SIP PRACK, otra parte en respuestas a peticiones PSAP u originadas en la red o peticiones SIP UPDATE, y otra parte en otras peticiones de refresco objetivo SIP. La información 180 podría opcionalmente incluir una señal u otro indicador que indique que cierta información relativa a la emergencia, como la identificación, el acceso a la red y la información sobre la posición, no se va a compartir (por ejemplo, con el PSAP 130). Si se fijan uno o más indicadores de privacidad, la red aún podría ser capaz de utilizar la información relativa a la emergencia con propósitos de encaminamiento o para proporcionar una devolución de llamada anónima.
En otra realización, podría almacenarse una regla en el UE 110. La regla, o reglas, podrían utilizarse para determinar si incluir uno o más indicadores a la petición de privacidad cuando se permite la petición de sesiones de emergencia o si se proporciona información relativa a la emergencia cuando un PSAP realiza una devolución de llamada o si se permite solicitar privacidad cuando se proporciona información relativa a la emergencia en respuesta a una devolución de llamada PSAP. La regla podría entonces consultarse cuando el UE 110 quiere divulgar información que es sensible a la privacidad, tal como, pero no limitada, a la posición. La regla podría ser proporcionada por el usuario, 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 regla por defecto, pero el usuario podría ser capaz de saltarse esta regla si así lo desea. La regla se puede almacenar en una memoria interna o externa al dispositivo.
Es posible que la regla/preferencia pudiera ser establecida de forma contraria a los requisitos reguladores de PSAP. Por ejemplo, el UE 110 podría proceder de un país donde puede elegir suministrar, o no, información relativa al usuario o relativa al evento, y la regla/preferencia puede fijarse de tal forma que no se proporcione la información. Alternativamente, la regla/preferencia pueden establecerse de tal forma que se pueda proporcionar la información (por ejemplo, a efectos de determinar el PSAP más cercano), pero se podría realizar una petición para que no se divulgue la información. El UE 110 puede posteriormente ir a un país en el que la ley exige que se deba proporcionar información sobre la posición si está disponible. En tales casos, la red podría indicar al UE 110 que se salte la regla/preferencia y que debe suministrar la información. Esta notificación de salto podría señalizarse como una señal en un mensaje de la red. Por ejemplo, un mensaje SIP podría contener una señal que se codifica como una nueva etiqueta de característica, un nuevo parámetro URI, un cuerpo de texto XML, un parámetro SDP o una característica similar de codificación. La señal podría también requerir la propiedad de ser de confianza del UE 110.
A continuación se ilustra una posible realización de cómo puede ser el comportamiento del UE 110.
El procedimiento básico será
Fijar Regla/Preferencia
Mensaje recibido de la red que contiene la marca de salto
Consultar preferencia/regla
Permitir proporcionar información sobre la posición
No se permite determinar si se ha recibido la marca
Marca recibida, determinar la autenticidad de la marca y si es válida,
proporcionar
información sobre la posición
Marca recibida, falsa, proporcionar indicación a la red de que la marca recibida es falsa,
no proporcionar información sobre la posición.
La marca puede ser acarreada en una devolución de llamada del PSAP 130, por ejemplo como un SIP INVITE. Alternativamente, podría suministrarse la marca en el momento en el que el UE 110 se registra con la red 120, de forma que en IMS la marca pudiera proporcionarse en un mensaje SIP 200OK, en respuesta a un registro de una emergencia. Dentro del 200OK, si la marca viene codificada como una nueva etiqueta característica, o un nuevo parámetro URI o un cuerpo de texto XML, la marca podría ser una marca segura. En una red LTE/SAE, el mensaje 200OK podría ser transmitido en respuesta a una petición para unirse a la red o como parte de la secuencia de autenticación del UE 110.
Otra realización es que la regla VPLMN se podría transmitir en un mensaje del sistema que marque el comportamiento del UE en el caso de que se recibiera una devolución de llamada de emergencia.
El suministro de la regla se puede realizar en, pero no limitado a, una de las siguientes formas: OMA DM, CP, OTA, propietario u otra. Para el suministro, se podría utilizar cualquiera de las siguientes formas de transporte: Transmisión por Célula, SMS, USSD, MBMS, encauzamiento IP Genérico u otras.
La regla podría almacenarse en una memoria interna o externa. La memoria externa puede ser, aunque no se limita a, Tarjeta PC PCMCIA, Flash Compacta I CF-I, Flash Compacta II CF-II, Medios Inteligentes SM/SMC, Barra de Memoria MS, Barra de Memoria Doble MSD, Barra de Memoria PRO Doble MSPD, Barra de Memoria PRO
-
HG Doble MSPDX, Micro Barra de Memoria M2, Tarjeta Multimedia MMC, Tarjeta Multimedia RS-MMC, Tarjeta MMCmicro MMCmicro, Tarjeta Digital Segura SD, SxS SxS, Almacenamiento Flash Universal UFS,Tarjeta miniSD miniSD, Tarjeta microSD microSD, xD-Tarjeta de fotos-xD xD, Barra Inteligente iStick, Módulo Flash Serie SFM, µ tarjeta µtarjeta, Tarjeta NT NT NT+, USIM, R-UIM, etc.
En una realización de la información de la regla, habría un archivo en la memoria extraíble consistente en ocho bits por cada archivo. El Bit 1 (el Bit Menos Significativo) podría fijarse a 1 para indicar que se debe suministrar esa información acerca de la posición o fijarse a 0 para indicar que no se debe suministrar esa información acerca de la posición. Los restantes 7 bits podrían estar reservados (RFU). El archivo de preferencias de usuario podría estar bajo control PIN (es decir, el usuario podría, tras introducir el PIN, controlar el contenido del archivo), y el archivo del operador podría estar bajo control ADM (Administrativo), impidiendo que cualquiera de los grupos diferentes del administrador (el emisor de la tarjeta, normalmente el portador), altere los contenidos del archivo.
En varias realizaciones, la regla puede ejecutarse según diferentes formatos. A continuación se ofrece un ejemplo de formato de la regla, pero los formatos no deben estar limitados por este ejemplo, ya que se contemplan otros formatos. /<X</ regla de Situación de Emergencia tras devolución de llamada PSAP/ La guía sobre regla de Situación de Emergencia indica si el UE proporciona información de emergencia, o no, para devolución de llamadas de emergencia.
•
Suceso: Uno
•
Formato: bool
•
Tipos de Acceso: Get, Replace
•
Valores: 0,1 0 – UE proporciona información de emergencia 1 – UE no proporciona información de emergencia <Node>
<NodeName> Emergency Location policy </NodeName>
<DFProperties>
<AccessType>
<Get/>
<Replace/>
</AccessType>
<DFFormat>
<bool/>
</DFFormat>
<Occurrence>
<One/>
</Occurrence>
<DFTitle> Emergency Location policy </DFTitle>
<DFType>
<MIME>text/plain</MIME> </DFType> </DFProperties> </Node
Como se ha mencionado anteriormente, 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 regla lo permite, una parte de la información 180 que el UE 110 podría incluir en el mensaje 170 SIP es la identidad pública del usuario del UE (por ejemplo, Tel URI, SIP URI o el Número ISDN Internacional de la Estación Móvil (MSISDN)) o algún otro símbolo identificativo. La inclusión de tal información podría estar sujeta a la regla o podría estar acompañada de un indicador de que la información privada no se tiene que compartir con el PSAP ni con el centro de emergencia ni con elementos de la red no fiables. La identidad pública del usuario podría estar en formato GRU o podría contener suficiente información como para realizar una devolución de llamada con tecnología de Conmutación de Circuitos, por ejemplo en formato Tel URI. El PSAP 130 puede utilizar el identificador para realizar una devolución de llamada al UE 110 si fuera necesario, como se describe posteriormente. Otra parte de la información 180 que el UE 110 podría transmitir en el mensaje de reconocimiento 170 es el tipo de acceso que está usando el UE 110. Por ejemplo, si la llamada de emergencia se está haciendo sobre una red de área local inalámbrica (LAN), el UE 110 podría incluir este hecho en la información 180, además de un ID de célula, un ID de línea, y/o un ID de nodo de acceso LAN inalámbrico. Durante el diálogo, los puntos de unión a la Red de Acceso con Conectividad IP (IP-CAN) del UE pueden cambiar (por ejemplo, UE se conecta a diferentes células). El UE puede entonces cubrir el encabezamiento Info-Red-Acceso-P en cualquier petición o respuesta dentro de un diálogo soportado para la transmisión de dicha información (por ejemplo, excluyendo peticiones ACK y peticiones y respuestas CANCEL), con el punto de unión actual al IP-CAN (por ejemplo, la información de la célula actual).
Si el UE 110 conoce su posición geográfica, por ejemplo, mediante el uso de un sistema de posicionamiento global (GPS), el UE 110 puede incluir su posición como otra parte de la información 180, tal como, pero no limitada a, la Identidad Global de la Célula (CGI), el Identificador del Conjunto de Servicios (SSID), puntos de referencia tales como mojones, y la potencia de la señal de las células adyacentes con las CGIs correspondientes. Si el UE 110 no conoce su posición geográfica, los datos relativos a la posición no se incluyen en la información 180. Si un GRUU (UA encaminable globalmente (agente usuario) URI (identificador de recursos uniformes)) se asocia con el UE 110, el GRUU del UE puede ser incluido como otra parte de la información 180. Dependiendo de la configuración de privacidad del usuario, el GRUU puede ser un P-GRUU o un T-GRUU, aunque un GRUU público (P-GRUU) es preferible a un GRUU temporal (T-GRUU). Otros elementos que podrían incluirse en la información 180 podrían ser las capacidades del UE 100, la tecnología de acceso radioeléctrico que utiliza el UE 110, la duración de la batería del UE 110, la intensidad de la señal, y la identidad de la red (por ejemplo, CGI, SSID, SID). El UE 110 podría también invocar que se envíe al PSAP 130 lo que se conoce comúnmente como funcionalidad eCall.
Antes de que la petición de emergencia alcance el PSAP 130, podría ser gestionada por uno o más componentes de la red IMS 120. Ejemplos de dichos componentes son P-CSCF, E-CSCF, AS e IBCF (Función de Control de Límite de Interconexión). Un componente de red IMS, como P-CSCF, AS y E-CSCF, puede inspeccionar todas las peticiones con objeto de determinar si están relacionadas con emergencias. Si se determina que una petición está relacionada con una emergencia, basándose en configuraciones y reglas reguladoras, el componente de red puede determinar que se rechace la petición, que se actualice la petición o que se incluya el indicador de llamada de urgencia 160 en una respuesta SIP que se envía al UE 110. La actualización de la petición podría hacerse si el UE proporciona un T-GRUU y si los ajustes de la regla del operador de la red (por ejemplo, en el P-CSCF) indican que se deben proporcionar las identidades del usuario público. En tal caso, el T-GRUU puede ser reemplazado por el GRUU. Además, la actualización de los mensajes a encaminar a los PSAPs podría hacerse si el mensaje contiene campos de encabezamiento Servicio-Preferido-P, campos de encabezamiento Servicio-Impuesto-P, campos de encabezamiento Aceptar-Contactar que contienen uno o más valores Identificadores de Servicio de Comunicación IMS (ICSI) (codificados tal como se especifica en la sub-cláusula 7.2A.8.2 en 3GPP TS 24.229) o uno o más valores de Identificador de Referencia de la Aplicación IMS (IARI) (codificados como se especifica en la sub-cláusula 7.2A.9.2 en 3GPP TS 24.229) que se relacionan con la petición en una etiqueta de características g.3.gpp.app_ref. Obsérvese que el elemento de red puede estar en un Agente de Usuario en Ambos Extremos (B2BUA) o en un modelo proxy al actualizar estas peticiones o respuestas SIP. Obsérvese que si el elemento de la red es un AS, existe una necesidad de un nuevo punto de referencia entre el AS y al menos uno de IBCF, E-CSCF o P-CSCF ya que en este momento sólo hay un punto de referencia de control del servicio entre AS y S-SCSF o I-CSF. Los campos de encabezamiento Servicio-Preferido-P y los campos de encabezamiento Servicio-Impuesto-P no deben ser enviados al PSAP o centro de emergencias. Los campos de encabezamiento Aceptar-Contactar deben ser maquillados para los valores ICSI y para los valores IARI ya que pueden provocar interacciones al seleccionar a un agente de usuario SIP terminando la sesión en el PSAP. Si el campo de encabezamiento Aceptar-Contactar contiene etiquetas de características de medios g.3gpp.app_ref, estas y sus valores tienen que ser eliminados. Si el campo de encabezamiento Aceptar-Contactar contiene etiquetas IARII de características de medios g.3gpp.app_ref, estas y sus valores tienen que ser eliminadas.
En otras palabras, lo que se denomina “actualización” puede incluir el cambiar el GRUU de un GRUU temporal a un GRUU público. Esto se hace porque un GRUU temporal es inválido si el UE se desconecta y tiene que volver a registrarse. Un PSAP no puede realizar una devolución de llamada a un GRUU temporal después de que el UE se des registre y se vuelva a registrar de nuevo. Los GRUU públicos, por otro lado, tienen la propiedad de ser encaminables incluso después de que el UE se des registre y se registre de nuevo (haciendo una devolución de llamada PSAP al GRUU público con más posibilidades de completar). La “actualización” también puede incluir la no propagación de las etiquetas de características ICSI o IARI, los campos de encabezamiento Servicio-Preferido-P, y/o los campos de encabezamiento Servicio-Impuesto-P. La presencia de dichas etiquetas o campos podría distorsionar la gestión de la petición en el PSAP y hacer que la petición se encamine basándose en los servicios soportados en el UE en lugar de, por ejemplo, en la proximidad geográfica y el tipo de servicio solicitado. Ya que normalmente no hay un S-SCSF ni un Servidor de Aplicación (Telefonía Multimedia) en el trayecto de la sesión entre el UE, el P-CSCF, el E-CSCF y el PSAP, estos servicios que soporta el UE no están normalmente disponibles durante la llamada de emergencia. Así que señalizarlo como parte de la petición de emergencia (incluso cuando el UE no lo hizo, es una petición de emergencia e incluye etiquetas de características ICSI o IARI, campos de encabezamiento Servicio-Preferido-P, y/o campos de encabezamiento Servicio-Impuesto-P porque cree que la petición que hace es una petición normal) no sirve a ningún propósito y puede sólo valer para perjudicar/acabar en encaminar las peticiones a otros PSAP o Agentes de Usuario de PSAP, diferentes de aquellos determinados en función de su situación, tipo de servicio solicitado, y procedimientos RFC 3261. En el peor de los escenarios, si un Agente de Usuario PSAP registra su soporte para dichos servicios, puede que reciba una mayor carga de peticiones de servicios de emergencia que otros Agentes de Usuario PSAP, lo que posiblemente conduzca a un retraso en la respuesta de emergencia.
En las realizaciones en que un componente en la red IMS 120 rechaza la petición del servicio de emergencia, puede responder con un mensaje SIP 3xx, tal como un mensaje 300 (Elecciones Múltiples), 301 (Trasladado
Permanentemente), 302 (Trasladado Temporalmente), 380 (Servicio Alternativo), o una respuesta SIP 4xx o una respuesta SIP 6xx. Se utiliza preferiblemente un SIP 380 (Servicio Alternativo) para indicar que el UE debe 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 podría también utilizarse para informar al UE de no usar el contexto actual (que se podría haber creado como resultado de un registro de emergencia).
Los siguientes son casos en los que la red puede ser configurada para rechazar la petición: a) la red no es capaz de gestionar las sesiones de emergencia; b) el sub-sistema IM CN al que pertenece P-CSCF no es capaz de gestionar las sesiones de emergencia; c) debido a reglas locales, la red no gestiona sesiones de emergencia; d) la red sólo gestiona ciertos tipos de sesiones de emergencia; e) el UE se encuentra en tránsito; f) el P-CSCF está en una red diferente que la red del operador doméstico del UE; g) la red no soporta sesiones de emergencia tanto para la posición geográfica en la que se encuentra el UE o para el IP-CAN al que está conectado el UE.
Debe observarse que una respuesta de re-dirección 3xx puede ser solo válida o encaminable en la red conectada en ese momento. Por ejemplo urn:service:sos.animal-control puede ser válido en la agenda sólo para algunas redes a las que el UE 110 se puede conectar/registrar. El uso de una dirección de la agenda puede estar condicionado al operador o a la región a la que el UE 110 está conectado/registrado. Una respuesta 3xx que insta al UE a que use otra dirección para esta petición relacionada con una emergencia o una petición determinada que no está relacionada con una emergencia no debería seguirse simplemente cambiando la correspondiente entrada en la agenda, si está, en la agenda.
Dos ejemplos pueden ilustrar aquellos casos en que la red rechaza la petición porque el tipo de petición de la sesión de emergencia no está soportado. En el primer ejemplo, RFC 5031 define urn:service:sos.animal-control de la siguiente manera: el control de animales normalmente asegura el cumplimiento de leyes y ordenanzas relacionadas con el control y gestión de los animales, investiga casos de abusos a animales, educa a la comunidad en lo referente a tenencia responsable de animales y protección de la fauna salvaje y proporciona alojamiento y cuidados a animales callejeros, entre otros servicios relacionados con los animales. En algunas jurisdicciones, una petición urn:service:sos.animal-control puede no estar clasificada como emergencia en el sentido de estar sujeta a procedimientos de emergencia de la red y del operador (por ejemplo, permitir o no una petición urn:service:sos.animal-control cuando el UE no ha sido registrado o no tiene suficientes credenciales). Si está configurado de tal modo, la red podría o bien rechazar la llamada con una indicación de que no es en realidad una llamada de emergencia o podría rechazarla con una indicación de que la llamada no es una emergencia y ofrecer etapas alternativas para ejecutarla tal como por ejemplo ofrecer un URI diferente al que contactar y/o una dirección diferente de red Conmutada de Circuitos (CS), tal como una cadena de dígitos. Debe observarse que, ya que los URNs del servicio de emergencia no son encaminables y no son números E.164, el UE puede no ser capaz de proceder al faltarle conocimiento sobre direcciones o números encaminables. En esas jurisdicciones, no sería apropiado que el UE ejecutara procedimientos de emergencia (como los especificados en 3GPP TS 24.008) y un UE no debe contactar automáticamente, por ejemplo, “911” o “112” tras recibir un rechazo al contactar, por ejemplo, urn:service:sos.animal-control.
Obsérvese que es posible que un UE habilitado CS haya recibido una lista de números de emergencia locales CS (por ejemplo, que haya recibido un resultado del procedimiento de Actualización-Localización). Un UE podría indicar el tipo de servicio de emergencia solicitado en una petición de emergencia CS y ser conectado al PSAP solicitado, utilizando procedimientos en 3GPP TS 24.008. Por ejemplo, existe la siguiente tabla:
Tabla 10.5.135d/3GPP TS 24.008: Elemento de Información de Categoría de Servicios
Valor de Categoría del Servicio de Emergencia (octeto 3) El significado del Valor de Categoría de Emergencia se deriva de los siguientes ajustes (por favor, véase 3GPP TS 22.101 cláusula 8): Bi1 1 Policía Bit 2 Ambulancia Bit 3 Bomberos Bit 4 Guardacostas Bit 5 Rescate de Montaña Bits 6,7,8 están libres y fijados a “0”
La estación móvil puede fijar uno o más bits a “1” Si se fija más de un bit a “1”, es necesario encaminarse a un centro de Emergencia combinado (por ejemplo, ambulancia y bomberos en Japón). Si el MSC no puede hacer coincidir la categoría del servicio recibido con cualquiera de los centros de emergencia, encaminará la llamada a un centro de emergencia por defecto definido por el operador.
Si no se fija ningún bit a “1”, el MSC encaminará la llamada de Emergencia a un centro de emergencia por defecto definido por el operador.
Sin embargo, en el momento actual no existe mapeo para urn:service:sos.animal-control. Puede realizarse un mapeo para algunos otros servicios de emergencia, como los definidos en RFC 5031 (por ejemplo, urn:service:sos.police), fijando el bit correspondiente en Valor de Categoría de la Emergencia (por ejemplo, urn:service:sos.police mapea el Bit 1 del Valor de Categoría del Servicio de Emergencia, urn:service:sos.ambulance mapea el Bit 2 del Valor de Categoría del Servicio de Emergencia, urn:service:sos.fire mapea el Bit 3 del Valor de Categoría del Servicio de Emergencia, urn:service:sos.marine mapea el Bit 4 del Valor de Categoría del Servicio de Emergencia, urn:service:sos.mountain mapea el Bit 5 del Valor de Categoría del Servicio de Emergencia). Urn:service:sos.animal-control, urn:service:sos.physician, urn:servicio:sos.poison, urn:servicio:sos.gas y otros podrían mapear un Valor de Categoría del Servicio de Emergencia sin bits fijados a “1”, haciendo que la llamada se encamine a un centro de emergencia por defecto definido por el operador. Alternativamente, para peticiones para las cuales ningún PSAP está soportado en la red, el UE podría ser instruido para hacer una petición SIP normal (utilizando los procedimientos definidos en 3GPP TS 24.228) o establecer una llamada CS normal (utilizando los procedimientos definidos en 3GPP TS 24.008). La red podría realizarlo, no indicando una dirección alternativa que no pueda ser mapeada a un Valor de Categoría del Servicio de Emergencia (es decir, ninguno de los URNs urn:service:sos para los cuales existe un mapeo normalizado). Cuando el PSAP recibe una petición de emergencia pero el PSAP no puede gestionar la petición y devuelve un SIP 380 o un mensaje similar, si existe un mapeo en el UE desde el URN determinado a un Valor de Categoría del Servicio de Emergencia, se establecerá una llamada a ese número CS PSAP E.164 automáticamente.
En el segundo ejemplo: el P-CSCF puede determinar que la petición de emergencia se hace a urn:service:sos.police. Sin embargo, por ejemplo en Holanda, el contactar con la policía no garantiza por definición que se activen los procedimientos de emergencia. En cambio, se configura un número especial, diferente de “112“: 0900-8844. Otros ejemplos son “19” Policía (Albania), “100” (Policía y Bomberos (Ciudades griegas)), “100” (Ambulancia y Bomberos (Bélgica)), “112” (Policía y Ambulancias (Italia)), “112” (Llamada general de emergencia, todas las categorías (Suecia)); “115” (Bomberos (Italia)), “144” (Ambulancias (Austria)), “*377” (Agencia de Policía Local u oficina del Departamento de Seguridad Pública, asistencia en carretera no de emergencia en Tejas). Tal número puede ser un servicio especial. Esto podría no ser adecuado si el UE contactado, por ejemplo, el “911” o el “112” si la red rechaza la llamada a urn:service:sos.police, y podría no ser adecuado si la red contactada automáticamente, por ejemplo, el 0900-8844 como una llamada normal y que el usuario, sin realizarla, pueda entonces automáticamente recibir cargos especiales. El P-CSCF podría ofrecer salidas alternativas, tales como por proporcionar una cadena de dígitos, por ejemplo, 0900-8844, en una respuesta SIP 3xx. Sin embargo, la cadena de dígitos puede formar parte de un mensaje que indique que debe mostrarse la cadena de dígitos y/o que debe mostrarse un mensaje de texto para indicar la naturaleza de la llamada que se ha realizado y la naturaleza del número proporcionado.
En una realización, el P-CSCF tiene listas configurables con identificadores de servicios de emergencia de afiliados locales y en tránsito que indican la gestión en función del identificador del servicio de emergencia. Cuando se rechaza la petición, se puede incluir en la respuesta una lista configurable de URLs del servicio alternativo de emergencias, por ejemplo señalizada como parte del campo de encabezamiento Contacto SIP. Estos servicios de emergencia alternativos pueden ser representados con información alfanumérica que puede ser mostrada, por ejemplo, cuando sea señalizada como parte del campo de encabezamiento Contacto SIP. Los servicios de emergencia alternativos pueden ser también identificados, utilizando un cuerpo de texto XML con elementos XML y atributos XML, que se muestran sólo si es necesario.
En algunos casos, la red podría rechazar una petición hecha a un centro normal de emergencias o quizás a un PSAP combinado o a un centro combinado de emergencias, donde un PSAP combinado o un centro combinado de emergencias es un PSAP que acepta llamadas de múltiples tipos de emergencias. Por ejemplo, un PSAP combinado o un centro combinado de emergencias podrían aceptar llamadas de emergencias policiales, emergencias de bomberos, emergencias de ambulancias, y otros tipos de emergencias. Una petición hecha a un centro combinado de emergencias podría incluir bits, marcas u otros indicadores (tales como una dirección PSAP (por ejemplo, “119” en algunos países) o parte de una dirección PSAP) que especifica las entidades de respuesta de emergencia a las que debe encaminarse la petición. Por ejemplo, si se hace una petición de servicio de bomberos y de servicio de ambulancia, la petición podría incluir una marca de “incendio” y una marca de “ambulancia”. Al leer estas etiquetas, el centro de emergencias combinado puede encaminar la petición a las entidades de respuesta de emergencia apropiadas.
En una realización, un UE podría enviar una petición a un centro de emergencias o quizás a un centro combinado de emergencias y el UE no saber que la petición se refiere a un centro de emergencias y que por varias razones, la red rechaza o de otro modo no procesa la petición. En este caso, la red podría identificar la petición como relacionada con un centro combinado de emergencias. La red entonces envía un mensaje al UE que contiene información que identifica que la petición se refiere a un centro combinado de emergencias. El UE podría entonces utilizar esta información para enviar la petición a un centro combinado de emergencias o a un PSAP combinado o a otro centro alternativo de emergencias o PSAP. En algunas realizaciones, el PSAP alternativo se encuentra en el dominio
conmutado de circuitos. La información en el mensaje que la red envía al UE puede incluir información que identifica el centro combinado de emergencias, bits, marcas u otros indicadores que especifican las entidades de respuesta de emergencia a las cuales se encaminó la petición inicial. Al recibir este mensaje, el UE puede entonces enviar una petición alternativa al PSAP alternativo o combinado y puede incluir los bits, marcas u otros indicadores, de forma que el PSAP alternativo puede encaminar la petición alternativa a las entidades de respuesta de emergencia apropiadas. Los bits, marcas u otros indicadores pueden ser los bits especificados en la Tabla 10.5.135d en 3GPP TS 24.008.
Más concretamente, un elemento de red tal como un P-CSCF verifica si las peticiones que recibe contienen identificadores de servicio de emergencias. El P-CSCF puede determinar que se realizó una petición de llamada de emergencia adecuada pero que la red local no soporta el PSAP de emergencia solicitado (por ejemplo, se realizó una petición a urn:service:sos.gas). El P-CSCF puede entonces determinar que el UE falló al reconocer la petición como una petición de llamada de emergencia. El P-CSCF puede entonces ser configurado para rechazar la petición y proporcionar suficiente información para que el UE encamine la petición a un punto de respuesta alternativo ya que el usuario del UE tiene la impresión de que está informando de una situación que requiere atención. Sin embargo, un PSAP/centro de emergencias para ese tipo de emergencia no está soportado por la red.
A día de hoy, en la red CS, se han asignado Categorías de Servicio a Policía, Ambulancia, Bomberos, Guarda Costas y Rescate de Montaña. Sin embargo, en el caso de que un 380 (Servicio Alternativo) sea devuelto por el P-CSCF, una de las opciones que tiene el UE es iniciar una llamada de emergencia en el dominio CS utilizando procedimientos específicos adecuados de tecnología de acceso. Sin embargo, el UE, tras recibir el 380, aún no sabe si la petición original con identificador del servicio de emergencia que no fue reconocida por el UE estaba destinada a un PSAP por defecto, PSAP de Policía, PSAP de Ambulancia, PSAP de Bomberos, PSAP combinado, etc.
En una realización, en el caso de que el P-CSCF haya sido configurado para reconocer la petición como un tipo de emergencia concreto, el P-CSCF informa al UE de que la petición era para ese tipo de emergencia. Además, si el P-CSCF rechaza la petición porque no está soportado el tipo de emergencia solicitado, el P-CSCF puede proporcionar información adicional. El UE puede entonces ser mejorado para gestionar mensajes 380 (Servicios Alternativos) para peticiones de emergencia no reconocidas a PSAPs particulares. Cuando se intenta conectar con un PSAP particular utilizando el Dominio CS, se puede realizar un mapeo al Valor de Categoría de Emergencia correcto (ver 3GPP TS 24.2008 sub-cláusula 10.5.4.33). El P-CSCF puede ser mejorado para rechazar peticiones de servicio de emergencia a PSAPs no soportados, por ejemplo: urn:service.sos.gas, basándose en la reglamentación local.
A continuación se muestra un ejemplo de cuerpo de texto XML que indica al UE que se detectó una petición de servicio de emergencia y que instruye al UE para que se conecte al PSAP determinado.
<ims-3gpp version=”…”>
<alternative-service>
<type alternate=”
tel:119; pone-context=+81
Urn:service:sos.fire-urn:servicio:sos.ambulance”>
<emergency/>
</type>
<reason/>
</alternative-service>
</ims-3gpp>
Las propuestas anteriores mencionadas que señalizan el reconocimiento por parte de la red IMS de una petición a un centro combinado de emergencias y que mapean desde el valor señalizado representando un centro combinado de emergencias con uno o más bits presentados en la Tabla 10.5.135d en 3GPP TS 24.2008. 3GPP TS 24.2008 es la especificación GSM/UMTS, y GMS/UMTS soporta diferente Configuración regular en relación con la Configuración de Emergencia (es decir, sin marcación de dígitos). En CDMA, desde “IS-2000 versión A” en adelante, existe también un campo llamado GLOBAL_EMERGENCY_CALL que puede incluirse en un mensaje de Origen para hacer tal llamada independiente de la cadena marcada. El nivel de revisión de protocolo que proporciona es 7 y superior. Anteriores UEs, con un “nivel de revisión protocolo actualmente en uso es inferior a 7”, no distinguen entre llamadas de emergencia y normales. Por lo tanto, tales UE podrían tener que mapear, es decir, “tel:110:contextoteléfono=+81” a 119 y marcar 119 como una llamada normal.
Tampoco, CDMA soporta el encaminamiento a los Centros Combinados de Emergencias o a los Centros Especializados de Emergencias (por ejemplo, sólo para la “policía”). 3GPP2 sólo documenta cómo encaminar a PSAPs por defecto. Por lo tanto, en una realización alternativa, un UE CDMA detecta que la red IMS ha determinado que la petición original a la red IMS era para un PSAP no por defecto. El UE CDMA podría entonces, en lugar de enviar una llamada de emergencia con GLOBAL_EMERGENCY_CALL fijada 1 1 (en lugar de encaminarlo al PSAP por defecto), soportar algo de lo siguiente: una llamada de emergencia con Global_Emergency fijada a “1” y en el campo de direcciones, un número de teléfono: por ejemplo, 119, si “el nivel de revisión del protocolo actualmente en uso NO es inferior a 7”; una llamada de emergencia con Global_Emergency fijada a “0” y el campo de direcciones un
número de teléfono: por ejemplo, 119, si “el nivel de revisión de protocolo actualmente en uso no es inferior a 7”; y/o una llamada de emergencia con un número de teléfono en el campo de direcciones: por ejemplo, 119, si “el nivel de revisión de protocolo actualmente en uso es inferior a 7”.
Las propuestas actuales añaden un “atributo alternativo” al Esquema XML existente. En una realización, el atributo alternativo incluye un número de direcciones alternativas, una de las cuales (el último elemento) podría ser un indicador que codifique la necesidad de encaminar la llamada a un centro combinado de emergencias, uniendo juntos con un guion los URNs del servicio de emergencias: por ejemplo, “Urn:service:sos.ambulanceUrn:service:sos.fire”. Realizaciones alternativas podrían codificar las direcciones alternativas de forma diferente en la respuesta SIP, por ejemplo, en los campos de encabezamiento de Contacto o en un nuevo cuerpo de texto separado XML. Otra alternativa podría ser una codificación diferente tal que el indicador podría ser aún un URN o tel URI o SIP URI. Por ejemplo, urn:service:sos.fire.ambulance (por ejemplo, uniendo con puntos los sub-tipos de emergencia).
Un número de emergencia podría interpretarse de diferente forma en países diferentes. Por ejemplo, la dirección “119” podría interpretarse como policía+marina en un país o como incendio+ambulancia, en otro. Si ambos países tienen operadores que son afiliados en tránsito de la red doméstica de un usuario en tránsito, el UE o la red necesitan reconocer la dirección como una petición de emergencia, pero la red podría no saber qué interpretación dar a 119. En una realización, en tal situación, la red selecciona una de las interpretaciones tras una interacción adicional con el UE.
Tal interacción adicional incluye, por ejemplo, que la red envíe información al UE, indicando que la dirección está asociada con diferentes tipos de emergencia en diferentes jurisdicciones. Tal información incluye un mapeo entre la dirección, un contexto telefónico y uno o más tipos de identificador de emergencia opcionales, y se le conoce como información de dirección alternativa. Un tipo de identificador de emergencia es opcional en el que el contexto telefónico no mapea a un tipo de emergencia pero no se conocen alternativas “de emergencia” o “urgentes”.
La información de dirección alternativa comprende un mapeo entre una dirección, un contexto telefónico y uno o más tipos de identificador de emergencia opcionales. La dirección indica el número de emergencia marcado, que podría ser un número de teléfono, tal como por ejemplo “119”. El contexto telefónico indica una condición relevante del UE, como la posición o el país en que se encuentra el UE, y podría ser un número o una cadena, tal como ‘+81’, la cadena de texto ‘Japón’, una combinación de un número y una cadena u otra información que pudiera estar relacionada con una posición, por ejemplo. La cadena de texto (por ejemplo, ‘Japón’) puede ser recibida en múltiples lenguajes y múltiples codificaciones de caracteres, incluyendo Japonés y otros grupos de caracteres no ASCII. El tipo del identificador de emergencia (por ejemplo, ‘policía’, ‘fuego’ o ‘ambulancia’, por ejemplo) es ampliable e indica el tipo de servicio de emergencia asociado con la dirección para un contexto telefónico determinado. El país o región donde se aplican los servicios de emergencia pueden ser identificados utilizando los códigos ITU, IANA, ISO aplicables, sin embargo, en algunos casos, se proporcionan servicios de emergencia en una zona que no coincide con un ‘país’ o región, en cuyo caso podría no haber sido asignado ningún código ITU, IANA, ISO normalizado. Algunos códigos ITI, IANA, ISO u otros códigos aplicables para codificar situaciones, países o regiones son ampliables, tal como el ISO 3166-1 y el ISO 3166/MA.
La información de dirección alternativa puede además contener un elemento de razón, como el elemento XML <reason> (como se describe en, por ejemplo, el cuerpo de texto 3GPP IMS XML definido en 3GPP TS 24.29). Un elemento de razón se completa con información que puede ser presentada a un usuario de un UE para identificar, por ejemplo, la posición, los tipos de servicio de emergencia soportados y/o los números del servicio de emergencia. Tal elemento de razón podría ser transmitido en un cuerpo de texto mejorado aplicación/3gpp-ims+xml (como el que se define en 3GPP TS 24.229). Los contenidos de un elemento de razón pueden especificarse en múltiples lenguajes, utilizando el atributo xml:lang. Por ejemplo, un elemento de razón puede ser representado por el siguiente cuerpo de texto (que se corresponde con un Esquema XML mejorado en 3GPP TS 24.229).
<ims-3gpp version=”2”>
<alternative-service>
<type><emergency/></type>
<reason lang=”en”>emergency</reason> <reason lang=”nl”>noodgeval</reason </alternative-service> </ims-3gpp>
La red envía dicha información de dirección alternativa al UE, por ejemplo, como parte del cuerpo de texto de una respuesta SIP 300 (Múltiples Elecciones), en uno o más encabezamientos de campo de Contacto de la respuesta SIP 300 (Múltiple Elección) o en otra respuesta SIP 3xx (por ejemplo, una respuesta SIP 380 (Servicio Alternativo)).
Lo siguiente es un ejemplo de un cuerpo de texto XML incluido en una respuesta a una petición de servicio de emergencia que indica al UE que una dirección (“119”, por ejemplo) está asociada a un tipo diferente de emergencia,
o una combinación de ellos (“fuego”, “ambulancia”, o “policía”, por ejemplo) en diferentes contextos telefónicos
(‘+81’, por ejemplo). Obsérvese que los tipos de emergencia se derivan del URN del servicio de emergencia de RFC 5031 (por ejemplo, urn:service:sos y sus sub-tipos, policía, ambulancia, gas, incendio, etc., donde <police/> puede mapear a urn:service:sos.police, etc.) Obsérvese que el tipo de emergencia <sos/> puede mapear al URN del servicio genérico urn:service.sos. Obsérvese que <sos/> puede mapear a la cadena de marcación “112” o a un dominio GSM/UMTS CS de llamadas de emergencia configurado con todos los bits de Valor de Categoría del Servicio de Emergencia fijados a “0” (véase Tabla 10.5.135d/3GPP TS 24.2008: elemento de información de Categoría del Servicio) de forma que la llamada es encaminada a un centro de emergencia definido por defecto por el operador o señalización equivalente en otras tecnologías de dominio CS, tales como CDMA. Obsérvese que <police/> podría también mapear para fijar el bit 1 del Valor de Categoría del Servicio de Emergencia al hacer una llamada de emergencia GMS/UMTS sobre el dominio CS.
<ims-3gpp version=”…”> <alternative-service> <type>
>emergency </type> <reason <action>
<alternative> <alternativeURI>tel:112;phonecontext=+57</alternativeURI> <sos
</alternative>
<alternative> <alternativeURI>tel:123;phonecontext=+57</alternativeURI> <ambulance <fire <police
</alternative>
<alternative> <alternativeURI>tel:119;phonecontext=+81</alternativeURI> <alternativeURI>tel:119;phonecontext=+82</alternativeURI> <alternativeURI>tel:119;phonecontext=+886</alternativeURI> <ambulance <fire
</alternative>
<alternative> <alternativeURI>tel:119;phonecontext=+94</alternativeURI> <alternativeURI>tel:119;phonecontext=+1876</alternativeURI> <police
</alternative>
<alternative> <alternativeURI>tel:119;phonecontext=+57</alternativeURI> <alternativeURI>tel:119;phonecontext=+86</alternativeURI> <fire
</alternative>
<alternative> <alternativeURI>tel:119;phonecontext=+62</alternativeURI> <alternativeURI>tel:119;phonecontext=+62</alternativeURI> <ambulance
</alternative> </action> </alternative-service> </ims-3gpp>
El cuerpo de texto XML del ejemplo anterior indica que la dirección ‘119’ puede ser interpretada como un tipo de emergencia diferente en una jurisdicción diferente. Por ejemplo, la dirección ‘119’ está asociada con servicios de emergencia de ‘incendio’ y ‘ambulancia’ cuando el UE está en una jurisdicción con un contexto telefónico de ‘+81’ (Japón) o ‘+82’ (Corea). La dirección ‘119’ se asocia alternativamente con servicios de emergencia de ‘policía’ cuando el UE está en una jurisdicción con un contexto telefónico de ‘+94’ (Sri Lanka).
Si un código de país o código de localidad se incluye en una petición de servicio de emergencia que puede ser mapeada a múltiples tipos de servicios de emergencia, se supone que el terminal pretende solicitar específicamente ser encaminado al tipo de servicio de emergencia asociado con la dirección del servicio de emergencia en el país o región indicados.
En otra realización, el UE o la red están configurados para seleccionar o reducir las alternativas en la respuesta y para eliminar algunas de las posibilidades menos probables. Dicha selección o reducción pueden lograrse basándose en la red actual de un UE, en la red doméstica del UE, en la nacionalidad del usuario del UE, o en anteriores planes de viaje del usuario del UE, por ejemplo. Un UE que realiza la selección o la reducción podría incluir una regla que codifique de forma fija un mapeo entre una dirección, un tipo de emergencia y un contexto telefónico, permitiendo por tanto que el UE seleccione explícitamente el tipo de emergencia deseado cuando realice una llamada sobre el dominio CS o sobre el dominio PS. En el dominio PS, un tipo de emergencia puede venir indicado por un URN RFC 5031 o por un URL TEL, que incluye un indicador de país o región, por ejemplo un ‘contexto telefónico’. Una función de selección de tipo de emergencia en el UE podría además ser mejorada si el UE sabe en qué país o región se encuentra y si se dispone de un mapeado almacenado o recibido localmente de los tipos de emergencia, indicadores de localidad y direcciones de llamadas de emergencia. La función de selección del tipo de emergencia podría entonces determinar que en ciertos países o regiones se aplica, o NO, un cierto mapeo o si el mapeo se aplica universalmente (por ejemplo, para terminales UMTS/GSM el número “112” puede mapear una llamada de emergencia en el dominio GSM/UMTS CS configurada con todos los bits del Valor de Categoría del Servicio de Emergencia fijados a ‘0’ (véase Tabla 10.5.135.d/3GPP TS 24.2008: elemento de información de Categoría del Servicio).
Tal interacción adicional entre la red y el UE para seleccionar una interpretación también incluye, por ejemplo, colocar las alternativas para la interpretación en un campo de texto para que aparezcan en el UE (tal como el elemento <reason> en el cuerpo de texto 3GPP IMS XML). El usuario del UE podría entonces seleccionar una de las alternativas, la selección podría ser transmitida a la red, y la red podría interpretar el número de emergencia basándose en la selección. Alternativamente, la red podría hacer la selección en el siguiente orden: mapear la dirección (por ejemplo, 119) como se define en la red doméstica; si la dirección no está definida en la red doméstica, mapear la dirección tal y como se define en la red visitada en ese momento, si la dirección no está definida en la red visitada en ese momento, mapear la dirección tal y como está definida para afiliados en tránsito o encaminar la llamada al PSAP predeterminado o más capaz. Alternativamente, la petición puede siempre ser encaminada/dirigida al PSAP más capaz o al por defecto.
Le puede ocurrir un problema similar al UE cuando intenta reconocer la dirección marcada como un identificador de emergencia. En una realización, el UE está configurado con una interpretación para impedir que se produzca este problema. Alternativamente, el UE puede interactuar con el usuario para seleccionar una interpretación deseada. Alternativamente, el UE puede estar configurado para encaminar la llamada al PSAP más capaz o al por defecto. Alternativamente, el UE podría encaminar la llamada basándose en la red a la que esté conectado y podría mapear los dígitos de acuerdo con las reglas de la red. El UE podría también interactuar con la red y utilizar cualquier consejo que reciba.
En otra realización más, el P-CSCF no rechazará la petición de un tipo de servicio de emergencia no soportado (tal como urn:service:sos.poison) pero la preparará para remitirla a la red doméstica del usuario S-CSCF, utilizando procedimientos normales (en lugar de remitirla a un E-CSCF). El S-SCSF de la red doméstica del usuario debe entonces estar configurado para gestionar el valor URI de la Petición no encaminable. La red IMS puede también estar configurada para tener en cuenta los usuarios en tránsito que soliciten una sesión con urn:service:sos:police, de forma que el servicio solicitado por un UE que pueda estar en el otro extremo del mundo, puede sin embargo ser gestionado de forma puntual y efectiva. La red IMS podría proporcionar una indicación en un mensaje SIP al UE de que se ha determinado que la llamada no es una llamada de emergencia y que su gestión será diferente. La indicación podría ser un indicador y/o una información alfanumérica. En este documento se dan posibles codificaciones de este tipo de indicador.
Volviendo al caso en el que un componente de la red IMS determine que el UE 110 ha iniciado una llamada de emergencia sin reconocerla como tal, en algunas realizaciones la red IMS 120 incluye el indicador 160 de llamada de emergencia en una respuesta SIP que se envía al UE 110. En este caso, se proporciona el indicador 160 durante la fase de señalización del establecimiento de la llamada. En otras realizaciones, el indicador 160 de llamada de emergencia se incluye en un mensaje que se origina en el PSAP 130. La red IMS 120 transfiere entonces el mensaje del PSAP 130 al UE 110.
En otras realizaciones, si un componente de la red IMS 120 incluye el indicador 160 de llamada de emergencia en la respuesta SIP que se envía al UE 110, el UE 110 puede abortar la señalización actual e iniciar los procedimientos normales de establecimiento de llamada de emergencia, que pueden suponer que se origine una llamada en una red Conmutada de Circuitos, si es capaz y está disponible, o después de iniciar los procedimientos de registro de emergencia, o enviar una petición SIP INVITE que contiene un indicador que indica que la petición SIP INVITE es una petición de llamada relativa a una emergencia y que contiene información relativa a la emergencia en sí misma.
La información que es similar a la información 180 que el UE 110 incluye en el mensaje 170 SIP podría ser incluida por el UE 110 en un mensaje enviado en diferentes circunstancias. Esto lo ilustra la figura 2, en la que el UE 110, la red 120 IMS y el PSAP 130 están de nuevo presentes. Sin embargo, en este caso, el PSAP 130 inicia una devolución de llamada al UE 110. Como es bien conocido en la técnica, una vez finalizada la llamada de emergencia, el PSAP 130 puede realizar una devolución de llamada al UE 110 por varias razones. Por ejemplo, si la llamada de emergencia parece haber finalizado de forma anormal, el PSAP 130 podría llamar de nuevo al UE 110 para determinar si el usuario del UE desea transmitir alguna información adicional. Alternativamente, el PSAP 130 podría llamar de nuevo al usuario para pedirle la información que inadvertidamente omitió solicitar en la llamada inicial. Otras razones para realizar una devolución de llamada del PSAP 130 a alguien que realiza una llamada de emergencia tras la finalización de una llamada de emergencia pueden resultarle familiares a los expertos en la técnica.
El PSAP 130 podría iniciar la devolución de la llamada, enviando un mensaje 210 SIP INVITE, o un mensaje similar, al UE 110 a través de la red 120 IMS. En una realización, el mensaje 210 SIP INVITE contiene un indicador 220 que indica que el mensaje 210 SIP INVITE está relacionado con una devolución de llamada de emergencia. El indicador 220 podría ser sustancialmente similar al indicador 160 de la figura 1 o podría ser 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 del PSAP 130 y puede responder al indicador 220 adecuadamente, invocando la funcionalidad de la devolución de llamadas de emergencia, sujeta a las reglas. En una realización, la respuesta del UE 110 a la recepción del indicador 220 es sustancialmente similar a la respuesta del UE 110 tras recibir el indicador 160 de la figura 1.
Por ejemplo, una medida que el UE 110 podría tomar al reconocer el indicador 220 es indicar visual o audiblemente al usuario la naturaleza de la sesión. Es decir, 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 aparezca en la pantalla del UE 110 u otro tipo de indicación de la naturaleza de la llamada. Otras medidas tomadas por el UE 110 pueden implicar transmitir una respuesta 230 SIP 2xx o 1xx (por ejemplo, respuesta SIP 200(OK)) o mensaje similar, que incluya la información 240 sobre el UE 110, sujeta a las reglas. Alternativamente, debido a las limitaciones en SIP, la información 240 puede ser transmitida a través de varios mensajes SIP o mensajes de red (por ejemplo, la información proporcionada por el UE sobre la identidad de IP-CAN puede no ser completamente fiable y por lo tanto un mecanismo basado en lo que aporta la red (por ejemplo, utilizando Control de Reglas y Tarificación (PCC)), puede proporcionar tal información), o dentro de una petición de refresco del objetivo tal como por ejemplo una petición SIP re-INVITE o una petición UPDATE o parcialmente en una petición SIP PRACK. La información 240 podría ser sustancialmente parecida a la información 180 que el UE 110 proporcionó tras recibir el indicador 160 de la figura 1.
Una parte de la información 240 que el UE 110 podría enviar al PSAP 130 es la identidad pública del usuario del UE
o cualquier otro símbolo identificativo. Otra parte de la información 240 que el UE 110 podría transmitir en el mensaje 230 SIP 200OK es el tipo de acceso utilizado por el UE 110 para la llamada de emergencia original. Por ejemplo, si la llamada de emergencia se realizó a través de una LAN inalámbrica, el UE 110 podría incluir tal dato en la información 240, así como una ID de la célula, una ID de la línea, y/o una ID del nodo de acceso inalámbrico LAN.
Si el 110 conoce su localización geográfica, a través del uso de un sistema GPS, por ejemplo, el UE 110 puede incluir su posición como parte adicional de la información 240. Si el UE 110 no conoce su posición geográfica, no se incluyen datos relativos a la posición en la información 240. Si un GRUU está asociado con el UE 110, puede incluirse el GRUU del UE como otra parte adicional de la información 240.
En una realización alternativa, el PSAP 130 podría establecer una llamada Conmutada de Circuitos (CS) y una pasarela CS podría convertir la llamada y la señalización en tecnología conmutada de paquetes si la llamada CS es encaminada a la pasarela CS. Activada por la llamada entrante del PSAP 130, la pasarela CS podría iniciar la devolución de llamada usando tecnología conmutada de paquetes, enviando un mensaje 210 SIP INVITE, o mensaje similar, al UE 110 a través de la red IMS 120.
La figura 3 ilustra una realización de un método 300 para que un UE responda a un mensaje relativo a una emergencia enviado al UE. En el bloque 310, el UE recibe un mensaje que contiene un indicador que indica que se ha realizado una llamada relativa a una emergencia. En algunos casos, la llamada de emergencia puede haber sido realizada por el UE sin que el UE fuera consciente de que la llamada estaba relacionada con una emergencia. En otros casos, la llamada relativa a una emergencia podría ser una devolución de llamada de un PSAP al UE en respuesta a una llamada previa de emergencia del UE. En el bloque 320, el UE reconoce el indicador como una
indicación de que su primer mensaje (petición SIP inicial de transacción de diálogo o autónoma, o método desconocido o mensaje similar) tiene relación con una emergencia. Opcionalmente, en el bloque 330, el UE proporciona una indicación visual, audible o de otro tipo al usuario del UE de que la llamada relativa a la emergencia está relacionada con una emergencia. En el bloque 340, el UE envía un mensaje que contiene información relativa a la emergencia sobre sí mismo.
La presente descripción de esta memoria podría ejecutarse como una o más modificaciones al Proyecto de Asociación de Tercera Generación (3GPP) Especificación Técnica (TS) 24.229 “Protocolo de Control de Llamadas Multimedia sobre Protocolo Internet (IP) basándose en Protocolo de Iniciación de Sesión (SIP) y Protocolo de Descripción de Sesión (SDP): Etapa 3”. A continuación se proporcionan propuestas de adendas y modificaciones a la TS 24.229, de acuerdo con varias realizaciones de la presente descripción.
La siguiente adenda a 3GPP TS 24.229 se aplica a la petición inicial INVITE en el caso de que se origine en el UE un inicio de llamada:
En el caso de que el UE reciba una respuesta 380 (Servicio Alternativo) a una petición INVITE, conteniendo la respuesta un cuerpo de texto XML que incluya un elemento <alternative service> con el atributo “alternativo” del elemento hijo <type> que contenga uno o más URIs dle servicio de emergencia, el UE puede intentar realizar una llamada normal como se describe en la sub-cláusula 5.1.3.1, utilizando un servicio de emergencia URI o utilizando el establecimiento de llamada de acuerdo con los procedimientos descritos en 3GPP TS
24.008 [8]. El comportamiento del UE es de ejecución específica si el atributo “alternativo” del elemento hijo <type> no está presente o no contiene servicio de emergencia URIs.
La siguiente modificación a 3GPP TS 24.229 se aplica al servicio general de emergencia:
EL P-CSCF almacenará una lista configurable de los identificadores locales del servicio de emergencias, es decir, números de emergencia y servicios de emergencia URN, que son válidos para el operador al cual pertenece el P-CSCF. Además de esto, el P-CSCF almacenará una lista configurable de los identificadores del servicio de emergencia de los abonados en tránsito. Las listas configurables con los indicadores del servicio de emergencia de los abonados locales y en tránsito indicarán la gestión en función del identificador del servicio de emergencia. Cuando la gestión indique que la petición deba ser rechazada, puede incluirse en la respuesta una lista configurable de URIs alternativas de servicios de emergencia.
La siguiente adenda a 3GPP TS 24.229 se aplica al tratamiento general para todos los diálogos y transacciones autónomas excluyendo el método REGISTER tras el registro de emergencia:
Si el P-CSCF detecta que la Petición-URI de la petición inicial para un diálogo o transacción autónoma, o un método desconocido coincide con un tipo de emergencia no soportado en los identificadores del servicio de emergencias de la VPLMN o de la HPLMN, el P-CSCF:
responderá a la petición INVITE con una respuesta 380 (Servicio Alternativo) supondrá que el UE soporta la versión 1 del Esquema XML para el subsistema IM CN cuerpo de texto XML si no se indica que soporte el cuerpo de texto 3GPP IMS XML; e incluirá en la respuesta 380 (Servicio Alternativo):
-
un campo de encabezamiento Tipo-Contenido con el valor establecido en el tipo asociado MIME del cuerpo de texto 3GPP IMS XML, descrito en la sub-cláusula 7.6.1
El cuerpo de texto contendrá:
a) un elemento <alternative-service>, establecido en los parámetros del servicio alternativo; b) si el encabezamiento Aceptar indica que soporta la versión 2 del Esquema XML para el sub-sistema IM CN cuerpo de texto XML,
-
entonces, un elemento hijo <type> con un atributo “alternativo” establecido en una lista de servicios de emergencias alternativos URIs
- si no, un elemento hijo <type>, establecido en “emergencia”. c) un elemento hijo <reason> establecido en una razón configurable por el operador.
La siguiente adenda alternativa a 3GPP TS 24.229 se aplica al tratamiento general de todos los diálogos y transacciones autónomas, excluyendo el método REGISTER tras el registro de emergencia.
Si P-CSCF detecta que la Petición-URI de la petición inicial de diálogo, o de transacción autónoma, u de otro método desconocido coinciden con un tipo de emergencia no soportado en los identificadores del servicio de emergencias de la VPLMN o de la HPLMN, el P-CSCF:
-
responderá a la petición INVITE con una respuesta 380 (Servicio Alternativo)
-
supondrá que el UE soporta la versión 1 del Esquema XML para el subsistema IM CN cuerpo de texto XML si no se indica en el encabezamiento Aceptar que soporta el cuerpo de texto 3GPP IS XML; e
-
incluirá en la respuesta 380 (Servicio Alternativo):
-
un campo de encabezamiento Tipo-Contenido con el valor establecido en el tipo MIME asociado del cuerpo de texto 3GPP IMS XML descrito en la subcláusula 7.6
El cuerpo de texto contendrá:
a) un elemento <alternative-service>, establecido en los parámetros del servicio alternativo; b) un elemento hijo <type> con un atributo “alternativo” establecido en la lista de servicios de emergencias alternativos URIs, c) un elemento hijo <reason> establecido en una razón configurable por el operador
La siguiente modificación a 3GPP TS 24.229 se aplica al tratamiento general para todos los diálogos y transacciones autónomas, excluyendo el método REGISTER para el registro de una no emergencia:
Si el P-CSCF recibe una petición inicial de diálogo, o de transacción autónoma, o de un método desconocido, para un usuario registrado, el P-CSCF inspeccionará la Petición URI independientemente de los valores de posibles entradas en los encabezamientos recibidos Encaminamiento para identificadores conocidos del servicio de emergencias, es decir, números de emergencia y servicio de emergencias URN de estas listas configurables. Si el P-CSCF detecta que la Petición-URI de la petición inicial de diálogo o de transacción independiente, o de un método desconocido, coincide con uno de los identificadores del servicio de emergencias de cualquiera de estas listas, el P-CSCF:
0� determinará la posición geográfica del UE. Se describen los procedimientos específicos de tecnología de acceso en cada anexo específico de tecnología de acceso. Si el P-CSCF no es capaz de gestionar las sesiones de emergencia o debido a las reglas locales nogestiona sesiones de emergencia
o sólo gestiona ciertos tipos de petición de servicio de emergencia o el IP-CAN al cual el UE está conectado o el UE está en tránsito o el P-CSCF está en una red diferente de la red del operador doméstico del UE, entonces el P-CSCF
:
-
rechazará la petición, devolviendo una respuesta 380 (Servicio Alternativo) al UE.
-
supondrá que el UE soporta la versión 1 del Esquema XML para el subsistema IM CN cuerpo de texto XML si no se indica que soporte el cuerpo de texto 3GPP IMS XML; e
-
incluirá en la respuesta 380 (Servicio Alternativo):
-
Un campo de encabezamiento de Tipo-Contenido con el valor establecido en el tipo MIME asociado del cuerpo de texto 3GPP IMS XML tal y como se describe en la subcláusula 7.6.1
El cuerpo de texto contendrá:
a) un elemento <alternative-service>, establecido en los parámetros del servicio alternativo; b) si el encabezamiento Aceptar indica que se soporta la versión 2 del Esquema XML para el sub-sistema IM CN cuerpo de texto XML
-
entonces, un elemento hijo <type> con un atributo “alternativo” establecido en una lista de servicios alternativos de emergencias URIs, y
- si la petición inicial de diálogo o transacción autónoma, o método desconocido, era para un tipo de emergencia soportado, el elemento hijo <type> se fija en “emergencia” para indicar que se trata de un llamada de emergencia soportada,
-
si no, un elemento hijo <type> se fija en “emergencia”;
c) un elemento hijo <reason>, establecido en una razón configurable por el operador; y d) un elemento hijo <action>, establecido en “registro de emergencia” si la petición incluía un servicio de emergencia URN en la Petición-URI
NOTA 1: La situación de tránsito se produce cuando un UE se encuentra en una zona geográfica que está fuera de la zona geográfica del servicio del subsistema doméstico IM CN. NOTA 1a: sip:911@example.com;user=phone podria ser un servicio alternativo de emergencias URI.“urn:service:sos.animal-control” podría ser un tipo de llamada de emergencia no soportado. NOTA 2: El servicio de emergencia URN en la petición-URI indica a la red que el intento de llamada de emergencia es reconocido por el UE.
La siguiente modificación alternativa a 3GPP TS 24.229 se aplica al tratamiento general de todos los diálogos y transacciones autónomas, excluyendo el método REGISTER para un registro no de emergencia:
Si el P-CSCF recibe una petición inicial de diálogo, o transacción autónoma, o un método desconocido, para un usuario registrado, el P-CSCF inspeccionará la Petición URI con independencia de los valores de entradas posibles en los encabezamientos de Encaminamiento recibidos para identificadores del servicio de emergencia conocidos, es decir, números de emergencia y el servicio de emergencia URN de estas listas configurables. Si el P-CSCF detecta que el URI-Petición de la petición inicial de diálogo, o transacción indendiente, o método desconocido, coincide con uno de los identificadores del servicio de emergencia de cualquiera de estas listas, el P-CSCF:
0) determinará la posició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 el P-CSCF no es capaz de gestionar las sesiones de emergencia o por motivos de reglas locales no gestiona sesiones de emergencia o sólo gestiona ciertos tipos de petición de servicio de emergencia o el IP-CAN al cual el UE está conectado o el UE se encuentra en tránsito o el P-CSCF está en una red diferente de la red del operador doméstico del UE, entonces el P-CSCF:
-
rechazará la petición, devolviendo una respuesta 380 (Servicio Alternativo) al UE.
-
supondrá que el UE soporta la versión 1 del Esquema XML para el subsistema IM CN cuerpo de texto XMl, si no se indica en el encabezamiento Aceptar que soporta el cuerpo de texto 3GPP IMS XML, e
-
incluirá en la respuesta 380 (Servicio Alternativo):
-
un campo de encabezamiento Contenido-Tipo con el valor establecido en el tipo MIME asociado del cuerpo de texto 3GPP IMS XML tal y como se describe en la subcláusula
7.6.1.
El cuerpo de texto contendrá:
a) un elemento <alternative-service>, establecido en los parámetros del servicio alternativo; b) un elemento hijo <type> con un atributo “alternativo” establecido en la lista de servicios de emergencias alternativos URIs, y
-
si la petición inicial de diálogo o transacción autónoma, o método desconocido, era para un tipo de emergencia soportado, el elemento hijo <type> se fija en “emergencia” para indicar que se trata de una llamada de emergencia soportada,
c) un elemento hijo <reason>, establecido en una razón configurable por el operador; y d) un elemento hijo <action>, establecido en “registro de emergencia” si la petición incluía un servicio de emergencia URN en la Petición-URI.
NOTA 1: El tránsito se produce cuando un UE se encuentra en una zona geográfica que está fuera de la zona geográfica del servicio del subsistema doméstico IM CN. NOTA 2: El servicio de emergencia URN en la petición-URI indica a la red que el intento de llamada de emergencia es reconocido por el UE.
La siguiente modificación a 3GPP TS 24.229 se aplica a casos anormales:
Si el subsistema IM CN al que pertenece el P-CSCF no es capaz de gestionar sesiones de emergencia, o debido a las reglas locales no gestiona sesiones de emergencia, o sólo gestiona ciertos tipos de petición de sesión de emergencia, o no soporta sesiones de emergencia ni para la posición geográfica en la que se encuentra el UE o ni para el IP-CAN al que está conectado el UE, el P-CSCF no enviará la petición INVITE. El P-CSCF:
-
responderá a la petición INVITE con una respuesta 380 (Servicio Alternativo);
-
supondrá que el UE soporta la versión 1 del Esquema XML para el subsistema IM CN cuerpo de texto XML si no se indica en el encabezamiento Aceptar que soporta el cuerpo de texto 3GPP IMS XML; e
-
incluirá en la respuesta 380 (Servicio Alternativo):
-
Un campo de encabezamiento Contenido-Tipo con el valor establecido en el tipo MIME asociado del cuerpo de texto 3GPP IMS XML como se describe en la subcláusula 7.6.1
El cuerpo de texto contendrá:
a) un elemento <alternative service>, establecido en los parámetros del servicio alternativo; b) si el encabezamiento Aceptar indica que soporta la versión 2 del Esquema XML para el subsistema IM CN cuerpo de texto XML,
-
entonces, un elemento hijo <type> con un atributo “alternativo” establecido en una lista de servicios alternativos de emergencia URIs, y
-
si la petición inicial de diálogo o transacción autónoma, o método desconocido, era para un
5 tipo de emergencia soportado, el elemento hijo <type> se fija en “emergencia” para indicar que se trata de una llamada de emergencia soportada,
si no, un elemento hijo <type> se fija en “emergencia”;
10 c) un elemento hijo <reason>, establecido en una razón configurable por el operador; y d) un elemento hijo <action>, establecido en “registro de emergencia” si la petición incluía un servicio de emergencia URN en la Petición-URI.
NOTA 1: El Servicio de Emergencia URN en la petición-URI indica a la red que el intento de llamada de emergencia
15 es reconocido por el UE. NOTA 1a: sip:911@example.com;user=phone podria ser un URI alternativo del servicio de emergencia. “urn:service:sos.animal-control” podría ser un tipo de emergencia no soportado. NOTA 2: Algunas redes sólo permiten peticiones de sesión con una Petición-URI- que contenga un URN del servicio de emergencia, es decir, un URN del servicio con un tipo de servicio de nivel superior de “sos” como se especifica
20 en draft-ietf-ecrit.service-urn [69].
La siguiente modificación alternativa a 3GPP TS 24.229 se aplica a casos anormales:
Si el subsistema IM CN al que pertenece P-CSCF no es capaz de gestionar sesiones de emergencia o debido
25 a reglas locales no gestiona sesiones de emergencia, o sólo gestiona ciertos tipos de petición de sesión de emergencia o no soporta sesiones de emergencia ni para la posición geográfica en la que se encuentra el UE ni para el IP-CAN al que está conectado el UE, el P-CSCF no enviará la petición INVITE. El P-CSCF:
-
responderá a la petición INVITE con una respuesta 380 (Servicio Alternativo);
30 - supondrá que el UE soporta la versión 1 del Esquema XML para el subsistema IM CN cuerpo de texto XML si no se indica en el encabezamiento Aceptar que soporta el cuerpo de texto 3GPP IMS XML; e
-
incluirá en la respuesta 380 (Servicio Alternativo):
-
Un campo de encabezamiento Contenido-Tipo con el valor establecido en el tipo MIME35 asociado del cuerpo de texto 3GPP IMS XML como se describe en la subcláusula 7.6.1
El cuerpo de texto contendrá:
a) un elemento <alternative-service>, establecido en los parámetros del servicio alternativo; 40 b) un elemento hijo <type> con un atributo “alternativo” establecido en una lista de URIs alternativos del servicio de emergencia, y
-
si la petición inicial de diálogo, o transacción autónoma, o método desconocido, fuera
para un tipo de emergencia soportado, el elemento hijo <type> se fija en “emergencia” 45 para indicar que se trata de una llamada de emergencia soportada;
c) un elemento hijo <reason>, establecido en una razón configurable por el operador; y d) un elemento hijo <action>, establecido en “registro de emergencia” si la petición incluía un servicio de emergencia URN en la Petición-URI.
NOTA 1: El Servicio de Emergencia URN en la Petición-URI indica a la red que el intento de llamada de emergencia es reconocido por el UE. NOTA 2: Algunas redes sólo permiten peticiones de sesión con una Petición-URI que contenga un servicio de emergencia URN, es decir, un servicio URN con un tipo de servicio de nivel superior de “sos” como se especifica en
55 draft-ietf-ecrit.service-urn [69].
Se podría realizar la siguiente modificación en el subsistema 3GPP IM CN cuerpo de texto XML Esquema XML para ejecutar una o más de las realizaciones descritas en esta memoria:
El elemento <action> contiene el atributo “alternativo” y sólo el valor “emergencia-registro” en el presente documento. El atributo “alternativo” puede ser establecido en una lista de servicios alternativos de emergencia URIs.
Las siguientes dos adendas a 3GPP TS 24.229 se aplican a procedimientos genéricos aplicables a todos los métodos excluyendo el método REGISTRO: Tras generar una petición inicial de diálogo, o una transacción autónoma, o un método desconocido, excluyendo ACK y CANCEL, el UE incluirá el encabezamiento ACCEPT con “aplicación/sdp”, el tipo MIME asociado al cuerpo de texto 3GPP IMS XML (véase subcláusula 7.6.1) y cualquier otro tipo MIME que el UE quiera y pueda aceptar. En el caso de que el UE reciba una respuesta 380 (Servicio Alternativo) a una petición inicial de diálogo o transacción autónoma, o método desconocido, incluyendo la respuesta un subsistema IM CN cuerpo de texto XML como el descrito en la subcláusula 7.6 que incluye un elemento <alternative-service> con el elemento hijo <type> establecido en “emergencia”, el UE intentará realizar una llamada de emergencia como la descrita en la subcláusula 5.1.6
Si la respuesta 1xx o 2xx a una petición inicial de diálogo, o a una transacción autónoma, o a un método desconocido, contiene un indicador de sesión de emergencia, el UE enviará un método de petición re-INVITE de acuerdo con RFC 3261 [26], y:
1) el UE indicará al usuario la naturaleza de la sesión; NOTE 17: El UE no cambia el encabezamiento FROM para incluir una identidad pública de usuario o el tel URI asociado con la identidad pública del usuario, en esta versión de la especificación. 2) si se encuentra disponible para el UE, y si está definido para el tipo de acceso como el especificado en la subcláusula 7.2A.4, el UE incluirá un encabezamiento Info-Red-Acceso-P y contendrá un identificador de posición, tal como la id de célula, la id de linea o la identidad del nodo de acceso I-WLAN. NOTA 18: La especificación de emergencia IMS en 3GPP TS 23.164[4B] describe varios métodos de cómo el UE puede obtener información de su posició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 tel URI asociado con la identidad pública del usuario como se describe en la subcláusula 4.2; 4) Si el UE dispone de información sobre su posición, entonces el UE la incluirá de la siguiente forma:
-
si el UE conoce el URI que señala dónde se almacena la posición del UE, incluirá el URI en el encabezamiento de Geolocalización de acuerdo con draft-ietf-sip-location-conveyance [89]; o
-
si el UE dispone de información sobre la posición geográfica del UE, incluirá la información sobre su posición geográfica como objeto de localización PIDF de acuerdo con RFC 4119 [90] e incluirá el objeto posición en un cuerpo de texto de mensaje con la solicitud de tipo de contenido/pidf+xml de acuerdo con draft-ietf-sip-location-conveyance [89]. El encabezamiento de Geolocalización se fija en un ID Contenido de acuerdo con draft-ietf-sip-location-conveyance [89]; y
5) si el UE no dispone de información sobre su posición geográfica, el UE no incluirá ninguna información sobre posición geográfica como se especifica en draft-ietf-sip-location-conveyance [89]; y 6) si un valor GRUU público (pub-gruu) se ha guardado, asociado con la identidad pública del usuario y el UE no indica privacidad de la Identidad-Confirmada-P, entonces el UE insertará el valor GRUU público (pub-gruu) en el encabezamiento Contacto como se especifica en draft-ietf-sip-gruu [89]; de lo contrario, UE incluirá el puerto servidor protegido en la dirección del encabezamiento Contacto. NOTA 19: De acuerdo con RFC.3261 [26], una petición re-INVITE no puede ser enviada mientras haya otra transacción INVITE en curso en cualquier dirección. NOTA 20: No es necesario para esta petición re-INVITE cambiar los parámetros de sesión.
NOTA 21: Se sugiere que los UEs sólo utilicen la opción de proporcionar un URI cuando la parte del dominio pertenezca al proveedor actual P-CSCF o S-CSCF. Esta es una cuestión respecto a la cual el operador de red necesita proporcionar orientación al usuario final. No es deseable un URI que sólo pueda atender al UE que está haciendo la llamada.
NOTA 22: Durante el diálogo, los puntos de conexión al IP-CAN del UE pueden cambiar (por ejemplo, el UE se conecta a diferentes células). El UE completará el encabezamiento Info-Red-Acceso-P en cualquier petición (excepto peticiones ACK y peticiones CANCEL) o respuesta (excepto respuestas CANCEL) dentro de un diálogo con el punto actual de conexión al IP-CAN (por ejemplo, la información actual de la célula).
La aplicación de privacidad, incluyendo la eliminación de información relativa a la posición y red de acceso, si el PSAP está dentro del dominio fiable de la red, puede ser realizada por elementos de red IMS tales como E-CSCF, IBCF u otros. Puede preferirse que se solicite privacidad de “sesión” (es decir, un campo de encabezamiento Privacidad establecido para incluir el valor “sesión” ya que el campo de encabezamiento Info-Red-Acceso-P está presente en la mayoría de los mensajes SIP). Puede preferirse que el E-CSCF reciba la posición de tal forma que pueda determinar cuál es el PSAP más aplicable y utilizarlo para encaminar la petición al PSAP o centro de respuesta de emergencias. Pueden aplicarse también requisitos de privacidad de acuerdo con RFC 4244 pero en la actualidad, ningún procedimiento prevé la inclusión de información sobre el historial en una petición de servicios de emergencia. Las siguientes dos adendas a 3GPP TS 24.229 se aplican a los Procedimientos en el E-CSCF:
Cuando el E-CSCF reciba una petición de diálogo solicitando privacidad o transacción autónoma que solicite privacidad o cualquier petición o respuesta relativa a un diálogo originado en el UE que solicite privacidad o transacción autónoma que solicite privacidad, y si las reglas del operador local permiten que el usuario solicite la supresión de los identificadores públicos de usuario e la información sobre la posición, el E-CSCF:
aplicará cualquier privacidad requerida por RFC 3323 [33] en relación a privacidad y por RFC 3325
[34] en relación al encabezamiento Identidad-Confirmada-P;
si existe, eliminará el campo de encabezamiento P-INFO-RED-ACCESO;
-
si existe, eliminará el objeto posición del cuerpo de texto del mensaje y eliminará la aplicación de tipo de contenido/pidf+xml del campo de encabezamiento Contenido-Tipo;
si existe, eliminará el campo de encabezamiento Geolocalización.
NOTA: Las reglas del operador (por ejemplo, requisitos para soportar comunicaciones de emergencia) pueden anular la petición de supresión realizada por el usuario.
6) seleccionará, basándose en la información de posición y, opcionalmente, en el tipo de servicio de emergencia:
-
un PSAP conectado a la red del subsistema IM CN y añadirá el PSAP URI al encabezamiento de Encaminamiento superior; o
NOTA 3: Si el usuario no solicitó privacidad, el E-CSCF lleva el encabezamiento Info-Red-Acceso-P que contiene el identificador de posición, si viene definido para el tipo de acceso al PSAP como se especifica en la subcláusula 7.2A.4.
-
Un PSAP en el PSTN añadirá el BGCF URI al encabezamiento de Encaminamiento superior y añadirá un PSAP URI en el formato tel URI a la Petición-URI con una entrada utilizada en el dominio PSTN/CS para dirigir el PSAP;
NOTA 4: Si el usuario no solicitó privacidad, el E-CSCF lleva el encabezamiento Info-Red-Acceso-P que contiene el identificador de posición, si viene definido para el tipo de acceso hacia el MGFC como se especifica en la subcláusula 7.2A.4,. El MGCF puede interpretar la información sobre la posición si está incluida en INVITE ( es decir, tanto la información sobre la posición geográfica en PIDF-LO como el identificador de la posición en el encabezamiento P-Info-Red-Acceso) dentro de la señalización ISUP, véase 3GPP TS 29.163 [11B]. NOTA 5: El E-CSCF puede solicitar información sobre la posición e información sobre el tránsito al LRF. El E-CSCF puede por ejemplo enviar el identificador de la posición al LRF y el LRF mapea el identificador de la posición dentro de la información de la posición geográfica correspondiente que el LRF envía al E-CSCF. El LRF puede invocar un RDF para convertir la información sobre la posición en un PSAP/EC URI apropiado. Tanto la información sobre URI como el PSAP URI se devuelven al E-CSCF.
NOTA 6: La forma en la que el E-CSCF determina el siguiente salto de dirección cuando la dirección del PSAP es un tel URI que depende de la ejecución. 7) Si el usuario no solicitó privacidad y si el E-CSCF recibe un número de referencia del LRF, el E-CSCF incluirá el número de referencia en el encabezamiento Identidad-Confirmada-P; NOTA 7: El número de referencia se utiliza en la comunicación entre el PSAP y LRF.
La figura 4 ilustra un sistema de comunicaciones inalámbrico que incluye una realización del UE 110. El UE 110 funciona para ejecutar aspectos de la descripción, pero la descripción no debe limitarse a estas ejecuciones. Aunque se ilustra como un teléfono móvil, el UE 110 puede adoptar varias formas, incluyendo un teléfono inalámbrico, un buscapersonas, un PDA (asistente personal digital), un ordenador portátil, una tableta o un ordenador de bolsillo. Muchos dispositivos adecuados combinan alguna o todas estas funciones. En algunas realizaciones de la descripción, el UE 110 no es un dispositivo de ordenador de carácter general, tipo ordenador portátil, de bolsillo o tableta, sino un dispositivo de comunicaciones específico, tipo teléfono móvil, teléfono inalámbrico, buscapersonas o PDA. En otra realización, el UE 110 puede ser un ordenador portátil, de bolsillo o cualquier otro dispositivo de ordenador. El UE 110 puede soportar actividades especializadas, tales como juegos, control de inventario, control de trabajo y/o funciones de gestión de tareas, etc.
El UE 110 incluye una pantalla 402. El UE 110 también incluye una pantalla sensible al tacto, un teclado u otras teclas de entrada normalmente referidas como 404 para introducir datos por parte del usuario. El teclado puede ser un teclado alfanumérico completo o reducido, del tipo QWERTY, Dvorak, AZERTY y tipos secuenciales, o un teclado numérico tradicional, con letras de alfabeto asociadas a un teclado de teléfono. Las teclas pueden incluir una rueda de desplazamiento, una tecla de escape o salida, una bola de desplazamiento y otras teclas para navegación o funcionales, que pueden ser presionadas interiormente para proporcionar más funciones de entrada. El UE 110 puede presentar opciones para que el usuario seleccione, controles para que el usuario accione y/o cursores u otros indicadores para que el usuario dirija. El UE 110 puede además aceptar la introducción de datos por parte del usuario, incluyendo números a marcar o diversos valores de parámetros para configurar el funcionamiento del UE
110. El UE 110 puede además ejecutar una o más aplicaciones de software o firmware en respuesta a comandos del usuario. Estas aplicaciones pueden configurar el UE 110 para que realice varias funciones personalizadas en respuesta a la interacción del usuario. Adicionalmente, el UE 110 puede estar programado y/o configurado por radio, por ejemplo, desde una estación base inalámbrica, un punto de acceso inalámbrico o un par UE 110.
Entre las diversas aplicaciones ejecutables por el UE 110 se encuentra un navegador web, que permite que la pantalla 402 muestre una página web. La página web puede ser obtenida a través de comunicaciones inalámbricas con un nodo de acceso de red inalámbrico, una torre celular, un par UE 110 o cualquier otra red de comunicación inalámbrica o sistema 400. La red 400 está acoplada a una red cableada 408, tal como Internet. A través del enlace inalámbrico y de la red cableada, el UE 110 tiene acceso a la información en varios servidores, como el servidor 410. El servidor 410 puede proporcionar contenidos que pueden mostrarse en la pantalla 402. Alternativamente, el UE 110 puede acceder a la red 400 a través de un par UE 110 que actúa como intermediario, en una conexión tipo repetidor o tipo salto.
La figura 5 muestra un diagrama de bloques del UE 110. Aunque se representa una variedad de componentes conocidos de UEs 110, en una realización se puede incluir en el UE 110 un subconjunto de los componentes de la lista y/o componentes adicionales no presentes en la lista. El UE 110 incluye un procesador de señal digital (DSP) 502 y una memoria 504. Como se muestra, el UE 110 puede además incluir una antena y una unidad final frontal 504, un transceptor 508 de radio frecuencia (RF), una unidad 510 de tratamiento analógico de banda base, un micrófono 512, un altavoz 514 de audífono, un puerto 516 para auriculares, un interfaz 518 de entrada/salida, una tarjeta 520 de memoria extraíble, un puerto 522 bus serie universal (USB), un subsistema 524 de comunicación inalámbrica de corto alcance, una alerta 526, un teclado 528, una pantalla 530 de cristal líquido (LCD) que puede incluir una superficie sensible al tacto, un controlador 532 de LCD, una cámara 534 de dispositivo de carga acoplada (CCD), un controlador 536 de cámara y un sensor 538 de sistema de posicionamiento global (GPS). En una realización, el UE 110 puede incluir otro tipo de pantalla que no incorpore una superficie sensible al tacto. En una realización, el DSP 502 puede comunicarse directamente con la memoria 504 sin pasar a través del interfaz 518 de entrada/salida.
El DSP 502 u otro tipo de controlador o unidad de tratamiento central funcionan para controlar los diversos componentes del UE 110 de acuerdo con el software o firmware integrado en la memoria 504 o almacenado en la memoria que contiene el propio DPS 502. Además del software o firmware integrados, el DSP 502 puede ejecutar otras aplicaciones almacenadas en la memoria 504 o disponibles a través de medios portadores de información tales como medios portátiles de almacenamiento de datos, como la tarjeta 520 de memoria extraíble o por medio de comunicaciones de red cableada o inalámbrica. El software de aplicación puede comprender un conjunto compilado de instrucciones interpretables por el procesador que configuran el DSP 502 para proporcionarle la funcionalidad deseada o el software de aplicación pueden ser instrucciones de software de alto nivel para ser procesadas por un intérprete o compilador para configurar indirectamente el DSP 502.
La antena y la unidad final frontal 506 pueden estar dispuestas para convertir señales inalámbricas en señales eléctricas, haciendo que el UE 110 envíe y reciba información de una red celular o de alguna otra red disponible de comunicaciones inalámbricas, o de un par UE 110. En una realización, la antena y la unidad final frontal 506 pueden incluir múltiples antenas para soportar formación de haces y/o operaciones de entrada múltiple, salida múltiple (MIMO). Como conocen los expertos en la técnica, las operaciones MIMO pueden proporcionar diversidad espacial que puede ser utilizada para superar condiciones difíciles del canal y/o incrementar el rendimiento del canal. La antena y la unidad central 506 pueden incluir el ajuste de antena y/o los componentes de adaptación de impedancias, amplificadores de RF de potencia y/o amplificadores de bajo ruido.
El transceptor RF 508 proporciona desplazamiento de frecuencia, convirtiendo las señales RF recibidas a banda base y convirtiendo las señales de transmisión de banda base a RF. En algunas descripciones, puede entenderse que un radio transceptor o transceptor de RF incluyan otras funcionalidades de tratamiento de la señal, tales como modulación/desmodulación, codificación/descodificación, entrelazado/desentrelazado, dispersión/concentración, transformada rápida inversa de Fourier (IFFT)/transformada rápida de Fourier (FFT), anexión/eliminación del prefijo cíclico y otras funciones de tratamiento de la señal. En aras de la claridad, la presente descripción separa la descripción de este tratamiento de la señal de la RF y/o de la etapa de radio y asigna de forma conceptual dicho tratamiento de la señal a la unidad 510 de tratamiento analógico de banda de base y/o al DSP 502 u otra unidad de tratamiento central. En algunas realizaciones, el Transceptor RF 508, partes de la Antena y de la Unidad Final Frontal 506, y la unidad 510 de tratamiento análogico de base de banda pueden combinarse en una o más unidades de tratamiento y/o circuitos integrados de aplicaciones específicas (ASICs).
La unidad 510 de tratamiento analógico de banda base puede proporcionar diversos tratamientos analógicos de entradas y salidas, por ejemplo, el tratamiento analógico de entradas del micrófono 512 y del auricular 516 y de salidas al audífono 514 y al auricular 516. Con ese propósito, la unidad 510 de tratamiento analógico de banda base puede tener puertos para conectarse al micrófono incorporado 512 y al audífono 514 que permita que el UE 110 pueda ser utilizado como teléfono móvil. La unidad 510 de tratamiento analógico de banda base puede además incluir un puerto para conectarse a un auricular u otro micrófono y altavoz según una configuración de manos libres. La unidad 510 de tratamiento analógico de banda base puede proporcionar conversión digital analógica en un sentido de la señal y conversión analógica digital en el sentido opuesto. En algunas realizaciones, al menos algo de la funcionalidad de la unidad 510 de tratamiento analógico de banda base puede ser proporcionada por los componentes de tratamiento digital, por ejemplo, por el DSP 502 o por otras unidades de tratamiento central.
El DSP 502 puede realizar modulación/desmodulación, codificación/descodificación, entrelazado/desentrelazado, difusión/concentración, transformada rápida inversa de Fourier (IFFT)/transformada rápida de Fourier (FFT), anexión/eliminación de prefijo cíclico y otras funciones de tratamiento de la señal asociadas a las comunicaciones inalámbricas. En una realización, por ejemplo en una aplicación de tecnologia de acceso múltiple por división de código (CDMA), para una función de transmisor, el DSP 502 puede desempeñar funciones de modulación, codificación, entrelazado y difusión, y para una función de receptor, el DSP 502 puede desempeñar funciones de 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 ortogonal de frecuencia (OFDMA), para la función de transmisor, el DSP 502 puede desempeñar funciones de modulación, codificación, entrelazado, transformada rápida inversa de Fourier y anexión de prefijo cíclico, y para una función de receptor, el DSP 502 puede desempeñar funciones de eliminación de prefijo cíclico, transformada rápida de Fourier (FFT), desentrelazado, descodificación y desmodulación. En otras aplicaciones de tecnología inalámbrica, otras más funciones de tratamiento de la señal y combinaciones de funciones de tratamiento de la señal pueden ser desempeñadas por el DSP 502.
El DSP 502 se puede comunicar con una red inalámbrica a través de la unidad 510 de tratamiento analógico de banda base. En algunas realizaciones, la comunicación puede proporcionar conectividad de Internet, posibilitando que el usuario tenga acceso al contenido de Internet y envíe y reciba correos electrónicos o mensaje de textos. El interfaz 518 de entrada/salida interconecta el DSP 502 con varias memorias e interfaces. La memoria 504 y la tarjeta 520 de memoria extraíble pueden proporcionar software y datos para configurar el funcionamiento del DSP
502. Entre los interfaces pueden encontrarse el interfaz 522 USB y el subsistema 524 de comunicación inalámbrica de corto alcance. El interfaz 522 USB puede utilizarse para cargar el UE 110 y puede también hacer que el UE 110 funcione como un dispositivo periférico para intercambiar información con un ordenador personal u otro sistema de ordenador. El subsistema 524 de comunicación inalámbrico de corto alcance puede incluir un puerto de infrarrojos, un interfaz Bluetooth, un interfaz inalámbrico compatible IEEE 802.11 o cualquier subsistema de comunicación inalámbrica de corto alcance que pueda hacer que el UE 110 se comunique de modo inalámbrico con otros UEs cercanos y/o con estaciones base inalámbricas.
El interfaz 518 de entrada/salida puede además conectar el DS 502 a la alerta 526, que una vez disparada, hace que el UE 110 proporcione un aviso al usuario, por ejemplo, por medio de un timbre, una melodía o vibración. La alerta 526 puede servir como mecanismo para alertar al usuario respecto a diversos eventos, tales como una llamada entrante, un nuevo mensaje de texto y un recordatorio de cita por medio de una vibración silenciosa, o haciendo sonar una melodía específicamente pre asignada a un interlocutor en particular.
El teclado 528 se acopla al DSP 502 a través del interfaz 518 para proporcionar un mecanismo al usuario que le permita hacer selecciones, introducir información y de otro modo, proporcionar información al UE 110. El teclado 528 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 de alfabeto asociados a un teclado telefónico. Las teclas de entrada pueden incluir una rueda de desplazamiento, una tecla de salida o escape, una bola de desplazamiento y otras teclas de navegación o funcionales, que pueden ser presionadas internamente para proveer más funciones de entrada. Otro mecanismo de entrada puede ser el LCD 530, que puede incluir capacidad de pantalla sensible al tacto y también representar texto y/o gráficos al usuario. El controlador LCD 532 acopla el DSP 502 al LCD 530.
La cámara CCD 534, si está incorporada, permite que el UE 110 tome fotos digitales. El DSP 502 se comunica con la cámara CCD 534 a través del controlador de cámara 536. En otra realización, puede emplearse una cámara que funcione con tecnología diferente a la de las cámaras de Dispositivo de Carga Acoplada. El sensor GPS 538 se acopla al DSP 502 para descodificar señales del sistema de posicionamiento global, permitiendo por tanto que el UE determine su posición. Se pueden incluir otros periféricos para proporcionar funciones adicionales, por ejemplo, recepción de radio y televisión.
La figura 6 ilustra un entorno software 602 que puede ser ejecutado por el DSP 502. El DSP 502 ejecuta los controladores 604 del sistema operativo que proporcionan una plataforma desde la que opera el resto del software. Los controladores 604 del sistema operativo proporcionan controladores para el hardware del nodo con interfaces normalizados que son accesibles al software de aplicación. Los controladores 604 del sistema operativo incluyen servicios 606 de gestión de aplicaciones (“AMS”) que transfieren el control entre las aplicaciones que se ejecutan en el UE 110. También se muestra en la figura 6 una aplicación 608 de navegador web, una aplicación 610 de reproductor de medios y applets Java 612. La aplicación 608 de navegador web configura el UE 110 para que opere como un navegador web, permitiendo que un usuario introduzca información en formularios y seleccione enlaces para recuperar y ver páginas web. La aplicación 610 de reproductor de medios configura el UE 110 para recuperar y reproducir medios de audio o audiovisuales. Los applets Java 612 configuran el UE 110 para proporcionar juegos, utilidades y otras funcionalidades. 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 tratamiento que sea capaz de ejecutar instrucciones relacionadas con las acciones antes descritas. La figura 7 ilustra un ejemplo de un sistema 1300 que incluye un componente 1310 de tratamiento adecuado para ejecutar una o más de las realizaciones descritas en esta memoria. Además del procesador 1310 (que puede ser considerado como un procesador central o CPU), el sistema 1300 podría incluir dispositivos 1320 de conectividad de red, memoria 1330 de acceso aleatorio (RAM), memoria 1340 de solo lectura (ROM), almacenamiento secundario 1350 y dispositivos 1360 de entrada/salida (I/O). En algunos casos, algunos de estos componentes pueden no estar presentes o pueden estar combinados en varias combinaciones entre sí o con otros componentes no mostrados. Estos componentes podrían estar localizados en una única entidad física o en más de una entidad física. Cualquiera de las medidas descritas en esta memoria como tomada por el procesador 1310 podría ser tomada por el procesador 1310 por sí 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 archivos scripts a los que podría acceder desde los dispositivos 1320 de conectividad de red, RAM 1330, ROM 1340 o almacenamiento secundario 1350 (que podría incluir varios sistemas basados en discos, tales como disco duro, disco flexible o disco óptico). Aunque sólo se muestre un procesador 1310, puede haber múltiples procesadores. Por lo tanto, aunque las instrucciones se pueden describir como ejecutadas por un procesador, las instrucciones pueden ser ejecutadas simultáneamente, en serie o de otra forma por uno o múltiples procesadores. El procesador 1310 puede estar formado por uno o más chips de CPU.
Los dispositivos 1320 de conectividad de red pueden adoptar la forma de módems, bancos de módems, dispositivos Ethernet, dispositivos de interfaz de bus serie universal (USB), interfaces serie, dispositivos de trama en anillo, dispositivos de interfaz para distribución de datos por fibra óptica (FDDI), dispositivos de red de área local inalámbrica (WLAN), dispositivos radio transceptores tales como acceso múltiple por división de código (CDMA) y/o sistema global para dispositivos transceptores de comunicaciones de radio con móviles (GSM), y otros dispositivos bien conocidos para conectar a las redes. Estos dispositivos 1320 de conectividad de red pueden habilitar al procesador 1310 para comunicarse con Internet o con una o más redes de telecomunicaciones u 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 1320 de conectividad de red podrían también incluir uno o más componentes 1325 de transceptor capaces de transmitir y/o recibir datos de forma inalámbrica en forma de ondas electromagnéticas, tales como señales de radio frecuencia o señales de frecuencia de microondas. Alternativamente, los datos pueden propagarse en o sobre la superficie de conductores eléctricos, cables coaxiales, guías de onda, medios ópticos tales como fibra óptica u otros medios. El componente 1325 transceptor podría incluir unidades de recepción y transmisión separadas o un solo transceptor. La información transmitida o recibida por el transceptor 1325 puede incluir datos que han sido tratados por el procesador 1310 o instrucciones que tienen que ser ejecutadas por el procesador 1310. Tal información puede ser recibida desde y enviada a una red, en la forma de, por ejemplo, una señal de banda base
de datos informáticos o una señal incoporada en una onda portadora. Los datos pueden ser ordenados de acuerdo con diferentes secuencias según sea deseable, para tratarlos o para generar los datos o para transmitir o recibir los datos. Se puede hacer referencia a la señal de banda base, la señal incorporada en la onda portadora, u otros tipos de señales usadas en la actualidad, o que se desarrollen posteriormente, como el medio de transmisión y pueden generarse de acuerdo con diversos métodos bien conocidos por los expertos en la técnica.
La RAM 1330 puede 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 generalmente tiene una capacidad de memoria menor que la capacidad de memoria 1350 de almacenamiento secundario. La ROM 1340 puede utilizarse para almacenar instrucciones y quizás datos que se leen durante la ejecución de las instrucciones. El acceso tanto a la RAM 1330 como a la ROM 1340 es normalmente más rápido que al almacenamiento secundario 1350. El almacenamiento secundario 1350 consta normalmente de una o más unidades de disco o unidades de cinta y podría utilizarse para almacenamiento no volátil de datos o como un dispositivo de almacenaje de datos de desborde si la RAM 1330 no fuera lo bastante grande para albergar todos los datos de trabajo. El almacenamiento secundario 1350 puede ser utilizado para almacenar programas que se cargan en la RAM 1330 cuando tales programas son seleccionados para su ejecución.
Los dispositivos 1360 de E/S pueden incluir pantallas de cristal líquido (LCD), pantallas sensibles al tacto, teclados, teclados numéricos, conmutadores, diales, ratones, bolas de deslizamiento, reconocedores de voz, lectores de tarjeta, lectores de cinta de papel, impresoras, monitores de video u otros dispositivos de entrada bien conocidos. Además, el transceptor 1325 podría ser considerado como uno de los componentes de los dispositivos 1360 de I/O en lugar de, o además de, ser un componente de los dispositivos 1320 de conectividad de red. Algunos de, o todos, los dispositivos 1360 pueden ser sustancialmente similares a diversos componentes descritos en el dibujo previamente descrito del UE 110, tales como la pantalla 402 y la entrada 404.
En una realización, se proporciona un método para que un componente de red gestione peticiones enviadas al componente de red. El componente de red inspecciona las peticiones enviadas al componente de red para determinar si las peticiones están relacionadas con emergencias, y si se determina que una de las peticiones está relacionada con una emergencia, el componente de red actualiza la petición.
Cuando se determina que la petición es relativa a una emergencia, el componente de red se configura alternativamente, basándose en configuraciones y reglas reguladoras, para realizar una de las siguientes acciones: aceptar la petición; aceptar la petición e incluir un indicador de llamada de emergencia en una respuesta de Protocolo de Inicio de Sesión (SIP) enviada a un equipo de usuario (UE) que inició la petición; no aceptar la petición, rechazando la petición; no aceptar la petición e indicar la información de contacto alternativa para un centro de respuesta de emergencias al que se dirigía la llamada.
En una realización, se envía una respuesta SIP (Protocolo de Inicio de Sesión) al UE en respuesta al UE que realiza la llamada, de que el UE no sabe que es una llamada de emergencia.
Si un identificador de recurso uniforme de agente de usuario globalmente encaminable (GRUU) está asociado con el UE, y si el GRUU es un GRUU temporal, el GRUU temporal es reemplazado por un GRUU no-temporal. El GRUU temporal podría ser reemplazado por el GRUU no temporal sólo cuando no se ha hecho una petición de mantener el GRUU privado.
Si un Identificador del Servicio de Comunicación IMS (ICSI) o un Identificador de Referencia de Aplicación IMS (IARI) está presente, antes de que la petición se encamine a un PSAP o a un centro de emergencia, el componente de red realiza al menos una de las siguientes acciones: eliminar los campos de encabezamiento Servicio-Preferido-P; eliminar los campos de encabezamiento Servicio-Confirmado-P; eliminar las etiquetas de características ICSI y los valores de etiqueta de los campos de encabezamiento Contactar-Aceptar; y eliminar las etiquetas de características IARI y los valores de etiqueta de los campos de encabezamiento Contactar-Aceptar.
Cuando el componente de red no acepte la petición, el componente de red responde con uno de los mensajes 300 (Múltiple Elección), mensaje 301 (Trasladado Permanente), Mensaje 302 (Trasladado Temporalmente), respuesta SIP 4xx, respuesta SIP 6xx, respuesta SIP 380 (Servicio Alternativo). En una realización, el componente de red no acepta la petición debido a al menos una de las siguientes razones: la red no es capaz de gestionar sesiones de emergencia; un subsistema de red de núcleo multimedia de internet al que pertenece el componente de red no es capaz de gestionar sesiones de emergencia; la red no gestiona sesiones de emergencia debido a reglas locales; la red sólo gestiona ciertos tipos de peticiones de sesiones de emergencia; el UE está en tránsito; el componente de la red está en una red diferente de la red del operador doméstico del UE; y la red no soporta sesiones de emergencia para una de las posiciones geográficas en las está localizado el UE y para la Red de Acceso de Conectividad de Protocolo Internet a la que está conectado el UE.
En una realización, el componente de red incluye una lista configurable con identificadores del servicio de emergencia de colaboradores locales y de tránsito que indican la gestión de las peticiones basándose en el identificador del servicio por emergencia. Cuando el componente de red no acepta la petición, se envía al UE una
lista configurable de identificadores del servicio de emergencia alternativo. Al menos un URI del servicio de emergencia alternativo podría presentarse al usuario del UE.
En una realización, el componente de red, en lugar de no aceptar la petición de un tipo de servicio de emergencia no soportado, prepara la petición para enviarla a la red doméstica del UE. La red doméstica del UE podría estar configurada para gestionar el valor URI asociado a la petición.
En una realización, el componente de red es una función de control de sesión de llamada proxy (P-CSCF).
En una realización, las peticiones comprenden peticiones SIP iniciales de diálogo, transacciones SIP autónomas, métodos SIP desconocidos.
En una realización alternativa, se proporciona un equipo de usuario. El equipo de usuario comprende un componente, responsable de hacer una petición de emergencia que es rechazada, configurado para recibir un mensaje que contiene información asociando la petición de emergencia con un centro de emergencia combinado. El componente puede estar además configurado para utilizar la información para hacer una petición de emergencia subsiguiente al centro de emergencia combinado.
En una realización alternativa, se proporciona un componente de red. El componente de red comprende un componente, que tras recibir una petición de emergencia de un equipo de usuario, el componente está configurado para determinar si la petición de emergencia está relacionada con un centro de emergencia combinado y para enviar al equipo de usuario un mensaje que contiene información que identifica que la petición de emergencia está relacionada con un centro de emergencia combinado.
En una realización alternativa, se proporciona un equipo de usuario. El equipo de usuario comprende un componente configurado para recibir un mensaje de rechazo que contiene información de dirección alternativa que asocia una petición de emergencia con una pluralidad de centros de emergencia, centros de no emergencia, o centros de emergencia combinados. La información de dirección alternativa puede utilizarse para determinar a cuál de la pluralidad de centros debe encaminarse una llamada de emergencia.
En una realización alternativa, se proporciona un componente de red. El componente de red comprende un componente configurado para determinar si una petición recibida es una petición de emergencia y si la petición recibida está relacionada con uno o más centros de emergencia, centros de emergencia combinados, o centros de no emergencia y para enviar una respuesta de rechazo que contiene información de dirección alternativa. La información de dirección alternativa puede comprender un mapeo entre la petición recibida, un contexto telefónico y uno o más tipos de identificador de emergencia opcionales.
Las siguientes Especificaciones Técnicas (TS) del Proyecto de Asociación de Tercera Generación (3GPP) se incorporan en esta memoria con referencias: TS 24.229 V7.8.0 (2007-12) y TS 24.2008
Se exponen realizaciones adicionales de ejemplo de la presente descripción en las siguientes cláusulas numeradas:
Cláusula número 1. Un aparato que comprende:
un componente de red configurado para:
recibir de un equipo de usuario (“UE”) un mensaje de Protocolo de Iniciación de Sesión (“SIP”) de petición de diálogo (140) que es una petición relativa a una emergencia. enviar al UE (110) un mensaje (150) de respuesta SIP que contiene un campo de encabezamiento Identidad-Confirmada-P con un indicador (160) que indica que el mensaje SIP de petición de diálogo
(140) es una petición relacionada con una emergencia; y recibir del UE (110), en respuesta al mensaje (150) de respuesta SIP, un mensaje de petición SIP dentro del diálogo (170), conteniendo dicho mensaje de petición SIP dentro del diálogo (170) información relacionada con una emergencia (180) asociada al UE (110).
Cláusula número 2. Un método para que un componente de red gestione información relativa a una emergencia, que comprende:
recibir de un equipo de usuario (“UE”) (110) un mensaje de Protocolo de Iniciación de Sesión (“SIP”) de petición de diálogo (140), que es una petición relativa a una emergencia, enviar desde el componente de red al UE (110) un mensaje (150) de respuesta SIP que contiene un campo de encabezamiento Identidad-Confirmada-P con un indicador (160) que indica que un mensaje de petición SIP de diálogo (170), enviado por el UE (110) es una petición relativa a una emergencia; y recibir del UE (110), en respuesta al mensaje (150) de respuesta SIP, un mensaje de petición SIP dentro del diálogo (170), conteniendo dicho mensaje de petición SIP dentro del diálogo (170) información (180) relacionada con una emergencia asociada con el UE (110).
Cláusula número 3. El aparato de la cláusula 1 o el método de la cláusula 2, en los que la información (180) relativa a la emergencia asociada con el UE (110) contenida en el mensaje de petición SIP dentro del diálogo (170), comprende una identidad UE.
Cláusula número 4. El aparato o método de la cláusula 3, en los que la identidad del UE es un identificador de recurso uniforme de agente de usuario globalmente encaminable (“GRUU”).
Cláusula número 5. El aparato de la cláusula 1 o el método de la cláusula 2, en los que la información (180) relativa a la emergencia asociada con el UE (110) contenida en el mensaje de petición SIP dentro del diálogo (170), comprende una posición del UE.
Cláusula número 6. El aparato de la cláusula 1 o el método de la cláusula 2, en los que la información (180) relativa a la emergencia asociada con el UE (110) contenida en el mensaje de petición SIP dentro del diálogo (170), comprende una información de red de acceso al UE.
Cláusula número 7. El aparato o método de cualquiera de las cláusulas precedentes, en los que el componente de red es una función de control de sesión de llamada de emergencia (“E-CSCF”).
Cláusula número 8. El aparato o método de cualquiera de las cláusulas precedentes, en los que el mensaje de respuesta SIP (150) es uno de entre las respuestas SIP 1xx o 200 (OK).
Cláusula número 9. El aparato o método de cualquiera de las cláusulas precedentes, en los que el mensaje (150) de respuesta SIP dentro del diálogo (170) es uno de entre los siguientes:
un SIP ACK; un SIP PRACK; un refresco de objetivo SIP, un SIP UPDATE, y una petición SIP RE-INVITE.
Cláusula número 10. El aparato o método de cualquiera de las cláusulas precedentes, en los que un campo de encabezamiento de geo localización del mensaje de petición SIP dentro del diálogo (170), incluye un URI (Identificador de Recurso Uniforme) que indica la posición del UE.
Cláusula número 11. El aparato o método de cualquiera de las cláusulas precedentes, en los que el cuerpo del mensaje del mensaje de petición SIP dentro del diálogo (170), incluye información (180) de la posición geográfica del UE (110) como un objetivo de localización PIDF.
Cláusula número 12. El aparato o método de cualquiera de las cláusulas precedentes, en los que un campo de encabezamiento de contacto del mensaje de petición SIP dentro del diálogo (170), incluye un valor GRUU público asociado a una identidad pública de usuario.
Cláusula número 13. El aparato o método de la cláusula 6, en los que la información de red de acceso del UE se incluye en un campo de encabezamiento Info-Red-Acceso-P en el mensaje de petición SIP dentro del diálogo (170) y comprende un identificador de posición, un identificador de célula o una identidad de un nodo de acceso I-WLAN.
Cláusula número 14. El aparato o método de cualquiera de las cláusulas precedentes, en los que el indicador (160) que indica que un mensaje de petición SIP de diálogo (140) es una petición relativa a una emergencia, es un Nombre de Recurso Uniforme (URN).
Cláusula número 15. El aparato o método de la cláusula 14, en los que el URN indica una función PSAP.
Cláusula número 16. El aparato o método de cualquiera de las cláusulas precedentes, en los que el indicador indica 911 en general.
Cláusula número 17. Un medio interpretable por ordenador que almacena instrucciones interpretables por ordenador ejecutables por un procesador de un dispositivo de ordenador para hacer que dicho dispositivo ejecute el método de cualquiera de las cláusulas 2-16.
Cláusula número 18. Un aparato que comprende:
un componente de red configurado para:
recibir de un equipo de usuario (“UE”) (110) un mensaje de Protocolo de Iniciación de Sesión (“SIP”) de petición de diálogo (140), que es una petición relativa a una emergencia.
enviar al UE (110) un mensaje (150) de respuesta SIP que contiene un Identificador de Recurso Uniforme (“URI”), que indica que el mensaje SIP de petición de diálogo (140) es una petición relativa a una emergencia; y recibir del UE (110), en respuesta al mensaje (150) de respuesta SIP, un mensaje de petición SIP
5 dentro del diálogo (170), conteniendo dicho mensaje de petición SIP dentro del diálogo (170) información (180) relativa a la emergencia asociada con el UE (110).
Cláusula número 19. El aparato de la cláusula 18, en que el URI está comprendido dentro de un campo de encabezamiento SIP.

Claims (28)

  1. REIVINDICACIONES
    1. Un método para que un componente de red gestione información relativa a una emergencia, que comprende:
    recibir de un equipo de usuario (UE) un mensaje de Protocolo de Iniciación de Sesión (SIP) de petición de un diálogo SIP, conteniendo dicho mensaje de petición SIP un Identificador de Recurso Uniforme de Petición (URI); inspeccionar la Petición URI del mensaje de petición SIP para hallar un identificador que coincida con un identificador del servicio de emergencia en una lista configurable almacenada por el componente de la red; si la petición URI coincide con un identificador del servicio de emergencia de la lista configurable:
    enviar desde el componente de la red al UE un mensaje de respuesta SIP que contiene un campo de encabezamiento Identidad-Confirmada-P con un indicador que indica que el mensaje de petición SIP de diálogo SIP, enviado por el UE, era una petición relativa a una emergencia; y recibir desde el UE, en respuesta al mensaje de respuesta SIP, un mensaje de petición SIP dentro del mismo diálogo SIP, conteniendo el mensaje de petición SIP dentro del mismo diálogo SIP información relativa a la emergencia asociada con el UE que comprende la posición del UE.
  2. 2.
    El método según la reivindicación 1, en el que la información relativa a la emergencia asociada con el UE contenida en el mensaje de petición SIP dentro del mismo diálogo SIP comprende una identidad del UE.
  3. 3.
    El método según la reivindicación 1, en el que en que la información relativa a la emergencia asociada con el UE contenida en el mensaje de petición SIP dentro del mismo diálogo SIP, comprende información de la red de acceso al UE.
  4. 4.
    El método según cualquiera de las reivindicaciones anteriores, en el que el mensaje de respuesta SIP es uno de entre las respuestas SIP 1xx o 200 (OK).
  5. 5.
    El método según cualquiera de las reivindicaciones anteriores, en el que el mensaje de petición SIP dentro del mismo diálogo es uno de entre los siguientes:
    un SIP ACK; un SIP PRACK; un refresco de objetivo SIP, un SIP UPDATE; y una petición SIP RE-INVITE.
  6. 6.
    El método según la reivindicación 2, en el que la identidad del UE es un identificador de recurso uniforme de agente de usuario globalmente encaminable (GRUU).
  7. 7.
    El método según cualquiera de las reivindicaciones anteriores, en el que un campo de encabezamiento de geo localización del mensaje de petición SIP dentro del mismo diálogo SIP, incluye un URI (Identificador de Recurso Uniforme) que señaliza la posición del UE.
  8. 8.
    El método según cualquiera de las reivindicaciones anteriores, en el que un cuerpo de mensaje del mensaje de petición SIP dentro del mismo diálogo SIP incluye información sobre la posición geográfica del UE como un objetivo de localización PIDF.
  9. 9.
    El método según cualquiera de las reivindicaciones anteriores, en el que un campo de encabezamiento de contacto del mensaje de petición SIP dentro del mismo diálogo SIP incluye un valor público GRUU asociado a una identidad pública de usuario.
  10. 10.
    El método según la reivindicación 3, en el que la información de red de acceso al UE está incluida en un campo de encabezamiento Info-Red-Acceso-P en el mensaje de petición SIP dentro del mismo diálogo SIP y comprende uno de los siguientes: un identificador de posición, un identificador de célula o una identidad de un nodo de acceso WLAN.
  11. 11.
    El método según la reivindicación 1, en el que el componente de red está además configurado para actualizar el mensaje de petición SIP.
  12. 12.
    El método según la reivindicación 11, que comprende además enviar a otro componente de red, el mensaje de petición SIP actualizado.
  13. 13.
    El método según la reivindicación 11, en que el otro componente de red es un E-CSCF.
  14. 14.
    El método según la reivindicación 12, que comprende además recibir el mensaje de respuesta SIP del otro componente de red antes de enviar el mensaje de respuesta SIP al UE.
  15. 15.
    El método según la reivindicación 1, en el que la lista configurable comprende identificadores de servicios de emergencia locales.
  16. 16.
    El método según la reivindicación 15, en el que el indicador es un Nombre de Recurso Uniforme (URN), y los identificadores de servicios de emergencia locales comprenden números de emergencia y el URN del servicio de emergencia.
  17. 17.
    El método según la reivindicación 1, en el que la lista configurable comprende identificadores de servicios de emergencia de los abonados en tránsito del UE.
  18. 18.
    El método según la reivindicación 1, en el que la lista configurable indica la gestión de cada identificador del servicio de emergencia de la lista configurable.
  19. 19.
    Un aparato que comprende un componente de red configurado para realizar el método de cualquier reivindicación anterior.
  20. 20.
    El aparato según la reivindicación 19, en el que el mensaje de petición SIP dentro del mismo diálogo SIP es una petición SIP UPDATE.
  21. 21.
    El aparato según la reivindicación 19, en el que el indicador consta de un nombre y un valor.
  22. 22.
    El aparato según la reivindicación 19, en el que el indicador es una etiqueta de características.
  23. 23.
    El aparato de la reivindicación 19, en el que el componente red es un P-CSCF.
  24. 24.
    El aparato de la reivindicación 19, en el que el indicador es un Nombre de Recurso Uniforme (URN).
  25. 25.
    El aparato de la reivindicación 24, en el que el URN indica una función PSAP.
  26. 26.
    El aparato de la reivindicación 24, en el que el URN indica 911 en general.
  27. 27.
    Un aparato que comprende:
    un componente de red configurado para
    recibir de un equipo de usuario (UE) un mensaje de petición de Protocolo de Iniciación de Sesión (SIP) de diálogo SIP, conteniendo dicho mensaje de petición SIP un Identificador del Recurso Uniforme de Petición (URI), inspeccionar la Petición URI del mensaje de petición SIP para hallar un identificador que coincida con un identificador del servicio de emergencia de la lista configurable almacenada por el componente de la red; si la Petición URI coincide con un identificador del servicio de emergencia de la lista configurable:
    actualizar el mensaje de petición SIP y enviar el mensaje de petición SIP actualizado a otro
    componente de la red; recibir un mensaje de respuesta SIP del otro componente de red, conteniendo dicho mensaje de respuesta SIP un campo de encabezamiento Identidad-Confirmada-P con un indicador que indica que el mensaje de petición SIP de diálogo SIP, enviado por el UE es una petición relativa a una emergencia; enviar al UE el mensaje de respuesta SIP; y recibir del UE, en respuesta al mensaje de respuesta SIP, un mensaje de petición SIP dentro del mismo diálogo SIP, conteniendo dicho mensaje de petición SIP dentro del mismo diálogo SIP, información relativa a la emergencia asociada con el UE, comprendiendo la posición del UE.
  28. 28. Un método para que un componente de red gestione la información relativa a una emergencia, que comprende:
    recibir de un equipo de usuario (UE) un mensaje de Protocolo de Iniciación de Sesión (SIP) de petición de diálogo SIP, conteniendo dicho mensaje de petición SIP un Identificador del Recurso Uniforme de Petición (URI); inspeccionar la Petición URI del mensaje de petición SIP para hallar un identificador que coincida con un identificador del servicio de emergencia en una lista configurable almacenada por el componente de red; si la Petición URI coincide con un identificador del servicio de emergencia en la lista configurable:
    5 actualizar el mensaje de petición SIP y enviar el mensaje de petición SIP actualizado a otro componente de red; recibir un mensaje de respuesta SIP del otro componente de la red, conteniendo dicho mensaje de respuesta SIP un campo de encabezamiento Identidad-Confirmada-P con un indicador que indica que el mensaje de petición SIP de diálogo SIP, enviado por el UE es una petición relativa a una
    10 emergencia; enviar desde el componente de la red al UE el mensaje de respuesta SIP; y recibir del UE, en respuesta al mensaje de respuesta SIP, un mensaje de petición SIP dentro del mismo diálogo, conteniendo dicho mensaje de petición SIP dentro del mismo diálogo SIP, información relativa a la emergencia asociada con el UE, comprendiendo la posición del UE.
ES12172479.3T 2008-06-02 2009-06-02 Sistema y método para gestionar llamadas de emergencia Active ES2440344T3 (es)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US131785 1987-12-11
US12/131,785 US8478226B2 (en) 2008-06-02 2008-06-02 Updating a request related to an IMS emergency session
US6150708P 2008-06-13 2008-06-13
US61507P 2008-06-13
US8157608P 2008-07-17 2008-07-17
US81576P 2008-07-17

Publications (1)

Publication Number Publication Date
ES2440344T3 true ES2440344T3 (es) 2014-01-28

Family

ID=40972853

Family Applications (2)

Application Number Title Priority Date Filing Date
ES12172479.3T Active ES2440344T3 (es) 2008-06-02 2009-06-02 Sistema y método para gestionar llamadas de emergencia
ES09759255T Active ES2393301T3 (es) 2008-06-02 2009-06-02 Sistema y método para gestionar solicitudes de emergencia

Family Applications After (1)

Application Number Title Priority Date Filing Date
ES09759255T Active ES2393301T3 (es) 2008-06-02 2009-06-02 Sistema y método para gestionar solicitudes de emergencia

Country Status (10)

Country Link
US (5) US9462616B2 (es)
EP (1) EP2260633B1 (es)
JP (1) JP5244969B2 (es)
KR (1) KR101281844B1 (es)
CN (1) CN102113293B (es)
CA (1) CA2726627C (es)
ES (2) ES2440344T3 (es)
HK (1) HK1151148A1 (es)
MX (1) MX2010013081A (es)
WO (1) WO2009149096A1 (es)

Families Citing this family (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8401002B2 (en) 2005-06-22 2013-03-19 Research In Motion Limited Exchange and use of globally unique device identifiers for circuit-switched and packet switched integration
CA2726627C (en) 2008-06-02 2014-01-21 Research In Motion Limited System and method for managing emergency requests
CN102098618A (zh) * 2010-12-30 2011-06-15 华为终端有限公司 一种自动确定求助联系人的方法以及终端
US9762662B2 (en) * 2011-05-12 2017-09-12 Microsoft Technology Licensing, Llc Mass re-formation of groups in a peer-to-peer network
EP2813044A1 (en) * 2012-02-07 2014-12-17 Telefonaktiebolaget L M Ericsson (publ) Session persistent data and method of use thereof
JP5559846B2 (ja) * 2012-07-25 2014-07-23 株式会社Ｎｔｔドコモ 移動通信システム、呼制御装置、移動局及び移動通信方法
WO2015039123A1 (en) * 2013-09-16 2015-03-19 Blackberry Limited System and method for maintaining privacy applied to communications caused by an emergency
US9274071B2 (en) * 2013-12-30 2016-03-01 General Electric Company Methods for assessing cell culture fluid by impedance spectra
EP3032800B1 (en) * 2014-12-08 2017-08-16 Alcatel Lucent Control and supervision of connected objects
WO2016208768A1 (ja) * 2015-06-26 2016-12-29 日本電気株式会社 通信装置、端末、及び通信方法
US9894504B2 (en) 2015-11-30 2018-02-13 Verizon Patent And Licensing Inc. Emergency call support for VoLTE roaming within S8 home routing architecture
CN107579945B (zh) * 2016-07-04 2021-05-04 中国移动通信有限公司研究院 Ims业务自动开通方法、装置及网元
LT3379790T (lt) * 2017-03-22 2019-12-10 Deutsche Telekom Ag Patobulinto paketinio komutuojamo avarinio iškvetimo tvarkymo telekomunikacijų tinkle ir (arba) patobulinto vietinės pagalbos tarnybos informacijos tvarkymo būdas, naudojant vartotojo įrangą, sistemą,vartotojo įrangą ir programą
US10433145B2 (en) 2017-12-22 2019-10-01 At&T Intellectual Property I, L.P. System and method for device-based E911 call trigger
WO2019133054A1 (en) * 2017-12-29 2019-07-04 Blackberry Limited Methods and systems for provisioning emergency numbers
WO2019197018A1 (en) * 2018-04-09 2019-10-17 Telefonaktiebolaget Lm Ericsson (Publ) Method and devices for handling uniform resource names for emergency services
CN111385784B (zh) * 2018-12-28 2021-08-27 展讯通信（上海）有限公司 紧急呼叫的通信建立方法及装置、网络设备、终端
US10805982B1 (en) 2019-04-29 2020-10-13 Blackberry Limited Supported extended emergency information type
US10757557B1 (en) 2019-07-17 2020-08-25 T-Mobile Usa, Inc. Practice emergency call system
US10904736B1 (en) * 2019-07-17 2021-01-26 T-Mobile USA, Ine. Practice emergency call system
FR3111507A1 (fr) * 2020-06-26 2021-12-17 Orange Procédé de traitement de messages échangés dans un réseau de télécommunication, par exemple en vue de leur analyse.

Family Cites Families (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3115268B2 (ja) 1997-10-08 2000-12-04 孝雄 三枝 緊急通報システム
CN1222807A (zh) * 1998-01-08 1999-07-14 摩托罗拉公司 基地小区的紧急呼叫系统和方法
US6184829B1 (en) 1999-01-08 2001-02-06 Trueposition, Inc. Calibration for wireless location system
US6766159B2 (en) 2000-03-10 2004-07-20 Nokia Mobile Phones Ltd. Alpha tagging and type indication of emergency call number
US6738808B1 (en) 2000-06-30 2004-05-18 Bell South Intellectual Property Corporation Anonymous location service for wireless networks
US6687504B1 (en) 2000-07-28 2004-02-03 Telefonaktiebolaget L. M. Ericsson Method and apparatus for releasing location information of a mobile communications device
DE60142450D1 (de) * 2001-04-27 2010-08-05 Nokia Corp Teilnehmerendgerät, netzwerkelement, und verfahren und kommunikationssystem zur herstellung einer notfallsitzung
JP2005525030A (ja) 2002-05-06 2005-08-18 ノキア コーポレイション 通信ネットワークにおいて特定形式のセッションを取り扱うシステム及び方法
CN1784910B (zh) 2003-03-14 2011-05-25 北方电讯网络有限公司 在无线通信网络中使用有关位置业务是紧急相关位置业务还是执法相关位置业务的指示来提供位置业务
US7177623B2 (en) 2003-07-02 2007-02-13 The United States Of America As Represented By The Secretary Of The Army Localized cellular awareness and tracking of emergencies
US7050785B2 (en) 2003-12-08 2006-05-23 Research In Motion Limited Apparatus and method of explicit indication of call from emergency call centre
US20060018272A1 (en) * 2004-07-20 2006-01-26 Nokia Corporation Instance identification
US7336962B2 (en) 2005-06-17 2008-02-26 Nextel Communications Inc. System and method for position equipment dusting in search and rescue operations
CN1889606B (zh) * 2005-06-30 2011-04-06 华为技术有限公司 一种分组域地理位置信息查询方法
US10178522B2 (en) 2005-08-02 2019-01-08 Qualcomm Incorporated VoIP emergency call support
EP1911257B1 (en) * 2005-08-02 2018-06-06 Qualcomm Incorporated Voip emergency call support
US7245900B1 (en) 2005-08-24 2007-07-17 Sprint Spectrum L.P. Method and system for using basic service set identifiers (BSSIDs) for emergency services routing
US20070117539A1 (en) 2005-11-23 2007-05-24 Research In Motion Limited Notification of a received message in a wireless mobile communication device based upon authentication
US7676234B2 (en) 2005-11-23 2010-03-09 Research In Motion Limited Routing of a short message originated by a mobile device
US20070143423A1 (en) 2005-12-21 2007-06-21 Oliver Kieselbach Method and system for allowing a session initiating user to select one or more privacy settings to be applied to an instant messaging session from among multiple possible privacy controls
US20070149166A1 (en) 2005-12-23 2007-06-28 Telefonaktiebolaget Lm Ericsson (Publ) Voice call continuity for emergency calls
US7710950B2 (en) 2006-02-06 2010-05-04 Research In Motion Limited System and methods for originating a SIP call via a circuit-switched network from a user equipment device
US7702081B1 (en) 2006-02-21 2010-04-20 Sprint Communications Company L.P. Call back number provisioning for emergency call services
CN101496387B (zh) 2006-03-06 2012-09-05 思科技术公司 用于移动无线网络中的接入认证的系统和方法
US8340626B2 (en) 2006-04-28 2012-12-25 Qualcomm Incorporated System and method for supporting voice call continuity for VOIP emergency calls
US8090830B2 (en) 2006-05-02 2012-01-03 Research In Motion Limited Apparatus, and associated method, for generating and transmitting an anonymous routing identifier to identify user agent
US20080008157A1 (en) 2006-07-06 2008-01-10 Edge Stephen W Method And Apparatus For Parallel Registration And Call Establishment
EP2053873A4 (en) 2006-08-16 2010-11-17 Huawei Tech Co Ltd EMERGENCY SERVICE TRANSMITTING / RECEIVING DEVICE METHOD
US8774370B2 (en) 2006-08-21 2014-07-08 Connexon Telecom Inc. System and method for delivering callback numbers for emergency calls in a VOIP system
CN101132623B (zh) * 2006-08-25 2011-08-10 华为技术有限公司 紧急业务处理方法及通信网络
US7668159B2 (en) 2007-04-25 2010-02-23 Research In Motion Limited Methods and apparatus for obtaining variable call parameters suitable for use in originating a SIP call via a circuit-switched network from a user equipment device
US9185216B2 (en) 2007-06-15 2015-11-10 Blackberry Limited System and method for indicating emergency call back to user equipment
US20090047922A1 (en) 2007-08-13 2009-02-19 Research In Motion Limited Apparatus, and associated method, for facilitating an emergency call session using a packet-switched-capable wireless device
JP5001436B2 (ja) 2008-01-10 2012-08-15 テレフオンアクチーボラゲット エル エム エリクソン（パブル） 通信ネットワークにおけるメッセージの処理
US8200185B2 (en) 2008-04-02 2012-06-12 Qualcomm Incorporated Method and apparatus for supporting emergency calls (eCalls)
CA2726627C (en) 2008-06-02 2014-01-21 Research In Motion Limited System and method for managing emergency requests
US9602552B2 (en) 2008-06-02 2017-03-21 Blackberry Limited Coding and behavior when receiving an IMS emergency session indicator from authorized source
US8478226B2 (en) 2008-06-02 2013-07-02 Research In Motion Limited Updating a request related to an IMS emergency session
US20090296689A1 (en) 2008-06-02 2009-12-03 Research In Motion Limited Privacy-Related Requests for an IMS Emergency Session

Also Published As

Publication number Publication date
CN102113293B (zh) 2016-08-03
CN102113293A (zh) 2011-06-29
US20160374117A1 (en) 2016-12-22
MX2010013081A (es) 2011-03-03
JP5244969B2 (ja) 2013-07-24
KR20110015654A (ko) 2011-02-16
US20160100435A1 (en) 2016-04-07
WO2009149096A1 (en) 2009-12-10
EP2260633B1 (en) 2012-08-15
US9814082B2 (en) 2017-11-07
US20190090303A1 (en) 2019-03-21
KR101281844B1 (ko) 2013-08-23
US10856359B2 (en) 2020-12-01
HK1151148A1 (en) 2012-01-20
ES2393301T3 (es) 2012-12-20
JP2011524674A (ja) 2011-09-01
EP2260633A1 (en) 2010-12-15
US9462616B2 (en) 2016-10-04
US10187924B2 (en) 2019-01-22
CA2726627C (en) 2014-01-21
CA2726627A1 (en) 2009-12-10
US20180042055A1 (en) 2018-02-08
US10631360B2 (en) 2020-04-21
US20200221537A1 (en) 2020-07-09

Similar Documents

Publication Publication Date Title
ES2440344T3 (es) Sistema y método para gestionar llamadas de emergencia
ES2392141T3 (es) Codificación y comportamiento cuando se recibe un indicador de sesión de emergencia de ims desde una fuente autorizada
US8755765B2 (en) System and method for managing emergency requests
US8369824B2 (en) Privacy-related requests for an IMS emergency session