ES2393301T3 - Sistema y método para gestionar solicitudes de emergencia - Google Patents
Sistema y método para gestionar solicitudes de emergencia Download PDFInfo
- Publication number
- ES2393301T3 ES2393301T3 ES09759255T ES09759255T ES2393301T3 ES 2393301 T3 ES2393301 T3 ES 2393301T3 ES 09759255 T ES09759255 T ES 09759255T ES 09759255 T ES09759255 T ES 09759255T ES 2393301 T3 ES2393301 T3 ES 2393301T3
- Authority
- ES
- Spain
- Prior art keywords
- emergency
- sip
- request
- dialogue
- network
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims description 76
- 230000004044 response Effects 0.000 claims abstract description 91
- 230000000977 initiatory effect Effects 0.000 claims abstract description 11
- 108010007100 Pulmonary Surfactant-Associated Protein A Proteins 0.000 claims description 6
- 102100027773 Pulmonary surfactant-associated protein A2 Human genes 0.000 claims description 6
- 230000006870 function Effects 0.000 description 27
- 230000015654 memory Effects 0.000 description 21
- 238000004891 communication Methods 0.000 description 18
- 238000005516 engineering process Methods 0.000 description 15
- 230000009471 action Effects 0.000 description 14
- 230000000007 visual effect Effects 0.000 description 14
- 238000012545 processing Methods 0.000 description 13
- 239000003795 chemical substances by application Substances 0.000 description 9
- 230000011664 signaling Effects 0.000 description 9
- 230000002596 correlated effect Effects 0.000 description 8
- 238000012986 modification Methods 0.000 description 8
- 230000004048 modification Effects 0.000 description 8
- 230000005540 biological transmission Effects 0.000 description 7
- 238000010586 diagram Methods 0.000 description 7
- 102000018059 CS domains Human genes 0.000 description 6
- 108050007176 CS domains Proteins 0.000 description 6
- 241001465754 Metazoa Species 0.000 description 6
- 230000000875 corresponding effect Effects 0.000 description 6
- 239000006185 dispersion Substances 0.000 description 6
- 239000012634 fragment Substances 0.000 description 6
- 238000013519 translation Methods 0.000 description 6
- 230000014616 translation Effects 0.000 description 6
- 230000008859 change Effects 0.000 description 5
- 238000006243 chemical reaction Methods 0.000 description 5
- 230000003993 interaction Effects 0.000 description 5
- 238000007792 addition Methods 0.000 description 4
- 238000012790 confirmation Methods 0.000 description 4
- 125000004122 cyclic group Chemical group 0.000 description 4
- 238000007726 management method Methods 0.000 description 4
- 230000007246 mechanism Effects 0.000 description 4
- 230000001413 cellular effect Effects 0.000 description 3
- 239000004973 liquid crystal related substance Substances 0.000 description 3
- 238000010295 mobile communication Methods 0.000 description 3
- 230000001105 regulatory effect Effects 0.000 description 3
- 238000012546 transfer Methods 0.000 description 3
- 101150002602 Psap gene Proteins 0.000 description 2
- 230000002159 abnormal effect Effects 0.000 description 2
- 230000006399 behavior Effects 0.000 description 2
- 238000013500 data storage Methods 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 238000012905 input function Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 230000002093 peripheral effect Effects 0.000 description 2
- 239000002574 poison Substances 0.000 description 2
- 231100000614 poison Toxicity 0.000 description 2
- 230000009467 reduction Effects 0.000 description 2
- 230000032258 transport Effects 0.000 description 2
- 230000001960 triggered effect Effects 0.000 description 2
- 241000134253 Lanka Species 0.000 description 1
- 241000699670 Mus sp. Species 0.000 description 1
- 230000004913 activation Effects 0.000 description 1
- 238000007630 basic procedure Methods 0.000 description 1
- 230000015572 biosynthetic process Effects 0.000 description 1
- 238000012508 change request Methods 0.000 description 1
- 208000001642 combined saposin deficiency Diseases 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 230000001143 conditioned effect Effects 0.000 description 1
- 239000004020 conductor Substances 0.000 description 1
- 238000001816 cooling Methods 0.000 description 1
- 239000013256 coordination polymer Substances 0.000 description 1
- 238000012937 correction Methods 0.000 description 1
- 230000008878 coupling Effects 0.000 description 1
- 238000010168 coupling process Methods 0.000 description 1
- 238000005859 coupling reaction Methods 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000006073 displacement reaction Methods 0.000 description 1
- 230000009977 dual effect Effects 0.000 description 1
- 230000008030 elimination Effects 0.000 description 1
- 238000003379 elimination reaction Methods 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- 238000010348 incorporation Methods 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 238000002222 matrix solid-phase dispersion Methods 0.000 description 1
- 238000002156 mixing Methods 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 239000013307 optical fiber Substances 0.000 description 1
- 230000000644 propagated effect Effects 0.000 description 1
- 238000012552 review Methods 0.000 description 1
- 238000013515 script Methods 0.000 description 1
- 230000001629 suppression Effects 0.000 description 1
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
- 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 aparato que comprende:un componente de red, configurado para:recibir desde un equipo de usuario ("UE") (110) un mensaje de petición de Protocolo de Inicio deSesión ("SIP") para un diálogo (140), que es una petición relacionada con una emergencia;enviar al UE (110) un mensaje (150) de respuesta de SIP que contiene un campo de cabecera deIdentidad-Declarada-P con un indicador (160) que indica que el mensaje de petición de SIP para undiálogo (140) es una petición relacionada con una emergencia; yrecibir del UE (110), en repuesta al mensaje (150) de respuesta de SIP, un mensaje de petición de SIPdentro del diálogo (170), de tal manera que el mensaje de petición de SIP contenido en el diálogo (170)contiene información (180) relacionada con una emergencia, asociada con el UE (110).
Description
Sistema y método para gestionar solicitudes de emergencia.
ANTECEDENTES
El Subsistema Multimedia de IP (Protocolo de Internet –“Internet Protocol”) (IMS –“IP Multimedia Subsystem”) es una arquitectura normalizada para proporcionar servicios multimedia y llamadas de voz sobre IP a equipo de usuario (UE –“user equipment”) tanto móvil como fijo. El Protocolo de Inicio de Sesión (SIP –“Session Initiation Protocol”) ha sido normalizado y gobernado fundamentalmente por el Grupo de Trabajo de Ingeniería de Internet (IETF –“Internet Engineering Task Force”) como protocolo para el establecimiento y la gestión de llamadas basadas en IMS. Tal y como se utiliza en la presente memoria, el término “UE” puede referirse a dispositivos móviles tales como teléfonos móviles, asistentes personales digitales, computadoras de mano o portátiles, así como dispositivos similares que tienen capacidades de telecomunicación. Un UE de este tipo puede consistir en un dispositivo inalámbrico y su Tarjeta de Circuito Integrado Universal (UICC –“Universal Integrated Circuit Card”), que incluye una aplicación de Módulo de Identidad de Abonado (SIM –“Subscriber Identity Module”), una aplicación de Módulo de Identidad de Abonado Universal (USIM –“Universal Subscriber Identity Module”) o una aplicación de Módulo de Identidad de Usuario Extraíble (R-UIM –“Removable User Identity Module”), o bien puede consistir en el dispositivo en sí, sin semejante tarjeta. El término “UE” puede referirse también a dispositivos que tienen capacidades similares pero que no son transportables, tales como teléfonos de línea fija, computadoras de sobremesa o cajas de equipo terminal. El término “UE” puede hacer referencia también a cualquier componente de hardware o de software que puede poner fin a una sesión de SIP.
El documento de Nokia Siemens Networks et al.: “Corrections for emergency procedures” (Correcciones para procedimientos de emergencia), 3GPP Draft [Borrador del 3GPP]; C1-072991_24229CR1997R2_EMC1_REL-8_ Procedure, 3RD Generation Partnership Project (3GPP –Proyecto de Sociedad de Tercera Generación), Mobile Compétanse Centre [Centro de Competencia Móvil]; 650, Route Des Lucioles; F-06921 Sophia-Antipolis Cedes; Francia, Vol. CT WG1, no. Sophia Antipolis, Francia; 20071112, 12 de noviembre de 2007 (), XP050027161, divulga diversas peticiones de cambio para las normas de 3GPP en el momento de su remisión, que hacen referencia a servicios de emergencia de IMS.
SUMARIO DE LA INVENCIÓN
En las reivindicaciones 1, 2, 17 y 18 se definen aspectos de la presente invención.
BREVE DESCRIPCIÓN DE LOS DIBUJOS
Para una comprensión más completa de esta invención, se hará ahora referencia a la siguiente descripción breve, tomada en conexión con los dibujos que se acompañan y con la descripción detallada, en la que los mismos números de referencia representan partes similares.
La Figura 1 es un diagrama de una red de IP ilustrativa que incluye un UE y un PSAP [Punto de Respuesta de Seguridad Pública –“Public Safety Answering Point”] de acuerdo con una realización de la invención.
La Figura 2 es un diagrama de una red de IP ilustrativa que incluye un UE y un PSAP de acuerdo con otra realización de la invenció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 invención.
La Figura 4 es un diagrama de un sistema de comunicaciones inalámbrico que incluye equipo de usuario susceptible de hacerse funcionar para algunas de las diversas realizaciones de la invención.
La Figura 5 es un diagrama de bloques de equipo de usuario susceptible de hacerse funcionar para algunas de las diversas realizaciones de la invención.
La Figura 6 es un diagrama de un entorno de programación o software que puede ser implementado en equipo de usuario susceptible de hacerse funcionar para algunas de las diversas realizaciones de la invención.
La Figura 7 es un sistema informático ilustrativo adecuado para algunas de las diversas realizaciones de la invención.
DESCRIPCIÓN DETALLADA
Ha de comprenderse desde el principio que, si bien se proporcionas en lo que sigue implementaciones ilustrativas de una o más realizaciones de la presente invención, los sistemas y/o métodos divulgados pueden ser implementados utilizando cualquier número de técnicas, ya sean conocidas en la actualidad o por conocer. La invención no debe estar limitada en ningún modo a las implementaciones ilustrativas, dibujos y técnicas que se ilustran más adelante, incluyendo los diseños proporcionados a modo de ejemplo y las implementaciones que se ilustran y describen en esta memoria, sino que puede modificarse dentro del ámbito de las reivindicaciones que se acompañan, junto con su ámbito completo de equivalentes.
En una realización, se proporciona un equipo de usuario. El equipo de usuario incluye un componente tal, que, en respuesta a la realización de una petición o solicitud de emergencia que es rechazada, el componente se ha configurado para recibir un mensaje que contiene información que asocia la solicitud de emergencia con una central de emergencias combinada.
En otra realización, se ha proporcionado un componente de red que incluye un componente tal, que, al recibir una solicitud de emergencia procedente de un equipo de usuario, el componente se ha configurado para determinar si la solicitud de emergencia está relacionada con una central de emergencias combinada y para enviar al equipo de usuario un mensaje que contiene información que indica que la solicitud de emergencia se ha relacionado con una central de emergencias combinada.
Un usuario de un UE, tal como un UE con capacidad para IMS, puede realizar, por lo común, una llamada de emergencia marcando el 911 (en Norteamérica), el 112 (en la mayor parte de Europa), el 999 (en el Reino Unido), 110, 118 o 119 (Japón), o algún otro número específico para emergencias. Semejante llamada puede ser manejada por un Punto de Respuesta de Seguridad Pública (PSAP –“Public Safety Answering Point”), que puede consistir en una central de llamadas de emergencia o en un sistema que puede coordinar una respuesta apropiada a la emergencia. Se hará referencia en la presente memoria a cualquier llamada que se haga a un PSAP como una llamada de emergencia. En este documento, un PSAP puede también ser una central de emergencia o centrales de emergencia.
En algunos casos, un UE puede no percatarse de que una llamada que se ha realizado era una llamada de emergencia. Por ejemplo, un UE fabricado para utilizarse en Norteamérica puede haberse programado para reconocer que una llamada al 911 es una llamada de emergencia. Si un UE de este tipo se lleva a un país en el que se utiliza un número distinto del 911 para las llamadas de emergencia, y el usuario del UE marca ese otro número de emergencia, el UE puede no reconocer que la llamada es una llamada de emergencia. Pueden producirse consecuencias no deseadas si el UE no reconoce que una llamada es una llamada de emergencia. Por ejemplo, el UE puede fallar a la hora de proporcionar información relevante al PSAP, el UE puede tratar la llamada como una llamada normal y colocarla en suspenso o en espera de llamadas, la llamada puede ser bloqueada, o bien el UE puede fallar de otro modo a la hora de tratar la llamada apropiadamente. Además, la red puede no aplicar un tratamiento especial, por ejemplo, en una red o celda congestionada, y la llamada de emergencia que no se ha reconocido puede no ser sometida a procedimientos de llamada de emergencia (por ejemplo, puede no recibir prioridad).
La presente invención hace posible la indicación a un UE de que una llamada que ha efectuado el UE era una llamada de emergencia de IMS, al incluir en un mensaje para el UE un indicador de que la llamada era una llamada de emergencia. El indicador puede ser incluido en un mensaje de SIP que puede estar limitado, pero no lo está, a un mensaje 2xx de SIP o 1xx de SIP enviado al UE en respuesta a una petición de SIP inicial de un diálogo otransacción aislada o única, o a un método desconocido (por ejemplo, una petición de INVITACIÓN DE SIP) o un mensaje similar, que el UE envía al intentar establecer la llamada de emergencia. En lo sucesivo, el término“mensaje de SIP” puede referirse a una petición de SIP (incluyendo, por ejemplo, una petición de re-INVITACIÓN o una petición de refrescamiento de Objetivo para un diálogo o una petición de SIP inicial de un diálogo o transacción aislada, o bien un método desconocido) o una respuesta de SIP. Ha de apreciarse que la petición del método de re-INVITACIÓN tan solo puede enviarse cuando se satisfacen las condiciones documentadas en la Petición de Comentarios (RFC –“Request for Comments”) del Grupo de Trabajo de Ingeniería de Internet (IETF –“Internet Engineering Task Force”) 3261. El mensaje de SIP que incluye el indicador puede ser enviado por el PSAP o por un componente de una red a través del cual se comunican el PSAP y el UE entre sí. Ejemplos de tales componentes son l P-CSCF y el E-CSCF.
El indicador relativo a las emergencias puede ser codificado en SIP utilizando las siguientes alternativas: a) cuerpos de SIP tales como “application/3gpp-ims+xml” (aplicación/3gpp-ims+xml) se han venido utilizando en el IMS para indicar información adicional o directivas para recibir UAs. Es posible extenderlo para que indique también al UEque, al recibir la entrada de una INVITACIÓN o petición similar, la petición ha de ser considerada como una llamada de emergencia o una devolución o retorno de llamada de PSAP, y que se ha de recurrir a la capacidad funcional asociada con las llamadas de este tipo. Esta capacidad funcional puede incluir la alerta al usuario por métodos visuales, audibles u otros, así como incluir información de posición en la respuesta, aunque no está limitada a estas funciones. Puede ser necesario definir un nuevo valor de campo de cabecera de disposición de contenidos. b) Puede definirse una nueva cabecera de SIP, o bien puede mejorarse una cabecera de SIP ya existente. El propio PSAP o el S-CSCF que maneja el retorno de llamada del PSAP en representación del PSAP u otro elemento de red tal como una pasarela de intercambio de señales, o señalización, puede introducir un indicador. c) El indicador puede ser un nuevo campo de cabecera de SIP. d) El indicador puede consistir en un nuevo valor de campo de cabecera de SIP, por ejemplo, un URN [nombre de recursos uniformes –“Uniform Resource Name”] de SIP normalizado que indica la función de PSAP (por ejemplo, rescate en montaña o guardia costera, o un 911 general) o una función de central de emergencias, o bien un función de personal de emergencias. e) El indicador puede ser un nuevo campo de URI [identificador de recursos uniformes –“Uniform Resource Identifier”]. f) El indicador puede ser un nuevo valor de campo de URI, por ejemplo, usuario = psap, donde ‘usuario’ es un campo de URI de SIP y ‘psap’ es un nuevo valor que puede ser emplazado dentro del campo de cabecera de Contacto. g) El URN de SIP normalizado puede ser colocado en la Identidad-Declarada-P (“P-Asserted-Identity”) por el dominio de confianza en el que reside el PSAP o la central de emergencias o el personal de emergencias. h) El indicador puede estar contenido en el valor de campo de cabecera de FROM, y el valor de campo de cabecera de FROM puede ser declarado de conformidad con la RFC 4474 o con la RFC 3893. Esta solución está basada en certificados.
Como se ha indicado anteriormente, es posible utilizar diversas posibilidades para indicar que una sesión es, en efecto, una sesión de emergencia. Se ha destacado que el PSAP puede estar en una red visitada, tal como una red VPLMN, y que no tiene ninguna relación de confianza con la red doméstica, tal como una HPLMN (Red Móvil Terrestre Pública Doméstica –“Home Public Land Mobile Network”). Suponiendo que este es el caso cuando el UE está estableciendo una sesión de emergencia que el UE no reconoce, o cuando se recibe una petición de terminación de comunicación móvil que contiene una indicación en el mensaje de SIP (por ejemplo, respuestas 1xx
o 2xx o una petición de refrescamiento de objetivo de SIP, o bien un mensaje similar) referente a que la petición es un retorno de llamada del PSAP, el PSAP o la red puede también enviar de vuelta un símbolo o testigo que almacenará el UE. La red puede proporcionar este testigo cuando el UE se registra con el subsistema de red de núcleo (CN –“core network”) de IM. El testigo puede ser almacenado en una memoria, la cual puede ser interna o extraíble. En el caso de que la llamada de emergencia sea desconectada o apagada o el UE necesite ser informado de que está solicitando una sesión de emergencia, la red o el PSAP pueden incluir este testigo. Al recibirse el testigo desde la red, el UE puede compararlo con el testigo compartido. Si los testigos no coinciden, el UE sabe que la llamada no está relacionada con una emergencia.
El campo de cabecera de “prioridad” de SIP ajustado en “emergencia” no ha sido utilizado hasta ahora como un indicador de confianza para una llamada de emergencia [RFC 3261]. La base instalada de UAs de SIP tendrá un tratamiento divergente y diferente para esta cabecera, si es que hay tratamiento.
En el caso de que el retorno de llamada del PSAP o la respuesta de señalización de llamada de emergencia se reciba a través de una red Conmutada en Circuitos, la solución puede permitir establecer una relación de correspondencia o correlación entre campos de Categoría de Llamante (“Calling-Party-Fields”) que se utiliza en ocasiones para portar la indicación de una llamada de emergencia en sistemas basados en ISUP / TUP (Parte de Usuario de ISDN –“ISDN User Part” / Parte de Usuario de Telefonía –“Telephone User Part”). Por lo común, la información de señalización de ISUP / TUP no permite una granularidad tan fina como los identificadores urn:service:sos definidos en la RFC 5031.
La Figura 1 ilustra un sistema 10 que incluye uno o más componentes asociados con una red 120 de IMS. Un UE 110 puede ser cualquier dispositivo o sistema de usuario final que pueda conectarse con la red 120 de IMS. Ejemplos del UE 110 pueden incluir teléfonos móviles, teléfonos de línea fija, dispositivos inalámbricos móviles (incluyendo dispositivos digitales, celulares o de modo dual), asistentes personales digitales (“personal digital assistants”), computadoras portátiles / del tipo de tableta / del tipo de agenda o de mano, y computadoras de sobremesa. El UE 110 puede comunicarse a través de la red 120 de IMS con un PSAP 130, el cual puede consistir en un sistema de 911 u otra central o sistema de llamadas de emergencia.
La red 120 de IMS puede incluir cualquier conjunto de componentes bien conocido, tal como estaciones de base y otro equipo de transmisión y recepción de radio que puedan promover una conexión basada en IMS entre el UE 110 y el PSAP 130. Otros componentes que pueden estar presentes en la red 120 de IMS pero que no se muestran incluyen una P-CSCF (Función de Control de Sesión de Llamada de Representante –“Proxy Call Session Control Function”), que puede ser el primer punto de contacto para el UE 110; una CSCF (CSCF en Servicio –“Serving CSCF”) que puede llevar a cabo el control de la sesión, la carga y la descarga de perfiles de usuario así como otras funciones; una E-CSCF (CSCF de Emergencia –“Emergency CSCF) que puede proporcionar funciones de control de sesión para el PSAP 130; y otros componentes bien conocidos para iniciar y mantener sesiones basadas en IMS.
Para realizar una llamada de emergencia, el UE 110 puede enviar una petición de SIP inicial para un diálogo otransacción aislada, o método desconocido (por ejemplo, una petición de INVITACIÓN DE SIP) 140, o un mensaje de invitación similar, al PSAP 130 a través de la red 120 de IMS. El PSAP 130 responde, típicamente, al mensaje de invitación 140 con un mensaje 150 de respuesta 1xx de SIP o 2xx de SIP (por ejemplo, CONFORMIDAD 200 DE SIP –“SIP 200 OK”), o un mensaje de respuesta similar. Alternativamente, el PSAP 130 puede transmitir una peticiónde refrescamiento de objetivo (por ejemplo, una petición de re-INVITACIÓN). Pueden seguirse entonces los procedimientos estándares de SIP 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 efectuada por el UE 110 era una llamada de emergencia. El indicador 160 puede ser un bit, una etiqueta o distintivo o algún otro elementos de datos que sea reconocible por el UE como una designación de que una llamada efectuada por el UE 110 era una llamada de emergencia (por ejemplo, URNs de servicio de emergencia según se especifica en la RFC 5031, tal como el urn:service:sos [urn:servicio:sos], el urn:service:sos.animal-control [urn:servicio:sos.control-animal],
o el urn:service:sos.police [urn:servicio:sos.policía], si se determina que la llamada que se realizó puede ser clasificada como, por ejemplo, una llamada de urn:service:sos, una llamada de urn:service:sos.animal-control, o una llamada de 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 que realizó era una llamada de emergencia de IMS y puede entonces adoptar las acciones apropiadas y apelar o recurrir a la capacidad funcional para una llamada de emergencia. Una de las acciones que puede adoptar el UE 110 consiste en indicar al usuario del UE la naturaleza de la llamada inicial. Es decir el UE 110 puede alertar al usuario de que la llamada era una llamada de emergencia. La alerta puede consistir en un mensaje que aparece en la pantalla de presentación visual del UE 110, una alerta visual o audible, o algún otro tipo de estado del entorno o indicación de la naturaleza de la llamada. Otras acciones adoptadas por el UE 110 pueden implicar la transmisión de un mensaje de petición 170 de SIP, tal como un mensajede CONFIRMACIÓN DE SIP (“SIP ACK”) o “SIP RACK”, o cualquier parte de petición de SIP subsiguiente del diálogo (incluyendo peticiones de refrescamiento de objetivo) o petición de nuevo diálogo, de tal manera que la petición del diálogo se sirve del campo de cabecera de Diálogo de Objetivo de SIP (“SIP Target-Dialog”) con un conjunto de valores idénticos al valor del identificador de diálogo correspondiente para la sesión de emergencia. En el caso de enviar una petición de un nuevo mensaje de diálogo 170 con el conjunto de campo de cabecera de Diálogo de Objetivo de SIP, este puede indicar al destinatario que el remitente está al corriente de un diálogo existente con el destinatario, ya sea debido a que el remitente se encuentra al otro lado del diálogo, ya sea porque ha accedido a los identificadores del diálogo, y el destinatario puede entonces autorizar la petición basándose en esta constatación. Dentro de las limitaciones del SIP, alguno de estos mensajes puede incluir información dentro de la petición como parte de la información disponible para el PSAP 130 en el caso de que el destinatario sea el PSAP
130. Como ya se ha mencionado, el mensaje 170 puede ser una petición de refrescamiento de objetivo de SIP, unaACTUALIZACIÓN DE SIP, un mensaje 170 de re-INVITACIÓN DE SIP o un mensaje similar (de confirmación) (por ejemplo, PRACK DE SIP). El mensaje 170 puede incluir información 180 acerca del UE 110, que se describirá en detalle más adelante. Debido a las limitaciones en el protocolo SIP, la información 180 puede ser repartida en varios mensajes de SIP; por ejemplo, cierta información puede estar en peticiones de PRACK DE SIP, cierta en respuestas a las peticiones originadas en el PSAP o en la red, o a peticiones de ACTUALIZACIÓN DE SIP (“SIP UPDATE”), y alguna más en otras peticiones de refrescamiento de objetivo de SIP. La información 180 puede estar destinada al PSAP 130 o a uno o más componentes de la red 120 de IMS. La información 180 puede incluir, opcionalmente, una etiqueta u otro indicador que indique que cierta información relacionada con una emergencia, tal como información de identificación, de acceso a red o de posición, no ha de ser compartida (por ejemplo, con el PSAP 130). Si se establecen uno o más indicadores de privacidad, la red podría aún ser capaz de utilizar la información la información relacionada con una emergencia para el encaminamiento de propósitos o para proporcionar una devolución o retorno de llamada anónimo.
En otra realización, puede almacenarse una política o criterio en el UE 110. El criterio o criterios pueden ser utilizados para determinar si se permite la inclusión de uno o más indicadores para solicitar privacidad cuando un PSAP realiza una llamada de vuelta o un retorno de llamada, o si se permite solicitar privacidad cuando se proporciona información relacionada con una emergencia en respuesta a una llamada de vuelta del PSAP. Puede consultarse el criterio cuando el UE 110 desea divulgar información que es delicada en cuanto a la privacidad, tal como la posición, aunque no está limitada por esta. El criterio puede ser proporcionado por el usuario, proporcionarse por el operador, o ambas posibilidades. Cuando la información es proporcionada tanto por el usuario como por el operador, el operador puede proporcionar un criterio por defecto, pero el usuario puede ser capaz de prevalecer sobre este criterio si desea hacerlo así. El criterio puede ser almacenado en la memoria, la cual es interna o externa con respecto al dispositivo.
Cabe la posibilidad de que el criterio / preferencia pueda ser establecido de una forma que sea contraria a los requisitos regulatorios del PSAP. Por ejemplo, el UE 110 puede proceder de un país en el que es capaz de escoger si proporcionar o no información relativa al usuario o relativa a un suceso, y el criterio / preferencia puede establecerse de tal manera que la información no será proporcionada. Alternativamente, el criterio / preferencia puede establecerse de tal modo que la información pueda ser proporcionada (por ejemplo, para los propósitos de determinar el PSAP más próximo), pero puede realizarse una petición de que no se entregue la información. El UE 110 puede, subsiguientemente, ir a un país en el que, por ley, debe proporcionarse la información si se dispone de ella. En tales casos, la red puede señalizar al UE 110 que se ha ignorado o relegado la preferencia y que se ha de proporcionar la información. Esta notificación de la relegación puede ser indicada como un símbolo o testigo dentro de un mensaje procedente de la red. Por ejemplo, un mensaje de SIP puede contener un testigo que se ha codificado como una nueva etiqueta de característica, un nuevo parámetro de URI, un cuerpo de XNL, un parámetro de SDP [procesador de señal digital –“signal digital processor”] o una característica de codificación similar. El testigo puede también requerir la propiedad de poder ser de confianza para el UE 110.
Lo que sigue ilustra una posible realización del modo como puede comportarse el UE 110.
El procedimiento básico será:
Ajuste de Criterio / Preferencia
Mensaje recibido desde la red, que contiene un testigo de relegación Consultar preferencia / criterio
Permitir proporcionar información de posición
No se permite; determinar si se ha recibido indicador
El testigo recibido averigua la autenticidad del testigo y, si es válido, proporcionar información de posición
Si el testigo recibido es falso, proporcionar indicación a la red de que se ha recibido un testigo falso; no proporcionar información de posición.
El testigo puede ser portado en una llamada procedente del PSAP 130, tal como una INVITACIÓN DE SIP. Alternativamente, el testigo puede ser proporcionado en el momento en que el UE 110 efectúa su registro con la red 120, de tal manera que, en el IMS, el testigo puede ser proporcionado en un mensaje 200OK (CONFORMIDAD200) en respuesta a un registro de emergencia. Con el 200OK, si el testigo se ha codificado como una nueva etiqueta de característica, un nuevo parámetro de URI o un cuerpo de XML, el testigo puede ser un testigo seguro. En una red de LTE/SAE, el mensaje 200OK puede ser transmitido en respuesta a una petición para engancharse a la red o como parte de la secuencia de autentificación del UE 110.
Otra realización consiste en que el criterio de VPLMN puede ser radiodifundido en un mensaje de sistema que indica el comportamiento del UE en caso de que este reciba una llamada de vuelta o retorno de llamada de emergencia.
La facilitación del criterio puede llevarse a cabo de una de las siguientes maneras, aunque sin limitarse a ellas: OMA DM, CP, OTA, en propiedad u otras. A la hora de ser aportado, es posible utilizar cualquiera de los siguientes medios de transporte: Radiodifusión celular (“Cell Broadcast”), SMS, USSD, MBMS, conducción de IP genérica (“Generic IP pipe”) u otros.
El criterio puede ser almacenado en una memoria interna o externa. La memoria externa puede ser PC Card PCMCIA [tarjeta de PC PCMCIA], CompactFlasch I CF-I, CompactFlash II CF-II, SmartMedia SM/SMC, Memory Stick MS [lápiz de memoria MS], Memory Stick Duo MSC, Memory Stick PRO Duo MSPD, Memory Stick PRO-HG Duo MSPDX, Memory Stick Micro M2, Multimedia Card MMC [tarjeta multimedia MMC], Multimedia Card RS-MMC [tarjeta multimedia RS-MMC], MMCmicro Card MMCmicro [tarjeta MMCmicro], Secure Digital Card SD [tarjeta digital segura SD], SxS SxS, Universal Flash Storage UFS [dispositivo de almacenamiento de tipo flash universal UFS], miniSD Card miniSD [tarjeta miniSD], microSD Card microSD [tarjeta microSD], xD-Picture Card xD [tarjeta de imagen xD], Intelligent Stick iStick [lápiz inteligente iStick], Serial Flash Module SFM [módulo de tipo flash en serie SFM], !Card !Card [microtarjeta !Card], NT Card NT NT+ [tarjeta NT NT+], USIM, R-UIM, etc., aunque no esta limitada por estas.
En una realización de la información de criterio, existirá un archivo en la memoria extraíble que consiste en ocho bits por cada archivo. El bit 1 (el bit menos significativo (“the Least Significant Bit”)) puede ser ajustado en 1 para indicar que se ha de proporcionar información de posición, o bien en 0 con el fin de indicar que no se ha de proporcionar la información de posición. Los siete bits restantes pueden ser reservados (RFU). El archivo de preferencia del usuario puede estar bajo el control del PIN [Número de Identificación Personal –“Personal Identification Number”] (es decir, el usuario puede, después de haber introducido el PIN, controlar el contenido del archivo), y el archivo del operador puede estar bajo el control de ADM (Administrativo), con lo que se impide que cualquier tercero distinto del administrador (el emisor de la tarjeta, habitualmente el portador) altere el contenido del archivo.
En diversas realizaciones, el criterio puede ser implementado en diferentes formatos. En lo que sigue se proporciona un ejemplo de un formato para el criterio, pero los formatos no deben estar limitados por este ejemplo, puesto que se contemplan otros formatos.
/<X>/Criterio de Localización de Emergencia bajo retorno de llamada de PSAP/
(/<X>/Emergency Location Policy upon PSAP call back/)
El pliego de Criterios de Emergencia indica si el UE proporciona información de emergencia o no para un retorno de llamada de emergencia.
- •
- Ocurrencia: Uno
- •
- Formato: booleano
- •
- Tipos de acceso: Obtener, Reemplazar
(Access Types: Get, Replace)
- •
- Valores: 0, 1 (Values: 0, 1) 0 –UE proporciona información de emergencia. 1 –UE no proporciona información de emergencia. <Nodo> (<Node>)
(Occurrence: One)
(Format: bool)
<NombreNodo> criterio Posición Emergencia </NombreNodo>
(<NodeName> Emergency Location policy </NodeName>)
<PropiedadesDF>
(<DFProperties>)
<TipoAcceso>
(<AccessType>) <Obtener/> (<Get/>) <Reemplazar/> (<Replace/>)
</TipoAcceso> <FormatoDF>
<booleano/>
</FormatoDF>
<Ocurrencia>
<Uno/>
</Ocurrencia>
<TítuloDF> criterio Posición de Emergencia </TítuloDF>
(<DFTitle> Emergency Location policy </DFTitle>)
<TipoDF>
(<DFType>)
<MIME>texto/lleno/MIME> (<MIME>text/plain>/MIME>)
</TipoDF>
</PropiedadesDF>
(</DFProperties>)
</Nodo Como se ha mencionado anteriormente, cuando el UE 110 recibe el mensaje de respuesta 150 que incluye el indicador 160, el UE 110 puede transmitir información 180 acerca de sí mismo al PSAP 130. Si el criterio lo permite, un trozo o fragmento de la información 180 que el UE 110 puede incluir en el mensaje 170 de SIP lo constituyen las identidades de usuario públicas del UE (tales como el URI de Tel, el URI de SIP, o el Número de ISDN internacional
de Estación Móvil (MSISDN –“Mobile International ISDN Number”)), o bien algún otro símbolo de identificación. La inclusión de tal información puede estar sometida al criterio o puede ser acompañada por un indicador de que la información privada no se está compartiendo con el PSAP o la central de emergencias, ni con elementos de red en los que no se tiene confianza. Las identidades de usuario públicas pueden estar en formato de GRUU o pueden contener información suficiente de que es posible una llamada de vuelta o retorno de llamada por tecnología de Conmutación en Circuitos, por ejemplo, en el formato de URI. El PSAP 130 puede utilizar el identificador para hacer una llamada de vuelta al UE 110 en caso necesario, según se describe más adelante. Otro fragmento de información 180 que el UE 110 puede transmitir en el mensaje de confirmación 170 es el tipo de acceso que está utilizando el UE 110. Por ejemplo, si la llamada de emergencia se está realizando por una red de área local (LAN –“local area network”) inalámbrica, el UE 110 puede incluir este hecho en la información 180, así como un ID de celda, un ID de línea y/o un ID de nodo de acceso a LAN inalámbrica. Durante el diálogo, los puntos de enganche a la Red de Acceso con Capacidad de Conexión de IP (IP-CAN –“IP-Connectivity Access Network”) del UE pueden cambiar (por ejemplo, el UE se conecta a diferentes células). El UE puede poblar la cabecera de Información de Red de Acceso P (“P-Access-Network-Info”) en cualquier petición o respuesta, dentro de un diálogo para el que se da soporte a latransmisión de tal información (por ejemplo, excluyendo peticiones de CONFIRMACIÓN (“ACK”) y peticiones deCANCELACIÓN (“CANCEL”), con el punto de enganche en ese momento a la IP-CAN (por ejemplo, la información de la celda en curso en ese momento).
Si el UE 110 está al corriente de posición geográfica, por ejemplo, mediante el uso de un sistema de localización global (GPS –“global positioning system”), el UE 110 puede incluir su posición como otro trozo o fragmento de la información 180, tal como la Identidad Global de Celda (CGI –“Cell Global Identity”), el Identificador de Conjunto de Servicios (SSID –“Service Set Identifier”), puntos de paso tales como puntos o hitos de referencia, así como la intensidad de señal de las celdas adyacentes, con las CGIs correspondientes, si bien no está limitado por estos. En caso de que el UE 110 no esté al corriente de su posición geográfica, no se incluyen en la información 180 datos referentes a la posición. Si un URI (identificador de recursos uniformes –“uniform resource identifier”) de GRUU (UA (agente de usuario –“user agent”) susceptible de ser encaminado globalmente –“globally routable UA”) está asociado con el UE 110, el GRUU del UE puede ser incluido como otro fragmento de la información 180. Dependiendo de los ajustes de privacidad del usuario, el GRUU puede ser un P-GRUU o un T-GRUU, si bien se prefiere un GRUU público (P-GRUU –“public GRUU”) sobre un GRUU temporal (T-GRUU –“temporary GRUU”).
Otros elementos que pueden incluirse en la información 180 pueden incluir las capacidades del UE 100, la tecnología de acceso por radio que se está utilizando por el UE 110, el tiempo de vida 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 puede también recurrir o apelar a lo que se conoce comúnmente como capacidad funcional de llamada electrónica (“ecall”) para que sea enviada al PSAP 130.
Antes de que la solicitud de emergencia llegue al PSAP 130, pueden hacerse cargo de ella uno o más componentes de la red 120 de IMS. Ejemplos de tales componentes son la P-CSCF, E-CSCF, AS e IBCF (Función de Control de Frontera de Interconexión –“Interconnect Border Control Function”). Un componente de red de IMS, tal como la P-CSCF, AS y E-CSCF, puede inspeccionar todas las solicitudes al objeto de determinar si están relacionadas con emergencias. Si se determina que una solicitud está relacionada con una emergencia, basándose en las configuraciones y en los criterios reguladores, el componente de red puede determinar el rechazo de la solicitud o actualizar la solicitud, o bien incluir el indicador 160 de llamada de emergencia en una respuesta de SIP que es enviada al UE 110. La actualización de la solicitud puede llevarse a cabo si el UE proporciona un T-GRUU y los ajustes de los criterios de operador de red (por ejemplo, en la P-CSCF) indican que deben proporcionarse las identidades de usuario públicas. En tal caso, el T-GRUU puede ser reemplazado por el GRUU. Además, puede realizarse la actualización de los mensajes que se han de encaminar a los PSAPs si el mensaje contiene campos de cabecera de Servicio-Preferido-P (“P-Preferred-Service”), campos de cabecera de Servicio-Declarado-P (“PAsserted-Service”), campos de cabecera de Aceptar-Contacto (“Accept-Contact”) que contienen uno o más valores de Identificador de Servicio de Comunicación de IMS (ICSI –“IMS Communication Service Identifier”) (codificados como especificados en la subclase 7.2A.8.2 de la TS [Especificación Técnica –“Technical Specification”] de 3GPP 24.229), o uno o más valores de Identificador de Referencia de Aplicación de IMS (IARI –“IMS Application Reference Identifier”) (codificados según se especifica en la subclase 7.2A.9.2 de la TS de 3GPP 24.229) que están relacionados con la solicitud en una etiqueta de característica g.3gpp.app_ref. Nótese que el elemento de red puede estar desempeñando un papel de Agente de Usuario de Mutuo Respaldo (B2BUA –“Back to Back User Agent”) o de representante a la hora de actualizar estas peticiones o respuestas de SIP. Es de apreciar que si el elemento de red es un AS, existe la necesidad de un nuevo punto de referencia entre el AS y al menos una de la IBCF, la E-CSCF o la P-CSCF, puesto que, en ese momento, tan solo hay un único punto de referencia para el control del servicio entre el AS y la S-SCSF o la I-CSF. Los campos de cabecera de Servicio-Preferido-P así como los campos de cabecera de Servicio-Declarado-P no deben ser remitidos al PSAP o a la central de emergencias. Los campos de cabecera de Aceptar-Contacto han de ser aprestados para los valores de ICSI y para los valores de IARI, ya que pueden provocar interacciones cuando se selecciona un agente de usuario de SIP que pone fin a la sesión en el PSAP. Si el campo de cabecera de Aceptar-Contacto contiene etiquetas de características de medios g.3gpp.app_ref, estas y sus valores serán eliminados. Si el campo de cabecera de Aceptar-Contacto contiene etiquetas de IARII de características de medios g.3gpp.app_ref, estas y sus valores serán eliminados.
En otras palabras, lo que se ha dado en llamar “actualización” puede incluir cambiar el GRUU de un GRUU temporal a un GRUU público. Eso se hace porque un GRUU temporal no es válido si el UE se ha desconectado y tiene que volver a registrarse. Un PSAP no puede hacer una llamada de vuelta a un GRUU temporal después de que el UE se haya desregistrado y vuelto a registrar. Los GRUUs públicos, por otra parte, tienen la propiedad de que son susceptibles de ser encaminados incluso después de que el UE se desregistre y se registre de nuevo (lo que hace que una llamada de vuelta del PSAPD a ese GRUU público tenga una mayor probabilidad de completarse). La “actualización” puede también incluir la no propagación de etiquetas de características de ICSI o de IARI, campos de cabecera de Servicio-Preferido-P y/o campos de cabecera de Servicio-Declarado-P. La presencia de tales etiquetas
o campos puede distorsionar el manejo de la petición en el PSAP y provocar que la petición sea encaminada basándose en servicios a los que se da soporte en el UE, en lugar de, por ejemplo, en el servicio de proximidad geográfica y tipo solicitados. Puesto que no hay, por lo común, ninguna S-SCSF ni tampoco ningún Servidor de Aplicación (de Telefonía Multimedia) en el recorrido o trayecto de la sesión entre el UE, la P-CSCF la E-CSCF y el PSAP, estos servicios a los que el UE da soporte no están, por lo común, disponibles durante la llamada de emergencia. De manera que el hecho de señalizarlos como parte de una solicitud de emergencia (incluso cuando el UE no se ha dado cuenta de que se trata de una llamada de emergencia e incluye etiquetas de características de ICSI o IARI, campos de cabecera de Servicio-Preferido_P y/o campos de cabecera de Servicio-Declarado-P, debido a que cree que la petición que realiza es una petición normal) no sirve a ningún propósito y tan solo puede desvirtuar / tener el resultado de que las solicitudes sean encaminadas a otros PSAPs o Agentes de Usuario de PSAP distintos de los determinados basándose en la posición, en el tipo de servicio solicitado y en los procedimientos de la RFC 3261. En el peor escenario posible, si un Agente de Usuario de PSAP registra su soporte para dichos servicios, puede recibir una carga más alta de peticiones de servicios de emergencia que otros Agentes de Usuario de PSAP, lo que conducirá, posiblemente, a un retraso en la respuesta a la emergencia.
En las realizaciones en las que un componente de la red 120 de IMS rechaza la solicitud de servicio de emergencia, este puede responder con un mensaje 3xx de SIP, tal como el mensaje 300 (Múltiples Opciones), el 301 (Trasladado Permanentemente), el 302 (Trasladado Temporalmente), el 380 (Servicio Alternativo), o bien una respuesta 4xx de SIP o una respuesta 6xx de SIP. Se utiliza un 380 (Servicio Alternativo) de SIP preferiblemente para indicar que el UE ha de intentarlo con otra tecnología de acceso, tal como CS, o utilizar / crear otro contexto / registro seguro, tal como el contexto creado por el registro de emergencia. El mensaje puede también utilizarse para informar al UE de que no utilice el contexto presente (que puede haber sido creado como resultado de un registro de emergencia).
Los que siguen son casos en que la red puede haberse configurado para rechazar la solicitud: a) la red no es capaz de hacerse cargo de sesiones de emergencia; b) el subsistema de CN de IM al que pertenece la P-CSCF no es capaz de hacerse cargo de sesiones de emergencia; c) debido a los criterios locales, la red no se hace cargo de sesiones de emergencia; d) la red solo se hace cargo de ciertos tipos de peticiones de sesión de emergencia; e) el UE se encuentra en desplazamiento itinerante; f) la P-CSCF se encuentra en una red distinta de la red del operador doméstico del UE; g) la red no da soporte a sesiones de emergencia para alguna ubicación geográfica en la que se encuentra ubicado el UE o la IP-CAN a la que está enganchado el UE.
Ha de apreciarse que una repuesta de redireccionamiento 3xx puede ser válida o susceptible de encaminarse únicamente en la red enganchada en ese momento. Por ejemplo, el urn:service:sos.animal-control puede ser válido en el libro de direcciones únicamente para algunas redes a las que puede engancharse / con las que puede registrarse el UE 110. El uso de una dirección del libro de direcciones puede estar condicionado al operador o a la región a la que se ha enganchado / con la que se ha registrado el UE 110. Una respuesta 3xx que obliga al UE a utilizar otra dirección para esta petición relacionada con una emergencia o una petición de la que se ha determinado que no está relacionada con una emergencia, no debe ser seguida por un simple cambio de la entrada correspondiente en el libro de direcciones, si está presente en el libro de direcciones.
Dos ejemplos pueden ilustrar casos en los que la red rechaza la petición porque no se da soporte al tipo de solicitud de sesión de emergencia. En el primer ejemplo, la RFC 5031 define el urn:service:sos.animal-control como sigue: el control de los animales hace cumplir las leyes y las ordenanzas pertenecientes al control y la gestión de los animales, investiga casos de maltrato a los animales, educa a la comunidad en la tenencia responsable de mascotas y en el cuidado de la vida salvaje, y procura alojamiento y cuidados a los animales sin hogar, entre otros servicios relacionados con los animales. En algunas jurisdicciones, una petición de urn:service:sos.animal-control puede no clasificarse como una emergencia en el sentido de que está sometida a procedimientos de emergencia de red y de operador (por ejemplo, permitir o inhabilitar una petición al urn:service:sos.animal-control cuando el UE no se ha registrado o no tiene unos credenciales insuficientes). Si se ha configurado de esta forma, la red puede, bien rechazarla con una indicación de que la llamada no es realmente una llamada de emergencia, o bien puede rechazarla con una indicación de que la llamada no es una llamada de emergencia y ofrecer etapas alternativas para su ejecución, tales como ofrecer un URI diferente con el que contactar y/o una dirección de red Conmutada en Circuitos (CS –“Circuit Switched”) diferente, tal como una cadena de dígitos. Es de apreciar que, puesto que los URNs de servicio de emergencia no son susceptibles de encaminamiento y no son números de E.164, el UE puede no ser capaz de proseguir si le falta el conocimiento de direcciones o números susceptibles de encaminamiento. En esas jurisdicciones, sería inapropiado que los procedimientos de emergencia llevados a cabo por el UE (según se ha especificado en la TS de 3GPP 24.008) y un UE no contactasen automáticamente, por ejemplo, con el “911” o el “112” al recibir un rechazo cuando contactan, por ejemplo, con el urn:service:sos.animal-control.
Nótese que cabe la posibilidad de que un UE habilitado en CS haya recibido una lista de números de emergencia CS locales (por ejemplo, recibidos como resultado del procedimiento de Actualización de posición). Un UE puede indicar el tipo de servicio de emergencia solicitado en una petición de emergencia CS y ser conectado al PSAP solicitado utilizando procedimientos de la TS de 3GPP 24.008. Por ejemplo, existe la siguiente tabla:
Valor de Categoría de Servicio de Emergencia (octeto 3)
El significado del Valor de Categoría de Emergencia se deduce de los siguientes ajustes (véase, por favor, la TS de 3GPP 22.101, cláusula 8):
- Bit 1
- Criterio
- Bit 2
- Ambulancia
- Bit 3
- Cuerpo de Bomberos
- Bit 4
- Guardia Marina
- Bit 5
- Rescate de Montaña
Bits 6, 7, 8 son espacio sobrante y restitución a “0”
La estación móvil puede ajustar uno o más bits a “1”.
Si se ajusta a “1” más de un bit, es necesario el encaminamiento a una central de Emergencias combinada (por ejemplo, ambulancia y cuerpo de bomberos en Japón). Si la MSC [Central de Conmutación Móvil –“Mobile Switching Center”] no puede hacer coincidir la categoría de servicio recibida con ninguna de las centrales de emergencia, encaminará la llamada a una central de emergencias por defecto definida por el operador.
Si no se ha ajustado ningún bit a “1”, la MSC encaminará la llamada de Emergencia a una central de emergencias por defecto definida por el operador.
Sin embargo, no existe en la actualidad ninguna relación de correspondencia para el urn:service:sos.animal-control. Puede llevarse a cabo una relación de correspondencia o correlación para algunos otros servicios de emergencia según se define en la RFC 5031 (por ejemplo, urn:service:sos.police), mediante el ajuste del bit correspondiente del Valor de Categoría de Emergencia (por ejemplo, el urn:service:sos.police se corresponde con el Bit 1 del Valor de Categoría de Servicio de Emergencia, el urn:service:sos.ambulance [urn:servicio:sos.ambulancia] se corresponde con el Bit 2 del Valor de Categoría de Servicio de Emergencia, el urn:service:sos.fire [urn:servicio:sos.fuego] se corresponde con el Bit 3 del Valor de Categoría de Servicio de Emergencia, el urn:service:sos.marine [urn:servicio:sos.marino] se corresponde con el Bit 4 del Valor de Categoría de Servicio de Emergencia, y el urn:service:sos.mountain [urn:servicio:sos.montaña] se corresponde con el Bit 5 del Valor de Categoría de Servicio de Emergencia). El urn:service:sos.animal-control, urn:service:sos.physician [urn:servicio:sos.médico], urn:service:sos.poison [urn:servicio:sos.veneno], urn:service:sos.gas [urn:servicio:sos.gas] y otros pueden correlacionarse con un Valor de Categoría de Servicio de Emergencia en el que ningún bit se ha ajustado en “1”, lo que hace que la llamada sea encaminada a una central de emergencias por defecto definida por el operador. Alternativamente, para solicitudes para las que no se da soporte a ningún PSAP en la red, pueden darse instrucciones al UE para que realice una petición de SIP normal (utilizando procedimientos de la TS de 2GPP 24.228) o establezca una llamada CS normal (utilizando procedimientos de la TS de 3GPP 24.008). La red puede conseguir esto al no indicar una dirección alternativa que no pueda ser correlacionada con Valor de Categoría de Servicio de Emergencia (es decir, no uno de los URNs de urn:service:sos para el que se ha normalizado una correlación). Cuando se recibe una solicitud de emergencia por parte del PSAP pero el PSAP no puede hacerse cargo de la solicitud y devuelve un SIP 380 o un mensaje similar, si existe una correlación en el UE desde el URN dado a un Valor de Categoría de Servicio de Emergencia, se establecerá una llamada a ese número de E.164 de PSAP CS automáticamente.
En el segundo ejemplo: la P-CSCF puede determinar que la petición de emergencia se ha realizado al urn:service:sos:police. Sin embargo, por ejemplo en los Países Bajos, el hecho de contactar con la policía no garantiza por definición la activación de procedimientos de emergencia. En lugar de ello, se ha configurado un número especial diferente del “112”: 0900-8844. Otros ejemplos son el “19” de la Policía (Albania), el “112” (Policía y Ambulancia (Italia)), el “112” (llamada de emergencia general, todas las categorías (Suecia)), el “115” (Cuerpo de Bomberos (Italia)), el “144” (Ambulancia (Austria)), el “*377” (comisaría de policía local u oficina del Departamento de Seguridad Pública, asistencia de carrera sin emergencia, en Texas). Tal número puede ser un servicio preferente. Podría ser inapropiado que se contactara automáticamente con el UE, por ejemplo, el “911” o el “112” si la red rechazase la llamada al urn:service:sos.police, y podría resultar inapropiado que contactase automáticamente con la red, por ejemplo, el 0900-8844 como llamada normal, ya que el usuario podría entonces, sin darse cuenta, recibir automáticamente cargos de categoría preferente. La P-CSCF puede proporcionar etapas alternativas tales como proporcionar una cadena de dígitos, por ejemplo, el 0900-8844, en una respuesta 3xx de SIP. Sin embargo, la cadena de dígitos puede formar parte de un mensaje que indica que la cadena de dígitos ha de ser visualmente presentada y/o que debe presentarse visualmente un mensaje de texto para indicar la naturaleza de la llamada que se ha hecho y la naturaleza del número proporcionado.
En una realización, la P-CSCF tiene listas configurables con identificadores de servicio de emergencia de socios en desplazamiento itinerante, las cuales indican el manejo por cada identificador de servicio de emergencia. Cuando se rechaza una petición, puede incluirse en la respuesta una lista configurable de URIs de servicios de emergencia alternativos, por ejemplo, señalizada como parte del campo de cabecera de Contacto de SIP. Estos servicios de emergencia alternativos pueden ser anotados con información alfanumérica que puede ser visualmente presentada, por ejemplo, cuando se señala como parte del campo de cabecera de Contacto de SIP. Los servicios de emergencia alternativos pueden ser también identificados, utilizando un cuerpo de XML con elementos de XML y atributos de XML, de manera que son presentados visualmente solo si se requiere.
En algunos casos, la red puede rechazar una petición realizada a una central de emergencias convencional o, quizá, a un PSAP combinado o a una central de emergencias combinada, donde un PSAP combinado o una central de emergencias combinada es un PSAP que acepta llamadas de múltiples tipos de emergencias. Por ejemplo, un PSAP combinado o una central de emergencias combinada puede aceptar llamadas relativas a emergencias policiales, emergencias de incendio, emergencias de ambulancia y otros tipos de emergencias. Una petición hecha a una central de emergencias combinada puede incluir bits, distintivos u otros indicadores (tales como una dirección de PSAP (por ejemplo, “119” en algunos países) o parte de una dirección de PSAP) que especifiquen las entidades de respuesta a la emergencia a las que ha de ser encaminada la petición. Por ejemplo, si se realiza una petición para el servicio contra incendios y el servicio de ambulancia, la petición puede incluir un distintivo de “fuego” y un distintivo de “ambulancia”. Al leer estos distintivos, la central de emergencias combinada puede encaminar la petición a las entidades de respuesta a la emergencia apropiadas.
En una realización, el UE puede enviar una petición a una central de emergencias o, quizá, a una central de emergencias combinada, y el UE no está al tanto de que la petición está relacionada con una central de emergencias y, por diversas razones, la red rechaza o no trata la petición de algún otro modo. En este caso, la red puede identificar la petición como relacionada con una central de emergencias combinada. La red envía entonces un mensaje al UE que contiene información que indica que la petición se refiere a una central de emergencias combinada. El UE puede entonces utilizar esta información para enviar la petición a una central de emergencias combinada o a un PSAP combinado u otra central de emergencias o PSAP alternativo. En algunas realizaciones, el PSAP alternativo se encuentra en el dominio conmutado en circuitos. La información contenida en el mensaje que la red envía al UE puede incluir información que identifica la central de emergencias combinada, bits, distintivos u otros indicadores que especifiquen las entidades de respuesta a la emergencia a las que se ha encaminado la petición inicial. Al recibir este mensaje, el UE puede enviar una petición alternativa al PSAP alternativo o combinado, y puede incluir los bits, distintivos u otros indicadores para que el PSAP alternativo pueda encaminar la petición alternativa a las entidades de respuesta a la emergencia apropiadas. Los bits, distintivos u otros indicadores pueden ser los bits especificados en la Tabla 10.5.135d de la TS de 3GPP 24.008.
Más concretamente, un elemento de red tal como una P-CSCF verifica si las peticiones que recibe contienen identificadores de servicio de emergencia. La P-CSCF puede determinar que se ha realizado una solicitud de llamada de emergencia apropiada, pero que la red local no da soporte al PSAP de la emergencia solicitada (por ejemplo, si se ha hecho una petición al urn:service:sos.gas). LA P-CSCF puede también determinar que el UE no ha podido reconocer la petición como una petición de llamada de emergencia. La P-CSCF puede entonces haberse 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, puesto que el usuario del UE tiene la impresión de que está informando de una situación que requiere atención. Sin embargo, no se da soporte en la red a un PSAP / central de emergencias para ese tipo de emergencia.
Hoy en día, en la red CS, se han asignado Categorías de Servicio a la Policía, Ambulancia, Cuerpo de Bomberos, Guardia Marina y Rescate de Montaña. Sin embargo, en el caso de que se devuelva por parte de la P-CSCF un 380 (Servicio Alternativo), una de las opciones que tiene el UE es iniciar una llamada de emergencia en el dominio CS utilizando procedimientos específicos de tecnología de acceso apropiados. Sin embargo, el UE, al recibir el 380, aún no sabe si la petición inicial con el identificador de servicio de emergencia que no fue reconocida por el UE, fue destinada a un PSAP por defecto, a un PSAP de la Policía, a un PSAP de Ambulancia, a un PSAP del Cuerpo de bomberos, a un PSAP combinado, etc.
En una realización, en el caso de que la P-CSCF haya sido configurada para reconocer la petición como correspondiente a un tipo concreto de emergencia, la P-CSCF informa entonces al UE de que la petición era para ese tipo de emergencia. Además, si la P-CSCF rechaza la petición porque no se da soporte al tipo de emergencia solicitado, la P-CSCF puede proporcionar información adicional. El UE puede ser mejorado para que haga cargo mensajes de 380 (Servicio Alternativo) para peticiones de emergencia no reconocidas para PSAPs particulares. A la hora de tratar de conectar con un PSAP particular utilizando el Dominio CS, puede establecerse una relación de correspondencia o correlación con el Valor de Categoría de Emergencia correcto (véase la TS de 3GPP 24.008, subcláusula 10.5.4.33). La P-CSCF puede ser mejorada para que rechace las peticiones de servicios de emergencia a PSAPs a los que no se da soporte, por ejemplo, urn:service:sos.gas, basándose en un criterio local.
Lo que sigue es un ejemplo de un cuerpo de XML que indica al UE que se ha detectado una petición de servicio de emergencia y da instrucciones al UE para que se conecte al PSAP determinado.
<versión ims-3gpp=“...”>
(<ims-3gpp version=“...”>)
<servicio-alternativo>
(<alternative-service>)
<tipo alternativo=“
tel:119;contexto-telefónico=+81
(<type alternate=“
tel:119;pone-context=+81)
urn:service:sos.fire-urn:service:sos.ambulance”>
<emergencia/>
(<emergency/>)
</tipo>
(</type>)
<razón/>
(<reason/>)
</servicio-alternativo>
</ims-3gpp>
En la Tabla 10.5.135d de la TS de 3GPP 24.008 se presentan propuestas previas mencionadas que señalan el reconocimiento por la red de IMS de una petición a una central de emergencias combinada y la correlación desde el valor señalado que representa una central de emergencias combinada, hasta uno o más bits presentes en la Tabla 10.5.135d de la TS de 3GPP 24.008. La TS de 3GPP 24.008 es la especificación de GSM / UMTS, y el GSM / UMTS da soporte a diferentes Ajustes normales frente a un Ajuste de Emergencia (es decir, sin la marcación de dígitos), En el CDMA [Acceso Múltiple por División en Código –“Code Division Multiple Access”], desde la “IS-2000 release A” (Entrega A de la IS-2000) en adelante, existe también un campo denominado LLAMADA_EMERGENCIA_GLOBAL (GLOBAL_EMERGENCY_CALL) que puede ser incluido en un mensaje de Origen con el fin de realizar tal llamada independiente de una cadena de marcación. El nivel de revisión de protocolo que da soporte a esto es el 7 y superior. Los UEs anteriores, con un “nivel de revisión de protocolo actualmente en uso que es menor que 7”, no distinguen entre llamadas de emergencia y llamadas normales. De esta forma, tales UEs pueden tener que correlacionar, póngase por caso, “tel:119;pone-context=+81” con el 119 y marcar el 119 como una llamada normal.
Asimismo, el CDMA no da soporte al encaminamiento a Centrales de Emergencia Combinadas o a Centrales de Emergencia Especializadas (por ejemplo, únicamente para “policía”). El 3GPP2 únicamente documenta el modo de encaminamiento hacia PSAPs por defecto. De esta forma, en una realización alternativa, un UE de CDMA detecta que la red de IMS ha determinado que la petición inicial a la red de IMS era para un PSAP que no es por defecto. El UE de CDMA puede entonces, en lugar de enviar una llamada de emergencia con la LLAMADA_EMERGENCIA_GLOBAL ajustada en “1” (en vez de encaminarla al PSAP por defecto), da soporte a una
o más de las siguientes posibilidades: una llamada de emergencia con la Emergencia_Global ajustada en “1” y, en el campo de dirección, un número de teléfono: póngase por caso el 119, si “el nivel de revisión de protocolo actualmente en uso NO es menor que 7”; una llamada de emergencia con la Emergencia_Global ajustada en “0” y, en el campo de dirección, un número de teléfono: póngase por caso el 119, si “el nivel de revisión de protocolo actualmente en uso NO es menor que 7”; y/o una llamada de emergencia con un número de teléfono en el campo de dirección: póngase por caso el 119, si “el nivel de revisión de protocolo actualmente en uso es menor que 7”.
Propuestas actuales añaden un “atributo alternativo” al Esquema de XML existente. En una realización, el atributo alternativo incluye diversas direcciones alternativas, una de las cuales (el último elemento) puede ser un indicador que codifica la necesidad de encaminar la llamada a una central de emergencias combinada ‘mezclando’ entre sí URNs de servicios de emergencia: por ejemplo, “Urn:service:sos.ambulance-Urn:service:sos.fire”. Realizaciones alternativas pueden codificar las direcciones alternativas de forma diferente en la respuesta de SIP, por ejemplo, en los campos de cabecera de Contacto o en un nuevo de XML independiente. Otra alternativa puede consistir en una codificación diferente, tal que el indicador seguirá siendo un URN o un URI de tel o un URI de SIP. Por ejemplo, urn:service:sos.fire.ambulance (por ejemplo, ‘puntear’ juntos los subtipos de emergencias).
Un número de emergencia puede ser interpretado de diferentes maneras en diferentes países. Por ejemplo, la dirección “119” puede traducirse a policía+marina en un país y a fuego-ambulancia en otro. Si ambos países tienen operadores que son socios en desplazamiento itinerante con la red doméstica de un usuario en desplazamiento itinerante, el UE o la red necesita reconocer la dirección como una petición de emergencia, pero la red puede no saber qué traducción se ha pretendido para el 119. En una realización, en semejante situación, la red selecciona una de las traducciones tras una interacción adicional con el UE.
Tal interacción adicional incluye, por ejemplo, el envío de información por parte de la red al UE indicando que la dirección está asociada con diferentes tipos de emergencias en diferentes jurisdicciones. Semejante información incluye una correlación entre la dirección, un contexto de telefonía y uno o más tipos de identificadores de emergencia opcionales, y se conoce como información de dirección alternativa. Un tipo de identificador de emergencia es opcional en el caso de que el contexto de telefonía no se correlacione con un tipo de emergencia pero se conozcan alternativas de “emergencia” o “urgentes”.
La información de dirección alternativa comprende una correlación entre una dirección, un contexto de telefonía y uno o más tipos de identificadores de emergencia opcionales. La dirección indica el número de emergencia marcado, que puede ser un número de teléfono tal como el ‘119’, por ejemplo. El contexto de telefonía indica un estado relevante del U, tal como la posición o el país en el que se encuentra el UE, y puede ser un número o una cadena tal como ‘+81’, la cadena de texto ‘Japan’ (Japón), una combinación de un número y una cadena u otra información que puede ser resuelta o definida para una posición, por ejemplo. La cadena de texto (por ejemplo, ‘Japan’) puede ser recibida en múltiples idiomas y en múltiples codificaciones de caracteres, incluyendo el japonés y otros conjuntos de caracteres que no son de ASCII. El tipo de identificador de emergencia (póngase por caso ‘policía’, ‘fuego’ o ‘ambulancia’, por ejemplo) es extensible e indica el tipo de servicio de emergencia asociado con la dirección para un contexto de telefonía dado. El país o región en la que se aplican los servicios de emergencia puede ser identificado utilizando códigos aplicables ITU, IANA, ISO, si bien, en algunos casos, se proporcionan ciertos servicios de emergencia en una zona que no coincide con un “país” o región, en cuyo caso puede no haberse asignado un código estándar ITU, IANA, ISO. Algunos de entre el ITI, IANA, ISO u otros códigos aplicables para codificar posiciones, países o regiones son extensibles, tales como el ISO 3166-1 y el ISO 3166/MA.
La información de dirección alternativa puede contener, adicionalmente, un elemento de razón, tal como un elemento de XML de <razón> (según se describe, por ejemplo, en el cuerpo de XML de IMS de 3GPP según se define en la TS de 3GPP 24.229), por ejemplo. Un elemento de razón se puebla o llena con información que puede ser presentada a un usuario de un UE para identificar, por ejemplo, la posición, los tipos de servicios de emergencia a los que se da soporte, y/o los números de servicio de emergencia. Tal elemento de razón puede ser transmitido en un cuerpo de mejorado de application/3gpp-ims+xml (según se define en la TS de 3GPP 24.229). El contenido de un elemento de razón puede ser especificado en múltiples idiomas, utilizando el atributo xml:lang. Por ejemplo, un elemento de razón puede ser presentado por el siguiente cuerpo (que corresponde a un Esquema de ML mejorado según la TS de 3GPP 24.229).
<ims-3gpp versión=“2”>
<servicio-alternativo>
<tipo><emergencia/></tipo>
<razón lang=“en”>emergencia</razón>
<razón lang=“nl”>noodgeval</razón>
</servicio-alternativo>
</ims-3gpp>
La red envía dicha información de dirección alternativa al UE, por ejemplo, como parte del cuerpo de una respuesta de 300 (Múltiples Opciones) de SIP, en una o más cabeceras del campo de Contacto de la respuesta de 300 (Múltiples Opciones) de SIP o en otra respuesta 3cc de SIP (por ejemplo, una respuesta de 380 (Servicio Alternativo) de SIP.
Lo que sigue es un ejemplo de un cuerpo de XML incluido en una respuesta a una petición de un servicio de emergencia que indica al UE que una dirección (‘119’, por ejemplo) está asociada con un tipo de emergencia o una combinación de tipos de emergencia diferentes (‘fuego’, ‘ambulancia’ o ‘policía’, por ejemplo) en diferentes contextos de telefonía (‘+81’, por ejemplo). Nótese que los tipos de emergencia son obtenidos del URN de servicio de emergencia de la RFC 5031 (es decir, el urn:service:sos y sus subtipos, policía, ambulancia, gas, fuego, etc., donde <policía/> puede correlacionarse con el urn:servicio:sos.policía, etc.). Nótese que el tipo de emergencia <sos/> puede correlacionarse con el URN de servicio genérico urn:service:sos. Nótese que <sos/> puede correlacionarse con la cadena de marcación “112” o con el establecimiento de llamada de emergencia en el dominio CS de GSM / UMTS, con todos los bits de Valor de Categoría de Servicio de Emergencia ajustados en ‘0’ (véase la Tabla 10.5.135d/3GPP TS 24.008: elemento de información de Categoría de Servicio), de tal manera que la llamada es encaminada a una central de emergencias por defecto definida por el operador o se efectúa una señalización equivalente en otras tecnologías de dominio CS tales como el CDMA. Nótese que <policía/> puede también correlacionarse con el ajuste del bit 1 del Valor de Categoría de Servicio de Emergencia cuando se realiza una llamada de emergencia de GSM / UMTS a través del dominio CS.
<ims-3gpp versión=“...”> <servicio-alternativo> <tipo>
<emergencia/
</tipo
<razón/
<acción
<alternativo> <URIalternativo>tel:112;contexto-telefonía=+57</URIalternativo> <sos/>
</alternativo>
<alternativo> <URIalternativo>tel:123;contexto-telefonía=+57</URIalternativo> <ambulancia/> <fuego/> <policía/>
</alternativo>
<alternativo> <URIalternativo>tel:119;contexto-telefonía=+81</URIalternativo> <URIalternativo>tel:119;contexto-telefonía=+82</URIalternativo> <URIalternativo>tel:119;contexto-telefonía=+886</URIalternativo> <ambulancia/> <fuego/>
</alternativo>
<alternativo> <URIalternativo>tel:119;contexto-telefonía=+94</URIalternativo> <URIalternativo>tel:119;contexto-telefonía=+1876</URIalternativo> <policía/>
</alternativo> <alternativo>
<URIalternativo>tel:119;contexto-telefonía=+57</URIalternativo>
<URIalternativo>tel:119;contexto-telefonía=+86</URIalternativo>
<fuego/>
</alternativo>
<alternativo>
<URIalternativo>tel:119;contexto-telefonía=+62</URIalternativo>
<URIalternativo>tel:118;contexto-telefonía=+62</URIalternativo>
<ambulancia/>
</alternativo>
</acción>
</servicio-alternativo>
</ims-3gpp>
El cuerpo de XML proporcionado a modo de ejemplo en lo anterior indica que la dirección ‘119’ puede ser traducida a un tipo de emergencia diferente en una jurisdicción diferente. Por ejemplo, la dirección ‘119’ se asocia con servicios de emergencia de ‘fuego’ y ‘ambulancia’ cuando el UE se encuentra en una jurisdicción que tiene un contexto de telefonía de ‘+81’ (Japón) o ‘+82’ (Corea). La dirección ‘119’ se asocia, alternativamente, con servicios de emergencia de ‘policía’ cuando el UE se encuentra en una jurisdicción que tiene un contexto de telefonía de ‘+94’ (Sri Lanka).
Si un código de país o un código de posición están incluidos en una petición de servicio de emergencia que puede ser correlacionada con múltiples tipos de servicios de emergencia, se supone que el equipo de mano está intentando específicamente que la petición sea encaminada al tipo de servicio de emergencia asociado con la dirección de servicio de emergencia del país o región indicados.
En otra realización, el UE o la red se han configurado para seleccionar o reducir las alternativas en la respuesta y para eliminar algunas de las posibilidades menos probables. Dicha selección o reducción puede conseguirse basándose, por ejemplo, en la red en curso de un UE, en la red doméstica del UE, en la nacionalidad del usuario del UE o en los planes de viaje pasados del usuario del UE. Un UE que lleva a cabo una selección o reducción puede incluir un criterio que realiza una codificación “dura” [con incorporación de datos en código fuente] de una correlación entre una dirección, un tipo de emergencia y un contexto de telefonía, con lo que se permite que el UE seleccione explícitamente el tipo de emergencia deseado a la hora de hacer una llamada de emergencia a través del dominio CS o del dominio PS. En el dominio PS, un tipo de emergencia puede indicarse, bien por un URN de la RFC 5031 o bien por un URL de TEL que incluye un indicador de país o región tal como un ‘contexto de telefonía’. Puede mejorarse adicionalmente una función de selección de tipo de emergencia en el UE si el UE está al corriente del país
o región donde se encuentra y si está presente una correlación almacenada o recibida de tipos de emergencia, indicadores de posición y direcciones de llamada de emergencia. La función de selección del tipo de emergencia puede entonces determinar que en ciertos países o regiones una cierta correlación NO se aplica, o bien que la correlación se aplica universalmente (por ejemplo, para equipos de mano de UMTS / GSM, el número “112” puede correlacionarse con un establecimiento de llamada de emergencia en el dominio CS de GSM / UMTS, con todos los bits del Valor de Categoría de Servicio de Emergencia ajustados en ‘0’ (véase la Tabla 10.5.135d/3GPP TS 24.008: elemento de información de Categoría de Servicio)).
Dicha interacción adicional entre la red y el UE para seleccionar una traducción también incluir, por ejemplo, situar las opciones para la traducción en un campo de texto destinado a ser presentado visualmente en el UE (tal como el elemento <razón> del cuerpo de XML de IMS según el 3GPP). El usuario del UE puede entonces seleccionar una de las opciones, la selección puede ser transmitida a la red, y la red puede traducir el número de emergencia basándose en la selección. Alternativamente, la red puede realizar la selección en el siguiente orden: correlacionar la dirección (por ejemplo, 119) según se define en la red doméstica; si la dirección no se ha definido en la red doméstica, correlacionar la dirección según se define en la red en ese momento visitada; si la dirección no se ha definido en la red que se está visitando en ese momento, correlacionar la dirección según se define para los socios en desplazamiento itinerante o encaminar la llamada al PSAP por defecto o con mayor capacidad. Alternativamente, la petición puede ser siempre encaminada al PSAP por defecto o con mayor capacidad.
Puede producirse un problema similar para el UE cuando este trata de reconocer la dirección marcada como un identificador de emergencia. En una realización, el UE se ha configurado con una traducción al objeto de evitar que se produzca este problema. Alternativamente, el UE puede interactuar con el usuario para seleccionar una traducción deseada. Como alternativa, el UE puede haberse configurado para encaminar la llamada al PSAP por defecto o con mayor capacidad. De forma alternativa, el UE puede encaminar la llamada basándose en la red y se vincula a, y puede correlacionar los dígitos de acuerdo con, las reglas de esa red. El UE puede también interactuar con la red y utilizar cualquier aviso o anuncio que obtenga.
En aún otra realización, la P-CSCF no rechazará la petición de un tipo de servicio de emergencia al que no se dé soporte (tal como el urn:service:sos.poison (urn:servicio:sos.veneno)), sino que la prepara para remitirla a la S-CSCF doméstica del usuario utilizando procedimientos normales (en contraposición a su remisión a una E-CSCF). La S-CSCF de la red doméstica del usuario debe entonces haberse configurado para hacerse cargo del valor de URI de Solicitud no susceptible de ser encaminado. La red de IMS puede también haberse configurado para tener en cuenta a los usuarios en desplazamiento itinerante que soliciten una sesión con el urn:service:sos.police, de tal modo que el servicio solicitado por un UE que pueda estar a medio camino en cualquier parte del mundo siga pudiendo ser manejado a tiempo y de un modo efectivo. La red de IMS puede proporcionar una indicación en un mensaje de SIP al UE de que se ha determinado que la llamada no es una llamada de emergencia y que su manejo será diferente. La indicación puede consistir en un distintivo y/o en información alfanumérica. Se proporcionan en este documento posibles codificaciones para este tipo de indicador.
Volviendo al caso en que un componente de la red de IMS determina que el UE 110 ha iniciado una llamada de emergencia sin reconocerla como tal, en algunas aplicaciones, la red 120 de IMS incluye el indicador 160 de llamada de emergencia en una respuesta de SIP que es enviada al UE 110. En este caso, el indicador 160 se proporciona durante la fase de señalización o intercambio de señales para el 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 120 de IMS transfiere entonces el mensaje desde el PSAP 130 al UE 110.
En otras realizaciones, si un componente de la red 120 de IMS incluye el indicador 160 de llamada de emergencia en la respuesta de SIP que se envía al UE 110, el UE 110 puede abortar la señalización en curso en ese momento e iniciar procedimientos normales de establecimiento de llamada de emergencia, los cuales pueden implicar que se origine una llamada por una red Conmutada en Circuitos, si tiene capacidad para ello o se encuentra disponible, odespués de iniciar procedimientos de registro de emergencia, o bien enviar una petición de INVITACIÓN DE SIP quecontiene un indicador que indica que la petición de INVITACIÓN DE SIP es una petición de llamada relacionada con una emergencia y que contiene información sobre sí misma, relacionada con la emergencia.
Información que es similar a la información 180 que el UE 110 incluye en el mensaje 170 de SIP, puede ser incluida por el UE 110 en un mensaje enviado bajo diferentes circunstancias. Esto se ilustra en la Figura 2, en la que el UE 110, la red 120 de IMS y el PSAP 130 están de nuevo presentes. Sin embargo, en este caso, el PSAP 130 inicia una llamada de vuelta al UE 110. Como es bien conocido en la técnica, una vez que se ha puesto fin a una llamada de emergencia, el PSAP 130 puede realizar una llamada de vuelta al UE 110 por varias razones. Por ejemplo, si la llamada de emergencia parece haber terminado de un modo anormal, el PSAP 130 puede llamar de vuelta al UE 110 con el fin de determinar si el usuario del UE desea transportar cualquier información adicional. Alternativamente, el PSAP 130 puede llamar de vuelta al usuario a fin de pedir información que no se solicitó inadvertidamente en la llamada inicial. Otras razones para una llamada de vuelta desde el PSAP 130 a un llamante de emergencia tras la terminación de una llamada de emergencia pueden ser familiares para un experto de la técnica.
El PSAP 130 puede iniciar la llamada de vuelta enviando un mensaje 210 de INVITACIÓN DE SIP o un mensaje similar al UE 110 a través de la red 120 de IMS. En una realización, el mensaje 210 de INVITACIÓN DE SIP contiene un indicador 220 que indica que el mensaje 210 de INVITACIÓN DE SIP esta relacionado con una llamada de vuelta de emergencia. El indicador 220 puede ser sustancialmente similar al indicador 160 de la Figura 1, o bien puede ser algún otro tipo de indicador. El UE 110 puede reconocer que el indicador 220 es una indicación de una llamada de vuelta de emergencia procedente del PSAP 130 y puede responder apropiadamente al indicador 220 al apelar a una capacidad funcional de devolución de llamada de emergencia, sometida a ciertos criterios. En una realización, la respuesta del UE 110 a la recepción del indicador 220 es sustancialmente similar a la respuesta que tuvo el UE 110 al recibir el indicador 160 de la Figura 1.
Por ejemplo, una acción que puede emprender el UE 110 al reconocer el indicador 220 es indicar, visual o audiblemente, la naturaleza de la sesión al usuario. Es decir, el UE 110 puede alertar al usuario de que la llamada entrante es una llamada de emergencia. La alerta puede consistir en un mensaje que aparece sobre la pantalla de presentación visual del UE 110 o en algún otro tipo de indicación de la naturaleza de la llamada. Otras acciones emprendidas por el UE 110 pueden implicar la transmisión de una respuesta 2xx o 1xx de SIP (por ejemplo, la respuesta 200(OK) de SIP) 320, o un mensaje similar, que incluye información 240 acerca del UE 110, sometida a ciertos criterios. Alternativamente, debido a las limitaciones del SIP, la información 240 puede ser transmitida a través de varios mensajes de SIP o mensajes de red (por ejemplo, la información de identidad de IP-CAN proporcionada por el UE puede no ser completamente fiable y, por tanto, un mecanismo basado en la provisión de red (por ejemplo, utilizando Control de Criterios y Cargo (PCC –“Policy Control and Charging”)) puede proporcionar tal información), o dentro de una petición de refrescamiento de objetivo tal como una petición de re-INVITACIÓN DE SIP o una petición de ACTUALIZACIÓN, o, parcialmente, en una petición PRACK DE SIP. La información 240 puede ser sustancialmente similar a la información 180 que proporcionó el UE 110 al recibir el indicador 160 de la Figura 1.
Un fragmento de la información 140 que el UE 110 puede enviar al PSAP 130 es la identidad de usuario pública del UE o algún otro símbolo de identificación. Otro fragmento de la información 240 que el UE 110 puede transmitir al mensaje 230 de 200OK DE SIP es el tipo de acceso que el UE 110 utilizó para la llamada de emergencia inicial. Por ejemplo, si la llamada de emergencia se realizó a través de una LAN inalámbrica, el UE 100 puede incluir ese hecho en la información 240, así como un ID de celda, un ID de línea y/o un ID de nodo de acceso de LAN inalámbrica.
En el caso de que el UE 110 esté al corriente de su posición geográfica mediante el uso de, por ejemplo, un sistema GPS, el UE 110 puede incluir su posición como otro fragmento de la información 240. Si el UE 110 no está al corriente de su posición geográfica, no se incluyen datos relativos a la posición en la información 240. Si existe un GRUU asociado con le UE 110, el GRUU del UE puede ser incluido como otro fragmento de la información 240.
En una realización alternativa, el PSAP 130 puede establecer una llamada Conmutada en Circuitos (CS –Circuit Switched”) y una pasarela CS puede entonces convertir la llamada y el intercambio de señales o señalización en tecnología conmutada en paquetes si la llamada CS es encaminada a la pasarela CS. Disparada o activada por la llamada entrante procedente del PSAP 130, la pasarela CS puede iniciar la devolución o retorno de llamada pormedio de tecnología conmutada en paquetes, al enviar un mensaje 210 de INVITACIÓN DE SIP, o un mensaje similar, al UE 110 a través de la red 120 de IMS.
La Figura 3 ilustra una realización de un método 300 para que un UE responda a un mensaje relacionado con una emergencia, enviado al UE. En el bloque 310, el UE recibe un mensaje que contiene un indicador que indica que se ha efectuado una llamada relacionada con una emergencia. En algunos casos, la llamada relacionada con una emergencia puede haberse realizado por el UE sin que el UE esté al corriente de que la llamada era relativa a una emergencia. En otros casos, la llamada relacionada con una emergencia puede ser una llamada de vuelta procedente de un PSAP para el UE, en respuesta a una llamada de emergencia previa procedente del UE. En el bloque 320, el UE reconoce el indicador como una indicación de que su primer mensaje (petición de SIP inicial para un diálogo o transacción aislada o única, o un método desconocido o un mensaje similar) está relacionado 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 relacionada con una emergencia es relativa a una emergencia. En el bloque 340, el UE envía un mensaje que contiene información relacionada con una emergencia, acerca de sí misma.
La invención que se ha descrito en la presente memoria puede ser implementada en forma de una o más modificaciones en la Especificación Técnica (TS –“Technical Specification”) del Proyecto de Sociedad de Tercera Generación (3GPP –“Third Generation Partnership Project”) 24.229 “Protocolo de Control de Llamadas Multimedia de Protocolo de Internet (IP) basado en el Protocolo de Inicio de Sesión (SIP) y en el Protocolo de Descripción de Sesión (SDP); Etapa 2” (“Internet Protocol (IP) Multimedia Call Control Protocol Based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3”). Se proporcionan en lo que sigue adendas y modificaciones propuestas a la TS 24.229, de acuerdo con diversas realizaciones de la presente invención.
La siguiente adenda a la TS de 3GPP 24.229 se aplica a la petición de INVITACIÓN inicial en el caso de que un inicio de llamada se origine en el UE:
En el caso de que el UE reciba una respuesta de 380 (Servicio Alternativo) a una petición de INVITACIÓN, de tal manera que la respuesta contenga un cuerpo de XML que incluye un elemento de <servicio alternativo> en el que el atributo “alternativo” del elemento hijo <tipo> contiene uno o más URIs de servicio de emergencia, el UE puede intentar realizar una llamada normal según se describe en la subcláusula 5.1.3.1. utilizando un URI de servicio de emergencia o utilizando un establecimiento de llamada de acuerdo con los procedimientos descritos en la TS de 3GPP 24.008 [8]. El comportamiento del UE es específico de la implementación en el caso de que esté ausente el atributo “alternativo” del elemento hijo <tipo>, o no contiene ningún URI de servicio de emergencia.
La siguiente modificación de la TS de 3GPP 24.229 se aplica al servicio general de emergencia:
La P-CSCF almacenará una lista configurable de identificadores de servicios de emergencia locales, es decir, números de emergencia y el URN del servicio de emergencia, que sean válidos para el operador al que pertenezca la P-CSCF. Además de ello, la P-CSCF almacenará una lista configurable de identificadores de servicios de emergencia de socios en desplazamiento itinerante. Las listas configurables con identificadores de servicios de emergencia de los socios locales y en desplazamiento itinerante indicarán el trato para cada identificador de servicio de emergencia. Cuando el trato indicare que la petición fuera a ser rechazada, podría incluirse en la respuesta una lista configurable de URIs servicios de emergencia alternativos.
La siguiente adenda a la TS de 3GPP 24.229 se aplica al tratamiento general para todos los diálogos y transacciones aisladas, excluido el método de REGISTRO tras el registro de emergencia:
Si la P-CSCF detecta que el URI de Solicitud de la solicitud inicial de un diálogo, o una transacción aislada, o un método desconocido, coincide con un tipo de emergencia al que no se da soporte en los identificadores de servicio
de emergencia de VPLMN o de HPLMN, la P-CSCF: -responderá a la petición de INVITACIÓN con una respuesta de 380 (Servicio Alternativo); -supondrá que el UE da soporte a la versión 1 del Esquema de XML para el cuerpo de XML del subsistema
de CN de IM, si no se indica que se da soporte al cuerpo de XML de IMS según 3GPPP en la cabecera de Aceptación; e -incluirá en la respuesta de 380 (Servicio Alternativo):
o un campo de cabecera de Tipo de Contenido, con el valor ajustado al tipo de MIME asociado del cuerpo de XML de IMS de 3GPP, según se describe en la subcláusula 7.6.1. El cuerpo contendrá: a) un elemento de <servicio alternativo>, ajustado a los parámetros del servicio alternativo;
b) si la cabecera de Aceptación indica que se da soporte a la versión 2 del Esquema de XML para el cuerpo de subsistema de CN de IM,
o entonces, un elemento hijo <tipo>, con un atributo “alternativo” ajustado a una lista de URIs de servicios de emergencia alternativos;
o en caso contrario, un elemento hijo <tipo>, ajustado en “emergencia”;
c) un elemento hijo <razón>, ajustado a una razón configurable por el operador.
La siguiente adenda alternativa a la TS de 3GPP 24.229 se aplica al tratamiento general de todos los diálogos y transacciones aisladas, excluyendo el método de REGISTRO tras el registro de emergencia: Si la P-CSCF detecta que el URI de Solicitud de la solicitud inicial de un diálogo, o una transacción aislada, o un
método desconocido, coincide con un tipo de emergencia al que no se da soporte en los identificadores de servicio de emergencia de VPLMN o de HPLMN, la P-CSCF: -responderá a la petición de INVITACIÓN con una respuesta de 380 (Servicio Alternativo);
- -
- supondrá que el UE da soporte a la versión 1 del Esquema de XML para el cuerpo de XML del subsistema de CN de IM, si no se indica que se da soporte al cuerpo de XML de IMS según 3GPPP en la cabecera de Aceptación; e
- -
- incluirá en la respuesta de 380 (Servicio Alternativo):
o un campo de cabecera de Tipo de Contenido, con el valor ajustado al tipo de MIME asociado del cuerpo de XML de IMS de 3GPP, según se describe en la subcláusula 7.6.1.
El cuerpo contendrá:
a) un elemento de <servicio alternativo>, ajustado a los parámetros del servicio alternativo;
b) un elemento hijo <tipo>, con un atributo “alternativo” ajustado a una lista de URIs de servicios de emergencia alternativos;
c) un elemento hijo <razón>, ajustado a una razón configurable por el operador.
La siguiente modificación de la TS de 3GPP 24.229 se aplica al tratamiento general de todos los diálogos y transacciones aisladas, excluyendo el método de REGISTRO para un registro que no sea de emergencia:
Si la P-CSCF recibe una solicitud o petición inicial para un diálogo, o una transacción aislada, o un método desconocido, para un usuario registrado, la P-CSCF inspeccionará el URI de Solicitud independientemente de los valores de posibles entradas en las cabeceras de Ruta recibidas para identificadores de servicios de emergencia conocidos, es decir, números de emergencia y el URM de servicio de emergencia, desde estas listas configurables. Si la P-CSCF detecta que el URI de Solicitud de la petición inicial de un diálogo, o una transacción aislada, o un método desconocido, coincide con uno de los identificadores de servicios de emergencia de cualquiera de estas listas, la 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 la P-CSCF no es capaz de hacerse cargo de sesiones de emergencia o, debido al criterio local, no se hace cargo de sesiones de emergencia o únicamente se encarga de cierto tipo de petición de sesión de emergencia, o la IP-CAN a la que está enganchado el UE o en la que se está desplazando de forma itinerante el UE o en la que se encuentra la P-CSCF, es una red distinta de la red del operador doméstico del UE, entonces la P-CSCF:
- -
- rechazará la petición devolviendo una respuesta de 380 (Servicio Alternativo) al UE;
- -
- supondrá que el UE da soporte a la versión 1 del Esquema de XML para el cuerpo de XML del subsistema de CN de IM, si no se indica que se dé soporte al cuerpo de XML de IMS según el 3GPP en la cabecera de Aceptación; e
- -
- incluirá en la respuesta de 380 (Servicio Alternativo):
o un campo de cabecera de Tipo de Contenido, con el valor ajustado al tipo de MIME asociado del cuerpo de XML de IMS de 3GPP, según se describe en la subcláusula 7. 6. 1.
El cuerpo contendrá:
a) un elemento de <servicio alternativo>, ajustado a los parámetros del servicio alternativo;
b) si la cabecera de Aceptación indica que se da soporte a la versión 2 del Esquema de XML para el cuerpo de XML del subsistema de CN de IM, entonces:
- o un elemento hijo <tipo> con un atributo “alternativo” ajustado a una lista de URIs de servicios de emergencia alternativos, y
• si la petición inicial de un diálogo, o transacción aislada, o método desconocido, fuera para un tipo de emergencia al que se da soporte, el elemento hijo <tipo> se ajusta en “emergencia” con el fin de indicar que se trataba de una llamada de emergencia a la que se daba soporte,
- o en caso contrario, un elemento hijo <tipo>, ajustado en "emergencia";
c) un elemento hijo <razón>, ajustado en una razón configurable por el operador; y
d) un elemento hijo <acción>, ajustado en “registro de emergencia” si la petición incluía un URN de servicio de emergencia en el URI de Solicitud.
NOTA 1: Desplazamiento itinerante es cuando un UE se encuentra en un área geográfica que está fuera del área geográfica de servicio del subsistema de CN de IM doméstico.
NOTA 1a: “sip:911@example.com;user=phone” puede ser un URI de servicio de emergencia alternativo.
“urn:service:sos.animal-control” puede ser un tipo de llamada de emergencia al que no se da soporte.
NOTA 2: URN de servicio de emergencia en el URI de Solicitud indica a la red que el intento de llamada de emergencia ha sido reconocido por el UE.
La siguiente modificación de la TS de 3GPP 24.229 se aplica al tratamiento general de todos los diálogos y transacciones aisladas, excluyendo el método de REGISTRO para un registro que no sea de emergencia:
Si la P-CSCF recibe una solicitud o petición inicial de un diálogo, o una transacción aislada, o un método desconocido, para un usuario registrado, la P-CSCF inspeccionará el URI de Solicitud independientemente de los valores de posibles entradas en las cabeceras de Ruta recibidas para identificadores de servicios de emergencia conocidos, es decir, números de emergencia y el URM de servicio de emergencia, desde estas listas configurables. Si la P-CSCF detecta que el URI de Solicitud de la petición inicial de un diálogo, o una transacción aislada, o un método desconocido, coincide con uno de los identificadores de servicios de emergencia de cualquiera de estas listas, la 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 la P-CSCF no es capaz de hacerse cargo de sesiones de emergencia o, debido al criterio local, no se hace cargo de sesiones de emergencia o únicamente se encarga de cierto tipo de petición de sesión de emergencia, o la IP-CAN a la que está enganchado el UE o en la que se está desplazando de forma itinerante el UE o en la que se encuentra la P-CSCF, es una red distinta de la red del operador doméstico del UE, entonces la P-CSCF:
- -
- rechazará la petición devolviendo una respuesta de 380 (Servicio Alternativo) al UE;
- -
- supondrá que el UE da soporte a la versión 1 del Esquema de XML para el cuerpo de XML del subsistema de CN de IM, si no se indica que se dé soporte al cuerpo de XML de IMS según el 3GPP en la cabecera de Aceptación; e
- -
- incluirá en la respuesta de 380 (Servicio Alternativo):
o un campo de cabecera de Tipo de Contenido, con el valor ajustado al tipo de MIME asociado del cuerpo de XML de IMS de 3GPP, según se describe en la subcláusula 7. 6. 1.
El cuerpo contendrá:
a) un elemento de <servicio alternativo>, ajustado a los parámetros del servicio alternativo;
b) un elemento hijo <tipo> con un atributo “alternativo” ajustado a una lista de URIs de servicios de emergencia alternativos, y
- -
- si la petición inicial de un diálogo, o transacción aislada, o método desconocido, fuera para un tipo de emergencia al que se da soporte, el elemento hijo <tipo> se ajusta en “emergencia” con el fin de indicar que se trataba de una llamada de emergencia a la que se daba soporte,
c) un elemento hijo <razón>, ajustado en una razón configurable por el operador; y
d) un elemento hijo <acción>, ajustado en “registro de emergencia” si la petición incluía un URN de servicio de emergencia en el URI de Solicitud.
NOTA 1: Desplazamiento itinerante es cuando un UE se encuentra en un área geográfica que está fuera del área geográfica de servicio del subsistema de CN de doméstico.
NOTA 2: URN de servicio de emergencia en el URI de Solicitud indica a la red que el intento de llamada de emergencia ha sido reconocido por el UE.
La siguiente modificación de la TS de 3GPP 24.229 se aplica a casos anormales:
Si el subsistema de CN de IM al que pertenece la P-CSCF no es capaz de hacerse cargo de sesiones de emergencia o, debido a un criterio local, no se hace cargo de sesiones de emergencia o únicamente se encarga de cierto tipo de petición de sesión de emergencia o no se hace cargo de sesiones de emergencia para la posición geográfica en la que el UE está situado o para la IP-CAN a la que está enganchado el UE, la P-CSCF no remitirá lapetición de INVITACIÓN. La P-CSCF:
- -
- responderá a la solicitud de INVITACIÓN con una respuesta de 380 (Servicio Alternativo);
- -
- supondrá que el UE da soporte a la versión 1 del Esquema de XML para el cuerpo de XML del subsistema de CN de IM, si no se indica que se dé soporte al cuerpo de XML de IMS según el 3GPP en la cabecera de Aceptación; e
- -
- incluirá en la respuesta de 380 (Servicio Alternativo):
o un campo de cabecera de Tipo de Contenido, con el valor ajustado al tipo de MIME asociado del cuerpo de XML de IMS de 3GPP, según se describe en la subcláusula 7. 6. 1. El cuerpo contendrá: a) un elemento de <servicio alternativo>, ajustado a los parámetros del servicio alternativo;
b) si la cabecera de Aceptación indica que se da soporte a la versión 2 del Esquema de XML para el cuerpo de XML del subsistema de CN de IM, entonces:
- o un elemento hijo <tipo> con un atributo “alternativo” ajustado a una lista de URIs de servicios de emergencia alternativos, y
• si la petición inicial de un diálogo, o transacción aislada, o método desconocido, fuera para un tipo de emergencia al que se da soporte, el elemento hijo <tipo> se ajusta en “emergencia” con el fin de indicar que se trataba de una llamada de emergencia a la que se daba soporte,
- o en caso contrario, un elemento hijo <tipo>, ajustado en "emergencia";
c) un elemento hijo <razón>, ajustado en una razón configurable por el operador; y
d) un elemento hijo <acción>, ajustado en “registro de emergencia” si la petición incluía un URN de servicio de emergencia en el URI de Solicitud.
NOTA 1: URN de servicio de emergencia en el URI de Solicitud indica a la red que el intento de llamada de emergencia ha sido reconocido por el UE.
NOTA 1a: “sip:911@example.com;user=phone” puede ser un URI de servicio de emergencia alternativo.
“urn:service:sos.animal-control” puede ser un tipo de llamada de emergencia al que no se da soporte.
NOTA 2: Algunas redes únicamente permiten peticiones de sesión con un URI de Solicitud que contenga un URN de servicio de emergencia, es decir, un URN de servicio con un tipo de servicio de nivel superior de “sos”, según se 5 especifica en la draft-ietf-ecrit-service-urn [69].
La siguiente modificación alternativa de la TS de 3GPP 24.229 se aplica a casos anormales:
Si el subsistema de CN de IM al que pertenece la P-CSCF no es capaz de hacerse cargo de sesiones de emergencia o, debido a un criterio local, no se hace cargo de sesiones de emergencia o únicamente se encarga de cierto tipo de petición de sesión de emergencia o no se hace cargo de sesiones de emergencia para la posición
10 geográfica en la que el UE está situado o para la IP-CAN a la que está enganchado el UE, la P-CSCF no remitirá la petición de INVITACIÓN. La P-CSCF:
- -
- responderá a la solicitud de INVITACIÓN CON una respuesta de 380 (Servicio Alternativo);
- -
- supondrá que el UE da soporte a la versión 1 del Esquema de XML para el cuerpo de XML del subsistema de CN de IM, si no se indica que se dé soporte al cuerpo de XML de IMS según el 3GPP en la cabecera de 15 Aceptación; e
- -
- incluirá en la respuesta de 380 (Servicio Alternativo):
o un campo de cabecera de Tipo de Contenido, con el valor ajustado al tipo de MIME asociado del cuerpo de XML de IMS de 3GPP, según se describe en la subcláusula 7. 6. 1.
El cuerpo contendrá:
20 a) un elemento de <servicio alternativo>, ajustado a los parámetros del servicio alternativo;
b) un elemento hijo <tipo> con un atributo “alternativo” ajustado a una lista de URIs de servicios de emergencia alternativos, y
- -
- si la petición inicial de un diálogo, o transacción aislada, o método desconocido, fuera para un tipo de emergencia al que se da soporte, el elemento hijo <tipo> se ajusta en “emergencia” con el fin de indicar que 25 se trataba de una llamada de emergencia a la que se daba soporte,
c) un elemento hijo <razón>, ajustado en una razón configurable por el operador; y
d) un elemento hijo <acción>, ajustado en “registro de emergencia” si la petición incluía un URN de servicio de emergencia en el URI de Solicitud.
NOTA 1: URN de servicio de emergencia en el URI de Solicitud indica a la red que el intento de llamada de 30 emergencia ha sido reconocido por el UE.
NOTA 2: Algunas redes únicamente permiten peticiones de sesión con un URI de Solicitud que contenga un URN de servicio de emergencia, es decir, un URN de servicio con un tipo de servicio de nivel superior de “sos”, según se especifica en la draft-ietf-ecrit-service-urn [69].
La siguiente modificación puede hacerse en el Esquema de XML de cuerpo de XML del subsistema de CN de IM 35 según el 3GPP, a fin de implementar una o más de las realizaciones que se describen en la presente memoria:
<xs:nombre Tipocomplejo=“tType”>
(<xs:complexType name=“tType”>) <xs:secuencia> (<xs:sequence>) <xs:nombre elemento=“emergencia” Ocurrenciamin=“0” Ocurrenciamax=“1”> (<xs:element name=“emergency” minOccurs=“0” maxOccurs=“1”>) <xs:Tipocomplejo/> (<xs:complexType/>)
</xs:elemento> (</xs:element>) <xs:cualquier espacionombre=“##cualquiera” Contenidoproceso=“lax” Ocurrenciamin=“0”
Ocurrenciamax=“no ligada”/>
(<xs:any namespace=“##any” processContents=“lax” minOccurs=“0” maxOccurs=“unbonded”/>)
</xs:secuencia>
<xs:nombre atributo=“alternativo” tipo=“cualquierlistaURI”/>
(<xs:attribute name=“alternate” type=“anyURIlist”/>)
<xs:cualquierAtributo/>
(<xs:anyAttribute/>)
</xs:Tipocomplejo>
El elemento <acción> contiene el atributo “alternativo” y únicamente el valor “registro de emergencia” en el presente documento. El atributo “alternativo puede ajustarse a una lista de URIs de servicios de emergencia alternativos.
Las dos siguientes adendas a la TS de 3GPP 24.229 se aplican a procedimientos genéricos aplicables a todos los 5 métodos, a excepción del método de REGISTRO:
Al generarse una petición inicial de un diálogo, una transacción aislada, o un método desconocido, excluidos ACK y CANCELACIÓN, el UE incluirá la cabecera de Aceptación con “aplicación/sdp” (“application/sdp”), el tipo de MIME asociado con el cuerpo de XML de IMS según el 3GPP (véase la subcláusula 7.6.1) y cualquier otro tipo de MIME que el UE desee y sea capaz de aceptar.
10 En el caso de que el UE reciba una respuesta de 380 (Servicio Alternativo) a una petición inicial de un diálogo, o una transacción aislada, o un método desconocido, incluyendo la respuesta un cuerpo de XML del subsistema de CN de IM según se ha descrito en la subcláusula 7.6 que incluye un elemento de <servicio alternativo> con el elemento hijo <tipo> ajustado en “emergencia”, el UE intentará una llamada de emergencia según se describe en la cláusula 5.1.6.
Si la respuesta 1xx o 2xx a una petición inicial de un diálogo, o una transacción aislada, o un método desconocido,
15 contiene un indicador de sesión de emergencia, entonces el UE enviará un método de petición de re-INVITACIÓN de acuerdo con la RFC 3261 [26], y:
1) el UE indicará la naturaleza de la sesión al usuario;
NOTA 17: El UE no cambia la cabecera De (“From”) para que incluya una identidad de usuario pública o el URI de tel asociado con la identidad de usuario pública, en esta versión de la especificación.
20 2) si está disponible para el UE, y si se ha definido para el tipo de acceso según se ha especificado en la subcláusula 7.2A.4, el UE incluirá una cabecera de Info-Red-Acceso-P (“P-Access-Network-Info”), y esta contendrá un identificador de posición tal como el id de celda, el id de línea o la identidad del nodo de acceso de I-WLAN;
NOTA 18: La especificación de emergencia de IMS de la TS de 3GPP 23.167 [4B] describe diversos métodos
25 mediante los cuales el UE puede obtener su información de posición de la red de acceso o de un servidor. Tales métodos no se encuentran dentro del ámbito de esta especificación.
3) el UE insertará una Identidad-Preferida-P (“P-Preferred-Identity”) que incluye la identidad de usuario pública
o el URI de tel asociado con la identidad de usuario pública, según se describe en la subcláusula 4.2;
4) si el UE tiene su información de posición disponible, entonces el URI la incluirá de la siguiente manera:
30 o si el UE está al corriente del URI que apunta adonde se encuentra almacenada la posición del UE, inclúyase el URI en la cabecera de Geoposición (“Geolocation”) de acuerdo con la draft-ietf-siplocation-conveyance [89]; o
o si la información de posición geográfica del UE está disponible para el UE, inclúyase su
información de posición geográfica como un objeto de posición de PIDF de acuerdo con la RFC 35 4119 [90], e inclúyase el objeto de posición en un cuerpo de mensaje con la aplicación/pidf+xml (“application/pidf+xml”) de tipo de contenido de acuerdo con la draft-ietf-sip-location-conveyance [89]; y
5) si el UE no tiene ninguna información de posición geográfica disponible, el UE no incluirá ninguna información de posición geográfica, según se especifica en la draft-ietf-sip-location-conveyance [89]; y
6) si se ha guardado un valor de GRUU público (pub-gruu) asociado con la identidad de usuario pública y el UE no indica la privacidad de la Identidad-Declarada-P (“P-Asserted-Identity”), entonces el UE insertará el valor de GRUU público (pub-gruu) en la cabecera de Contacto, según se especifica en la draft-ietf-sip-gruu [93]; en caso contrario,
NOTA 19: De acuerdo con la RFC 3261 [26], no puede enviarse una petición de re-INVITACIÓN mientras estéen curso, en cualquier dirección, otra transacción de INVITACIÓN.
NOTA 20: No es necesario cambiar los parámetros de la sesión para esta petición de re-INVITACIÓN.
NOTA 21: Se sugiere que el UE solo utilice la opción de proporcionar un URI cuando la parte de dominio pertenece al proveedor de P-CSCF o de S-CSCF en curso. Es este un aspecto en el que el operador de red necesita proporcionar una guía o directriz al usuario final. No es deseable un URI que únicamente sea resoluble para el UE que está realizando la llamada de emergencia.
NOTA 22: Durante el diálogo, los puntos de enganche a la IP-CAN del UE pueden cambiar (por ejemplo, el UE se conecta a diferentes celdas). El UE poblará o llenará la cabecera de Info-Red-Acceso-P en cualquier solicitud (excepto para solicitudes de ACK y solicitudes de CANCELACIÓN) o respuesta (excepto respuestas de CANCELACIÓN) dentro de un diálogo con el punto de enganche en ese momento a la IP-CAN (por ejemplo, la información de celda en curso en ese momento).
La aplicación de privacidad, incluyendo la eliminación de información de posición y de red de acceso, si el PSAP se encuentra dentro del dominio de confianza de la red, puede llevarse a cabo por elementos de red de IMS tales como la E-CSCF, la IBCF y otros. Puede preferirse que se solicite la privacidad de “sesión” (es decir, que el campo de cabecera de Privacidad se ajuste de manera que incluya el valor de “sesión”, puesto que el campo de cabecera de Info-Red-Acceso-P está presente en la mayor parte de mensajes de SIP). Puede ser preferible que la E-CSCF reciba información de posición, de tal manera que pueda determinar el PSAP más aplicable y utilizarlo a la hora de encaminar la petición al PSAP o a la central de respuesta de emergencias. Pueden también aplicarse los requisitos de privacidad de acuerdo con la RFC 4244, pero, en el presente, ningún procedimiento prevé incluir información de historial en una petición de servicios de emergencia. Las dos siguientes adendas a la TS de 3GPP 24.229 se aplican a los Procedimientos en la E-CSCF:
Cuando la E-CSCF recibe una petición de un diálogo solicitando privacidad, o una transacción aislada que solicita privacidad, o cualquier petición o respuesta relacionada con un diálogo originado por el UE y que solicita privacidad,
o transacción aislada solicitando privacidad, y si el operador local permite al usuario solicitar la supresión de identificadores de usuario públicos y de información de posición, la E-CSCF:
- -
- aplicará cualquier privacidad requerida por la RFC 3323 [33] relativa a privacidad y por la RFC 3325 [34] a la cabecera de Identidad-Declarada-P;
- -
- si está presente, eliminará el campo de cabecera de INFO-RED-ACCESO-P;
- -
- si está presente, eliminará el objeto de posición del cuerpo del mensaje y eliminará la aplicación/pifd+xml de tipo de contenido del campo de cabecera de Tipo de Contenido;
- -
- si está presente, eliminará el campo de cabecera de Geoposición.
NOTA: Los criterios del operador (por ejemplo, los requisitos para dar soporte a las comunicaciones de emergencia) pueden tener prioridad sobre la petición del usuario en cuanto a supresión.
6) seleccionará, basándose en la información de posición y, opcionalmente, en el tipo de servicio de emergencia:
o un PSAP conectado a la red de subsistema de CN de IM, y añadirá el URI de PSAP a la cabecera de Ruta más superior; o
NOTA 3: Si el usuario no ha solicitado privacidad, la E-CSCF transporta la cabecera de Info-Red-Acceso-P que contiene el identificador de posición, si se define para el tipo de acceso según se especifica en la subcláusula 7.2A.4, al PSAP.
o un PSAP de la PSTN, y añadirá el URI de BGCF a la cabecera de Ruta más superior, y añadirá un URI de PSAP en el formato de URI de tel al URI de Solicitud, de manera que se utiliza una entrada en el dominio de PSTN/CS para el direccionamiento del PSAP;
NOTA 4: Si el usuario no ha solicitado privacidad, la E-CSCF transporta la cabecera de Info-Red-Acceso-P que contiene el identificador de posición, si se ha definido para el tipo de acceso según se especifica en la subcláusula7.2A.4, hacia la MGCF. La MGCF puede traducir la información de posición si está incluida en la INVITACIÓN (es decir, tanto la información de posición geográfica contenida en PIDF-LO como el identificador de posición contenido en la cabecera de Info-Red-Acceso-P), a señalización de ISUP; véase la TS de 3GPP 29.163 [11B].
NOTA 5: La E-CSCF puede solicitar información de posición y encaminar la información desde la LRF. La E-CSCF puede enviar, por ejemplo, el identificador de posición a la LRF y la LRF correlaciona el identificador de posición con la información de posición geográfica correspondiente, que la LRF envía a la E-CSCF. La LRF puede invocar o recurrir a una RDF para convertir la información de posición en un URI de PSAP/EC adecuado. Tanto la información de posición como el URI de PSAP son devueltos a la E-CSCF.
NOTA 6: La manera como la C-CSCF determina la siguiente dirección de salto cuando la dirección de PSAP es un URI de tel, depende de la implementación.
7) Si el usuario no ha solicitado privacidad y si la E-CSCF recibe un número de referencia desde la LRF, la E-CSCF incluirá el número de referencia en la cabecera de Identidad-Declarada-P;
NOTA 7: El número de referencia se utiliza en la comunicación entre el PSAP y la LRF.
La Figura 4 ilustra un sistema de comunicaciones inalámbrico que incluye una realización del UE 110. El UE 110 es susceptible de hacerse funcionar para implementar aspectos de la invención, pero la invención no debe estar limitada por estas implementaciones. Si bien se ha ilustrado como un teléfono móvil, el UE puede adoptar diversas formas que incluyen un equipo de mano inalámbrico, un localizador portátil o busca, un asistente digital personal (PDA –“personal digital assistant”), una computadora portátil, una computadora del tipo de tableta o un ordenador portátil. Muchos dispositivos adecuados combinan algunas de estas funciones o todas ellas. En algunas realizaciones de la invención, el UE 110 no es un dispositivo informático de propósito general como una computadora portátil, un ordenador portátil o una computadora de tableta, sino que, en lugar de eso, es un dispositivo de comunicaciones de propósito especial, tal como un teléfono móvil, un equipo de mano inalámbrico, un localizador portátil o busca, o una PDA. En otra realización, el UE 110 puede ser una computadora portátil, un ordenador portátil u otro dispositivo de computación o informático. El UE 110 puede dar soporte a actividades especializadas tales como juegos, control de inventario, control de trabajo y/o funciones de gestión de tareas, y otros más.
El UE 110 incluye un dispositivo de presentación visual 402. El UE también incluye una superficie sensible al tacto, un teclado u otras teclas de entrada a las que se hace referencia generalmente como 404, para la introducción por parte de un usuario. El teclado puede ser un teclado alfanumérico completo o reducido, tal como QWERTY, Dvorak, AZERTY y de tipos secuenciales, o bien una placa o cuadro de teclas numéricas tradicional con las letras del alfabeto asociadas con un cuadro de teclas de teléfono. Las teclas de entrada pueden incluir una rueda de seguimiento, una tecla de salida o escape, una bola de seguimiento y otras teclas de desplazamiento o funcionales, las cuales pueden ser apretadas o pulsadas hacia dentro para proporcionar una función de entrada adicional. El UE 110 puede presentar opciones para su selección por parte del usuario, controles para su accionamiento por parte del usuario, y/o cursores u otros indicadores para que el usuario los dirija. El UE 110 puede aceptar, de manera adicional, la introducción de datos por parte del usuario, incluyendo números para marcar o diversos valores de parámetros para configurar el funcionamiento del UE 110. El UE 110 puede llevar a cabo, de manera adicional, una
- o más aplicaciones de software o de firmware, o software instalado permanentemente en hardware, en respuesta a las órdenes del usuario. Estas aplicaciones pueden configurar el UE 110 para que lleve a cabo diversas funciones personalizadas en respuesta a la interacción con el usuario. Adicionalmente, el UE 110 puede ser programado y/o configurado a través del aire, por ejemplo, desde una estación de base inalámbrica, un punto de acceso inalámbrico
- o un UE 110 semejante.
Entre las diversas aplicaciones susceptibles de ser ejecutadas por el UE 110, existe un explorador de web, que habilita al dispositivo de presentación visual 402 para mostrar 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ámbrica, una torre celular, un UE 110 semejante o cualquier otra red o sistema de comunicación inalámbrica 400. La red 400 está conectada a una red 408 con instalación de cables, tal como la Internet. A través del enlace inalámbrico y la red cableada, el UE 110 tiene acceso a información en varios servidores tales como el servidor 410. El servidor 410 puede proporcionar contenidos que pueden ser mostrados en el dispositivo de presentación visual 402. Alternativamente, el UE 110 puede acceder a la red 400 a través de un UE 110 semejante que actúa como intermediario, en una conexión del tipo de relé o del tipo de salto.
La Figura 5 muestra un diagrama de bloques del UE 110. Si bien se han representado una variedad de componentes conocidos de UEs 110, en una realización, puede incluirse en el UE 110 un subconjunto de los componentes listados y/o componentes adicionales no listados. El UE 110 incluye un procesador de señal digital (DSP –“digital signal processor”) 502 y una memoria 504. Como se muestra, el UE 110 puede incluir, de manera adicional, una unidad de antena y terminal frontal 506, un transmisor-receptor, o transceptor, de radiofrecuencia (RF) 508, una unidad de tratamiento de banda de base analógica 510, un micrófono 512, un altavoz de auricular 514, un acceso o puerta 516 para cascos, una interfaz de entrada / salida 518, una tarjeta de memoria extraíble 520, una puerta 522 de bus en serie universal (USB –“Universal Serial Bus”), un subsistema de comunicación inalámbrico de corto alcance 524, una alarma 526, un cuadro de teclas 528, un dispositivo de presentación visual de cristal líquido (LCD –“liquid crystal display”), que puede incluir una superficie sensible al tacto 530, un controlador 532 de LCD, una cámara 534 de dispositivo de acoplamiento de carga (CCD –“charge-coupled device”), un controlador 536 de cámara, y un sensor 538 de sistema de localización global (GPS –“global positioning system”). En una realización, el UE 110 puede incluir otra clase de dispositivo de presentación visual que no proporciona una pantalla sensible al tacto. En una realización, el DSP 502 puede comunicarse directamente con la memoria 504, sin pasar por la interfaz de entrada / salida 518.
El DSP 502 o alguna otra forma de controlador o de unidad central de procesamiento funciona para controlar los diversos componentes del UE 110 de acuerdo con software o firmware incorporado, almacenado en la memoria 504
o almacenado en la memoria contenida dentro del propio DSP 502. Además del software o el firmware incorporado, el DSP 502 pueden ejecutar otras aplicaciones almacenadas en la memoria 504 o que se hacen disponibles a través de medios portadores de información tales como medios de almacenamiento de datos portátiles, como la tarjeta de memoria extraíble 520, o a través de comunicaciones de red cableada o inalámbrica. El software de aplicación puede comprender un conjunto compilado de instrucciones legibles por la máquina, que configura el DSP 502 para proporcionar la capacidad funcional deseada, o bien el software de aplicación puede consistir en instrucciones de software de alto nivel destinadas a ser procesadas o tratadas por un intérprete o compilador a fin de configurar indirectamente el DSP 502.
La unidad de antena y terminal frontal 506 puede haberse proporcionado para la conversión entre señales inalámbricas y señales eléctricas, lo que permite al UE 110 enviar y recibir información de una red celular o alguna otra red de comunicaciones inalámbricas disponible, o desde un UE 110 semejante. En una realización, la unidad de antena y terminal frontal 506 puede incluir múltiples antenas con el fin de dar soporte a la formación del haz y/o a operaciones de múltiples entradas y múltiples salidas (MIMO –“multiple input-multiple output”). Como es conocido por los expertos de la técnica, las operaciones de MIMO pueden proporcionar diversidad espacial que puede ser utilizada para superar las condiciones difíciles de canal y/o aumentar la transferencia de datos del canal. La unidad de antena y terminal frontal 506 puede incluir componentes de sintonización de antena y/o de coincidencia de impedancia, amplificadores de potencia de RF y/o amplificadores de bajo ruido.
El transmisor-receptor de RF 508 proporciona el desplazamiento de frecuencia, la conversión de señales de RF recibidas a banda de base y la conversión de señales transmitidas en banda de base a RF. En algunas descripciones, puede entenderse que un transmisor-receptor de radio o un transmisor-receptor de RF incluye otras capacidades funcionales de tratamiento de señales, tales como la modulación / desmodulación, la codificación / descodificación, la intercalación / reversión de intercalación, la dispersión / reversión de dispersión, la transformada rápida de Fourier inversa (IFFT –“inverse fast Fourier transform”) / transformada rápida de Fourier (FFT), la adición / eliminación cíclica de prefijo, así como otras funciones de tratamiento de señales. Para propósitos de claridad, la descripción proporcionada en la presente memoria separa la descripción de este tratamiento de señal de la etapa de RF y/o de radio y asigna conceptualmente ese tratamiento de señal a la unidad de tratamiento de banda de base analógica 510 y/o al DSP 502 u otra unidad central de procesamiento. En algunas realizaciones, el Transceptor de RF 508, ciertas partes de la Antena y el Terminal Frontal 506, así como la unidad de tratamiento de banda de base analógica 510 pueden ser combinados en una o más unidades de tratamiento y/o circuitos integrados específicos de la aplicación (ASICs –“application specific integrated circuits”).
La unidad de tratamiento de banda de base analógica 510 puede proporcionar un tratamiento analógico diverso de las entradas y salidas, por ejemplo, un tratamiento analógico de las entradas procedentes del micrófono 512 y de los cascos 516, y de las salidas al auricular 514 y a los cascos 516. A este fin, la unidad de tratamiento de banda de base analógica 510 puede tener puertas para conectarse al micrófono incorporado 512 y al altavoz 514 de los auriculares, que permiten que el UE 110 sea utilizado como un teléfono celular. La unidad de tratamiento de banda de base analógica 510 puede incluir, de manera adicional, una puerta para conectarse a unos cascos o a otra configuración de micrófono y altavoz de manos libres. La unidad de tratamiento de banda de base analógica 510 puede proporcionar una conversión de digital a analógica en un sentido de las señales, y una conversión de analógica a digital en el sentido opuesto de las señales. En algunas realizaciones, al menos algunas de las capacidades funcionales de la unidad de tratamiento de banda de base analógica 510 pueden ser proporcionadas por componentes de tratamiento digital, por ejemplo, por el DSP 502 o por otras unidades centrales de procesamiento.
El DSP 502 puede llevar a cabo la modulación / desmodulación, la codificación / descodificación, la intercalación / reversión de intercalación, la dispersión / reversión de dispersión, la transformada rápida de Fourier inversa (IFFT – “inverse fast Fourier transform”) / transformada rápida de Fourier (FFT), la adición / eliminación cíclica de prefijo, así como otras funciones de tratamiento de señales asociadas con las comunicaciones inalámbricas. En una realización, por ejemplo, en una aplicación de tecnología de acceso múltiple por división en código (CDMA –“code division multiple access”), para una función de transmisor, el DSP 502 puede llevar a cabo una modulación, codificación, intercalación y dispersión, y para una función de receptor, el DSP 502 puede llevar a cabo la reversión de la dispersión, la reversión de la intercalación, la descodificación y la desmodulación. En otra realización, por ejemplo, en una aplicación de tecnología de acceso múltiple por división en frecuencia ortogonal (OFDMA –“orthogonal frequency division multiple access”), para la función de transmisor, el DSP 502 puede llevar a cabo la modulación, codificación, intercalación, transformada rápida de Fourier inversa y adición cíclica de prefijo, y para una función de receptor, el DSP 502 puede llevar a cabo la eliminación cíclica de prefijo, la transformada rápida de Fourier, la reversión de la intercalación, la descodificación y la desmodulación. En otras aplicaciones de tecnología inalámbrica, pueden llevarse a cabo por parte del DSP 502 aún otras funciones de tratamiento de señales y combinaciones de funciones de tratamiento de señales.
El DSP 502 puede comunicarse con una red inalámbrica a través de la unidad de tratamiento de banda de base analógica 510. En algunas realizaciones, la comunicación puede proporcionar capacidad de conexión o conectividad con la Internet, permitiendo al usuario obtener el acceso a contenidos de la Internet y enviar y recibir mensajes de correo electrónico o de texto. La interfaz de entrada / salida 518 interconecta el DSP 502 y diversas memorias e interfaces. La memoria 504 y la tarjera de memoria extraíble 520 pueden proporcionar programación o software y datos para configurar el funcionamiento del DSP 502. Entre las interfaces puede encontrarse la interfaz de USB 522 y el subsistema de comunicación inalámbrico de corto alcance 524. La interfaz de USB 522 pude ser utilizada para cargar el UE 110 y puede también permitir al UE 110 funcionar como dispositivo periférico a fin de intercambiar información con una computadora personal u otro sistema informático. El subsistema de comunicación inalámbrico de corto alcance 524 puede incluir una puerta de infrarrojos, una interfaz de tipo Bluetooth, una interfaz inalámbrica de conformidad con la norma IEEE 802.11, o cualquier otro subsistema de comunicación inalámbrico de corto alcance que pueda permitir al UE 110 comunicarse de forma inalámbrica con otros UEs y/o estaciones de base inalámbricas cercanos.
La interfaz de entrada / salida 518 puede conectar, de manera adicional, el DSP 502 a la alarma 526, la cual, cuando se dispara, hace que el UE 110 proporcione un aviso al usuario, por ejemplo, al sonar, reproducir una melodía o vibrar. La alarma 526 puede servir como mecanismo para alertar al usuario de cualquiera de diversos sucesos tales como una llamada entrante, un nuevo mensaje de texto y un recordatorio de cita, al vibrar en silencio o al reproducir una melodía específica previamente asignada para un llamante particular.
El cuadro de teclas 528 está conectado al DSP 502 a través de la interfaz 518 con el fin de proporcionar un mecanismo para que el usuario realice elecciones, introduzca información y proporcione de otros modos entradas al UE 110. El teclado 528 puede ser un teclado alfanumérico completo o reducido, tal como QWERTY, Dvorak, AZERTY y de tipos secuenciales. O bien un cuadro de teclas numéricas tradicional con letras del alfabeto asociadas con un cuadro de teclas de teléfono. Las teclas de entrada pueden incluir una rueda de seguimiento, una tecla de escape o salida, una bola de seguimiento así como otras teclas de desplazamiento o funcionales, las cuales pueden ser pulsadas o apretadas hacia dentro para proporcionar una función de entrada adicional. Otro mecanismo de entrada puede ser el LCD 530, el cual puede incluir la capacidad de pantalla táctil y también la presentación visual de texto y/o gráficos al usuario. El controlador de LCD 532 conecta el DSP 502 al LCD 530.
La cámara de CCD 534, si se ha instalado, permite al UE 110 tomar imágenes digitales. El DSP 502 se comunica con la cámara de CCD 534 a través del controlador 536 de cámara. En otra realización, puede emplearse una cámara que funciona de acuerdo con una tecnología diferente de la de las cámaras de Dispositivo de Acoplamiento de Carga. El sensor de GPS 538 está conectado al DSP 502 con el fin de descodificar señales del sistema de localización global, por lo que permite al UE 110 determinar su posición. Pueden haberse incluido también otros diversos dispositivos periféricos para proporcionar funciones adicionales, por ejemplo, recepción de radio y televisión.
La Figura 6 ilustra un entorno de software 602 que puede ser implementado por el DSP 502. El DSP 502 hace funcionar dispositivos de accionamiento 604 de sistema operativo que proporcionan una plataforma desde la que opera el resto del software. Los dispositivos de accionamiento 604 de sistema operativo proporcionan dispositivos de accionamiento para el hardware de nodo con interfaces normalizadas que son accesible a software de aplicación. Los dispositivos de accionamiento 604 de sistema operativo incluyen servicios de gestión de aplicación (AMS – “application management services”) 606 que transfieren el control entre aplicaciones que “corren” o marchan en el UE 110. También se han mostrado en la Figura 6 una aplicación 608 de explorador de web, una aplicación 610 de reproducir de medios de soporte de información y unas applets [componentes de aplicación ejecutadas en el contexto de otro programa] de Java 612. La aplicación 606 de explorador de web configura el UE 110 para funcionar como explorador de web, lo que permite a un usuario introducir información en formularios y seleccionar enlaces para recuperar y ver páginas web. La aplicación 610 de reproductor de medios de soporte de información configura el UE 110 para recuperar y reproducir medios de audio o audiovisuales. Las applets de Java 612 configuran el UE 110 para proporcionar juegos, utilidades y otras capacidades funcionales. Un componente 614 puede proporcionar las capacidades funcionales que se describen en esta memoria.
El UE 110 y otros componentes anteriormente descritos pueden incluir un componente de procesamiento o tratamiento que es capaz de ejecutar instrucciones relacionadas con las acciones descritas en lo anterior. La Figura 7 ilustra un ejemplo de un sistema 1300 que incluye un componente de tratamiento 1310 adecuado para implementar una o más realizaciones descritas en la presente memoria. Además del procesador 1310 (al que puede hacerse referencia como una unidad central de procesamiento o CPU (“central processing unit”)), el sistema 1300 puede incluir dispositivos 1320 de conectividad de red, memoria de acceso aleatorio (RAM –“random access memory”) 1330, memoria de solo lectura (ROM –“read only memory”) 1340, un dispositivo de almacenamiento secundario 1350 y dispositivos de entrada / salida (E/S –“I/O (input / output)”) 1360. En algunos casos, algunos de estos componentes pueden no estar presentes o pueden haberse combinado en diversas combinaciones unos con otros o con otros componentes no mostrados. Estos componentes pueden haberse asignado en una única entidad física o en más de una entidad física. Cualesquiera acciones descritas en esta memoria como adoptadas por el procesador 1310 pueden ser adoptadas por el procesador 1310 en solitario o por el procesador 1310 en combinación con uno o más componentes mostrados, o no mostrados, en los dibujos.
El procesador 1310 lleva a cabo instrucciones, códigos, programas informáticos o guiones a los que puede acceder desde los dispositivos 1320 de conectividad de red, la RAM 1330, la ROM 1340 o el dispositivo de almacenamiento secundario 1350 (el cual puede incluir diversos sistemas basados en disco, tales como un disco duro, un disco flexible o un disco óptico). Si bien se ha mostrado tan solo un procesador 1310, pueden estar presentes múltiples procesadores. De esta forma, aunque las instrucciones se han explicado como ejecutadas por un procesador, las instrucciones pueden ser ejecutadas simultáneamente, en serie o de otro modo, por uno o múltiples procesadores. El procesador 1310 puede ser implementado como uno o más circuitos integrados o chips de CPU.
Los dispositivos 1320 de conectividad de red pueden adoptar la forma de módems o moduladores-desmoduladores, bancos de módems, dispositivos de Ethernet, dispositivos de interfaz de bus en serie universal (USB), interfaces en serie, dispositivos de red en anillo, dispositivos de interfaz de datos distribuida de fibra (FDDI –“fiber distributed data interface”), dispositivos de red de área local inalámbrica (WLAN –“wireless local area network”), dispositivos transmisores-receptores de radio, tales como dispositivos transmisores-receptores de radio de acceso múltiple por división en código (CDMA) y/o de sistema global para comunicaciones móviles (GSM –“global system for mobile communications”), así como otros dispositivos bien conocidos para conexión a redes. Estos dispositivos 1320 de conectividad de red pueden permitir a un procesador 1310 comunicarse con la Internet o con una o más redes de telecomunicaciones u otras redes de las que el procesador 1310 puede recibir información o a las que el procesador 1310 puede suministrar como salida información.
Los dispositivos 1320 de conectividad de red pueden incluir también uno o más componentes transmisoresreceptores 1325, capaces de transmitir y/o recibir datos de manera inalámbrica en forma de ondas electromagnéticas, tales como señales de radiofrecuencia o señales de frecuencia de microondas. Alternativamente, los datos pueden propagarse dentro de, o por la superficie de, conductores eléctricos, por el interior de cables coaxiales, por el interior de guías de ondas, en el seno de medios ópticos tales como la fibra óptica, o en otros medios. El componente transmisor-receptor 1325 puede incluir unidades de recepción y de transmisión independientes, o un único transmisor-receptor. La información transmitida o recibida por el transmisor-receptor 1325 puede incluir datos que han sido tratados por el procesador 1310 o instrucciones que se han de ejecutar por el procesador 1310. Tal información puede ser recibida desde una red o suministrada como salida a la misma en forma de, por ejemplo, una señal de banda de base de datos informáticos, o una señal incorporada en una onda portadora. Los datos pueden ser ordenados de acuerdo con diferentes secuencias, según pueda ser deseable, bien para el tratamiento o la generación de los datos o bien para la transmisión o la recepción de los datos. Puede hacerse referencia a la señal de banda de base, a la señal incorporada en la onda portadora o a otros tipos de señales que se utilizan en la actualidad o que se desarrollen en un futuro, como el medio de transmisión, y pueden ser generadas de acuerdo con diversos métodos bien conocidos por un experto de la técnica.
La RAM 1330 puede ser utilizada para almacenar datos volátiles y, quizá, para almacenar instrucciones que son ejecutadas por el procesador 1310. La ROM 1340 es un dispositivo de memoria no volátil que tiene, típicamente, una capacidad de memoria más pequeña que la capacidad de memoria del dispositivo de almacenamiento secundario 1350. La ROM 1340 puede ser utilizada para almacenar instrucciones y, quizá, datos que son leídos durante la ejecución de las instrucciones. El acceso tanto a la RAM 1330 como a la ROM 130 es, por lo común, más rápido que al dispositivo de almacenamiento secundario 1350. El dispositivo de almacenamiento secundario 1350 consta, por lo común, de uno o más dispositivos de accionamiento de disco o dispositivos de accionamiento de cinta magnética y puede ser utilizado para el almacenamiento no volátil de datos o como un dispositivo de almacenamiento de datos de desbordamiento o flujo excesivo si la RAM 1330 no es lo bastante grande para albergar todos los datos de trabajo. El dispositivo de almacenamiento secundario 1350 puede ser utilizado para almacenar programas que son cargados en la RAM 1330 cuando se seleccionan tales programas para su ejecución.
Los dispositivos de E/S 1360 pueden incluir dispositivos de presentación visual de cristal líquido (LCDs), dispositivos de presentación visual de pantalla táctil, teclados, placas o cuadros de teclas, conmutadores, diales, ratones, bolas de seguimiento, reconocedores de voz, lectores de tarjetas, lectores de cinta de papel, impresoras, pantallas de vídeo u otros dispositivos de entrada bien conocidos. También, el transmisor-receptor 1325 puede ser considerado como un componente de los dispositivos de E/S 1320, en lugar de, o además de, ser un componente de los dispositivos 1320 de conectividad de red. Algunos de los dispositivos de E/S 1360, o todos ellos, pueden ser sustancialmente similares a diversos componentes representados en el dibujo previamente descrito del UE 110, tales como el dispositivo de presentación visual 402 y la entrada 404.
En una realización, se proporciona un método para que un componente de red se haga cargo de las 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 se relaciona con una emergencia, el componente de red se configura de forma alternativa, basándose en configuraciones y en criterios reguladores, a fin de llevar a cabo una de entre: 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 –“Session Initiation Protocol”) enviada a un equipo de usuario (UE –“user equipment”) que inició la petición; no aceptar la petición, rechazando la petición; no aceptar la petición e indicar información de contacto alternativa para una central de respuesta de emergencias a la que fue dirigida la petición.
En una realización, se envía una respuesta de SIP (Protocolo de Inicio de Sesión) al UE en respuesta al hecho de que el UE realice una llamada respecto a la cual el UE no está al corriente de que es una llamada de emergencia.
Si existe un identificador de recursos uniformes de agente de usuario susceptible de encaminarse globalmente (GRUU) 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 puede ser reemplazado por el GRUU no temporal únicamente cuando no se ha hecho una petición para mantener el GRUU privado.
Si está presente un Identificador de Servicio de Comunicación de IMS (ICSI –“IMS Communication Service Identifier”) o un Identificador de Referencia de Aplicación de IMS (IARI –“IMS Application Reference Identifier”), antes de que la Solicitud sea encaminada a un PSAP o central de emergencias, el componente de red lleva a cabo al menos una de entre: eliminar campos de cabecera de Servicio-Preferido-P (“P-Preferred-Service”); eliminar campos de cabecera de Servicio-Declarado-P (“P-Asserted-Service”); eliminar etiquetas de características de ICSI y valores de etiquetas de los campos de cabecera de Aceptar-Contacto (“Accept-Contact”); y eliminar etiquetas de características de IARI y valores de etiquetas de los campos de cabecera de Aceptar-Contacto.
Cuando el componente de red no acepta la petición, el componente de red responde con un mensaje de 300 (Múltiples Opciones), un mensaje de 301 (Trasladado Permanentemente), un mensaje de 302 (Trasladado Temporalmente), una respuesta 4xx de SIP, una respuesta 6xx de SIP, o una respuesta de 380 de SIP (Servicio Alternativo).
En una realización, el componente de red no acepta la petición debido a al menos una de entre estas causas: la red no es capaz de hacerse cargo de sesiones de emergencia; un subsistema de red de núcleo multimedia de Internet al que pertenece el componente de red no es capaz de hacerse cargo de sesiones de emergencia; la red no se encarga de sesiones de emergencia debido a una política o criterio local; la red únicamente se hace cargo de ciertos tipos de peticiones de sesión de emergencia; el UE está en desplazamiento itinerante; el componente de red es una red diferente a la red del operador doméstico del UE; y la red no da soporte a sesiones de emergencia para una de entre la posición geográfica donde está situado en UE y la Red de Acceso de Conectividad de Protocolo de Internet a la que está enganchado el UE.
En una realización, el componente de red incluye una lista configurable con identificadores de servicios de emergencia de los socios en desplazamiento itinerante, que indica el manejo de las peticiones según una pauta por cada identificador de servicio de emergencia. Cuando el componente de red no acepta la petición, una lista configurable de identificadores de servicios de emergencia alternativos es enviada al UE. Puede ser presentado al usuario del UE el al menos un URI de servicio de emergencia alternativo.
En una realización, el componente de red, en lugar de no aceptar la petición de un tipo de servicio de emergencia al que no se da soporte, prepara la petición para remitirla a la red doméstica del UE. La red doméstica del UE puede estar configurada para hacerse cargo del valor de URI asociado con la petición.
En una realización, el componente de red es una función de control de sesión de llamada de representante (P-CSCF –“proxy call session control function”).
En una realización, las peticiones comprenden peticiones de SIP iniciales de un diálogo, transacciones de SIP individuales o aisladas, o métodos de SIP desconocidos.
En una realización alternativa, se proporciona un equipo de usuario. El equipo de usuario comprende un componente, de tal manera que, en respuesta a la realización de una petición de emergencia que es rechazada, el componente se ha configurado para recibir un mensaje que contiene información que asocia la petición de emergencia con una central de emergencias combinada. El componente puede haberse configurado, adicionalmente, para utilizar la información al objeto de realizar una solicitud de emergencia subsiguiente a la central de emergencias combinada.
En una realización alternativa, se proporciona un componente de red. El componente de red comprende un componente tal, que, al recibir una petición de emergencia procedente de un equipo de usuario, el componente se ha configurado para determinar si la petición de emergencia está relacionada con una central de emergencias combinada, y para enviar al equipo de usuario un mensaje que contiene información que indica que la petición de emergencia está relacionada con una central de emergencias combinada.
En una realización alternativa, se proporciona un equipo de usuario. El equipo de usuario comprende un
5 componente configurado para recibir un mensaje de rechazo que contiene información de dirección alternativa que asocia una solicitud de emergencia con una pluralidad de centrales de emergencias, centrales que no son de emergencia, o centrales de emergencias combinadas. La información de dirección alternativa puede ser utilizada para determinar a cuál de la pluralidad de centrales se ha de encaminar una emergencia.
En una realización alternativa, se proporciona un componente de red. El componente de red comprende un
10 componente configurado para determinar si una petición recibida es una solicitud de emergencia y si la petición recibida está relacionada con una o más centrales de emergencias específicas, centrales de emergencia combinadas o centrales que no son de 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 una relación de correspondencia o correlación entre la petición recibida, un contexto de telefonía y uno o más tipos de identificador
15 de emergencia opcionales.
Se incorporan a la presente memoria como referencia las siguientes Especificaciones Técnicas (TS –“Technical Specifications”) del Proyecto de Sociedad de Tercera Generación (3GPP –“3rd Generation Partnership Project”): TS
Claims (19)
- REIVINDICACIONES1.-Un aparato que comprende:un componente de red, configurado para:recibir desde un equipo de usuario (“UE”) (110) un mensaje de petición de Protocolo de Inicio de Sesión (“SIP”) para un diálogo (140), que es una petición relacionada con una emergencia;enviar al UE (110) un mensaje (150) de respuesta de SIP que contiene un campo de cabecera de Identidad-Declarada-P con un indicador (160) que indica que el mensaje de petición de SIP para un diálogo (140) es una petición relacionada con una emergencia; yrecibir del UE (110), en repuesta al mensaje (150) de respuesta de SIP, un mensaje de petición de SIP dentro del diálogo (170), de tal manera que el mensaje de petición de SIP contenido en el diálogo (170) contiene información (180) relacionada con una emergencia, asociada con el UE (110).
- 2.-Un método para que un componente de red gestione información relacionada con una emergencia, que comprende:recibir de un equipo de usuario (“UE”) (110) un mensaje de petición de Protocolo de Inicio de Sesión (“SIP”) para un diálogo (140), que es una petición relacionada con una emergencia;enviar desde el componente de red al UE (110) un mensaje (150) de respuesta de SIP que contiene un campo de cabecera de Identidad-Declarada-P con un indicador (160) que indica que un mensaje de petición de SIP para un diálogo (170), enviado por el UE (110), es una petición relacionada con una emergencia; yrecibir del UE (110), en respuesta al mensaje (150) de respuesta de SIP, un mensaje de petición de SIP contenido dentro del diálogo (170), de tal modo que el mensaje de petición de SIP contenido en el diálogo(170) contiene información (180) relacionada con una emergencia, asociada con el UE (110).
- 3.-El aparato de acuerdo con la reivindicación 1 o con el método de acuerdo con la reivindicación 2, en el cual la información (180) relacionada con una emergencia, asociada con el UE (110) y contenida en el mensaje de petición de SIP, dentro del diálogo (170), comprende una identidad de UE.
- 4.-El aparato o el método de acuerdo con la reivindicación 3, en el cual la identidad de UE es un identificador de recursos uniformes de agente de usuario susceptible de ser encaminado globalmente (“GRUU”).
- 5.-El aparato de acuerdo con la reivindicación 1 o con el método de acuerdo con la reivindicación 2, en el cual la información (180) relacionada con una emergencia, asociada con el UE (110) y contenida en el mensaje de petición de SIP, dentro del diálogo (170), comprende una posición de UE.
- 6.-El aparato de acuerdo con la reivindicación 1 o con el método de acuerdo con la reivindicación 2, en el cual la información (180) relacionada con una emergencia, asociada con el UE (110) y contenida en el mensaje de petición de SIP, dentro del diálogo (170), comprende información de red de acceso de UE.
- 7.-El aparato o el método de acuerdo con cualquiera de las reivindicaciones precedentes, en el cual el componente de red es una función de control de sesión de llamada de emergencia (“E-CSCF”).
- 8.-El aparato o el método de acuerdo con cualquiera de las reivindicaciones precedentes, en el cual el mensaje(150) de respuesta de SIP es uno de entre una respuesta 1xx de SIP o una respuesta de 200 (OK).
- 9.-El aparato o el método de acuerdo con cualquiera de las reivindicaciones precedentes, en el cual el mensaje de petición de SIP contenido en el diálogo (170) es uno de entre:un ACK DE SIP;un PRACK DE SIP;un refrescamiento de objetivo de SIP;una ACTUALIZACIÓN DE SIP; yuna petición de RE-INVITACIÓN DE SIP.
- 10.-El aparato o el método de acuerdo con una cualquiera de las reivindicaciones precedentes, en el cual un campo de cabecera de geoposición del mensaje de petición de SIP, dentro del diálogo (170), incluye un URI (Identificador de Recursos Uniformes) que señala a la posición del UE.
- 11.-El aparato o el método de acuerdo con cualquiera de las reivindicaciones precedentes, en el cual el cuerpo de mensaje del mensaje de petición de SIP, dentro del diálogo (170), incluye información de posición geográfica (180) del UE (110), como un objeto de posición de PIDF.
- 12.-El aparato o el método de acuerdo con cualquiera de las reivindicaciones precedentes, en el cual un campo de cabecera de contacto del mensaje de petición de SIP, dentro del diálogo (170), incluye un valor de GRUU público asociado con una identidad de usuario pública.
- 13.-El aparato o el método de acuerdo con la reivindicación 6, en el cual la información de red de acceso de UE está incluida en un campo de cabecera de Info-Red-Acceso-P contenido en el mensaje de petición de SIP, dentro del diálogo (170), y comprende uno de entre un identificador de posición, un identificador de celda, o una identidad de un nodo de acceso de I-WLAN.
- 14.-El aparato o el método de acuerdo con cualquiera de las reivindicaciones precedentes, en el cual el indicador(160) que indica que un mensaje de petición de SIP para un diálogo (140) es una petición relacionada con una emergencia, es un Nombre de Recursos Uniformes (“URN”).
- 15.-El aparato o el método de acuerdo con la reivindicación 14, en el cual el URN indica una función de PSAP.
- 16.-El aparato o el método de acuerdo con cualquiera de las reivindicaciones precedentes, en el cual el indicador indica el 911 general.
- 17.-Un medio legible por computadora, que almacena instrucciones legibles por computadora y ejecutables por un procesador de un dispositivo informático con el fin de hacer que dicho dispositivo implemente el método de acuerdo con cualquiera de las reivindicaciones 2-16.
- 18.-Un aparato que comprende:un componente de red, configurado para:recibir de un equipo de usuario (“UE”) (110) un mensaje de petición de Protocolo de Inicio de Sesión (“SIP”) para un diálogo (140), que es una petición relacionada con una emergencia;enviar al UE (110) un mensaje (150) de respuesta de SIP que contiene un Identificador de Recursos Uniformes (“URI”) que indica que el mensaje de petición de SIP para un diálogo (170) es una petición relacionada con una emergencia; yrecibir del UE (110), en respuesta al mensaje (150) de respuesta de SIP, un mensaje de petición de SIP contenido dentro del diálogo (170), de tal modo que el mensaje de petición de SIP contenido en el diálogo(170) contiene información (180) relacionada con una emergencia, asociada con el UE (110).
- 19.-El aparato de acuerdo con la reivindicación 18, en el cual el URI está comprendido dentro de un campo de cabecera de SIP.
Applications Claiming Priority (7)
| 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 | ||
| PCT/US2009/045990 WO2009149096A1 (en) | 2008-06-02 | 2009-06-02 | System and method for managing emergency requests |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2393301T3 true ES2393301T3 (es) | 2012-12-20 |
Family
ID=40972853
Family Applications (2)
| 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 |
| ES12172479.3T Active ES2440344T3 (es) | 2008-06-02 | 2009-06-02 | Sistema y método para gestionar llamadas de emergencia |
Family Applications After (1)
| 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 |
Country Status (9)
| 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) | ES2393301T3 (es) |
| MX (1) | MX2010013081A (es) |
| WO (1) | WO2009149096A1 (es) |
Families Citing this family (27)
| 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 |
| ES2393301T3 (es) | 2008-06-02 | 2012-12-20 | Research In Motion Limited | Sistema y método para gestionar solicitudes de emergencia |
| 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 |
| US9848021B2 (en) * | 2012-02-07 | 2017-12-19 | Telefonaktiebolaget Lm Ericcson (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业务自动开通方法、装置及网元 |
| RS59582B1 (sr) * | 2017-03-22 | 2019-12-31 | Deutsche Telekom Ag | Postupak za unapređeno rukovanje hitnim pozivom sa komutacijom paketa unutar telekomunikacione mreže i/ili za poboljšano rukovanje informacijama o lokalnoj službi za hitne slučajeve pomoću korisničke opreme, sistema, korisničke opreme i programa |
| CN111512654B (zh) * | 2017-10-30 | 2023-06-13 | 瑞典爱立信有限公司 | 支持对于VoLTE的人工漫游 |
| US10433145B2 (en) | 2017-12-22 | 2019-10-01 | At&T Intellectual Property I, L.P. | System and method for device-based E911 call trigger |
| US10349257B1 (en) * | 2017-12-29 | 2019-07-09 | Blackberry Limited | Methods and systems for provisioning emergency numbers |
| EP3777264A1 (en) * | 2018-04-09 | 2021-02-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. |
| CN114554456B (zh) * | 2020-11-26 | 2025-03-07 | 华为技术有限公司 | 一种数据传输方法及装置 |
| US12335048B2 (en) * | 2021-09-16 | 2025-06-17 | Apple Inc. | Efficient communication in limited resource environments |
| US12200021B2 (en) | 2021-11-04 | 2025-01-14 | Charter Communications Operating, Llc | Continued PCMM session establishment |
| WO2026036379A1 (en) * | 2024-08-16 | 2026-02-19 | Guangdong Oppo Mobile Telecommunications Corp., Ltd. | Emergency information sending method and user equipment |
| US20260067397A1 (en) * | 2024-08-29 | 2026-03-05 | Intrado Life & Safety, Inc. | Public safety answering point outage callback |
Family Cites Families (39)
| 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 |
| PT1386509E (pt) * | 2001-04-27 | 2010-07-27 | Nokia Corp | TERMINAL DE UTILIZADOR, ELEMENTO DE REDE E MéTODO E SISTEMA DE COMUNICAÃO PARA O ESTABELECIMENTO DE UMA SESSO DE EMERGNCIA |
| CN1625914B (zh) | 2002-05-06 | 2010-12-08 | 诺基亚公司 | 在通信网络中处理特定类型会话的系统和方法 |
| 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 |
| KR101030627B1 (ko) * | 2005-08-02 | 2011-04-20 | 콸콤 인코포레이티드 | Ｖｏｉｐ 긴급 호출 처리 |
| 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 |
| US7676234B2 (en) | 2005-11-23 | 2010-03-09 | Research In Motion Limited | Routing of a short message originated by a mobile device |
| 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 |
| 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 |
| WO2008022554A1 (en) | 2006-08-16 | 2008-02-28 | Huawei Technologies Co., Ltd. | Method and apparatus for transmit-receiving emergency services |
| 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) |
| US20090296689A1 (en) | 2008-06-02 | 2009-12-03 | Research In Motion Limited | Privacy-Related Requests for an IMS Emergency Session |
| ES2393301T3 (es) | 2008-06-02 | 2012-12-20 | Research In Motion Limited | Sistema y método para gestionar solicitudes de emergencia |
| 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 |
-
2009
- 2009-06-02 ES ES09759255T patent/ES2393301T3/es active Active
- 2009-06-02 JP JP2011511905A patent/JP5244969B2/ja active Active
- 2009-06-02 MX MX2010013081A patent/MX2010013081A/es active IP Right Grant
- 2009-06-02 WO PCT/US2009/045990 patent/WO2009149096A1/en not_active Ceased
- 2009-06-02 CA CA2726627A patent/CA2726627C/en active Active
- 2009-06-02 EP EP09759255A patent/EP2260633B1/en active Active
- 2009-06-02 CN CN200980130795.5A patent/CN102113293B/zh active Active
- 2009-06-02 ES ES12172479.3T patent/ES2440344T3/es active Active
- 2009-06-02 KR KR1020107029766A patent/KR101281844B1/ko active Active
-
2015
- 2015-12-14 US US14/968,686 patent/US9462616B2/en active Active
-
2016
- 2016-08-31 US US15/253,036 patent/US9814082B2/en active Active
-
2017
- 2017-10-20 US US15/789,586 patent/US10187924B2/en active Active
-
2018
- 2018-11-15 US US16/192,613 patent/US10631360B2/en active Active
-
2020
- 2020-03-18 US US16/823,174 patent/US10856359B2/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| CN102113293B (zh) | 2016-08-03 |
| KR101281844B1 (ko) | 2013-08-23 |
| JP5244969B2 (ja) | 2013-07-24 |
| US9462616B2 (en) | 2016-10-04 |
| HK1151148A1 (en) | 2012-01-20 |
| EP2260633A1 (en) | 2010-12-15 |
| JP2011524674A (ja) | 2011-09-01 |
| US10187924B2 (en) | 2019-01-22 |
| US20200221537A1 (en) | 2020-07-09 |
| ES2440344T3 (es) | 2014-01-28 |
| US10856359B2 (en) | 2020-12-01 |
| KR20110015654A (ko) | 2011-02-16 |
| US20160100435A1 (en) | 2016-04-07 |
| CA2726627C (en) | 2014-01-21 |
| CN102113293A (zh) | 2011-06-29 |
| WO2009149096A1 (en) | 2009-12-10 |
| US20180042055A1 (en) | 2018-02-08 |
| US9814082B2 (en) | 2017-11-07 |
| US20160374117A1 (en) | 2016-12-22 |
| CA2726627A1 (en) | 2009-12-10 |
| US10631360B2 (en) | 2020-04-21 |
| MX2010013081A (es) | 2011-03-03 |
| US20190090303A1 (en) | 2019-03-21 |
| EP2260633B1 (en) | 2012-08-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2393301T3 (es) | Sistema y método para gestionar solicitudes de emergencia | |
| ES2392141T3 (es) | Codificación y comportamiento cuando se recibe un indicador de sesión de emergencia de ims desde una fuente autorizada | |
| US8369824B2 (en) | Privacy-related requests for an IMS emergency session | |
| US8478226B2 (en) | Updating a request related to an IMS emergency session | |
| HK1212123B (en) | Coding and behavior when receiving an ims emergency session indicator from authorized source | |
| HK1212123A1 (en) | Coding and behavior when receiving an ims emergency session indicator from authorized source | |
| HK1150915B (en) | Coding and behavior when receiving an ims emergency session indicator from authorized source | |
| HK1177836B (en) | Coding and behavior when receiving an ims emergency session indicator from authorized source | |
| HK1151148B (en) | System and method for managing emergency requests | |
| HK1151147A (en) | Privacy-related requests for an ims emergency session | |
| HK1151147B (en) | Privacy-related requests for an ims emergency session |