ES2729752T3

ES2729752T3 - Control de la transferencia de datos telemáticos mediante señalización relacionada con la sesión

Info

Publication number: ES2729752T3
Application number: ES13774889T
Authority: ES
Inventors: Randall Coleman Gellens; Nikolai Konrad Leung; Stephen William Edge; David Hugh Williams
Original assignee: Qualcomm Inc
Current assignee: Qualcomm Inc
Priority date: 2012-09-28
Filing date: 2013-09-27
Publication date: 2019-11-06
Anticipated expiration: 2033-09-27
Also published as: CN104704865A; HUE043615T2; EP2901727B1; US20140094210A1; JP6126228B2; CN104704865B; CN110099110B; CN110099110A; KR101751147B1; US9521526B2; WO2014052845A1; EP2901727A1; JP2016502293A; KR20150063082A

Abstract

Un procedimiento de comunicación de datos telemáticos (1800), que comprende: transmitir un primer mensaje de señalización (500) desde un primer dispositivo (110) a un segundo dispositivo (160) a través de un protocolo de señalización de sesión de comunicación, donde el primer mensaje de señalización (500) comprende al menos un primer conjunto de información de sesión (515) relacionada con una sesión de comunicación entre el primer dispositivo (110) y el segundo dispositivo (160) y un primer conjunto de datos telemáticos (520) para el primer dispositivo (110); y recibir un segundo mensaje de señalización (900) en el primer dispositivo (110) a través del protocolo de señalización de sesión de comunicación, donde el segundo mensaje de señalización (900) comprende metadatos (920) basados en un contenido del primer conjunto de datos telemáticos (520) transmitidos en el primer mensaje de señalización (500).

Description

DESCRIPCIÓN

Control de la transferencia de datos telemáticos mediante señalización relacionada con la sesión

REFERENCIAS CRUZADAS

[0001] La presente solicitud de patente reivindica el beneficio de prioridad de la solicitud de patente provisional estadounidense n.° 61/707,779, titulada "Acknowledging or Re-requesting Telematics Data Using Call Signaling" [Confirmación o nueva solicitud de datos telemáticos mediante señalización de llamadas] de Gellens et al., presentada el 28 de septiembre de 2012 y asignada al cesionario de la misma.

ANTECEDENTES

[0002] Lo siguiente se refiere en general a la comunicación inalámbrica, y más específicamente a la transmisión y recepción inalámbricas de datos y metadatos telemáticos. En algunos sistemas, los datos telemáticos (por ejemplo, lecturas de sensores y otros datos) pueden transmitirse desde un terminal inteligente a un servicio central para su procesamiento. Por ejemplo, un terminal asociado con un vehículo que experimenta una colisión puede transmitir datos de ubicación y despliegue del airbag a través de un sistema de comunicación inalámbrica a un punto de respuesta de seguridad pública (PSAP) en relación con una solicitud de servicios de emergencia. En algunos sistemas, los datos pueden transmitirse a un centro de servicio de terceros, que luego puede transmitir algunos o todos los datos a un PSAP.

[0003] Los terminales asociados con vehículos que ofrecen respuesta automática a choques y la funcionalidad de llamadas de emergencia usan en general el canal de voz de una red celular para establecer una llamada de voz entre un ocupante del vehículo y un operador de PSAP. Los datos telemáticos pueden transmitirse después desde el terminal a un servicio central (por ejemplo, un servidor PSAP o un centro de servicio de terceros) mediante la modulación del canal de voz usando señalización en banda, tonos de Baudot u otras técnicas modernas. Los metadatos asociados con los datos telemáticos, tales como la confirmación de que los datos telemáticos o una solicitud de retransmisión de los datos telemáticos se han recibido satisfactoriamente (por ejemplo, con éxito), también pueden comunicarse desde el servicio central al terminal mediante la modulación del canal de voz en sentido inverso. Esta manera de transmitir datos y metadatos telemáticos a través de un canal de voz puede ser problemática, ya que la comunicación de voz puede bloquearse o sufrir interferencias durante la transmisión de datos y metadatos telemáticos. Además, la transmisión de datos digitales modulados a través de canales de voz puede proporcionar un caudal de tráfico de datos limitado o ser poco fiable debido a las funciones de procesamiento de voz en la red (por ejemplo, compensadores de eco sintonizados incorrectamente y el uso de compresión en enlaces troncales de red). Estas limitaciones pueden exacerbarse aún más en sistemas tales como evolución a largo plazo (LTE) y acceso a paquetes de alta velocidad (HSPA) cuando se proporciona un canal de voz a través de paquetes en lugar de medios de circuito. Por lo tanto, se necesitan procedimientos más eficientes y fiables para transmitir datos y metadatos telemáticos entre un terminal y un servicio central.

Se presta atención al documento US 2010/202368 A1, que describe procedimientos y aparatos para proporcionar datos útiles en asociación con una llamada de alta prioridad, tal como una llamada de emergencia. En un ejemplo, los datos comprenden un dato (por ejemplo, un MSD o FSD) incorporado en uno o más paquetes de protocolo en tiempo real, tales como paquetes del Protocolo de Control RTP (RTCP), que están intercalados dentro del flujo de datos de voz o de usuario (transportados en, por ejemplo, paquetes RTP) de una llamada de emergencia. Se describen aparatos y procedimientos para transmitir la porción de datos de manera fiable desde el terminal de inicio (por ejemplo, un sistema en el vehículo) a un punto de respuesta de seguridad pública (PSAP), usando la misma conexión de transporte que los datos de usuario.

Se presta también atención al documento US 7 904 219 B1 que describe un sistema telemático que incluye un dispositivo telemático con un controlador en comunicación con un sistema de diagnóstico configurado para recibir información de diagnóstico desde un vehículo anfitrión; un sistema de localización de posición configurado para determinar información de ubicación del vehículo anfitrión; un transceptor inalámbrico configurado para transmitir y recibir información a través de una red inalámbrica hacia y desde al menos un sitio web con acceso a Internet; y una interfaz de comunicación que incluye al menos una interfaz inalámbrica de corto alcance. El dispositivo telemático está configurado además para comunicarse con al menos un dispositivo o sensor de acceso que no sea el sistema de diagnóstico y el sistema de localización de posición, y la interfaz de comunicación está configurada para interactuar de manera universal con una pluralidad de dispositivos o sensores de acceso.

SUMARIO

[0004] De acuerdo con la presente invención, se proporcionan procedimientos y aparatos como los descritos en las reivindicaciones independientes, respectivamente. Los modos de realización preferentes de la invención se describen en las reivindicaciones dependientes.

[0005] Las características descritas se refieren en general a procedimientos y/o aparatos para comunicar datos telemáticos. Los datos telemáticos incluyen datos telemáticos que se envían desde un terminal a un servicio central y metadatos que se envían desde el servicio central al terminal. Los mensajes de señalización utilizados en un protocolo de señalización de sesión de comunicación pueden modificarse para incluir los datos telemáticos. Por ejemplo, un primer mensaje de señalización enviado desde el terminal puede incluir información de sesión y datos telemáticos. En un ejemplo, la información de sesión puede incluir una solicitud para iniciar una sesión de comunicación entre el terminal y el servicio central. En otro ejemplo, la información de sesión puede incluir información relacionada con una sesión de comunicación ya existente entre el terminal y el servicio central. Un segundo mensaje de señalización puede ser enviado desde el servicio central al terminal. El segundo mensaje puede incluir metadatos basados en los datos telemáticos recibidos. Los metadatos pueden incluir, por ejemplo, una confirmación de si los datos telemáticos se recibieron en el servicio central, una solicitud para retransmitir los datos telemáticos, una solicitud para transmitir diferentes datos telemáticos, una solicitud para realizar alguna otra acción, datos auxiliares que describen acciones realizadas por el servicio central y/u otros metadatos telemáticos pertinentes. En algunas configuraciones, el segundo mensaje de señalización también puede incluir información de sesión relacionada con la sesión de comunicación.

[0006] En un modo de realización se describe un procedimiento para comunicar datos telemáticos. Un primer mensaje de señalización se transmite desde un primer dispositivo a un segundo dispositivo a través de un protocolo de señalización de sesión de comunicación. El primer mensaje de señalización incluye al menos un primer conjunto de información de sesión relacionada con una sesión de comunicación entre el primer dispositivo y el segundo dispositivo y un primer conjunto de datos telemáticos para el primer dispositivo. Se recibe un segundo mensaje de señalización en el primer dispositivo a través del protocolo de señalización de sesión de comunicación. El segundo mensaje de señalización incluye metadatos basados en el contenido del primer conjunto de datos telemáticos transmitidos en el primer mensaje de señalización.

[0007] En algunos modos de realización, el primer conjunto de información de sesión puede incluir una solicitud para iniciar la sesión de comunicación o información asociada con la sesión de comunicación. En algunos casos, el segundo mensaje de señalización puede incluir un segundo conjunto de información de sesión relacionada con la sesión de comunicación.

[0008] En algunos modos de realización, recibir el segundo mensaje de señalización a través del protocolo de señalización de sesión de comunicación puede incluir recibir una indicación de si el primer conjunto de datos telemáticos se recibió satisfactoriamente en el segundo dispositivo. La indicación puede incluir los metadatos basados en el contenido del primer conjunto de datos telemáticos.

[0009] En algunos modos de realización, recibir el segundo mensaje de señalización a través del protocolo de señalización de sesión de comunicación puede incluir además recibir una solicitud con respecto al primer conjunto de datos telemáticos. La solicitud puede incluir los metadatos basados en el contenido del primer conjunto de datos telemáticos. En un ejemplo, la solicitud puede incluir una solicitud para retransmitir el primer conjunto de datos telemáticos, una solicitud para transmitir una versión actualizada del primer conjunto de datos telemáticos, o una solicitud para transmitir un conjunto diferente de datos telemáticos.

[0010] En algunos modos de realización, un tercer mensaje de señalización puede transmitirse desde el primer dispositivo al segundo dispositivo a través del protocolo de señalización de sesión de comunicación. El tercer mensaje de señalización puede incluir al menos una respuesta a la solicitud recibida con respecto al primer conjunto de datos telemáticos.

[0011] En algunos modos de realización, recibir el segundo mensaje de señalización a través del protocolo de señalización de sesión de comunicación puede incluir además recibir una instrucción del segundo dispositivo para realizar al menos una acción basándose en el contenido del primer conjunto de datos telemáticos. La instrucción puede incluir los metadatos basados en el contenido del primer conjunto de datos telemáticos. La al menos una acción puede incluir al menos una de: recopilar datos telemáticos adicionales, realizar una acción que afecte al estado de un vehículo, activar un componente de un vehículo, desactivar un componente de un vehículo, apagar el motor de un vehículo, encender el motor de un vehículo, interrumpir el suministro de combustible de un vehículo, iniciar el suministro de combustible de un vehículo, abrir una puerta, cerrar una puerta, hacer sonar el claxon de un vehículo, activar un sonido audible externamente, encender las luces de un vehículo, encender los intermitentes de un vehículo, accionar una ventana eléctrica, reproducir un mensaje grabado, mostrar información multimedia o mostrar un mensaje de texto.

[0012] En algunos modos de realización, se puede determinar a partir de la cabecera del segundo mensaje de señalización que al menos una parte de un cuerpo del segundo mensaje de señalización incluye los metadatos. En un ejemplo, se puede determinar a partir de la cabecera del segundo mensaje de señalización que el cuerpo del segundo mensaje de señalización incluye un formato multiparte. En este ejemplo, una primera parte del cuerpo del segundo mensaje de señalización puede identificarse de acuerdo con la información de la cabecera. La primera parte del cuerpo del segundo mensaje de señalización puede incluir al menos el segundo conjunto de información de sesión relacionada con la sesión de comunicación. En este ejemplo, una segunda parte del cuerpo del segundo mensaje de señalización puede identificarse de acuerdo con la información de la cabecera. La segunda parte del cuerpo del segundo mensaje de señalización puede incluir al menos los metadatos basados en el contenido del primer conjunto de datos telemáticos transmitidos en el primer mensaje de señalización.

[0013] En algunos modos de realización, se puede generar una cabecera para el primer mensaje de señalización basándose en el protocolo de señalización de sesión de comunicación. La cabecera puede incluir una indicación de que al menos una parte de un cuerpo del primer mensaje de señalización incluye el primer conjunto de datos telemáticos. En algunos casos, el primer conjunto de información de sesión puede formatearse de acuerdo con un primer protocolo y el primer conjunto de datos telemáticos puede formatearse de acuerdo con un segundo protocolo. En estos casos, el primer conjunto formateado de información de sesión y el primer conjunto formateado de datos telemáticos pueden combinarse para generar el cuerpo del primer mensaje de señalización.

[0014] En algunos modos de realización, el primer mensaje de señalización puede incluir una invitación para iniciar la sesión de comunicación y el segundo mensaje de señalización puede incluir un rechazo de la invitación. En algunos casos, el protocolo de señalización de sesión de comunicación puede ser al menos uno de entre el protocolo de inicio de sesión (SIP), el protocolo de presencia y mensajería extensible (XMPP), Google Talk o Skype. En un ejemplo, la sesión de comunicación puede ser una llamada de voz sobre protocolo de Internet (VoIP). La sesión de comunicación puede transportar uno o más de entre voz, texto de un carácter a la vez, texto de un mensaje a la vez, vídeo o mensajes de texto utilizando al menos uno de entre medios de flujo continuo o sin flujo continuo.

[0015] También se describe un dispositivo para comunicar datos telemáticos. El dispositivo incluye un procesador y una memoria en comunicación electrónica con el procesador. La memoria incluye instrucciones. Las instrucciones pueden ser ejecutadas por el procesador para transmitir un primer mensaje de señalización desde un primer dispositivo a un segundo dispositivo a través de un protocolo de señalización de sesión de comunicación. El primer mensaje de señalización incluye al menos un primer conjunto de información de sesión relacionada con una sesión de comunicación entre el primer dispositivo y el segundo dispositivo y un primer conjunto de datos telemáticos para el primer dispositivo. Las instrucciones también pueden ser ejecutadas por el procesador para recibir un segundo mensaje de señalización en el primer dispositivo a través del protocolo de señalización de sesión de comunicación. El segundo mensaje de señalización incluye metadatos basados en un contenido del primer conjunto de datos telemáticos transmitidos en el primer mensaje de señalización.

[0016] También se describe un aparato para comunicar datos telemáticos. El aparato incluye medios para transmitir un primer mensaje de señalización desde un primer dispositivo a un segundo dispositivo a través de un protocolo de señalización de sesión de comunicación. El primer mensaje de señalización incluye al menos un primer conjunto de información de sesión relacionada con una sesión de comunicación entre el primer dispositivo y el segundo dispositivo y un primer conjunto de datos telemáticos para el primer dispositivo. El aparato incluye adicionalmente medios para recibir un segundo mensaje de señalización en el primer dispositivo a través del protocolo de señalización de sesión de comunicación. El segundo mensaje de señalización incluye metadatos basados en un contenido del primer conjunto de datos telemáticos transmitidos en el primer mensaje de señalización.

[0017] Además, se describe un producto de programa informático para comunicar datos telemáticos. El producto de programa informático incluye un medio legible por ordenador no transitorio que almacena instrucciones. Las instrucciones pueden ser ejecutadas por un procesador para transmitir un primer mensaje de señalización desde un primer dispositivo a un segundo dispositivo a través de un protocolo de señalización de sesión de comunicación. El primer mensaje de señalización incluye al menos un primer conjunto de información de sesión relacionada con una sesión de comunicación entre el primer dispositivo y el segundo dispositivo y un primer conjunto de datos telemáticos para el primer dispositivo. Las instrucciones pueden ser ejecutadas además por el procesador para recibir un segundo mensaje de señalización en el primer dispositivo a través del protocolo de señalización de sesión de comunicación. El segundo mensaje de señalización incluye metadatos basados en un contenido del primer conjunto de datos telemáticos transmitidos en el primer mensaje de señalización.

[0018] También se describe un procedimiento para comunicar datos telemáticos. Al menos una parte de un primer mensaje de señalización de un primer dispositivo se recibe en un segundo dispositivo a través de un protocolo de señalización de sesión de comunicación. El primer mensaje de señalización incluye al menos un primer conjunto de información de sesión relacionada con una sesión de comunicación entre el primer dispositivo y el segundo dispositivo y un primer conjunto de datos telemáticos para el primer dispositivo. Un segundo mensaje de señalización se transmite al primer dispositivo a través del protocolo de señalización de sesión de comunicación en respuesta al primer mensaje de señalización. El segundo mensaje de señalización incluye metadatos basados en un contenido del primer conjunto de datos telemáticos recibidos en el primer mensaje de señalización.

[0019] En algunos modos de realización, el primer conjunto de información de sesión puede incluir una solicitud para iniciar la sesión de comunicación o información asociada con la sesión de comunicación. En algunos casos, el segundo mensaje de señalización puede incluir un segundo conjunto de información de sesión relacionada con la sesión de comunicación.

[0020] En algunos modos de realización, transmitir el segundo mensaje de señalización a través del protocolo de señalización de sesión de comunicación puede incluir transmitir una indicación de si el primer conjunto de datos telemáticos se recibió satisfactoriamente en el segundo dispositivo. La indicación puede incluir los metadatos basados en el contenido del primer conjunto de datos telemáticos.

[0021] En algunos modos de realización, transmitir el segundo mensaje de señalización a través del protocolo de señalización de sesión de comunicación puede incluir transmitir una solicitud con respecto al primer conjunto de datos telemáticos. La solicitud puede incluir los metadatos basados en el contenido del primer conjunto de datos telemáticos. En un ejemplo, la solicitud puede incluir al menos una de: una solicitud para retransmitir el primer conjunto de datos telemáticos, una solicitud para transmitir una versión actualizada del primer conjunto de datos telemáticos, o una solicitud para transmitir un conjunto diferente de datos telemáticos.

[0022] En algunos modos de realización, un tercer mensaje de señalización puede recibirse desde el primer dispositivo a través del protocolo de señalización de sesión de comunicación. El tercer mensaje de señalización puede incluir una respuesta a la solicitud transmitida con respecto al primer conjunto de datos telemáticos.

[0023] En algunos modos de realización, transmitir el segundo mensaje de señalización a través del protocolo de señalización de sesión de comunicación puede incluir identificar al menos una acción asociada con el primer conjunto de datos telemáticos. En algunos casos, transmitir el segundo mensaje de señalización a través del protocolo de señalización de sesión de comunicación puede incluir transmitir una instrucción al primer dispositivo para realizar la al menos una acción identificada basándose en el contenido del primer conjunto de datos telemáticos. La instrucción puede incluir los metadatos basados en el contenido del primer conjunto de datos telemáticos. La al menos una acción identificada puede incluir al menos una de: recopilar datos telemáticos adicionales, realizar una acción que afecte al estado de un vehículo, activar un componente de un vehículo, desactivar un componente de un vehículo, apagar el motor de un vehículo, encender el motor de un vehículo, interrumpir el suministro de combustible de un vehículo, iniciar el suministro de combustible de un vehículo, abrir una puerta, cerrar una puerta, hacer sonar el claxon de un vehículo, activar un sonido audible externamente, encender las luces de un vehículo, encender los intermitentes de un vehículo, accionar una ventana eléctrica, reproducir un mensaje grabado, reproducir información multimedia o mostrar un mensaje de texto.

[0024] En algunos modos de realización, se puede determinar a partir de una cabecera del primer mensaje de señalización que al menos una parte de un cuerpo del primer mensaje de señalización incluye el primer conjunto de datos telemáticos. En un ejemplo, se puede determinar a partir de la cabecera del primer mensaje de señalización que el cuerpo del primer mensaje de señalización incluye un formato multiparte. En este ejemplo, una primera parte del cuerpo del primer mensaje de señalización puede identificarse de acuerdo con la información de la cabecera. La primera parte del cuerpo del primer mensaje de señalización puede incluir al menos el primer conjunto de información de sesión relacionada con la sesión de comunicación. En este ejemplo, una segunda parte del cuerpo del primer mensaje de señalización puede identificarse de acuerdo con la información de la cabecera. La segunda parte del cuerpo del primer mensaje de señalización puede incluir al menos el primer conjunto de datos telemáticos.

[0025] En algunos modos de realización, se puede generar una cabecera para el segundo mensaje de señalización basándose en el protocolo de señalización de sesión de comunicación. La cabecera puede incluir una indicación de que al menos una parte de un cuerpo del segundo mensaje de señalización comprende los metadatos. En algunos casos, el segundo conjunto de información de sesión relacionada con la sesión de comunicación se puede formatear de acuerdo con un primer protocolo. En algunos casos, los metadatos basados en el contenido del primer conjunto de datos telemáticos se pueden formatear de acuerdo con un segundo protocolo. En un ejemplo, el segundo conjunto formateado de información de sesión y los metadatos formateados basados en el contenido del primer conjunto de datos telemáticos pueden combinarse para generar el cuerpo del segundo mensaje de señalización.

[0026] En algunos modos de realización, el primer mensaje de señalización puede incluir una invitación para iniciar la sesión de comunicación y el segundo mensaje de señalización puede incluir un rechazo de la invitación. En algunos casos, el protocolo de señalización de sesión de comunicación puede incluir al menos uno de lo siguiente: protocolo de inicio de sesión (SIP), protocolo de presencia y mensajería extensible (XMPP), Google Talk o Skype. En un ejemplo, la sesión de comunicación puede ser una llamada de voz sobre protocolo de Internet (VoIP). La sesión de comunicación puede transportar uno o más de entre voz, texto de un carácter a la vez, texto de un mensaje a la vez, vídeo o mensajes de texto utilizando al menos uno de entre medios de flujo continuo o sin flujo continuo.

[0027] Se describe adicionalmente un dispositivo para comunicar datos telemáticos. El dispositivo incluye un procesador y una memoria en comunicación electrónica con el procesador. La memoria incluye instrucciones. Las instrucciones pueden ser ejecutadas por el procesador para recibir al menos una parte de un primer mensaje de señalización desde un primer dispositivo en un segundo dispositivo a través de un protocolo de señalización de sesión de comunicación. El primer mensaje de señalización incluye al menos un primer conjunto de información de sesión relacionada con una sesión de comunicación entre el primer dispositivo y el segundo dispositivo y un primer conjunto de datos telemáticos para el primer dispositivo. Las instrucciones pueden ser ejecutadas además por el procesador para transmitir un segundo mensaje de señalización al primer dispositivo a través del protocolo de señalización de sesión de comunicación en respuesta al primer mensaje de señalización. El segundo mensaje de señalización incluye metadatos basados en un contenido del primer conjunto de datos telemáticos recibidos en el primer mensaje de señalización.

[0028] También se describe un aparato para comunicar datos telemáticos. El aparato incluye medios para recibir al menos una parte de un primer mensaje de señalización desde un primer dispositivo en un segundo dispositivo a través de un protocolo de señalización de sesión de comunicación. El primer mensaje de señalización incluye al menos un primer conjunto de información de sesión relacionada con una sesión de comunicación entre el primer dispositivo y el segundo dispositivo y un primer conjunto de datos telemáticos para el primer dispositivo. El aparato incluye adicionalmente medios para transmitir un segundo mensaje de señalización al primer dispositivo a través del protocolo de señalización de sesión de comunicación en respuesta al primer mensaje de señalización. El segundo mensaje de señalización incluye metadatos basados en un contenido del primer conjunto de datos telemáticos recibidos en el primer mensaje de señalización.

[0029] Además, se describe un producto de programa informático para comunicar datos telemáticos. El producto de programa informático incluye un medio legible por ordenador no transitorio que almacena instrucciones. Las instrucciones pueden ser ejecutadas por un procesador para recibir al menos una parte de un primer mensaje de señalización desde un primer dispositivo en un segundo dispositivo a través de un protocolo de señalización de sesión de comunicación. El primer mensaje de señalización incluye al menos un primer conjunto de información de sesión relacionada con una sesión de comunicación entre el primer dispositivo y el segundo dispositivo y un primer conjunto de datos telemáticos para el primer dispositivo. Las instrucciones pueden ser ejecutadas además por el procesador para transmitir un segundo mensaje de señalización al primer dispositivo a través del protocolo de señalización de sesión de comunicación en respuesta al primer mensaje de señalización. El segundo mensaje de señalización incluye metadatos basados en un contenido del primer conjunto de datos telemáticos recibidos en el primer mensaje de señalización.

BREVE DESCRIPCIÓN DE LOS DIBUJOS

[0030] Puede obtenerse una mayor comprensión de la naturaleza y las ventajas de la presente invención en relación con los siguientes dibujos. En las figuras adjuntas, componentes o características similares pueden tener la misma etiqueta de referencia. Además, se pueden distinguir diversos componentes del mismo tipo posponiendo a la etiqueta de referencia un guion y una segunda etiqueta que distingue entre los componentes similares. Si solo se usa la primera etiqueta de referencia en la memoria descriptiva, la descripción es aplicable a uno cualquiera de los componentes similares que tiene la misma primera etiqueta de referencia, independientemente de la segunda etiqueta de referencia.

La FIG. 1A muestra un diagrama de bloques de un sistema de comunicación inalámbrica;

la FIG. 1B ilustra otro ejemplo de diagrama de bloques de un sistema de comunicación inalámbrica;

la FIG. 2 es un diagrama de bloques que ilustra un modo de realización de un terminal de acuerdo con los presentes sistemas y procedimientos;

la FIG. 3 es un diagrama de bloques que ilustra un modo de realización adicional del terminal;

la FIG. 4 es un diagrama de bloques que ilustra un ejemplo adicional del terminal para implementar la funcionalidad de los presentes sistemas y procedimientos;

la FIG. 5A muestra un diagrama de bloques de un formato a modo de ejemplo para un mensaje de solicitud de acuerdo con un protocolo de señalización de sesión de comunicación;

la FIG. 5B muestra un diagrama de un mensaje de solicitud a modo de ejemplo de acuerdo con un protocolo de señalización de sesión de comunicación;

la FIG. 5C muestra un diagrama de un mensaje de solicitud a modo de ejemplo de acuerdo con un protocolo de señalización de sesión de comunicación;

la FIG. 6 es un diagrama de bloques que ilustra un modo de realización de una estación central de acuerdo con los presentes sistemas y procedimientos;

la FIG. 7 es un diagrama de bloques que ilustra un modo de realización adicional de la estación central;

la FIG. 8 es un diagrama de bloques que ilustra un ejemplo adicional de la estación central para implementar la funcionalidad de los presentes sistemas y procedimientos;

la FIG. 9A muestra un diagrama de bloques de un formato a modo de ejemplo para un mensaje de respuesta de acuerdo con un protocolo de señalización de sesión de comunicación;

la FIG. 9B muestra un diagrama de un mensaje de respuesta a modo de ejemplo de acuerdo con un protocolo de señalización de sesión de comunicación;

la FIG. 9C muestra un diagrama de un mensaje de respuesta a modo de ejemplo de acuerdo con un protocolo de señalización de sesión de comunicación;

la FIG. 9D muestra un diagrama de un mensaje de respuesta a modo de ejemplo de acuerdo con un protocolo de señalización de sesión de comunicación;

la FIG. 9E muestra un diagrama de un mensaje de respuesta a modo de ejemplo de acuerdo con un protocolo de señalización de sesión de comunicación;

la FIG. 9F muestra un diagrama de un mensaje de respuesta a modo de ejemplo de acuerdo con un protocolo de señalización de sesión de comunicación;

la FIG. 10 muestra un diagrama de un intercambio de comunicaciones a modo de ejemplo entre un terminal y un servidor;

la FIG. 11 muestra un diagrama de un intercambio de comunicaciones a modo de ejemplo entre un terminal y un servidor;

la FIG. 12 muestra un diagrama de un intercambio de comunicaciones a modo de ejemplo entre un terminal y un servidor;

la FIG. 13 muestra un diagrama de un intercambio de comunicaciones a modo de ejemplo entre un terminal y un servidor;

la FIG. 14 muestra un diagrama de un intercambio de comunicaciones a modo de ejemplo entre un terminal y un servidor;

la FIG. 15 muestra un diagrama de un intercambio de comunicaciones a modo de ejemplo entre un terminal y un servidor;

la FIG. 16 muestra un diagrama de bloques de un terminal a modo de ejemplo en un sistema de comunicación inalámbrica;

la FIG. 17 muestra un diagrama de bloques de un servicio central a modo de ejemplo en un sistema de comunicación inalámbrica;

la FIG. 18 es un diagrama de flujo de un procedimiento a modo de ejemplo de comunicación de datos telemáticos; la FIG. 19 es un diagrama de flujo de un procedimiento a modo de ejemplo de comunicación de datos telemáticos; la FIG. 20 es un diagrama de flujo de un procedimiento a modo de ejemplo d comunicación de datos telemáticos; y

la FIG. 21 es un diagrama de flujo de un procedimiento a modo de ejemplo de comunicación de datos telemáticos. DESCRIPCIÓN DETALLADA

[0031] Se describe la gestión de datos telemáticos y de metadatos telemáticos entre un terminal y un servicio central. Cuando un terminal utiliza telefonía basada en paquetes (por ejemplo, voz sobre protocolo de Internet (VoIP), todo IP, red de última generación (NGN), etc.) para establecer una comunicación con un servicio central, un protocolo de señalización de sesión de comunicación (por ejemplo, protocolo de inicio de sesión (SIP)) se puede utilizar para transportar datos y metadatos telemáticos de manera separada al canal de voz. Por lo tanto, el terminal puede transmitir datos telemáticos al servicio central en un primer mensaje de señalización a través del protocolo de señalización de sesión de comunicación, incluyendo el primer mensaje de señalización al menos un conjunto de datos de sesión y un conjunto de datos telemáticos. El terminal puede recibir un segundo mensaje de señalización desde el servicio central a través del protocolo de señalización de sesión de comunicación, incluyendo el segundo mensaje de señalización metadatos asociados con el conjunto de datos telemáticos transmitidos en el primer mensaje de señalización. Los metadatos pueden incluir, por ejemplo, una confirmación de si los datos telemáticos se recibieron en el servicio central, una solicitud para retransmitir los datos telemáticos, una solicitud para transmitir diferentes datos telemáticos, una solicitud para realizar alguna otra acción, datos auxiliares que describen acciones realizadas por el servicio central y/u otros metadatos telemáticos pertinentes.

[0032] La siguiente descripción proporciona ejemplos, y no es limitante en cuanto al alcance, aplicabilidad o configuración expuestos en las reivindicaciones. Se pueden hacer cambios en la función y la disposición de los elementos analizados sin alejarse del alcance de la divulgación. Diversos modos de realización pueden omitir, sustituir o añadir diversos procedimientos o componentes según resulte adecuado. Por ejemplo, los procedimientos descritos se pueden realizar en un orden diferente al descrito, y se pueden añadir, omitir o combinar diversas etapas. Además, las características descritas con respecto a determinados modos de realización se pueden combinar en otros modos de realización.

[0033] Tal como se utiliza en la presente descripción y las reivindicaciones, el término "datos telemáticos" se refiere, en general, a datos generados, recopilados o almacenados en un dispositivo móvil para su transmisión a un servicio central para su procesamiento. Los datos telemáticos pueden incluir, pero sin limitarse a, datos de diagnóstico de vehículo (por ejemplo, datos de ubicación, datos de despliegue del airbag, datos del sensor de impacto o colisión, datos del sensor del motor y similares). En algunos modos de realización, el destinatario de los datos telemáticos puede ser otro dispositivo (por ejemplo, un PC, un ordenador portátil, un teléfono móvil) en lugar de un servidor central o un servicio central, y el destinatario puede almacenar entonces los datos telemáticos, procesarlos de alguna manera o reenviar los datos en el momento de la recepción o en otro momento posterior a otra entidad, tal como un servidor central. Como ejemplo de reenvío, una fuente de datos telemáticos que no puede establecer una sesión con un servidor central puede establecer una sesión con algún dispositivo intermedio que pueda acceder al servidor central. Los términos servidor, servidor central y servicio central tal como se utilizan en el presente documento deben entenderse en estos términos generales.

[0034] Tal como se utiliza en la presente descripción y en las reivindicaciones, el término "metadatos telemáticos" se refiere, en general, al control u otros datos asociados con datos telemáticos transmitidos entre un dispositivo móvil y un servicio central. Por ejemplo, los metadatos pueden incluir, pero no están limitados a, una confirmación de si los datos telemáticos se recibieron en el servicio central, una solicitud para retransmitir los datos telemáticos, una solicitud para transmitir diferentes datos telemáticos, una solicitud para realizar alguna otra acción, datos auxiliares que describen acciones realizadas por el servicio central y similares. Si bien los metadatos telemáticos pueden transmitirse a menudo desde el servicio central al dispositivo móvil en respuesta a un intento por parte del dispositivo móvil de transmitir datos telemáticos, los metadatos telemáticos también pueden ser transmitidos por el dispositivo móvil.

[0035] Tal como se utiliza en la presente descripción y en las reivindicaciones, el término "sesión de comunicación" o "sesión" se refiere, en general, a un intercambio de información interactivo temporal o semipermanente entre los puntos extremos o participantes (por ejemplo, un dispositivo móvil y un servidor central) para el propósito de un flujo continuo de audio, vídeo u otro contenido multimedia entre los puntos extremos o los participantes.

[0036] La FIG. 1A muestra un sistema de red inalámbrica 100 a modo de ejemplo que se puede usar para intercambiar datos telemáticos y metadatos relacionados entre un terminal 110 y un servicio central (es decir, un punto de respuesta de seguridad pública (PSAP) 160) a través de mensajes de señalización transmitidos a través de un protocolo de señalización de sesión de comunicación.

[0037] El sistema de red inalámbrica 100 puede incluir una red visitada 102, una red propia 104 y redes de terceros 106. La red visitada 102 también se puede denominar red móvil terrestre pública visitada (V-PLMN), red de servicio, etc. La red propia 104 también se puede denominar PLMN propia (H-PLMN). La red visitada 102 puede ser una red de servicio para un terminal 110, que puede estar en itinerancia desde su red propia 104, como se supone en gran parte de la siguiente descripción. La red visitada 102 y la red propia 104 pueden ser la misma red si el terminal 110 no está en itinerancia.

[0038] La red visitada 102 puede incluir una red de acceso por radio (RAN) 120, un centro de conmutación móvil (MSC)/registro de posición de visitantes (VLR) 130, y otras entidades de red que no se muestran en la FIG. 1A por simplicidad. La RAN 120 puede ser una red de sistema global de comunicaciones móviles (GSM), una red de acceso múltiple por división de código de banda ancha (WCDMA), una red de acceso del servicio general radioeléctrico por paquetes (GPRS), una red de evolución a largo plazo (LTE), una red CDMA IX, una red de datos por paquetes de alta velocidad (HRPD), o una red de banda ancha ultramóvil (UMB), etc. WCDMA y GPRS son parte del sistema universal de telecomunicaciones móviles (UMTS). GSM, WCDMA, GPRS y LTE se describen en documentos de una organización denominada "Proyecto de Asociación de Tercera Generación" (3GPP). CDMA IX y HRPD son parte de cdma2000, y cdma2000 y UMB se describen en los documentos de una organización denominada "Segundo Proyecto de Asociación de Tercera Generación" (3GPP2). El MSC 130 puede realizar funciones de conmutación para llamadas con conmutación de circuitos y también puede encaminar mensajes del servicio de mensajes cortos (SMS). VLR 130 puede almacenar información de registro para terminales que se han registrado con la red visitada 102. En algunos tipos de RAN (por ejemplo, una LTE, GPRS o RAN HRPD), Ms C/VLR 130 puede ser reemplazado por otras entidades, por ejemplo, por un nodo de soporte GPRS de servicio (SGSN) en el caso de GPRS o una entidad de gestión de movilidad (MME) en el caso de LTE.

[0039] La red propia 104 puede incluir un registro de posiciones base (HLR)/centro de autentificación (AC) 140 y otras entidades de red que no se muestran en la FIG. 1A por simplicidad. E1HLR 140 puede almacenar información de suscripción para terminales que tienen suscripción de servicio con la red propia 104. El AC 140 puede realizar la autentificación de terminales que tienen una suscripción de servicio con la red propia 104. En algunas redes, e1HLR 140 puede ser reemplazado por un servidor de abonados locales (HSS). En algunos casos, es posible que no haya ninguna red propia 104 si el terminal 110 no está suscrito a los servicios de comunicaciones habituales, por ejemplo, solo puede realizar llamadas de emergencia.

[0040] Las redes de terceros 106 pueden incluir un router 150 (por ejemplo, un router selectivo de PSAP), un servicio central 160 (por ejemplo, PSAP), una red telefónica pública conmutada (PSTN) 170, y posiblemente otras entidades de red que no se muestran en la FIG. 1A. El router 150 puede encaminar llamadas entre el MSC 130 y el servicio central 160. El servicio central 160 puede encargarse de responder a las llamadas de emergencia y también puede denominarse centro de emergencias (EC). El servicio central 160 puede ser gestionado o ser propiedad de una agencia gubernamental, por ejemplo, un condado o una ciudad. La PSTN 170 puede proporcionar servicios telefónicos para teléfonos cableados convencionales, como un teléfono 180. En ciertos ejemplos, las redes de terceros 106 también pueden incluir al menos un servicio central de terceros (no mostrado) que puede estar configurado para comunicarse con el servicio central 160 (por ejemplo, PSAP). Por ejemplo, un servicio central de terceros puede ser un servicio privado gestionado o afiliado a un fabricante de automóviles. En ciertos ejemplos, el servicio central de terceros puede recibir algunas o todas las llamadas de emergencia desde el terminal 110 y reenviar datos o llamadas al servicio central PSAP 160 cuando sea apropiado.

[0041] La FIG. 1A muestra solamente algunas de las entidades de red que pueden estar presentes en la red visitada 102 y la red propia 104. Por ejemplo, la red visitada 102 puede incluir entidades de red que admiten llamadas por conmutación de paquetes y otros servicios, así como un servidor de ubicación para ayudar a obtener la ubicación del terminal.

[0042] El terminal 110 puede ser estacionario o móvil y también puede denominarse estación móvil (MS) en GSM y Cd m A IX, equipo de usuario (UE) en WCDMA y LTE, terminal de acceso (AT) en HRPD, terminal habilitado para SUp L (SET) en la ubicación de plano de usuario seguro (SUPL), unidad de abonado, estación, etc. El terminal 110 puede ser un dispositivo tal como un teléfono celular u otro dispositivo de comunicación inalámbrica, dispositivo de sistema de comunicación personal (PCS), dispositivo de navegación personal (PND), gestor de información personal (PIM), asistente digital personal (PDA), ordenador portátil u otro dispositivo móvil adecuado que sea capaz de recibir comunicaciones inalámbricas y/o señales de navegación.

[0043] El terminal 110 también puede incluir dispositivos que se comunican con un dispositivo de navegación personal (PND), tal como mediante una conexión inalámbrica de corto alcance, una conexión mediante infrarrojos, una conexión por cable u otra conexión, independientemente de si la recepción de señales de satélites, la recepción de datos de asistencia y/o el procesamiento relacionado con la posición se llevan a cabo en el dispositivo o en el PND. Además, el terminal 110 pretende incluir todos los dispositivos, incluidos dispositivos de comunicación inalámbrica, ordenadores, ordenadores portátiles, etc., que puedan comunicarse con un servidor, tal como mediante Internet, Wi-Fi u otra red, e independientemente de si la recepción de señales de satélites, la recepción de datos de asistencia y/o el procesamiento relacionado con la posición se llevan a cabo en el dispositivo, en un servidor o en otro dispositivo asociado a la red. También puede incluirse cualquier combinación operativa de lo anterior. El terminal 110 también puede ser un sistema dedicado dentro de vehículo (IVS), que puede estar acoplado permanentemente a (y posiblemente parte de) un vehículo 190. El terminal 110 puede estar asociado con uno o más dispositivos que no se muestran en la FIG. 1A, como sensores acoplados a un vehículo o una unidad de control para sensores acoplados a un vehículo o alguna otra fuente de datos telemáticos que pueda enviar datos telemáticos al terminal 110 (por ejemplo, a través de medios inalámbricos) y posiblemente instigar una sesión desde el terminal 110 a un servidor central.

[0044] El terminal 110 puede tener una suscripción de servicio con la red propia 104 y puede estar en itinerancia en la red visitada 102, como se muestra en la FIG. 1A. El terminal 110 puede recibir señales desde la RAN 120 en la red visitada 102 o puede comunicarse con la RAN para obtener servicios de comunicación. El terminal 110 también puede comunicarse con la red propia 104 para obtener servicios de comunicación cuando no está en itinerancia (no se muestra en la FIG. 1A). En algunos modos de realización, el terminal 110 puede supervisar señales de la RAN 120 pero no comunicarse con la RAN 120 hasta que se pueda necesitar una sesión con el servicio central 160. Tales modos de realización pueden ser ventajosos para reducir la carga de señalización en la red visitada 102 y evitar o minimizar los cargos de suscripción al usuario del terminal 110. El terminal 110 también puede recibir señales desde uno o más satélites 195, que pueden ser parte de un sistema de posicionamiento por satélite (SPS). Un SPS puede incluir un sistema de transmisores situados para permitir que las entidades determinen su ubicación en o sobre la Tierra, en base, al menos en parte, a señales recibidas desde los transmisores. Dicho transmisor puede transmitir una señal marcada con un código de ruido seudoaleatorio (PN) repetitivo de un número establecido de chips y puede estar ubicado en estaciones de control terrestres, en equipos de usuario y/o en vehículos espaciales.

[0045] En un ejemplo particular, tales transmisores pueden estar ubicados en vehículos de tipo satélite (SV) que orbitan la Tierra. Por ejemplo, un SV en una constelación del sistema global de navegación por satélite (GNSS), tal como el sistema de posicionamiento global (GPS), Galileo, Glonass o Compass, puede transmitir una señal marcada con un código PN que puede distinguirse de códigos PN transmitidos por otros SV de la constelación (por ejemplo, usando diferentes códigos PN para cada satélite, como en GPS, o usando el mismo código en diferentes frecuencias, como en Glonass). De acuerdo con determinados aspectos, las técnicas presentadas en el presente documento no están limitadas a sistemas globales (por ejemplo, GNSS) para el SPS. Por ejemplo, las técnicas proporcionadas en el presente documento pueden aplicarse a, o su uso puede permitirse de otro modo en, varios sistemas regionales tales como, por ejemplo, el sistema de satélites cuasicenitales (QZSS) en Japón, el sistema indio de satélites de navegación regional (IRNSS) en la India, Beidou en China, etc., y/o varios sistemas de aumento (por ejemplo, un sistema de aumento basado en satélites (SBAS)) que pueden estar asociados a, o su uso puede permitirse de otro modo en, uno o más sistemas de satélites de navegación global y/o regional.

[0046] A modo de ejemplo no limitativo, un SBAS puede incluir uno o varios sistemas de aumento que proporciona(n) información de integridad, correcciones diferenciales, etc., tales como, por ejemplo, el sistema de aumento de área extensa (WAAS), el servicio europeo de superposición de navegación geoestacionaria (EGNOS), el sistema de aumento por satélite multifuncional (MSAS), la navegación geoaumentada y asistida por GPS, el sistema de navegación geoaumentada y con GPS (GAGAN) y/o similares. Por tanto, tal y como se usa en el presente documento, un SPS puede incluir cualquier combinación de uno o más sistemas de satélites de navegación global y/o regional y/o sistemas de aumento, y las señales del SPS pueden incluir señales del SPS, señales de tipo SPS y/u otras señales asociadas a dichos uno o más SPS. El terminal 110 puede medir señales procedentes de los satélites 195 y obtener mediciones de pseudodistancias para los satélites. El terminal 110 también puede medir señales de estaciones base en una RAN 120 y obtener mediciones de temporización y/o de intensidad de señal para las estaciones base. Las mediciones de pseudodistancias, las mediciones de temporización y/o las mediciones de intensidad de señal pueden utilizarse para obtener una estimación de posición para el terminal 110. Una estimación de posición también puede denominarse estimación de ubicación, una fijación de posición, etc.

[0047] El terminal 110 puede tener una identidad de equipo móvil internacional (IMEI), que es un número único asignado al terminal. El terminal 110 se puede utilizar para una suscripción de servicio de un usuario. La suscripción de servicio puede estar asociada a una identidad de abonado móvil internacional (IMSI), que es un número único asignado a una suscripción para redes GSM y UMTS. La suscripción de servicio también puede estar asociada con un número de red digital de servicios integrados de abonado móvil (MSISDN), que es un número de teléfono para la suscripción del servicio. La IMSI se puede usar como una clave para la suscripción de servicio en una base de datos de abonados en el HLR 140. El MSISDN puede ser marcado por otros usuarios para conectar las llamadas al terminal 110 utilizado para la suscripción de servicio. La IMSI, el MSISDN y otra información de suscripción pueden almacenarse en un módulo de identidad de abonado (SIM) o en un módulo de identidad de abonado universal (USIM), que puede insertarse en un terminal 110. El terminal 110 también puede no tener un SIM/USIM, en cuyo caso el terminal 110 puede tener solamente una IMEI, pero no una IMSI o un MSISDN.

[0048] Las redes inalámbricas pueden admitir diferentes tipos de llamadas de emergencia. Un tipo puede incluir llamadas de emergencia "normales" originadas por usuarios que marcan números de emergencia conocidos, como el 911 en América del Norte y el 112 en Europa. Otro tipo puede incluir eCalls, que son llamadas de emergencia que pueden tener las características descritas anteriormente y pueden incluir la transferencia de datos telemáticos a un servicio central, así como admitir la comunicación de voz y/u otros medios entre el usuario del terminal 110 y el servicio central. Es posible que la Unión Europea y otras regiones y/o países del mundo requieran asistencia para eCalls. Una eCall puede ser diferente de una llamada de emergencia normal en las formas en que se realiza la llamada y en los datos adicionales relacionados con la emergencia que pueden enviarse para establecer la eCall y usarse para procesar la eCall. Por ejemplo, los datos adicionales pueden indicar cómo se inició la eCall (por ejemplo, ya sea manualmente por un usuario o automáticamente en respuesta a los datos de sensor o un activador de sensor), un tipo de vehículo y un número de identificación del vehículo (VIN), una marca de tiempo, una estimación de posición y un indicador de confianza de posición, una dirección de desplazamiento, el número de pasajeros (por ejemplo, a partir de sensores de ocupación de asientos), otros datos de pasajeros (por ejemplo, cinturones de seguridad abrochados), un proveedor de servicios para el terminal 110 (si corresponde), un tipo de activador (por ejemplo, airbags desplegados, sensores de parachoques, indicadores de incendio, vuelco u otra detección de situación, etc.), y posiblemente otra información. Los datos adicionales también pueden permitir que se proporcione al servicio central 160 una ubicación geográfica precisa del terminal.

[0049] En ciertos ejemplos, el terminal 110 puede configurarse para iniciar una llamada de emergencia al servicio central 160 (por ejemplo, PSAP). La llamada de emergencia puede iniciarse en respuesta a la entrada manual de un usuario o en respuesta a una o más condiciones detectadas (por ejemplo, airbags desplegados, sensores de colisión, indicadores de incendio, vuelco u otra detección de situación, etc.). Para iniciar la llamada de emergencia, el terminal 110 puede usar un protocolo de señalización de sesión de comunicación tal como el protocolo de inicio de sesión (SIP), el protocolo de presencia y mensajería extensible (XMPP), Google Talk, Skype, OSCAR o el servicio Microsoft Messenger, u otro protocolo de señalización de sesión de comunicación, para establecer una llamada basada en paquetes (por ejemplo, una llamada de voz, una llamada de datos basada en paquetes que involucra texto, mensajería instantánea o comunicación de vídeo, y similares) con el servicio central 160 o un servicio central de terceros (no mostrado). El terminal 110 puede transmitir un conjunto de datos telemáticos en un primer mensaje de señalización a través del protocolo de señalización de sesión de comunicación, y el servicio central 160 o el servicio central de terceros puede responder a través de un segundo mensaje de señalización a través del protocolo de señalización de sesión de comunicación con metadatos para el conjunto de datos telemáticos, como una confirmación de si los datos telemáticos se recibieron en el servicio central, una solicitud para retransmitir los datos telemáticos, una solicitud para transmitir diferentes datos telemáticos, una solicitud para realizar alguna otra acción, datos auxiliares que describen acciones realizadas por el servicio central y/u otros metadatos telemáticos pertinentes. De esta manera, la transmisión de datos telemáticos y metadatos telemáticos relacionados puede ocurrir por separado de las comunicaciones de voz y/u otros medios (por ejemplo, mensajes instantáneos (IM), texto, vídeo, etc.) y, por lo tanto, no es necesario interrumpir el flujo de medios (por ejemplo, canal de medios). Además, los datos telemáticos y los metadatos telemáticos relacionados pueden intercambiarse entre el terminal 110 y el servicio central de manera mucho más eficiente y rápida de lo que puede ser posible con la modulación de canales de voz. Además, los datos telemáticos y los metadatos telemáticos relacionados pueden asociarse o coordinarse con la sesión y/o el canal de voz (por ejemplo, los datos telemáticos y los metadatos telemáticos relacionados pueden intercambiarse entre el mismo PSAP que está tratando el canal de voz).

[0050] La FIG. 1B es un diagrama que ilustra una arquitectura de red LTE/LTE-Avanzada de acuerdo con diversos modos de realización. La arquitectura de red LTE/LTE-A puede denominarse sistema de paquetes evolucionado (EPS) 101. El EPS 101 puede incluir uno o más terminales 110-a (por ejemplo, equipos de usuario (UE)), una red evolucionada de acceso por radio terrestre de UMTS (E-UTRAN) 115, un núcleo de paquetes evolucionado (EPC) 125, un servidor de abonados locales (HSS) 135 y puede conectarse a otros servicios y redes IP 175. El EPS 101 puede interconectarse con otras redes de acceso pero, para simplificar, esas entidades/interfaces no se muestran. Como se muestra, el EPS 101 proporciona servicios conmutados por paquetes; sin embargo, como apreciarán fácilmente los expertos en la técnica, los diversos conceptos presentados a lo largo de esta divulgación pueden extenderse a redes que proporcionen servicios de conmutación de circuitos.

[0051] La E-UTRAN 115 puede incluir una estación base 105-a (por ejemplo, nodo evolucionado B (eNB)) y otras estaciones base 105-b. La estación base 105-a puede proporcionar terminaciones de protocolo de plano de control y de usuario hacia el terminal 110-a. El terminal 110-a puede ser un ejemplo del terminal 110 de la FIG. 1A. La estación base 105-a puede conectarse con las otras estaciones base 105-b a través de una interfaz X2 (por ejemplo, red de retorno). La estación base 105-a puede proporcionar un punto de acceso al EPC 125 para el terminal 110-a. La estación base 105-a puede estar conectada mediante una interfaz S1 al EPC 125. El EPC 125 puede incluir una o más entidades de gestión de movilidad (MME) 145, una o más pasarelas de servicio 155, y una o más pasarelas de red de datos por paquetes (PDN) 165. La MME 145 puede ser el nodo de control que procesa la señalización entre el terminal 110-a y el EPC 125. En general, la MME 145 puede proporcionar gestión de portadoras y conexiones y gestionar la movilidad de terminales, tales como el terminal 110-a. Todos los paquetes IP de usuario pueden transferirse a través de la pasarela de servicio 155, que a su vez puede estar conectada a la pasarela PDN 165. La pasarela PDN 165 puede proporcionar asignación de direcciones IP de terminal, así como otras funciones. La pasarela PDN 165 se puede conectar a los otros servicios y redes IP 175, incluidos los servicios IP que son gestionados y que pertenecen al operador para EPS 101. Los otros servicios y redes IP 175 pueden incluir Internet, una Intranet, un subsistema multimedia IP (IMS) y un servicio de flujo continuo de conmutación de paquetes (PS) (PSS). Las otras redes y servicios IP 175 también pueden incluir (o conectarse a) una red IP de servicios de emergencia (ESInet) 185, que puede pertenecer a o gestionarse por o en nombre de alguna organización pública (por ejemplo, seguridad pública).

[0052] La pasarela PDN 165 también se puede conectar a una función de control de sesión de llamada de apoderado (proxy) (P-CSCF) 103. La P-CSCF 103 se puede conectar a una función de control de sesión de llamada de emergencia (E-CSCF) 109. En ciertos ejemplos (redes empresariales, por ejemplo), la P-CSCF 103 se puede conectar a la E-CSCF 109 a través de una función de control de sesión de llamada de servicio (S-CSCF) 107. La P-CSCF 103, la E-CSCF 109 y la S-CSCF 107 pueden ser parte de un IMS para el EPS 101. En caso de que el terminal 110-a sea un dispositivo IMS, puede enviar un mensaje INVITE a la red de su operador celular (por ejemplo, a la P-CSCF 103, la cual puede reenviarlo a la E-CSCF 109, la cual puede reenviarlo a la red de servicios de emergencia (ESInet) 185 que puede determinar el PSAP correcto (por ejemplo, el servicio central 160-a) y reenviarlo allí).

[0053] La ESInet 185 puede incluir un servicio central 160-a (por ejemplo, PSAP), que puede ser un ejemplo del servicio central 160 de la FIG. 1A. El servicio central 160-a puede estar conectado a un apoderado de encaminamiento de servicios de emergencia (ESRP) 111. El ESRP 111 se puede conectar a una función de encaminamiento de llamadas de emergencia (ECRF) 113.

[0054] El terminal 110-a puede estar configurado para comunicarse en colaboración con múltiples estaciones base 105 mediante, por ejemplo, múltiples entradas y múltiples salidas (MIMO), multipunto coordinado (CoMP) u otros esquemas. Las técnicas MIMO usan múltiples antenas en las estaciones base y/o múltiples antenas en el terminal para aprovechar los entornos multitrayectoria para transmitir múltiples flujos de datos. CoMP incluye técnicas para la coordinación dinámica de transmisión y recepción mediante una serie de estaciones base para mejorar la calidad de transmisión general para los terminales así como para aumentar la utilización de la red y el espectro.

[0055] En ciertos ejemplos, el terminal 110-a puede configurarse para iniciar una llamada de emergencia al servicio central 160-a (por ejemplo, PSAP). La llamada de emergencia puede iniciarse en respuesta a la entrada manual de un usuario o en respuesta a una o más condiciones detectadas (por ejemplo, airbags desplegados, sensores de colisión, indicadores de incendio, vuelco u otra detección de situación, etc.). La llamada de emergencia puede incluir un primer conjunto de señalización 117 relacionado con un protocolo de señalización de sesión de comunicación (por ejemplo, SIP) (que puede incluir información telemática, por ejemplo) y un segundo conjunto de señalización 119 relacionado con una sesión de comunicación (por ejemplo, voz/datos). La estación base 105-a puede encaminar el primer conjunto de señalización 117 y el segundo conjunto de señalización 119 hacia la pasarela de servicio 155. La pasarela de servicio 155 puede encaminar el primer conjunto de señalización 117 y el segundo conjunto de señalización 119 hacia la pasarela PDN 165. La pasarela PDN 165 puede encaminar el primer conjunto de señalización 117 hacia la P-CSCF 103 y puede encaminar el segundo conjunto de señalización 119 hacia el servicio central 160. La P-CSCF 103 puede encaminar el primer conjunto de señalización 117 hacia la E-CSCF 109. En algunos casos (en redes empresariales, por ejemplo), la P-CSCF 103 puede encaminar el primer conjunto de señalización 117 hacia la E-CSCF 109 a través de la S-CSCF 107. La E-CSCf 109 puede encaminar el primer conjunto de señalización 117 hacia el ESRP 111. El ESRP 111 puede encaminar el primer conjunto de señalización 117 hacia el servicio central 160-a. Por lo tanto, los datos telemáticos y los metadatos telemáticos relacionados pueden asociarse o coordinarse con la sesión y/o el/los flujo(s) de medios (por ejemplo, los datos telemáticos y los metadatos telemáticos relacionados pueden intercambiarse entre el mismo PSAP que está gestionando el/los flujo(s) de medios). El/los flujo(s) de medios puede(n) incluir cualquier medio de flujo continuo, incluyendo voz, texto de un mensaje a la vez (por ejemplo, IM), texto de un carácter a la vez (por ejemplo, texto de flujo continuo, texto en tiempo real), audio, vídeo y/o cualquier medio que no sea de flujo continuo, como mensajes de texto. En algunos casos, los medios intercambiados en lo que puede denominarse flujo de medios solo pueden transportar medios que no sean de flujo continuo.

[0056] La FIG.2 es un diagrama de bloques 200 que ilustra un modo de realización de un terminal 110-b, de acuerdo con los presentes sistemas y procedimientos. El terminal 110-b puede ser un ejemplo del terminal 110 de la FIG. 1A y/o del terminal 110-a de la f Ig . 1B. El terminal 110-b puede incluir un módulo receptor de terminal 205, un módulo de señalización de datos telemáticos 210 y un módulo transmisor de terminal 215. Cada uno de estos componentes puede estar en comunicación con los demás. El terminal 110-b puede incluir otros módulos no mostrados en la FIG.

2; por ejemplo, puede incluir sensores para detectar condiciones y eventos asociados con un vehículo y un receptor y procesador para permitir que la ubicación del terminal sea estimada o determinada a partir de señales inalámbricas recibidas desde satélites GPS.

[0057] Estos componentes del terminal 110-b se pueden implementar, individual o colectivamente, con uno o más circuitos integrados específicos de la aplicación (ASIC), adaptados para realizar algunas de, o todas, las funciones aplicables en hardware. De forma alternativa, una o más unidades de procesamiento (o núcleos) diferentes pueden realizar las funciones, en uno o más circuitos integrados. En otros modos de realización, pueden usarse otros tipos de circuitos integrados (por ejemplo, ASIC estructurados/de plataforma, matrices de puertas programables in situ (FPGA) y otros IC semipersonalizados), que pueden programarse de cualquier manera conocida en la técnica. Las funciones de cada unidad también pueden implementarse, en su totalidad o en parte, con instrucciones almacenadas en una memoria, ser formateadas para ser ejecutadas por uno o más procesadores generales o específicos de la aplicación.

[0058] En una configuración, el módulo receptor de terminal 205 puede incluir un receptor celular y puede recibir transmisiones desde una estación base 105. En un ejemplo, el módulo receptor de terminal 205 puede recibir un mensaje de señalización para un protocolo de señalización de comunicación que se ha adaptado para incluir metadatos telemáticos. El módulo de señalización de datos telemáticos 210 puede extraer los metadatos telemáticos a partir del mensaje de señalización adaptado. El módulo de señalización de datos telemáticos 210 también puede adaptar un mensaje de señalización para que un protocolo de señalización de comunicación incluya datos telemáticos. El mensaje de señalización adaptado para el protocolo de señalización de comunicación puede transmitirse a través del módulo transmisor de terminal 215. Los detalles con respecto al módulo de señalización de datos telemáticos 210 se describirán a continuación.

[0059] La FIG. 3 es un diagrama de bloques 300 que ilustra un modo de realización de un terminal 110-c de acuerdo con los presentes sistemas y procedimientos. El terminal 110-c puede ser un ejemplo del terminal 110 ilustrado en las FIG. 1A, 1B y/o 2. El terminal 110-c puede incluir un módulo receptor de terminal 205, un módulo de señalización de datos telemáticos 210-a y un módulo transmisor de terminal 215, como se ha descrito anteriormente. Cada uno de estos componentes puede estar en comunicación con los demás.

[0060] Estos componentes del terminal 110-c se pueden implementar, individual o colectivamente, con uno o más circuitos integrados específicos de la aplicación (ASIC), adaptados para realizar algunas de, o todas, las funciones aplicables en hardware. De forma alternativa, una o más unidades de procesamiento (o núcleos) diferentes pueden realizar las funciones, en uno o más circuitos integrados. En otros modos de realización, pueden usarse otros tipos de circuitos integrados (por ejemplo, ASIC estructurados/de plataforma, matrices de puertas programables in situ (FPGA) y otros IC semipersonalizados), que pueden programarse de cualquier manera conocida en la técnica. Las funciones de cada unidad también pueden implementarse, en su totalidad o en parte, con instrucciones almacenadas en una memoria, ser formateadas para ser ejecutadas por uno o más procesadores generales o específicos de la aplicación.

[0061] En un modo de realización, el módulo de señalización de datos telemáticos 210-a puede incluir un módulo de datos telemáticos 315. El módulo de datos telemáticos 315 puede generar y/u obtener datos telemáticos. El módulo de datos telemáticos 315 también puede recibir metadatos telemáticos. En ciertos ejemplos, el módulo de datos telemáticos 315 puede obtener datos telemáticos basándose en los metadatos telemáticos recibidos.

[0062] El módulo de señalización de datos telemáticos 210-a también puede incluir un módulo de control de sesión 310. El módulo de control de sesión 310 puede usar uno o más mensajes de señalización para controlar y/o facilitar una sesión de comunicación. En ciertos modos de realización, el módulo de control de sesión 310 puede controlar y/o facilitar una sesión de comunicaciones comunicando información de sesión de acuerdo con un protocolo de señalización de sesión de comunicación. En un ejemplo, el módulo de control de sesión 310 puede generar un mensaje de señalización que incluye un conjunto (por ejemplo, un primer conjunto) de información de señal. El módulo de control de sesión 310 también puede obtener un mensaje de señalización que incluye un conjunto (por ejemplo, un segundo conjunto) de información de señal.

[0063] En un modo de realización, el módulo de señalización de datos telemáticos 210-a puede incluir un módulo de separación de metadatos de sesión/telemáticos 305. Como se indicó anteriormente, un mensaje de señalización puede adaptarse para incluir datos telemáticos y/o metadatos telemáticos junto con la información de sesión. Por ejemplo, un mensaje de señalización puede adaptarse para incluir un segundo conjunto de información de sesión y un primer conjunto de metadatos telemáticos. El módulo de separación de metadatos de sesión/telemáticos 305 puede extraer cualquier metadato telemático de un mensaje de señalización adaptado. El módulo de separación de metadatos de sesión/telemáticos 305 puede proporcionar la información de sesión (en forma de un mensaje de señalización, por ejemplo) al módulo de control de sesión 310 y puede proporcionar los metadatos telemáticos al módulo de datos telemáticos 315.

[0064] El módulo de señalización de datos telemáticos 210-a también puede incluir un módulo de combinación de datos de sesión/telemáticos 320. El módulo de combinación de datos de sesión/telemáticos 320 puede adaptar un mensaje de señalización generado por el módulo de control de sesión 310 para incluir datos telemáticos del módulo de datos telemáticos 315. En un ejemplo, el mensaje de señalización adaptado puede incluir un primer conjunto de información de sesión y un primer conjunto de datos telemáticos. El mensaje de señalización adaptado puede transmitirse a través del módulo transmisor de terminal 215.

[0065] La FIG. 4 es un diagrama de bloques 400 que ilustra un modo de realización de un terminal 110-d de acuerdo con los presentes sistemas y procedimientos. El terminal 110-d puede ser un ejemplo del terminal 110 ilustrado en las FIG. 1A, 1B, 2 y/o 3. En una configuración, el terminal 110-d puede incluir un módulo receptor de terminal 205, un módulo de señalización de datos telemáticos 210-b y un módulo transmisor de terminal 215. Cada uno de estos componentes puede estar en comunicación con los demás.

[0066] Los componentes del terminal 110-d pueden implementarse, individual o colectivamente, con uno o más circuitos integrados específicos de la aplicación (ASIC), adaptados para llevar a cabo algunas de, o todas, las funciones aplicables en hardware. De forma alternativa, una o más unidades de procesamiento (o núcleos) diferentes pueden realizar las funciones, en uno o más circuitos integrados. En otros modos de realización, pueden usarse otros tipos de circuitos integrados (por ejemplo, ASIC estructurados/de plataforma, matrices de puertas programables in situ (FPGA) y otros IC semipersonalizados), que pueden programarse de cualquier manera conocida en la técnica. Las funciones de cada unidad también pueden implementarse, en su totalidad o en parte, con instrucciones almacenadas en una memoria, ser formateadas para ser ejecutadas por uno o más procesadores generales o específicos de la aplicación.

[0067] En un ejemplo, el terminal 110-d puede configurarse al menos para recopilar datos telemáticos, establecer una sesión de comunicación con un servicio central, transmitir datos telemáticos al servicio central mediante un uso adaptado de un protocolo de señalización de sesión de comunicación, recibir metadatos telemáticos del servicio central a través del uso adaptado del protocolo de señalización de sesión de comunicación, y realizar ciertas acciones basándose en los metadatos telemáticos recibidos.

[0068] El módulo de señalización de datos telemáticos 210-b puede incluir un módulo de control de sesión 310-a. El módulo de control de sesión 310-a puede incluir un módulo SIP/SDP 405 y un módulo de implementación de sesión 410. El módulo SIP/SDP 405 puede configurarse para negociar, configurar, gestionar y terminar sesiones de comunicación con el servicio central. El módulo SIP/SDP 405 puede generar contenido de cabecera de mensaje de señalización SIP y contenido de SDP para comunicar datos de señalización relacionados con la sesión con el servicio central. El módulo de implementación de sesión 410 puede configurarse para recibir contenido de medios (por ejemplo, datos de audio para una llamada de voz, datos de audio y vídeo para una llamada de vídeo, datos de texto para una llamada con texto con o sin voz o vídeo), transmitir el contenido de medios como un flujo de paquetes al servicio central de acuerdo con la sesión negociada, y recibir un flujo de paquetes que contienen contenido de medios desde el servicio central de acuerdo con la sesión negociada.

[0069] El módulo de señalización de datos telemáticos 210-b también puede incluir un módulo de datos telemáticos 315-a. El módulo de datos telemáticos 315-a puede incluir un módulo de adquisición de datos telemáticos 430, un módulo de mensajes de datos telemáticos 425, un módulo de análisis de metadatos telemáticos 415 y un módulo de control de sistemas externos 420. El módulo de adquisición de datos telemáticos 430 puede recopilar datos telemáticos de un sistema o dispositivo asociado con el terminal 110-d. Por ejemplo, cuando el terminal 110-d está asociado con un vehículo, el módulo de adquisición de datos telemáticos 430 puede recopilar datos relacionados con un tipo de vehículo y un número de identificación de vehículo (VIN), una o más marcas de tiempo, una estimación de posición y un grado de confianza asociado, una dirección de desplazamiento, el número de pasajeros (por ejemplo, con cinturones de seguridad abrochados), un proveedor de servicios para el terminal (si corresponde), un tipo de activador (por ejemplo, airbags desplegados, sensores de parachoques, activador manual, indicadores de incendio, vuelco u otra detección de situaciones, etc.), y/u otra información pertinente que pueda adaptarse a una aplicación particular de los principios descritos en el presente documento.

[0070] El módulo de mensajes de datos telemáticos 425 del módulo de datos telemáticos 315-a puede formatear datos telemáticos para su transmisión al servicio central de acuerdo con un protocolo entendido por el servicio central. En ciertos ejemplos, el módulo de mensaje de datos telemáticos 425 puede compilar un conjunto estándar de datos telemáticos para su transmisión al servicio central. De forma adicional o alternativa, el módulo de mensajes de datos telemáticos 425 puede configurarse para compilar un conjunto de datos telemáticos específicos solicitados desde el servicio central para su transmisión al servicio central.

[0071] El módulo de datos telemáticos 315-a puede incluir adicionalmente un módulo de análisis de metadatos telemáticos 415. El módulo de análisis de metadatos telemáticos 415 puede analizar los metadatos telemáticos para identificar cualquier acción que pueda realizarse basándose en los metadatos telemáticos recibidos desde el servicio central en asociación con los datos telemáticos transmitidos al servicio central. Las acciones identificadas pueden ser solicitadas específicamente por el servicio central o inferidas por el módulo de análisis de metadatos telemáticos 415 basándose en los metadatos telemáticos recibidos. Por ejemplo, los metadatos telemáticos pueden incluir una solicitud para retransmitir los datos telemáticos, transmitir un conjunto diferente de datos telemáticos o transmitir una versión actualizada del conjunto de datos telemáticos. El módulo de análisis de metadatos telemáticos 415 puede proporcionar los metadatos telemáticos apropiados y/o las instrucciones apropiadas al módulo de mensajes de datos telemáticos 425 y/o al módulo de control de sistemas externos 420.

[0072] El módulo de control de sistemas externos 420 del módulo de datos telemáticos 315-a puede configurarse para realizar una o más acciones basándose en los metadatos telemáticos recibidos desde el servicio central en asociación con los datos telemáticos transmitidos al servicio central. Volviendo de nuevo al ejemplo en el que el terminal 110-d está asociado con un vehículo y los datos telemáticos se transmiten al servicio central en respuesta a una colisión detectada, los metadatos telemáticos pueden incluir instrucciones para realizar ciertas acciones de precaución o rescate con respecto al vehículo y sus ocupantes. Dichas acciones pueden incluir, pero sin limitarse a, recopilar datos telemáticos adicionales, apagar o encender el motor del vehículo, iniciar o interrumpir el suministro de combustible del vehículo, desbloquear o bloquear una puerta del vehículo, hacer sonar la bocina del vehículo, reproducir sonidos audibles externamente, encender las luces (por ejemplo, faros, luces de circulación) del vehículo, encender las luces interiores (por ejemplo, la cabina) del vehículo, encender las luces intermitentes del vehículo (por ejemplo, los 4 intermitentes, intermitentes de emergencia, luces de emergencia), activar una ventana eléctrica, reproducir un mensaje grabado recibido desde el servicio central o almacenado en el terminal 110-d, reproducir información multimedia (por ejemplo, reproducir verbalmente un texto, reproducir medios enviados por el servicio central, reproducir medios a los que se hace referencia mediante y/o asociados con una instrucción enviada por el servicio central), mostrar un mensaje de texto recibido desde el servicio central o almacenado en el terminal 110-d, u otras acciones apropiadas. Se observa que acciones tales como hacer sonar la bocina, reproducir sonidos audibles externamente, encender luces y/o encender los intermitentes pueden ayudar a alertar al personal de emergencia sobre la ubicación del vehículo o a llamar la atención de otro modo.

[0073] El módulo de señalización de datos telemáticos 210-b puede incluir el módulo de separación de metadatos de sesión/telemáticos 305. El módulo de separación de metadatos de sesión/telemáticos 305 puede recibir (a través del módulo receptor de terminal 205, por ejemplo) un mensaje SIP modificado u otro mensaje de protocolo de señalización de sesión de comunicación y puede separar la información SIP/SDP (u otro protocolo) de los mensajes de metadatos telemáticos. En ciertos modos de realización, el módulo de separación de metadatos de sesión/telemáticos 305 puede proporcionar la información SIP/SDP (u otro protocolo) al módulo SIP/SDP 405 y el uno o más mensajes de metadatos telemáticos al módulo de análisis de metadatos telemáticos 415 como se describe anteriormente. En un ejemplo, el módulo de separación de metadatos de sesión/telemáticos 305 puede identificar diferentes partes de un mensaje SIP modificado basándose en la información de la cabecera del mensaje SIP modificado. En este ejemplo, el módulo de separación de metadatos de sesión/telemáticos 305 puede proporcionar las partes identificadas como información SIP/SDP al módulo SIP/SDP 405 y las partes identificadas como mensajes de metadatos telemáticos al módulo de análisis de metadatos telemáticos 415 como se describió anteriormente.

[0074] El módulo de señalización de datos telemáticos 210-b también puede incluir el módulo de combinación de datos de sesión/ telemáticos 320. El módulo de combinación de datos sesión/telemáticos 320 puede combinar información SIP/SDP (u otro protocolo) del módulo SIP/SDP 405 y uno o más mensajes de datos telemáticos del módulo de mensajes de datos telemáticos 425-a en un SIP modificado u otro mensaje de protocolo de señalización de sesión de comunicación como se describió anteriormente. El módulo transmisor de terminal 215 puede transmitir los mensajes de señalización generados al servicio central.

[0075] La FIG. 5A, la FIG. 5B y la FIG. 5C ilustran un ejemplo de un mensaje de solicitud de protocolo de inicio de sesión (SIP) modificado para transportar tanto datos de sesión como datos telemáticos. La FIG. 5A muestra un diagrama de un formato 500 de ejemplo del mensaje de solicitud y las FIG. 5B y 5C muestran un diagrama del contenido de un ejemplo de mensaje de solicitud SIP 550 basado en el formato de la FIG. 5A. Mientras que los ejemplos de la FIG. 5A, la FIG. 5B y la FIG. 5C se describen en el contexto de mensajes de solicitud SIP modificados y rediseñados, se entenderá que los principios de la presente descripción se pueden usar para modificar o extender otros protocolos de señalización de sesión de comunicación (por ejemplo, XMPP, Google Talk, MSN, etc.) o como base para nuevos protocolos de señalización de sesión de comunicación.

[0076] Al rediseñar protocolo SIP para transportar tanto datos de sesión como datos telemáticos, los datos telemáticos pueden transmitirse de manera eficiente a un servicio central sin interrumpir ni degradar la calidad de una llamada relacionada. Como se muestra en la FIG.5A, el formato de mensaje de solicitud de SIP modificado 500 puede incluir una línea de solicitud 505, una cabecera 510, un conjunto de información de sesión 515 (por ejemplo, parámetros de sesión, datos de sesión), y un conjunto de datos telemáticos 520. El protocolo SIP está definido por el Grupo de trabajo de Ingeniería de Internet (IETF) en una serie de normas de solicitud de comentarios, tal como la RFC 3261. Estas normas definen una serie de mensajes de solicitud y respuesta SIP, que incluyen un mensaje INVITE, un mensaje ACK, un mensaje BYE, un mensaje CANCEL, un mensaje OPTIONS, un mensaje REGISTER, un mensaje PRACK, un mensaje SUBSCRIBE, un mensaje NOTIFY, un mensaje PUBLISH, un mensaje INFO, un mensaje REFER, un mensaje MESSAGE y un mensaje UPDATE. El formato 500 actual puede usarse para cada uno de estos mensajes y para otros tipos de mensajes de solicitud y respuesta.

[0077] En el ejemplo de la FIG. 5B, un mensaje SIP INVITE 550-a modificado basado en el formato de la FIG. 5A puede ser utilizado, por ejemplo, por un terminal para solicitar simultáneamente una llamada u otra sesión de comunicaciones con un servicio central y transmitir datos telemáticos a ese servicio central. De esta manera, los datos telemáticos pueden ser recibidos por el servicio central incluso si el servicio central no puede establecer (o rechaza) una llamada con el terminal.

[0078] La línea de solicitud 505-a del mensaje SIP INVITE 550-a de ejemplo puede identificar el mensaje 550-a como una solicitud y especificar el tipo de solicitud que se está realizando (por ejemplo, INVITE). La cabecera 510-a del mensaje de solicitud puede definir la fuente de la solicitud, el destinatario previsto (por ejemplo, el servicio de emergencia URN) de la solicitud, un identificador de llamada, información de contacto para la fuente, un número de secuencia de llamada, una indicación del tipo de datos en el cuerpo y una longitud del mensaje. En el presente ejemplo, la cabecera 510-a puede especificar que el cuerpo contiene datos mixtos, donde la cadena de caracteres "-----NextPart-----" indica el límite entre los diferentes tipos de datos en el cuerpo. En el presente ejemplo, el cuerpo del mensaje incluye tanto información de sesión 515-a como datos telemáticos 520-a. Se observa que el presente ejemplo puede no mostrar todos los campos de cabecera que pueden incluirse típicamente.

[0079] La información de sesión 515-a puede incluir una lista de parámetros para la sesión propuesta entre el terminal y el servicio central. Por ejemplo, el mensaje SIP INVITE 550-a puede incluir un conjunto de parámetros del protocolo de descripción de sesión (SDP) para configurar una llamada de audio VoIP.

[0080] Los datos telemáticos 520-a pueden incluir lecturas de sensores, datos almacenados o registrados, y otros datos asociados con el terminal que se transmiten al servicio central. En ciertos ejemplos, los datos telemáticos pueden no estar directamente relacionados con la configuración y el mantenimiento de la sesión. Por lo tanto, incluso si el servicio central rechaza los parámetros propuestos de la llamada en la parte de información de sesión 515-a del mensaje SIP INVITE 550-a o no puede establecer la sesión por otras razones, el servicio central aún puede recibir y procesar los datos telemáticos 520-a. En el presente ejemplo, el mensaje SIP INVITE 550-a puede proponer una llamada de emergencia con un servicio PSAP basándose en una activación automática o manual en un vehículo. Los datos telemáticos 520-a transmitidos con los parámetros de información de sesión 515-a pueden incluir varias mediciones relacionadas con el estado del vehículo y/o sus ocupantes y los eventos que activan la llamada de emergencia. Como se muestra en el ejemplo de la FIG. 5B, los datos telemáticos 520-a pueden incluir un código de estado, un tipo de carga, un identificador específico del fabricante asociado con el terminal, la ubicación del vehículo, la velocidad actual u otra anterior del vehículo, la dirección del vehículo y una suma de control. En ciertos ejemplos, los datos telemáticos 520-a pueden incluir un conjunto mínimo de datos (MSD) de eCall u otro conjunto estándar de datos de llamada de emergencia, por ejemplo, según se define por o en nombre de algún país o región (por ejemplo, la Unión Europea).

[0081] La FIG. 5C muestra un ejemplo de mensaje de solicitud SIP modificado 550-b similar al mensaje de solicitud SIP modificado 550-a de la FIG. 5B. En el ejemplo de la FIG. 5C, sin embargo, la información de la sesión 515-b puede incluir un objeto de ubicación-formato de datos de información de presencia (PIDF-LO) y los datos telemáticos 520-b pueden incluir un objeto eCallData 535. En un ejemplo, puede hacerse referencia al objeto eCallData 535 mediante una etiqueta 530 en la cabecera 510-b. En un ejemplo, la etiqueta 530 en la cabecera 510-b puede usar el ID de contenido (es decir, 1234567890@rosebud.example.com) del objeto eCallData 535 para hacer referencia al objeto eCallData 535. En el ejemplo de la FIG. 5C, la cabecera 510-b también puede incluir una indicación 525 de que el mensaje INVITE es tanto para una llamada de emergencia como para una eCall activada automáticamente.

[0082] La FIG. 6 es un diagrama de bloques 600 que ilustra un modo de realización de un servicio central 160-b, de acuerdo con los presentes sistemas y procedimientos. El servicio central 160-b puede ser un ejemplo del servicio central 160 de las FIG. 1A y/o 1B. El servicio central 160-b puede incluir un módulo receptor de servicio central 605, un módulo de señalización de metadatos telemáticos 610 y un módulo transmisor de servicio central 615. Cada uno de estos componentes puede estar en comunicación con los demás.

[0083] Estos componentes del servicio central 160-b se pueden implementar, individual o colectivamente, con uno o más circuitos integrados específicos de la aplicación (ASIC), adaptados para realizar algunas de, o todas, las funciones aplicables en hardware. De forma alternativa, una o más unidades de procesamiento (o núcleos) diferentes pueden realizar las funciones, en uno o más circuitos integrados. En otros modos de realización, pueden usarse otros tipos de circuitos integrados (por ejemplo, ASIC estructurados/de plataforma, matrices de puertas programables in situ (FPGA) y otros IC semipersonalizados), que pueden programarse de cualquier manera conocida en la técnica. Las funciones de cada unidad también pueden implementarse, en su totalidad o en parte, con instrucciones almacenadas en una memoria, ser formateadas para ser ejecutadas por uno o más procesadores generales o específicos de la aplicación.

[0084] En una configuración, el módulo receptor de servicio central 605 puede incluir un receptor celular y/o una tarjeta de interfaz de red (NIC) y puede recibir comunicaciones a través de otros servicios y redes IP 175 o cualquier otro servicio de conectividad IP. En un ejemplo, el módulo receptor de servicio central 605 puede recibir un mensaje de señalización para un protocolo de señalización de comunicación que se ha adaptado para incluir datos telemáticos. El módulo de señalización de metadatos telemáticos 610 puede extraer los datos telemáticos a partir del mensaje de señalización adaptado. El módulo de señalización de metadatos telemáticos 610 también puede adaptar un mensaje de señalización para que un protocolo de señalización de comunicación incluya metadatos telemáticos. El mensaje de señalización adaptado para el protocolo de señalización de comunicación puede transmitirse a través del módulo transmisor de servicio central 615. Los detalles con respecto al módulo de señalización de metadatos telemáticos 610 se describirán a continuación. En otra configuración, el módulo receptor de servicio central 605 puede admitir la recepción de datos por paquetes a través de medios cableados, por ejemplo, del ESRP 111 en la FIG. 1B.

[0085] La FIG. 7 es un diagrama de bloques 700 que ilustra un modo de realización de un servicio central 160-c de acuerdo con los presentes sistemas y procedimientos. El servicio central 160-c puede ser un ejemplo del servicio central 160 ilustrado en las FIG. 1A, 1B y/o 6. El servicio central 160-c puede incluir un módulo receptor de servicio central 605, un módulo de señalización de metadatos telemáticos 610-a y un módulo transmisor de servicio central 615, como se ha descrito anteriormente. Cada uno de estos componentes puede estar en comunicación con los demás.

[0086] Estos componentes del servicio central 160-c se pueden implementar, individual o colectivamente, con uno o más circuitos integrados específicos de la aplicación (ASIC), adaptados para realizar algunas de, o todas, las funciones aplicables en hardware. De forma alternativa, una o más unidades de procesamiento (o núcleos) diferentes pueden realizar las funciones, en uno o más circuitos integrados. En otros modos de realización, pueden usarse otros tipos de circuitos integrados (por ejemplo, ASIC estructurados/de plataforma, matrices de puertas programables in situ (FPGA) y otros IC semipersonalizados), que pueden programarse de cualquier manera conocida en la técnica. Las funciones de cada unidad también pueden implementarse, en su totalidad o en parte, con instrucciones almacenadas en una memoria, ser formateadas para ser ejecutadas por uno o más procesadores generales o específicos de la aplicación.

[0087] En un modo de realización, el módulo de señalización de metadatos telemáticos 610-a puede incluir un módulo de metadatos telemáticos 710. El módulo de metadatos telemáticos 710 puede generar y/u obtener metadatos telemáticos. El módulo de metadatos telemáticos 710 también puede recibir datos telemáticos. En ciertos ejemplos, el módulo de metadatos telemáticos 710 puede generar metadatos telemáticos basándose en datos telemáticos recibidos.

[0088] El módulo de señalización de metadatos telemáticos 610-a también puede incluir un módulo de control de sesión 310-b. El módulo de control de sesión 310-b puede ser un ejemplo del módulo de control de sesión 310 ilustrado en las FIG. 3 y/o 4. En un ejemplo, el módulo de control de sesión 310-b puede obtener un mensaje de señalización que incluye un conjunto (por ejemplo, un primer conjunto) de información de señal. El módulo de control de sesión 310-b también puede generar un mensaje de señalización que incluye un conjunto (por ejemplo, un segundo conjunto) de información de señal.

[0089] En un modo de realización, el módulo de señalización de metadatos telemáticos 610-a puede incluir un módulo de separación de datos de sesión/telemáticos 705. Como se indicó anteriormente, un mensaje de señalización puede adaptarse para incluir datos telemáticos y/o metadatos telemáticos junto con la información de sesión. Por ejemplo, un mensaje de señalización puede adaptarse para incluir un primer conjunto de información de sesión y un primer conjunto de datos telemáticos. El módulo de separación de datos de sesión/telemáticos 705 puede extraer cualquier dato telemático a partir de un mensaje de señalización adaptado. El módulo de separación de datos de sesión/telemáticos 705 puede proporcionar la información de sesión (en forma de un mensaje de señalización, por ejemplo) al módulo de control de sesión 310-b y puede proporcionar los datos telemáticos al módulo de metadatos telemáticos 710.

[0090] El módulo de señalización de metadatos telemáticos 610-a también puede incluir un módulo de combinación de metadatos de sesión/telemáticos 715. El módulo de combinación de metadatos de sesión/telemáticos 715 puede adaptar un mensaje de señalización generado por el módulo de control de sesión 310-b para incluir metadatos telemáticos del módulo de metadatos telemáticos 710. En un ejemplo, el mensaje de señalización adaptado puede incluir un segundo conjunto de información de sesión y un primer conjunto de metadatos telemáticos. El mensaje de señalización adaptado puede transmitirse a través del módulo transmisor de servicio central 615.

[0091] La FIG. 8 es un diagrama de bloques 800 que ilustra un modo de realización de un servicio central 160-d de acuerdo con los presentes sistemas y procedimientos. El servicio central 160-d puede ser un ejemplo del servicio central 160 ilustrado en las FIG. 1A, 1B, 6 y/o 7. En una configuración, el servicio central 160-d puede incluir un módulo receptor de servicio central 605, un módulo de señalización de metadatos telemáticos 610-b y un módulo transmisor de servicio central 615. Cada uno de estos componentes puede estar en comunicación con los demás.

[0092] Estos componentes del servicio central 160-d se pueden implementar, individual o colectivamente, con uno o más circuitos integrados específicos de la aplicación (ASIC), adaptados para realizar algunas de, o todas, las funciones aplicables en hardware. De forma alternativa, una o más unidades de procesamiento (o núcleos) diferentes pueden realizar las funciones, en uno o más circuitos integrados. En otros modos de realización, pueden usarse otros tipos de circuitos integrados (por ejemplo, ASIC estructurados/de plataforma, matrices de puertas programables in situ (FPGA) y otros IC semipersonalizados), que pueden programarse de cualquier manera conocida en la técnica. Las funciones de cada unidad también pueden implementarse, en su totalidad o en parte, con instrucciones almacenadas en una memoria, ser formateadas para ser ejecutadas por uno o más procesadores generales o específicos de la aplicación.

[0093] En un ejemplo, el servicio central 160-d puede configurarse al menos para recibir datos telemáticos desde un terminal a través de un uso adaptado de un protocolo de señalización de sesión de comunicación, establecer una sesión de comunicación con el terminal, generar metadatos telemáticos basándose en el contenido de los datos telemáticos recibidos y transmitir los metadatos telemáticos al terminal mediante el uso adaptado del protocolo de señalización de sesión de comunicación. En ciertos ejemplos, el servicio central 160-d también puede dirigir el terminal a través de los metadatos telemáticos para realizar ciertas acciones basándose en los datos telemáticos recibidos.

[0094] El módulo de señalización de metadatos telemáticos 610-b puede incluir un módulo de control de sesión 310-c. El módulo de control de sesión 310-c puede ser un ejemplo del módulo de control de sesión 310 ilustrado en las FIG. 3, 4 y/o 7. El módulo de control de sesión 310-c puede incluir un módulo SIP/SDP 405-a y un módulo de implementación de sesión 410-a. El módulo SIP/SDP 405-a puede configurarse para negociar, configurar, gestionar y terminar sesiones de comunicación con el terminal. El módulo SIP/SDP 405-a puede generar contenido de cabecera de mensaje de señalización SIP y contenido de SDP para comunicar datos de señalización relacionados con la sesión con el terminal. El módulo de implementación de sesión 410-a puede configurarse para recibir contenido de medios (por ejemplo, datos de audio para una llamada de voz, datos de audio y vídeo para una llamada de vídeo, datos de texto para una llamada de texto), transmitir el contenido de medios como un flujo de paquetes al terminal de acuerdo con la sesión negociada, y recibir un flujo de paquetes que contienen contenido de medios desde el terminal de acuerdo con la sesión negociada.

[0095] El módulo de señalización de metadatos telemáticos 610-b también puede incluir un módulo de metadatos telemáticos 710-a. El módulo de metadatos telemáticos 710-a puede incluir un módulo de análisis de datos telemáticos 805, un módulo de acciones de servicio central 810, un módulo de acciones de terminal 820 y un módulo de mensajes de metadatos telemáticos 815.

[0096] El módulo de análisis de datos telemáticos 805 puede recibir datos telemáticos desde el terminal y aplicar un conjunto de una o más reglas para identificar la naturaleza de los datos telemáticos y determinar las acciones apropiadas a realizar en respuesta a los datos telemáticos. Por ejemplo, cuando el terminal está asociado a un vehículo, el módulo de análisis de datos telemáticos 805 puede analizar datos telemáticos relacionados con un tipo de vehículo y un número de identificación de vehículo (VIN), una o más marcas de tiempo, una estimación de posición y un grado de confianza asociado, una dirección de desplazamiento, el número de pasajeros (por ejemplo, con cinturones de seguridad abrochados), un proveedor de servicios para el terminal (si corresponde), un tipo de activador (por ejemplo, airbags desplegados, sensores de parachoques, activador manual, indicadores de incendio, vuelco u otra detección de situación, etc.), y/u otra información pertinente que pueda adaptarse a una aplicación particular de los principios descritos en el presente documento. En una configuración, el módulo de análisis de datos telemáticos 805 puede proporcionar datos telemáticos analizados y/o instrucciones al módulo de acciones de servicio central 810 y/o al módulo de acciones de terminal 820.

[0097] El módulo de acciones de servicio central 810 puede realizar acciones identificadas en el servicio central 160-d basándose en los datos telemáticos analizados, y el módulo de acciones de terminal 820 puede generar instrucciones para que el terminal realice ciertas acciones basándose en los datos telemáticos. El módulo de mensajes de metadatos telemáticos 815 puede generar un conjunto de metadatos telemáticos para su transmisión al terminal basándose en los datos telemáticos recibidos. El módulo de mensaje de metadatos telemáticos 815 puede generar adicionalmente un conjunto de metadatos telemáticos para su transmisión al terminal en respuesta a un intento detectado por el terminal de transmitir datos telemáticos al servicio central 160-d. Además, el módulo de mensajes de metadatos telemáticos 815 puede formatear metadatos telemáticos para su transmisión al terminal de acuerdo con un protocolo entendido por el terminal. Como se describió anteriormente, los metadatos telemáticos pueden incluir información tal como una confirmación o una confirmación negativa de si los datos telemáticos se recibieron en el servicio central 160-d, una solicitud para retransmitir los datos telemáticos (por ejemplo, la versión anterior y/o una versión actual), una solicitud para transmitir diferentes datos telemáticos, una solicitud para realizar alguna otra acción, datos auxiliares que describen acciones realizadas por el servicio central y/u otros metadatos telemáticos pertinentes.

[0098] Volviendo al ejemplo en el que un terminal está asociado a un vehículo e inicia una llamada de emergencia al servicio central 160-d en respuesta a una colisión, choque, vuelco u otra situación detectada, el módulo de análisis de datos telemáticos 805 puede recibir datos telemáticos desde el terminal que indica el tipo y la gravedad de la colisión, el módulo de acciones de servicio central 810 puede proporcionar (por ejemplo, reenviar) información acerca de la colisión a los servicios de emergencia (u otro destino adecuado), y el módulo de acciones de terminal 820 puede generar una instrucción para que el terminal interrumpa el suministro de combustible del vehículo y reproduzca un mensaje grabado o muestre un mensaje de texto (por ejemplo, desde el servicio central 160-d o almacenado por la terminal) que indica que hay ayuda en camino, reproduzca información multimedia (por ejemplo, reproducir verbalmente un texto), etc. El módulo de mensaje de metadatos telemáticos 815 puede generar entonces un conjunto de metadatos telemáticos para su transmisión al terminal, donde los metadatos telemáticos confirman los metadatos telemáticos, proporciona las instrucciones generadas por el módulo de acciones de terminal 820 y/o proporciona otra información pertinente al terminal (por ejemplo, el tiempo estimado antes de que un operador esté disponible para atender una llamada de voz y/o de otros medios, el tiempo estimado antes de que lleguen los servicios de emergencia, etc.).

[0099] En un modo de realización, el módulo de señalización de metadatos telemáticos 610-b puede incluir un módulo de separación de datos de sesión/telemáticos 705. El módulo de separación de datos de sesión/telemáticos 705 puede recibir (a través del módulo receptor de servicio central 605, por ejemplo) un mensaje SIP modificado u otro mensaje de protocolo de señalización de sesión de comunicación y puede separar la información SIP/SDP (u otro protocolo) de los mensajes de datos telemáticos. En ciertos modos de realización, el módulo de separación de datos de sesión/telemáticos 705 puede proporcionar la información SIP/SDP al módulo SIP/SDP 405-a y el uno o más mensajes de datos telemáticos al módulo de análisis de datos telemáticos 805 como se describe anteriormente. En un ejemplo, el módulo de separación de datos de sesión/telemáticos 705 puede identificar diferentes partes de un mensaje SIP modificado basándose en la información de la cabecera del mensaje SIP modificado. En este ejemplo, el módulo de separación de datos de sesión/telemáticos 705 puede proporcionar las partes identificadas como información SIP/SDP (u otro protocolo) al módulo SIP/SDP 405-a y las partes identificadas como mensajes de datos telemáticos al módulo de análisis de datos telemáticos 805 como se describió anteriormente.

[0100] El módulo de señalización de metadatos telemáticos 610-b también puede incluir un módulo de combinación de metadatos de sesión/telemáticos 715. El módulo de combinación de metadatos sesión/telemáticos 715 puede combinar información SIP/SDP (u otro protocolo) del módulo SIP/SDP 405-a y uno o más mensajes de metadatos telemáticos del módulo de mensajes de metadatos telemáticos 710-a en un SIP modificado u otro mensaje de protocolo de señalización de sesión de comunicación como se describió anteriormente. El módulo transmisor de servicio central 615 puede transmitir los mensajes de señalización generados al terminal.

[0101] La FIG. 9A, la FIG. 9B, la FIG. 9C, la FIG. 9D, la FIG. 9E y la FIG. 9F ilustran un ejemplo de un mensaje de respuesta de protocolo de inicio de sesión (SIP) modificado para transportar tanto datos de sesión como metadatos telemáticos. El mensaje de respuesta SIP de las FIG. 9A a 9F puede transmitirse a un terminal 110 desde un servicio central 160 en respuesta a la recepción de un mensaje de solicitud SIP de acuerdo con la descripción de las FIG. 5A a 5C.

[0102] Al rediseñar el protocolo SIP para transportar tanto datos de sesión como metadatos telemáticos, los metadatos telemáticos pueden transmitirse de manera eficiente a un terminal sin interrumpir o degradar la calidad de una llamada relacionada. La FIG. 9A muestra un diagrama de un formato 900 de ejemplo del mensaje de respuesta. La FIG. 9B, la FIG. 9C, la FIG. 9D, la FIG. 9E y la FIG. 9F muestran diagramas de mensajes de respuesta S iP 950ae de ejemplo basados en el formato de la FIG. 9A. Mientras que los ejemplos de la FIG. 9A, la FIG. 9B, la FIG. 9C, la FIG. 9D, la FIG. 9E y la FIG. 9F se describen en el contexto de mensajes de respuesta SIP modificados y rediseñados, se entenderá que los principios de la presente descripción se pueden usar para modificar o extender otros protocolos de señalización de sesión de comunicación (por ejemplo, XMPP, Google Talk, MSN, etc.) o como base para nuevos protocolos de señalización de sesión de comunicación.

[0103] El formato de mensaje de respuesta SIP modificado 900 puede usarse para generar mensajes de señalización en respuesta a mensajes de solicitud SIP. Como se muestra en la FIG. 9A, el formato de mensaje de respuesta SIP modificado 900 puede incluir una línea de estado 905, una cabecera 910, un conjunto de datos de sesión 915 y un conjunto de metadatos telemáticos 920. El protocolo SIP define una serie de mensajes de respuesta, respuestas provisionales, respuestas satisfactorias, respuestas de redirección y respuestas de fallo de cliente. El presente formato 900 puede usarse en cada uno de estos tipos de mensajes y en otros tipos de mensajes de respuesta.

[0104] En el ejemplo de la FIG. 9B, un mensaje SIP 200 (OK) modificado 950-a basado en el formato de la FIG. 9A puede ser utilizado, por ejemplo, por un servicio central en respuesta a la recepción del mensaje SIP INVITE modificado 550 de la FIG. 5b y/o la FIG. 5C para indicar que el servicio central acepta la sesión VolP propuesta. El mensaje SIP 200 (OK) 950-a puede proporcionar además metadatos al terminal que confirma los datos telemáticos transmitidos en el mensaje SIP INVITE 550. El mensaje SIP 200 (OK) 950-a también puede proporcionar información adicional (tal como que se ha avisado a los servicios de emergencia y que la confirmación de voz está pendiente, por ejemplo).

[0105] La línea de estado 905-a del mensaje de señalización SIP 200 (OK) 950-a de ejemplo puede identificar el mensaje 950-a como una respuesta SIP y especificar el tipo de respuesta que se está realizando (por ejemplo, OK). La cabecera 910-a del mensaje de respuesta puede proporcionar la identidad del terminal y el servicio central, el identificador de llamada, información de contacto para el terminal y el servicio central, el número de secuencia de llamada, una indicación del tipo de datos en el cuerpo y una longitud del mensaje de respuesta 950-a. En el presente ejemplo, la cabecera 910-a puede especificar que el cuerpo contiene datos mixtos, donde la cadena de caracteres "--— NextPart-----" indica el límite entre los diferentes tipos de datos en el cuerpo. En el presente ejemplo, el cuerpo del mensaje incluye tanto datos de sesión 915-a como metadatos telemáticos 920-a.

[0106] Los datos de sesión 915-a pueden incluir una lista de parámetros para la sesión propuesta entre el terminal y el servicio central. Estos parámetros de sesión pueden ser un conjunto de parámetros del protocolo de descripción de sesión (SDP) para la llamada de audio VoIP.

[0107] Los metadatos telemáticos 920-a pueden incluir información relacionada con los datos telemáticos recibidos en el servicio central en el mensaje de señalización SIP INVITE 550. Como se describió anteriormente, los metadatos telemáticos 920-a pueden incluir una confirmación de si los datos telemáticos se recibieron en el servicio central, una solicitud para retransmitir los datos telemáticos, una solicitud para transmitir diferentes datos telemáticos, una solicitud para realizar alguna otra acción, datos auxiliares que describen las acciones realizadas por el servicio central y/u otros metadatos telemáticos pertinentes. Volviendo al ejemplo de una llamada de emergencia realizada desde un terminal asociado con un vehículo a un servicio PSAP, los metadatos telemáticos 920-a mostrados en la FIG. 9B pueden incluir una confirmación de que se recibieron los datos telemáticos y un código de estado que indica que los servicios de emergencia han sido notificados y que hay una llamada de voz pendiente.

[0108] La FIG. 9C muestra un ejemplo de mensaje de respuesta SIP modificado 950-b similar al mensaje de respuesta SIP modificado 950-a de la FIG. 9B. En el ejemplo de la FIG. 9C, sin embargo, los metadatos telemáticos 920-b pueden incluir además una instrucción para que el terminal realice ciertas acciones con respecto a cualquier vehículo asociado con el terminal. Por tanto, los metadatos telemáticos 920-b de la FIG. 9C puede incluir una instrucción para apagar el motor del vehículo, apagar la bomba de combustible del vehículo, desbloquear las puertas del vehículo y reproducir una grabación específica de instrucciones para los ocupantes del vehículo. En algunas configuraciones, las instrucciones para el terminal pueden provenir de una persona. Por ejemplo, una persona que está atendiendo la llamada puede hacer que se envíen comandos al terminal, que pueden incluir solicitudes de datos telemáticos adicionales o actualizados, y que uno o más mensajes se comuniquen al vehículo (por ejemplo mostrando un texto, reproduciendo verbalmente un texto, reproduciendo una grabación, reproduciendo medios) que incluyen mensajes predefinidos o totalmente dinámicos (por ejemplo, escritos por una persona en el lugar), bloqueo/desbloqueo de puertas, activación de luces/bocina, etc.

[0109] La FIG. 9D muestra la línea de estado 905-c y la cabecera 910-c de un ejemplo de mensaje de respuesta SIP modificado 950-c similar al mensaje de respuesta SIP modificado 950-a de la FIG. 9B. En el ejemplo de la FIG.

9C, sin embargo, la cabecera 910-c incluye además una cabecera P para eCallMetaData 925. En este ejemplo, la cabecera P para eCallMetaData 925 puede incluir una confirmación 930 que confirma los datos con la ID especificada, un comando 935 para reproducir un mensaje estático, un comando 940 para llamar la atención (por ejemplo, encender luces de manera intermitente, hacer sonar la bocina, hacer ruido, etc.), y un comando 945 para enviar datos de eCall AltSet1. En un ejemplo, el mensaje estático se puede almacenar en el terminal y/o en una ubicación conocida.

[0110] La FIG. 9E muestra un ejemplo de mensaje de respuesta SIP modificado 950-d similar al mensaje de respuesta SIP modificado 950-a de la FIG. 9B. En el presente ejemplo, la cabecera 910-d puede incluir una cabecera P para eCallMetaData 925-a similar a la cabecera P para eCallMetaData 925 de la FIG. 9D. En el ejemplo de la FIG.

9E, sin embargo, la cabecera P para eCallMetaData 925-a puede incluir un comando 955 para reproducir un mensaje dinámico y una referencia 960 que indica el ID de contenido (es decir, 5432154321@example.gov) del mensaje dinámico que se debe reproducir. En este ejemplo, los medios dinámicos pueden incluirse en el cuerpo (por ejemplo, los metadatos telemáticos 920-d) del mensaje de respuesta 950-d. Como se indicó anteriormente, el objeto de medios dinámicos 965 puede tener y puede hacerse referencia al mismo mediante un ID de contenido específico.

[0111] La FIG. 9F muestra un ejemplo de mensaje de respuesta SIP modificado 950-e similar al mensaje de respuesta SIP modificado 950-a de la FIG. 9B. En el ejemplo de la FIG. 9F, sin embargo, los metadatos telemáticos (por ejemplo, metadatos de eCall) pueden incluirse en el cuerpo (por ejemplo, metadatos telemáticos 920-e). El presente ejemplo ilustra además que tanto los mensajes estáticos como los mensajes dinámicos pueden incluirse en un objeto de metadatos telemáticos (por ejemplo, el objeto eCallMetaData). En este ejemplo, la cabecera 910-e puede incluir una etiqueta 970 que hace referencia a un objeto de metadatos telemáticos 975 en el cuerpo (por ejemplo, metadatos telemáticos 920). Por ejemplo, la etiqueta 970 puede hacer referencia al objeto de metadatos telemáticos 975 haciendo referencia al ID de contenido (es decir, 9876543210@example.gov) del objeto de metadatos telemáticos 975. En este ejemplo, los metadatos telemáticos 920-b pueden incluir el objeto de metadatos telemáticos 975. En el presente ejemplo, el objeto de metadatos telemáticos 975 puede incluir una confirmación 930-a que confirma los datos con el ID especificado, un comando 935-a para reproducir un mensaje estático, un comando 955-a para reproducir un mensaje dinámico, un objeto de medios dinámicos 965-a, un comando 940-a para llamar la atención (por ejemplo, encender luces de manera intermitente, hacer sonar la bocina, hacer ruido, etc.), y un comando 945-a para enviar datos de eCall AltSet1. En una configuración, el objeto de metadatos telemáticos 975 puede formarse utilizando un lenguaje de marcado (por ejemplo, lenguaje de marcado extensible (XML)). Se observa que el objeto de metadatos telemáticos 975 puede formarse utilizando muchos otros mecanismos de codificación o estructuración, tales como ASN.1, JSON, MIME, etc.

[0112] Mientras que los ejemplos de las FIG. 5A, 5B, 5C, 9A, 9B, 9C, 9D, 9E y 9F ilustran el ejemplo de un mensaje de solicitud SIP modificado que transporta datos telemáticos y un mensaje de respuesta SIP modificado que transporta metadatos telemáticos, los expertos en la técnica reconocerán que cualquier tipo de mensaje puede transportar datos telemáticos o metadatos telemáticos. Por ejemplo, en ciertos ejemplos, un terminal puede transmitir datos telemáticos a un servicio central en un mensaje que responde a una solicitud del servicio central. De manera similar, en ciertos ejemplos, el servicio central puede transmitir metadatos telemáticos al terminal en un mensaje de solicitud al terminal. En ejemplos adicionales o alternativos, un mensaje de solicitud o un mensaje de respuesta puede incluir tanto datos telemáticos como metadatos telemáticos.

[0113] La FIG. 10 es un diagrama de un ejemplo de un intercambio de comunicaciones entre un terminal 110-e y un servicio central 160-e para el intercambio de datos telemáticos y metadatos telemáticos utilizando un protocolo de señalización de sesión de comunicación. El terminal 110-e puede ser un ejemplo del terminal 110 de las FIG. 1A, 1B, 2, 3 y/o 4, y el servicio central 160-e puede ser un ejemplo del servicio central 160 (por ejemplo, PSAP) de las FIG.

1A, 1B, 6, 7 y/u 8, u otro servicio central. En ciertos ejemplos, el servicio central 160-e puede ser implementado por uno o más servidores.

[0114] El protocolo de señalización de sesión de comunicación puede ser un protocolo de capa de aplicación diseñado para ser independiente de la capa de transporte subyacente. De este modo, en ciertos ejemplos, el protocolo de señalización de sesión de comunicación puede ser compatible con varios protocolos de capa de transporte diferentes. En ciertos ejemplos, uno o más servidores apoderados pueden estar dispuestos entre un terminal 110-e y el servicio central 160-e, de modo que los mensajes de señalización iniciales entre el terminal 110-e y el servicio central 160-e pueden reenviarse entre uno o más de los servidores apoderados. En aras de la claridad, tales servidores apoderados no se muestran en las figuras asociadas a la presente descripción. Se observa que puede haber otras entidades (por ejemplo, adicionales) que reciben, reenvían, regeneran, alteran o están involucradas de otro modo en el intercambio de mensajes (por ejemplo, en el caso de mensajes SIP, agentes de usuario de conexión directa, controladores de frontera de sesión, etc.). En la FIG. 10, el protocolo de señalización de sesión de comunicación puede ser SIP, XMPP, Google Talk, Skype, etc. y los protocolos de transporte subyacentes pueden ser el protocolo de datagrama de usuario (UDP) sobre IP o el protocolo de control de transmisión (TCP) sobre IP o algún otro conjunto de protocolos de transporte.

[0115] El terminal 110-e puede comunicarse con el servicio central a través del protocolo de señalización de sesión de comunicación para configurar y gestionar una sesión de comunicación. En el presente ejemplo, el terminal 110-e y el servicio central 160-e pueden comunicarse para establecer una sesión VoIP para una llamada (que transporta voz y/u otro medio) entre un usuario asociado con el terminal 110-e y un operador asociado con el servicio central 160-e. Como se muestra en la FIG. 10, el terminal 110-e puede transmitir un mensaje de señalización de inicio de sesión al servicio central 160-e. El mensaje de señalización de inicio de sesión puede invitar al servicio central 160-e a participar en una sesión VoIP con el terminal 110-e. El terminal 110-e puede transmitir el mensaje de inicio de sesión en respuesta a una solicitud manual de un usuario asociado al terminal 110-e. Por ejemplo, un ocupante de un vehículo asociado al terminal 110-e puede presionar un botón de llamada de emergencia del vehículo que indica al terminal 110-e a que invite al servicio central 160-e a la sesión de VoIP. De forma adicional o alternativa, el terminal 110-e puede transmitir el mensaje de inicio de sesión al servicio central 160-e en respuesta a una o más condiciones o eventos detectados o inferidos (por ejemplo, airbags desplegados, sensor de colisión, datos de diagnóstico del motor, incendio del motor, incendio del vehículo, vuelco u otra situación, etc.).

[0116] El mensaje de inicio de sesión puede incluir detalles y parámetros para la sesión propuesta (por ejemplo, direcciones de red, números de puertos, tipo de medios, temporización, protocolos de flujo continuo compatibles, ancho de banda, etc.). Además de este conjunto de datos de sesión para la sesión propuesta entre el terminal 110-e y el servicio central 160-e, el dispositivo terminal 110-e puede añadir (por ejemplo, agregar) datos telemáticos al mensaje de inicio de sesión transmitido al servicio central 160-e. Los datos telemáticos pueden incluir lecturas de uno o más sensores en comunicación con el terminal 110-e y/u otros datos almacenados, determinados, calculados y/o recibidos por el terminal 110-e. En ciertos ejemplos, los datos telemáticos pueden incluir datos que se transmiten típicamente a un PSAP durante una eCall u otra llamada de emergencia. Por ejemplo, los datos telemáticos pueden incluir al menos uno o más de: cómo se inició la eCall, un tipo de vehículo y un número de identificación de vehículo (VIN), una marca de tiempo, una estimación de posición y un indicador de confianza de posición, la dirección de desplazamiento, el número de pasajeros (por ejemplo, a partir de sensores de ocupación de asientos) y datos asociados (por ejemplo, asientos con cinturones de seguridad abrochados), un proveedor de servicios para el terminal (si corresponde), un tipo de activador (por ejemplo, airbags desplegados, sensores de parachoques, indicadores de incendio, vuelco u otra detección de situaciones, etc.), y/u otra información pertinente que pueda adaptarse a una aplicación particular de los principios descritos en el presente documento.

[0117] Al recibir el mensaje de inicio de sesión con los datos telemáticos adjuntos, el servicio central 160-e puede determinar si aceptar o rechazar la sesión propuesta. En el presente ejemplo, el servicio central 160-e puede transmitir un mensaje de confirmación de sesión a través del protocolo de señalización de sesión de comunicación que indica que se acepta la sesión propuesta además de proporcionar parámetros y datos adicionales para la sesión. Además, el mensaje de confirmación de sesión transmitido al terminal 110-e puede incluir un conjunto de metadatos telemáticos asociados al conjunto de datos telemáticos recibidos por el servicio central 160-e en el mensaje de inicio de sesión. En ejemplos alternativos, el servicio central 160-e puede transmitir los metadatos telemáticos al servicio central 160-e en un mensaje aparte (por ejemplo, en un mensaje de protocolo de señalización de sesión de comunicación utilizado específicamente para transmitir los metadatos telemáticos, añadido a un tipo diferente de mensaje de protocolo de señalización de sesión de comunicación, etc.). Los metadatos telemáticos pueden, por ejemplo, contener una confirmación de si los datos telemáticos se recibieron en el servicio central 160-e, una solicitud para retransmitir los datos telemáticos (por ejemplo, la versión anterior y/o una versión actual) al servicio central 160-e, una solicitud para transmitir diferentes datos telemáticos al servicio central 160-e, una solicitud para realizar alguna otra acción, datos auxiliares que describen las acciones realizadas por el servicio central 160-e y/u otros metadatos telemáticos pertinentes.

[0118] El terminal 110-e puede recibir los metadatos telemáticos y realizar las acciones apropiadas basándose en el contenido de los metadatos telemáticos recibidos. En ciertos ejemplos, los metadatos telemáticos pueden simplemente confirmar la recepción de los datos telemáticos, y el terminal 110-e puede no realizar ninguna acción en respuesta a los metadatos telemáticos. En otros ejemplos, el terminal 110-e puede responder a una solicitud en los metadatos telemáticos del servicio central 160-e o consultar un conjunto de reglas para identificar una acción a realizar basándose en los metadatos telemáticos recibidos.

[0119] Además, el terminal 110-e puede establecer una sesión VoIP con el servicio central 160-e basándose en los datos y parámetros de sesión, tanto en el mensaje de inicio de sesión como en el mensaje de confirmación de sesión. El terminal 110-e y el servicio central 160-e pueden intercambiar flujos de paquetes que contienen voz y/u otros datos de medios utilizando el protocolo de transporte en tiempo real (RTP) u otro protocolo de flujo continuo para implementar una llamada (que transporta voz y/u otros medios) entre el usuario del terminal 110-e y el operador del servicio central 160-e. La sesión VoIP puede transportar cualquier medio, incluido texto, tanto texto de un mensaje a la vez (tal como la mensajería instantánea) como texto de un carácter a la vez (texto de flujo continuo, a menudo denominado texto en tiempo real) y/o vídeo. Se observa que, si bien la mayoría de los medios se transmiten en flujo continuo, la sesión de VoIP también puede transmitir medios sin flujo continuo, además de o en lugar de los medios de flujo continuo.

[0120] Para concluir la sesión VoIP, el servicio central 160-e puede transmitir un mensaje de señalización de terminación de sesión al terminal 110-e a través del protocolo de señalización de sesión de comunicación. Al recibir el mensaje de señalización de terminación de sesión, el terminal 110-e puede transmitir un mensaje de señalización de confirmación de terminación de sesión al servicio central 160-e, y la sesión puede terminar.

[0121] La FIG. 11 es un diagrama de un ejemplo de un intercambio de comunicaciones 1100 entre un terminal 110-f y un servicio central 160-f mediante un protocolo de señalización de sesión de comunicación para a) establecer una llamada VoIP y b) intercambiar datos telemáticos y metadatos telemáticos. Al igual que en ejemplos anteriores, el protocolo de señalización de sesión de comunicación puede ser una versión de SIP modificada para transportar datos telemáticos y metadatos telemáticos. En otros ejemplos (no mostrados en la FIG. 11), se pueden usar otros protocolos de señalización de sesión de comunicación.

[0122] El terminal 110-f puede ser un ejemplo del terminal 110 de la FIG. 1A o uno de los otros terminales 110 descritos anteriormente con referencia a las figuras anteriores. El servicio central 160-f puede ser un ejemplo del servicio central (por ejemplo, PSAP) 160 de la FIG. 1A o uno de los otros servicios centrales 160 descritos anteriormente con referencia a las figuras anteriores. En ciertos ejemplos, el servicio central 160-f puede ser implementado por uno o más servidores. Además, en ciertos ejemplos, uno o más servidores apoderados pueden disponerse entre el terminal 110-f y el servicio central 160-f para reenviar los mensajes de protocolo de señalización de sesión de comunicación entre el terminal 110-f y el servicio central 160-f.

[0123] En una primera fase, el terminal 110-b puede transmitir un mensaje SIP INVITE al servicio central 160-f. En ciertos ejemplos, el mensaje SIP INVITE puede ser un ejemplo del mensaje de solicitud SIP modificado descrito anteriormente con referencia a las FIG. 5A, 5B y 5C. El mensaje SIP INVITE puede invitar simultáneamente al servicio central 160-f a una sesión VoIP propuesta que tenga un conjunto propuesto de parámetros y transmitir un conjunto de datos telemáticos desde el terminal 110-f al servicio central 160-f. En ciertos ejemplos, el terminal 110-f puede estar asociado a un vehículo y puede transmitir el mensaje SIP INVITE al servicio central 160-f en respuesta a una condición detectada en el vehículo o una solicitud manual de una llamada de emergencia por parte de un ocupante del vehículo.

[0124] En una segunda fase, el servicio central 160-f puede responder al mensaje SIP INVITE transmitiendo un mensaje SIP STATUS 200 (OK) al terminal 110-f. El mensaje SIP s Ta TUS 200 (OK) puede aceptar simultáneamente la sesión VoIP propuesta y transmitir metadatos telemáticos al terminal 110-f confirmando los datos telemáticos por parte del servicio central 160-f. En una tercera fase, al recibir el mensaje SIP STATUS 200 (OK) que incluye los metadatos telemáticos del servicio central 160-f, el terminal 110-f puede transmitir un mensaje SIP ACK al servicio central 160-f. En una cuarta fase, la sesión de VoIP se puede implementar mediante la transmisión de paquetes de datos de sesión que transportan voz y/u otras comunicaciones de medios entre el terminal 110-f y el servicio central 160-f de acuerdo con los parámetros acordados en los mensajes SIP INVITE, SIP STATUS 200 (OK) y SIP ACK. En una quinta fase, la sesión VoIP puede ser finalizada por el servicio central 160-f transmitiendo un mensaje SIP BYE al terminal 110-f. El terminal 110-f puede confirmar la finalización de la sesión en una sexta fase transmitiendo un mensaje de respuesta SIP STATUS 200 (OK) al servicio central 160-f. En otros ejemplos, el terminal 110-f puede iniciar la terminación de la sesión VoIP, y el servicio central 160-f puede transmitir el mensaje de respuesta SIP STATUS 200 (OK) al terminal 110-f.

[0125] La FIG. 12 es un diagrama de un ejemplo de un intercambio de comunicaciones 1200 entre un terminal 110-g y un servicio central 160-g mediante un protocolo de señalización de sesión de comunicación para a) establecer una llamada VoIP y b) intercambiar datos telemáticos y metadatos telemáticos. Al igual que en ejemplos anteriores, el protocolo de señalización de sesión de comunicación puede ser una versión de SIP modificada para transportar datos telemáticos y metadatos telemáticos. En otros ejemplos, se pueden usar otros protocolos de señalización de sesión de comunicación.

[0126] El terminal 110-g puede ser un ejemplo del terminal 110 de la FIG. 1A o uno de los otros terminales 110 descritos anteriormente con referencia a las figuras anteriores. El servicio central 160-g puede ser un ejemplo del servicio central 160 de la FIG. 1A o uno de los otros servicios centrales 160 descritos anteriormente con referencia a las figuras anteriores. En ciertos ejemplos, el servicio central 160-g puede ser implementado por uno o más servidores. Además, en ciertos ejemplos, uno o más servidores apoderados pueden disponerse entre el terminal 110-g y el servicio central 160-g para reenviar los mensajes de protocolo de señalización de sesión de comunicación entre el terminal 110-g y el servicio central 160-g.

[0127] En una primera fase, el terminal 110-g puede transmitir un mensaje SIP INVITE al servicio central 160-g. En ciertos ejemplos, el mensaje SIP INVITE puede ser un ejemplo del mensaje de solicitud SIP modificado descrito anteriormente con referencia a las FIG. 5A, 5B y 5C. El mensaje SIP INVITE puede invitar simultáneamente al servicio central 160-g a una sesión VoIP propuesta que tenga un conjunto propuesto de parámetros y transmitir un conjunto de datos telemáticos desde el terminal 110-g al servicio central 160-g. En ciertos ejemplos, el terminal 110-g puede estar asociado a un vehículo y puede transmitir el mensaje SIP INVITE al servicio central 160-g en respuesta a una condición detectada en el vehículo o una solicitud manual de una llamada de emergencia por parte de un ocupante del vehículo.

[0128] En una segunda fase, el servicio central 160-g puede responder al mensaje SIP INVITE transmitiendo un mensaje SIP STATUS 200 (OK) al terminal 110-g. El mensaje SIP s Ta TUS 200 (OK) puede aceptar simultáneamente la sesión VoIP propuesta y transmitir metadatos telemáticos al terminal 110-g confirmando los datos telemáticos por parte del servicio central 160-g. En una tercera fase, la sesión VoIP se puede implementar mediante la transmisión de paquetes de datos de sesión que transportan voz y/u otras comunicaciones de medios entre el terminal 110-g y el servicio central 160-g de acuerdo con los parámetros acordados en los mensajes SIP INVITE y SIP STATUS 200 (OK).

[0129] En una cuarta fase, el servicio central 160-g puede transmitir un mensaje SIP INFO al terminal 110-g con metadatos telemáticos adicionales. En un ejemplo, los metadatos telemáticos adicionales pueden solicitar datos telemáticos adicionales más allá de lo que se incluyó en el mensaje inicial SIP INVITE. En otro ejemplo, los metadatos telemáticos adicionales pueden incluir adicionalmente instrucciones para que el terminal 110-g y/o el vehículo las lleven a cabo. En una quinta fase, el terminal 110-g puede transmitir un mensaje SIP STATUS 200 (OK) al servicio central 160-g con los datos telemáticos adicionales solicitados.

[0130] En una sexta fase, la sesión VoIP puede ser finalizada por el servicio central 160-g que transmite un mensaje SIP BYE al terminal 110-g. El terminal 110-g puede confirmar la finalización de la sesión en una séptima fase al transmitir un mensaje de respuesta SIP STATUS 200 (OK) al servicio central 160-g. En otros ejemplos, el terminal 110-g puede iniciar la terminación de la sesión VoIP, y el servicio central 160-g puede transmitir el mensaje de respuesta SIP STATUS 200 (OK) al terminal 110-g.

[0131] La FIG. 13 es un diagrama de otro ejemplo de un intercambio de comunicaciones 1300 entre un terminal 110-h y un servicio central 160-h mediante un protocolo de señalización de sesión de comunicación para a) establecer una llamada VoIP y b) intercambiar datos telemáticos y metadatos telemáticos. Al igual que en ejemplos anteriores, el protocolo de señalización de sesión de comunicación puede ser una versión de SIP modificada para transportar datos telemáticos y metadatos telemáticos. En otros ejemplos, se pueden usar otros protocolos de señalización de sesión de comunicación.

[0132] El terminal 110-h puede ser un ejemplo del terminal 110 de la FIG. 1A o uno de los otros terminales 110 descritos anteriormente con referencia a las figuras anteriores. El servicio central 160-h puede ser un ejemplo del servicio central 160 de la FIG. 1A o uno de los otros servicios centrales 160 descritos anteriormente con referencia a las figuras anteriores. En ciertos ejemplos, el servicio central 160-h puede ser implementado por uno o más servidores. Además, en ciertos ejemplos, uno o más servidores apoderados pueden disponerse entre el terminal 110-h y el servicio central 160-h para reenviar los mensajes de protocolo de señalización de sesión de comunicación entre el terminal 110-h y el servicio central 160-h.

[0133] En una primera fase, el terminal 110-h puede transmitir un mensaje SIP INVITE al servicio central 160-h. El mensaje SIP INVITE puede ser un ejemplo de un mensaje de solicitud SIP modificado descrito anteriormente con referencia a las figuras anteriores. El mensaje SIP INVITE puede invitar simultáneamente al servicio central 160-h a una sesión VoIP con un conjunto propuesto de parámetros y transportar un conjunto de datos telemáticos desde el terminal 110-h al servicio central 160-h.

[0134] En una segunda fase, el servicio central 160-h puede responder al mensaje SIP INVITE transmitiendo un mensaje de respuesta SIP STATUS 180 (Ringing) al terminal 110-h. En ciertos ejemplos, el mensaje de respuesta SIP STATUS 180 (Ringing) puede indicar que el servicio central 160-h está intentando contactar con un operador humano para que responda la llamada VoIP. Si el servicio central 160-h no puede comunicarse con un operador humano para responder la llamada, el servicio central 160-h puede transmitir un mensaje de respuesta SIP STATUS 486 (Busy) al terminal 110-h en una tercera fase. En ejemplos alternativos, el servicio central 160-h puede aceptar la llamada con un mensaje de respuesta SIP STATUS 200 (OK) pero pone la llamada en una cola mientras espera que un operador humano esté disponible. El mensaje de respuesta SIP STATUS 486 (Busy) o, de forma alternativa, SIP STATUS 200 (OK) puede contener metadatos telemáticos relacionados con los datos telemáticos transmitidos al servicio central 160-h desde el terminal 110-h.

[0135] Los metadatos telemáticos pueden confirmar al terminal 110-h que los datos telemáticos fueron recibidos por el servicio central 160-h. En consecuencia, el terminal 110-h puede, en ciertos ejemplos, indicar a un usuario del terminal 110-h que los datos telemáticos se han recibido con éxito (recibido en un estado satisfactorio, por ejemplo) en el servicio central 160-h. Por lo tanto, aunque ningún operador asociado con el servicio central 160-h puede estar disponible para atender una llamada de voz y/o una llamada de otro medio, el usuario puede estar seguro de que los datos telemáticos se han recibido en el servicio central 160-h. En otros modos de realización, donde puede no haber ningún usuario que controle el terminal 110-h (por ejemplo, cuando el terminal 110-h invocó una llamada en respuesta a los datos de sensor), la confirmación de los metadatos telemáticos puede confirmar al terminal 110-h que se recibieron los datos telemáticos y, por lo tanto, no es necesario que el terminal 110-h realice un intento de repetición automática. Esto puede reducir la carga en el servicio central 160 h cuando muchos de dichos terminales 110 h intentan realizar llamadas de emergencia y enviar datos telemáticos al mismo tiempo, por ejemplo en respuesta a un incidente muy grave (por ejemplo, varios vehículos amontonados en una carretera) o una situación de desastre tal como un terremoto, un huracán, un tsunami o un incendio forestal.

[0136] En un ejemplo, el servicio central 160-h puede determinar si los datos telemáticos se han recibido en un estado satisfactorio (por ejemplo, recibido satisfactoriamente). Ejemplos de estados satisfactorios pueden ser una recepción completa de un conjunto de datos transmitidos (como resultado de una transmisión sin errores, por ejemplo). En algunos casos, un conjunto de datos menos completo puede calificarse como un estado satisfactorio, mientras que en otros casos, un conjunto de datos menos completo puede no calificarse como un estado satisfactorio. En algunos casos, la determinación de un estado satisfactorio puede basarse en la situación en la que se transmitieron los datos telemáticos (según lo determinado por el contenido del conjunto recibido de datos telemáticos, por ejemplo). De forma adicional o alternativa, la determinación de un estado satisfactorio puede basarse en factores tales como si los valores son coherentes entre sí o coherentes con intervalos típicos, si los datos de ubicación tienen una confianza lo suficientemente alta, si los datos telemáticos son lo suficientemente actuales, etc. En algunos casos, la determinación de un estado satisfactorio puede ser realizada por un ser humano (por ejemplo, un operador) en el servicio central 160-h. En otros casos, la determinación de un estado satisfactorio se puede hacer automáticamente (por ejemplo, por el servicio central).

[0137] Por ejemplo, volviendo al ejemplo de un terminal 110-h asociado a un sistema de llamadas de emergencia de vehículo, un ocupante del vehículo puede experimentar una colisión y proporcionar una indicación manual al terminal 110-h de que se desea una llamada de emergencia de voz y/o de otro medio al servicio central 160-h. Los datos telemáticos transmitidos al servicio central 160-h pueden incluir al menos la latitud y longitud del vehículo y una indicación de que ha ocurrido una colisión. Si el servicio central 160-h está experimentando un gran volumen de llamadas y no puede proporcionar un operador humano para responder la llamada, el ocupante del vehículo todavía puede recibir la seguridad de que su ubicación e información sobre la colisión se recibió en el servicio central 160-h. Por ejemplo, el terminal 110-h puede recibir un mensaje SIP STATUS 486 (Busy) que incluye metadatos telemáticos (que ordena al terminal 110-h que comunique al usuario que los datos se recibieron en el servicio central 160-h, por ejemplo). En ciertos ejemplos, los metadatos telemáticos también pueden comunicar otra información útil al usuario a través del terminal 110-h, incluido un mensaje que informa que se han enviado servicios de emergencia (o que están en el área del usuario gestionando otros incidentes y que posteriormente atenderán al usuario) o una instrucción de permanecer en el vehículo. En un ejemplo, los metadatos telemáticos pueden proporcionar de forma o alternativa instrucciones al vehículo, tales como apagar el motor o bloquear las puertas (por seguridad) o encender las luces (para ayudar a los servicios de emergencia a localizar el vehículo).

[0138] En una cuarta fase, el servicio central 160-h puede determinar que un operador está disponible para participar en una llamada VoIP con el usuario del terminal 110-h, y si la llamada no está en cola o en espera, el servicio central 160-h puede intentar volver a llamar al terminal 110-h mediante la transmisión de un mensaje SIP INVITE al terminal 110-h, donde el mensaje SIP INVITE propone una nueva sesión VoIP. El mensaje SIP INVITE puede incluir un conjunto adicional de metadatos telemáticos relacionados con los datos telemáticos recibidos. En el presente ejemplo, el conjunto adicional de metadatos telemáticos puede incluir una solicitud para que el terminal 110-h retransmita los datos telemáticos para permitir que el servicio central 160-h evalúe la versión más actualizada de los datos telemáticos.

[0139] En una quinta fase, el terminal 110-h puede aceptar la invitación a la nueva sesión VoIP propuesta por el servicio central 160-h mediante la transmisión de un mensaje SIP STATUS 200 (OK) al servicio central 160-h, donde el mensaje SIP STATUS 200 (OK) también contiene los datos telemáticos actualizados solicitados. En una sexta fase, el servicio central 160-h puede transmitir un SIP ACK al terminal 110-h con un nuevo conjunto de metadatos telemáticos que confirman los datos telemáticos actualizados. En una séptima fase, la llamada VoIP entre el terminal 110-h y el servicio central 160-h puede tener lugar en una o más secuencias de datos de sesión VoIP. Al finalizar la llamada, el servicio central 160-h puede transmitir un mensaje SIP BYE al terminal 110-h, y el terminal 110-h puede confirmar el final de la llamada transmitiendo un mensaje SIP STATUS 200 (OK) al servicio central 160-h.

[0140] En un ejemplo alternativo, el servicio central 160-h puede no establecer una sesión de llamada con el terminal 110-h después de transmitir el mensaje de respuesta SIP STATUS 486 (Busy) al terminal 110-h en la fase 3. Sin embargo, el terminal 110-h puede depender de los metadatos telemáticos recibidos en la etapa 3 para determinar que los datos telemáticos fueron recibidos por el servicio central 160-h y que se están tomando las medidas apropiadas.

[0141] La FIG. 14 es un diagrama de otro ejemplo de un intercambio de comunicaciones 1400 entre un terminal 110-i y un servicio central 160-i mediante un protocolo de señalización de sesión de comunicación para a) establecer una llamada VoIP y b) intercambiar datos telemáticos y metadatos telemáticos. Al igual que en ejemplos anteriores, el protocolo de señalización de sesión de comunicación puede ser una versión de SIP modificada para transportar datos telemáticos y metadatos telemáticos. En otros ejemplos, se pueden usar otros protocolos de señalización de sesión de comunicación.

[0142] El terminal 110-i puede ser un ejemplo del terminal 110 de la FIG. 1A o uno de los otros terminales 110 descritos anteriormente con referencia a las figuras anteriores. El servicio central 160-i puede ser un ejemplo del servicio central 160 de la FIG. 1A o uno de los otros servicios centrales 160 descritos anteriormente con referencia a las figuras anteriores. En ciertos ejemplos, el servicio central 160-i puede ser implementado por uno o más servidores. Además, en ciertos ejemplos, uno o más servidores apoderados pueden disponerse entre el terminal 110-i y el servicio central 160-i para reenviar los mensajes de protocolo de señalización de sesión de comunicación entre el terminal 110-i y el servicio central 160-i.

[0143] En una primera fase, el terminal 110-i puede transmitir un mensaje SIP INVITE al servicio central 160-i. El mensaje SIP INVITE puede invitar simultáneamente al servicio central 160-i a una sesión VoIP propuesta con un conjunto propuesto de parámetros y transmitir un conjunto de datos telemáticos desde el terminal 110-i al servicio central 160-i. En una segunda fase, el servicio central 160-i puede transmitir un mensaje de respuesta SIP STATUS 180 (Ringing) al terminal 110-i. En una tercera fase, el servicio central 160-i puede transmitir un mensaje SIP STATUS 200 (OK) al terminal 110-i para indicar la aceptación de la sesión VoIP propuesta. El mensaje SIP STATUS (OK) también puede contener metadatos telemáticos que indican que los datos telemáticos transmitidos por el terminal 110-i no se han recibido (por ejemplo, no se han recibido satisfactoriamente) (es decir, una respuesta NAK). En algunos casos, los metadatos telemáticos pueden incluir además instrucciones para el terminal, mensajes, etc. En consecuencia, en una cuarta fase, el terminal 110-i puede transmitir un mensaje SIP ACK que confirma la sesión VoIP y que retransmite los datos telemáticos. En ciertos ejemplos, los datos telemáticos retransmitidos pueden ser los mismos datos telemáticos enviados originalmente con el mensaje SIP INVITE. De forma alternativa, los datos telemáticos retransmitidos pueden actualizarse o ser diferentes de los datos telemáticos originales.

[0144] En una quinta fase, el servicio central 160-i puede transmitir un procedimiento SIP STATUS 183 (SESIÓN EN PROGRESO) que contiene metadatos telemáticos que confirman que los datos telemáticos retransmitidos se han recibido en el servicio central 160-i. En una sexta fase, la llamada VoIP puede ser implementada por la sesión VoIP negociada a través de la cual los datos de voz y/o de otros medios de flujo continuo pueden intercambiarse entre el terminal 110-i y el servicio central 160-i. En la séptima fase y la conclusión de la llamada VoIP, el servicio central 160-i puede transmitir un mensaje SIP BYE al terminal 110-i. En una octava fase, el terminal 110-i puede responder con un mensaje SIP STATUS 200 (OK) para confirmar que la sesión VoIP ha finalizado.

[0145] La FIG. 15 es un diagrama de otro ejemplo de un intercambio de comunicaciones 1500 entre un terminal 110-j y un servicio central 160-j mediante un protocolo de señalización de sesión de comunicación para a) establecer una llamada VoIP y b) intercambiar datos telemáticos y metadatos telemáticos. Al igual que en ejemplos anteriores, el protocolo de señalización de sesión de comunicación puede ser una versión de SIP modificada para transportar datos telemáticos y metadatos telemáticos. En otros ejemplos, se pueden usar otros protocolos de señalización de sesión de comunicación.

[0146] El terminal 110-j puede ser un ejemplo del terminal 110 de la FIG. 1A o uno de los otros terminales 110 descritos anteriormente con referencia a las figuras anteriores. El servicio central 160-j puede ser un ejemplo del servicio central 160 de la FIG. 1A o uno de los otros servicios centrales 160 descritos anteriormente con referencia a las figuras anteriores. En ciertos ejemplos, el servicio central 160-j puede ser implementado por uno o más servidores. Además, en ciertos ejemplos, uno o más servidores apoderados pueden disponerse entre el terminal 110-j y el servicio central 160-j para reenviar los mensajes de protocolo de señalización de sesión de comunicación entre el terminal 110-j y el servicio central 160-j.

[0147] En una primera etapa, el terminal 110-j puede transmitir un mensaje SIP INVITE al servicio central 160-j. El mensaje SIP INVITE puede invitar simultáneamente al servicio central 160-j a una sesión VoIP propuesta con un conjunto propuesto de parámetros y transmitir un conjunto de datos telemáticos desde el terminal 110-j al servicio central 160-j. En una segunda etapa, el servicio central 160-j puede transmitir un mensaje de respuesta SIP STATUS 180 (Ringing) al terminal 110-j. El mensaje de respuesta SIP STATUS 180 (Ringing) también puede incluir metadatos telemáticos que confirman que los datos telemáticos se han recibido en el servicio central 160-j. En una tercera fase, el servicio central 160-j puede transmitir un mensaje SIP STATUS 200 (OK) al terminal 110-j para indicar la aceptación de la sesión VoIP propuesta. En una cuarta fase, el terminal 110-j puede transmitir un mensaje SIP ACK al servicio central 160-j, y en una quinta fase, la sesión VoIP negociada puede implementar la llamada VoIP.

[0148] En una sexta fase, el servicio central 160-j puede transmitir un mensaje SIP INFO al terminal 110-j con metadatos telemáticos adicionales. Los metadatos telemáticos adicionales pueden solicitar datos telemáticos adicionales más allá de lo que se incluyó en el mensaje SIP INVITE inicial. En una séptima fase, el terminal 110-j puede transmitir un mensaje SIP STATUS 200 (OK) al servicio central 160-j con los datos telemáticos adicionales solicitados. En una octava fase, el servicio central 160-j puede transmitir un mensaje SIP INFO al terminal 110-j con un conjunto de metadatos telemáticos que confirman la recepción de los datos telemáticos adicionales. En una novena fase, el terminal 110-j puede transmitir un mensaje SIP STATUS 200 (OK) al servicio central 160-j como respuesta al mensaje SIP INFO de acuerdo con el protocolo SIP. En una décima fase, la sesión VoIP negociada puede continuar.

[0149] En ciertos ejemplos, las fases seis a nueve pueden tener lugar sin interrumpir el flujo de datos de sesión VoIP. Por lo tanto, los datos que transportan voz y/u otros medios pueden intercambiarse entre el terminal 110-j y el servicio central 160-j sustancialmente al mismo tiempo que se intercambian los mensajes SIP que transportan datos telemáticos y metadatos telemáticos. En ciertos ejemplos, los mensajes SIP INFO y SIP STATUS 200 (OK) transmitidos entre el servicio central 160-j y el terminal 110-j en las fases seis a nueve pueden no transportar datos útiles sobre la sesión de VoIP; en cambio, pueden generarse y/o transmitirse con el único propósito de transportar datos telemáticos y metadatos telemáticos. De forma alternativa, los mensajes SIP INFO y SIP STATUS 200 (OK) en las fases seis a nueve pueden transportar información de sesión importante o parámetros de sesión renegociados entre el terminal 110-j y el servicio central 160-j.

[0150] En la undécima fase y la conclusión de la llamada VoIP, el terminal 110-j puede transmitir un mensaje SIP BYE al servicio central 160-j. En una duodécima fase, el servicio central 160-j puede responder con un mensaje SIP STATUS 200 (OK) para confirmar que la sesión VoIP ha finalizado.

[0151] La FIG. 16 muestra un diagrama de bloques de un terminal inalámbrico 110-k a modo de ejemplo. El terminal 110-k puede ser un ejemplo del terminal 110 de la FIG. 1A o uno de los otros terminales 110 descritos anteriormente con referencia a las figuras anteriores. El terminal inalámbrico 110-k del presente ejemplo puede incluir un módulo procesador 1605, una memoria 1610, un módulo de señalización de datos telemáticos 210-c, un módulo transceptor 1625 y antenas 1630. Cada uno de estos componentes puede estar acoplado de manera comunicativa entre sí, directa o indirectamente, (por ejemplo, a través de uno o más buses).

[0152] El módulo transceptor 1625 está configurado para comunicarse de manera bidireccional, a través de las antenas 1630 y/o uno o más enlaces cableados o inalámbricos, con una o más redes, como se ha descrito anteriormente. El módulo transceptor 1625 pueden incluir un módem configurado para modular datos y proporcionar los datos modulados a las antenas 1630 para su transmisión y para desmodular los datos recibidos desde las antenas 1630. Aunque el terminal 110-k puede incluir una única antena, el terminal 110-k puede incluir múltiples antenas 1630 para múltiples enlaces.

[0153] La memoria 1610 puede incluir una memoria de acceso aleatorio (RAM) y una memoria de solo lectura (ROM). La memoria 1610 puede almacenar código de software ejecutable por ordenador y legible por ordenador 1615 que contiene instrucciones que están configuradas, cuando se ejecutan, para hacer que el módulo procesador 1605 realice varias funciones. De forma alternativa, el código de software 1615 puede no ser ejecutable directamente por el módulo procesador 1605 sino que puede configurarse para hacer que el terminal 110-k (por ejemplo, al compilarse y ejecutarse) realice las funciones descritas en el presente documento.

[0154] El módulo procesador 1605 puede incluir un dispositivo de hardware inteligente, por ejemplo una unidad central de procesamiento (CPU) como las fabricadas por Intel® Corporation, AMD® o Qualcomm®, un microcontrolador, un circuito integrado específico de la aplicación (ASIC), etc. De acuerdo con la arquitectura de la FIG. 16, el terminal 110-k puede incluir además el módulo de señalización de datos telemáticos 210-c. El módulo 210-c puede ser un ejemplo del módulo de señalización de datos telemáticos 210 ilustrado en las FIG. 2, 3 y/o 4. El módulo de señalización de datos telemáticos 210-c puede incluir un módulo de señalización 1620. El módulo de señalización 1620 puede hacer que el módulo transceptor 1625 transmita los mensajes de señalización generados al servicio central. Además, el módulo de señalización 1620 puede hacer que el módulo transceptor 1625 reciba mensajes SIP modificados u otros mensajes de protocolo de señalización de sesión de comunicación desde el servicio central.

[0155] La FIG. 17 muestra un diagrama de bloques de un dispositivo a modo de ejemplo que implementa un servicio central 160-k. El dispositivo que implementa el servicio central 160-k puede ser un servidor u otro dispositivo basado en ordenador. El servicio central 160-k puede ser un ejemplo del servicio central 160 de la FIG. 1A o uno o más servicios centrales 160 descritos anteriormente con referencia a las figuras anteriores. El servicio central 160-k del presente ejemplo puede incluir un módulo procesador 1605-a, una memoria 1610-a, un módulo de señalización de metadatos telemáticos 610-c y un controlador de interfaz de red (NIC) 1705. Todos estos componentes pueden estar acoplados de manera comunicativa entre sí, directa o indirectamente.

[0156] La memoria 1610-a puede incluir una memoria de acceso aleatorio (RAM) y una memoria de solo lectura (ROM). La memoria 1610-a puede almacenar código de software ejecutable por ordenador y legible por ordenador 1615-a que contiene instrucciones que están configuradas, cuando se ejecutan, para hacer que el módulo procesador 1605-a realice varias funciones. De forma alternativa, el código de software 1615-a puede no ser ejecutable directamente por el módulo procesador 1605-a sino que puede configurarse para hacer que el servicio central 160-k (por ejemplo, al compilarse y ejecutarse) realice las funciones descritas en el presente documento.

[0157] El servicio central 160-k puede incluir el módulo de señalización de metadatos telemáticos 610-c. El módulo 610-c puede ser un ejemplo del módulo de señalización de metadatos telemáticos 610 ilustrado en las FIG. 6, 7 y/u 8. El módulo de señalización de metadatos telemáticos 610-c puede incluir un módulo de señalización 1620-a. El módulo de señalización 1620-a puede hacer que la NIC 1705 transmita los mensajes de señalización generados al terminal 110. Además, el módulo de señalización 1620-a puede hacer que la tarjeta de interfaz de red 1705 reciba mensajes SIP modificados u otros mensajes de protocolo de señalización de sesión de comunicación desde el terminal.

[0158] La FIG. 18 es un diagrama de flujo que ilustra un modo de realización de un procedimiento 1800 para comunicar datos telemáticos y/o metadatos telemáticos. Para mayor claridad, el procedimiento 1800 se describe con referencia al terminal 110 de las FIG. 1A, 1B, 2, 3, 4, 10, 11, 12, 13, 14, 15 y/o 16. En una implementación, el módulo de señalización de datos telemáticos 210 de las FIG. 2, 3, 4 y/o 16 puede ejecutar uno o más conjuntos de códigos para controlar los elementos funcionales del terminal 110 para realizar las funciones que se describen a continuación.

[0159] En el bloque 1805, un primer mensaje de señalización puede transmitirse desde un primer dispositivo a un segundo dispositivo a través de un protocolo de señalización de sesión de comunicación. En un ejemplo, el primer mensaje de señalización puede incluir al menos un primer conjunto de información de sesión relacionada con una sesión de comunicación entre el primer dispositivo y el segundo dispositivo y un primer conjunto de datos telemáticos para el primer dispositivo. En ciertos ejemplos, el primer dispositivo puede ser uno o más de los terminales 110 descritos con referencia a las figuras precedentes, y el segundo dispositivo puede ser uno o más de los servicios centrales 160 descritos con referencia a las figuras anteriores. El protocolo de señalización de sesión de comunicación puede ser, por ejemplo, una versión modificada del protocolo de inicio de sesión (SIP) como se describe en los ejemplos anteriores, u otro protocolo de señalización de sesión de comunicación aplicable (por ejemplo, XMPP, Google Talk, Skype, etc.). La sesión de comunicación puede ser una llamada VoIP entre el terminal y el servicio central. En algunos casos, la sesión de comunicación puede intercambiar medios de flujo continuo (tales como voz, vídeo, flujo continuo o texto de un carácter a la vez) dentro de un flujo de medios, así como cualquier otro medio (tal como mensajes de texto) fuera de un flujo de medios. En un ejemplo, la sesión de comunicación solo puede transportar medios sin flujo continuo.

[0160] En el bloque 1810, se puede recibir un segundo mensaje de señalización en el primer dispositivo a través del protocolo de señalización de sesión de comunicación. En un ejemplo, el segundo mensaje de señalización puede incluir metadatos basados en un contenido del primer conjunto de datos telemáticos transmitidos en el primer mensaje de señalización. Los metadatos telemáticos pueden incluir, pero sin limitarse a, una confirmación de si los datos telemáticos se recibieron en el servicio central 160, una solicitud para retransmitir los datos telemáticos, una solicitud para transmitir diferentes datos telemáticos, una solicitud para realizar alguna otra acción, datos auxiliares que describen acciones realizadas por el servicio central y/u otros metadatos telemáticos pertinentes.

[0161] Por lo tanto, el procedimiento 1800 puede proporcionar la comunicación de datos telemáticos y/o de metadatos telemáticos. Cabe señalar que el procedimiento 1800 es solo una implementación y que las operaciones del procedimiento 1800 se pueden reorganizar o modificar de otra manera, de modo que otras implementaciones son posibles.

[0162] La FIG. 19 es un diagrama de flujo que ilustra un modo de realización de un procedimiento 1900 para comunicar datos telemáticos y/o metadatos telemáticos modificando los mensajes de señalización utilizados en un protocolo de señalización de sesión de comunicación. Para mayor claridad, el procedimiento 1900 se describe con referencia al terminal 110 de las FIG. 1A, 1B, 2, 3, 4, 10, 11, 12, 13, 14, 15 y/o 16. En una implementación, el módulo de señalización de datos telemáticos 210 de las FIG. 2, 3, 4 y/o 16 puede ejecutar uno o más conjuntos de códigos para controlar los elementos funcionales del terminal 110 para realizar las funciones que se describen a continuación. El procedimiento 1900 de la FIG. 19 puede ser un ejemplo del procedimiento 1800 de la FIG. 18.

[0163] En el bloque 1905, se puede detectar en el terminal un estado de vehículo (por ejemplo, choque, incendio, despliegue del airbag, volcado u otra situación), un mal funcionamiento o una activación manual. En el bloque 1910, se puede generar un primer conjunto de datos telemáticos para el vehículo en base a la entrada de uno o más sensores acoplados de manera comunicativa al terminal. En el bloque 1915, se puede generar una cabecera para un mensaje SIP INVITE en el terminal para invitar a un servicio central (por ejemplo, PSAP) a una sesión de llamada de voz sobre protocolo de Internet (VoIP), donde la cabecera indica que el cuerpo del mensaje asociado tiene un formato multiparte. En el bloque 1920 se puede generar en el terminal un mensaje de protocolo de descripción de sesión (SDP) que contiene un conjunto de parámetros para la sesión propuesta. En el bloque 1925, el mensaje SDP y el primer conjunto de datos telemáticos se pueden combinar en un cuerpo de mensaje del mensaje SIP INVITE, con el mensaje SDP como primera parte del cuerpo del mensaje SIP INVITE y los datos telemáticos como segunda parte del cuerpo del mensaje SIP INVITE. En el bloque 1930, el mensaje SIP INVITE puede transmitirse al servicio central. En un ejemplo, el terminal puede enviar el mensaje INVITE a una entidad que tiene la responsabilidad de gestionar las solicitudes de emergencia (tal como una entidad dentro de la red de un operador), y esa entidad puede procesar o reenviar el mensaje INVITE hacia el servicio central (por ejemplo, PSAP).

[0164] En el bloque 1935 se puede recibir un mensaje de respuesta SIP STATUS 486 (Busy) desde el dispositivo de servicio central PSAP. En un ejemplo, el mensaje de respuesta puede incluir un cuerpo multiparte que contiene una primera parte del cuerpo de mensaje y un conjunto de metadatos telemáticos que confirman el primer conjunto de datos telemáticos en una segunda parte del cuerpo de mensaje. Se observa que el mensaje de respuesta SIP STATUS 486 (Busy) puede no incluir información SDP en el cuerpo de mensaje (la primera parte del cuerpo de mensaje puede estar vacía, por ejemplo). En ciertos ejemplos, el terminal puede determinar a partir de una cabecera del segundo mensaje de señalización que el cuerpo del mensaje de respuesta SIP STATUS 486 (Busy) está en el formato multiparte. El terminal puede identificar además la primera parte del cuerpo de mensaje y la segunda parte del cuerpo de mensaje basándose en información de la cabecera del mensaje de respuesta SIP StAt US 486 (Busy). En algunos casos, se pueden usar otras respuestas STATUS.

[0165] En el bloque 1940, se puede recibir un mensaje SIP INVITE en el terminal desde el dispositivo de servicio central PSAP para una sesión de llamada VoIP, y el cuerpo del mensaje SIP INVITE puede incluir un conjunto de metadatos telemáticos que solicitan datos telemáticos adicionales desde el terminal. De forma alternativa, los metadatos telemáticos pueden recibirse en el terminal en un mensaje de señalización aparte. En el bloque 1945 se puede generar un segundo conjunto de datos telemáticos para el vehículo basándose en la entrada de los sensores y/u otras fuentes de datos telemáticos. En el bloque 1950 se puede generar una cabecera para un mensaje de respuesta SIP STATUS 200 (OK) en el terminal. En un ejemplo, la cabecera puede indicar que un cuerpo de mensaje asociado tiene un formato multiparte. En el bloque 1955 se puede generar un mensaje SDP que contiene parámetros para la sesión propuesta por el dispositivo de servicio central PSAP. En el bloque 1960, el mensaje SDP y el segundo conjunto de datos telemáticos se pueden combinar en un cuerpo de mensaje del mensaje SIP STATUS 200 (OK). En el bloque 1965, el mensaje de respuesta SIP STATUS 200 (OK) puede transmitirse al servicio central desde el terminal. En el bloque 1970 se puede recibir un mensaje SIP ACK en el terminal desde el servicio central, y en el bloque 1975 se puede establecer una sesión VoIP entre el terminal y el servicio central.

[0166] Por lo tanto, el procedimiento 1900 puede proporcionar la comunicación de datos telemáticos y/o de metadatos telemáticos. Cabe señalar que el procedimiento 1900 es solo una implementación y que las operaciones del procedimiento 1900 se pueden reorganizar o modificar de otra manera, de modo que otras implementaciones son posibles.

[0167] La FIG. 20 es un diagrama de flujo que ilustra un modo de realización de un procedimiento 2000 para comunicar datos telemáticos y/o metadatos telemáticos. Para mayor claridad, el procedimiento 2000 se describe con referencia al servicio central 160 de las FIG. 1A, 1B, 6, 7, 8, 10, 11, 12, 13, 14, 15 y/o 17. En una implementación, el módulo de señalización de metadatos telemáticos 610 de las FIG. 6, 7, 8 y/o 17 pueden ejecutar uno o más conjuntos de códigos para controlar los elementos funcionales del servicio central 160 para realizar las funciones que se describen a continuación.

[0168] En el bloque 2005, al menos una parte de un primer mensaje de señalización puede recibirse desde un primer dispositivo en un segundo dispositivo a través de un protocolo de señalización de sesión de comunicación. En un modo de realización, el primer mensaje de señalización puede tener al menos un primer conjunto de información de sesión relacionada con una sesión de comunicación entre el primer dispositivo y el segundo dispositivo. El primer mensaje de señalización también puede tener al menos un primer conjunto de datos telemáticos para el primer dispositivo. En ciertos ejemplos, el primer dispositivo puede ser uno o más de los terminales 110 descritos con referencia a las figuras precedentes, y el segundo dispositivo puede ser uno o más de los servicios centrales 160 descritos con referencia a las figuras anteriores. El protocolo de señalización de sesión de comunicación puede ser, por ejemplo, una versión modificada del protocolo de inicio de sesión (SIP) como se describe en los ejemplos anteriores, u otro protocolo de señalización de sesión de comunicación aplicable (por ejemplo, XMPP, Google Talk, Skype, etc.). La sesión de comunicación puede ser una llamada VoIP entre el terminal y el servicio central. En algunos casos, la sesión de comunicación puede intercambiar medios de flujo continuo (tales como voz, vídeo, flujo continuo o texto de un carácter a la vez) dentro de un flujo de medios, así como cualquier otro medio (tal como mensajes de texto) fuera de un flujo de medios. En un ejemplo, la sesión de comunicación solo puede transportar medios sin flujo continuo.

[0169] En el bloque 2010 se puede transmitir un segundo mensaje de señalización al primer dispositivo a través del protocolo de señalización de sesión de comunicación en respuesta al primer mensaje de señalización, teniendo el segundo mensaje de señalización metadatos basados en un contenido del primer conjunto de datos telemáticos recibidos en el primer mensaje de señalización.

[0170] Por lo tanto, el procedimiento 2000 puede proporcionar la comunicación de datos telemáticos y/o de metadatos telemáticos modificando mensajes de señalización utilizados en un protocolo de señalización de sesión de comunicación. Cabe señalar que el procedimiento 2000 es solo una implementación y que las operaciones del procedimiento 2000 se pueden reorganizar o modificar de otra manera, de modo que otras implementaciones son posibles.

[0171] La FIG. 21 es un diagrama de flujo que ilustra un modo de realización de un procedimiento 2100 para comunicar datos telemáticos y/o metadatos telemáticos modificando los mensajes de señalización utilizados en un protocolo de señalización de sesión de comunicación. Para mayor claridad, el procedimiento 2100 se describe con referencia al servicio central 160 de las FIG. 1A, 1B, 6, 7, 8, 10, 11, 12, 13, 14, 15 y/o 17. En una implementación, el módulo de señalización de metadatos telemáticos 610 de las FIG. 6, 7, 8 y/o 17 pueden ejecutar uno o más conjuntos de códigos para controlar los elementos funcionales del servicio central 160 para realizar las funciones que se describen a continuación. El procedimiento 2100 de la FIG. 21 puede ser un ejemplo del procedimiento 2000 de la FIG. 20.

[0172] En el bloque 2105 se puede recibir un mensaje SIP INVITE en un servicio central (por ejemplo, PSAP) desde un terminal asociado a un vehículo. Un cuerpo del mensaje SIP INVITE puede incluir un mensaje SDP y un conjunto de datos telemáticos para el vehículo. En el bloque 2110 se determina si un operador está disponible para aceptar una llamada de voz y/o de otro medio en el servicio central. Si hay un operador disponible (bloque 2110, SÍ), el servicio central puede transmitir un mensaje de respuesta SIP STATUS 200 (OK) al terminal; en el bloque 2115 el mensaje de respuesta SIP STATUS 200 (OK) incluye metadatos que confirman los datos telemáticos. De forma alternativa, los metadatos pueden transmitirse al terminal en un mensaje de señalización aparte. En el bloque 2120 se puede recibir un mensaje SIP ACK desde el terminal, y en el bloque 2125 se puede establecer una sesión VoIP u otra comunicación con el terminal.

[0173] Sin embargo, si no hay un operador disponible para aceptar la llamada (bloque 2110, NO), en el bloque 2130, el dispositivo de servicio central PSAP puede transmitir un mensaje de respuesta SIP STATUS 485 (Busy) al terminal, donde el mensaje de respuesta incluye metadatos que confirman los datos telemáticos. En el bloque 2135, cuando un operador está disponible, el servicio central puede transmitir un mensaje SIP INVITE al terminal, donde un cuerpo del mensaje SIP contiene un mensaje SDP y metadatos que solicitan una retransmisión de los datos telemáticos. En el bloque 2140, el servicio central puede recibir un mensaje de respuesta SIP STATUS 200 (OK) desde el terminal, donde el cuerpo del mensaje de respuesta SIP STATUS 200 (OK) contiene un mensaje SDP y un segundo conjunto de datos telemáticos. En el bloque 2145 se puede transmitir un mensaje SIP ACK al terminal, y en el bloque 2125 se puede establecer una sesión VoIP u otra comunicación con el terminal.

[0174] Por lo tanto, el procedimiento 2100 puede proporcionar la comunicación de metadatos telemáticos. Cabe señalar que el procedimiento 2100 es solo una implementación y que las operaciones del procedimiento 2100 se pueden reorganizar o modificar de otra manera, de modo que otras implementaciones son posibles.

[0175] La descripción detallada que se ha expuesto anteriormente en relación con los dibujos adjuntos describe modos de realización a modo de ejemplo y no representa los únicos modos de realización que pueden implementarse o que están dentro del alcance de las reivindicaciones. La expresión "a modo de ejemplo" usada a lo largo de esta descripción significa "que sirve como ejemplo, instancia o ilustración", y no "preferente" o "ventajoso con respecto a otros modos de realización". La descripción detallada incluye detalles específicos con el propósito de permitir una comprensión de las técnicas descritas. Sin embargo, estas técnicas se pueden poner en práctica sin estos detalles específicos. En algunos casos, estructuras y dispositivos bien conocidos se muestran en forma de diagrama de bloques para no complicar los conceptos de los modos de realización descritos.

[0176] La información y las señales se pueden representar usando cualquiera de una variedad de tecnologías y técnicas diferentes. Por ejemplo, los datos, las instrucciones, los comandos, la información, las señales, los bits, los símbolos y los chips que puedan haberse mencionado a lo largo de la descripción anterior pueden representarse mediante tensiones, corrientes, ondas electromagnéticas, campos o partículas magnéticos, campos o partículas ópticos o cualquier combinación de los mismos.

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

[0178] Las funciones descritas en el presente documento se pueden implementar en hardware, software ejecutado por un procesador, firmware o cualquier combinación de los mismos. Si se implementan en software ejecutado por un procesador, las funciones se pueden almacenar en, o transmitir por, un medio legible por ordenador como una o más instrucciones o código. Otros ejemplos e implementaciones están dentro del alcance de la divulgación y de las reivindicaciones adjuntas.

Por ejemplo, debido a la naturaleza del software, las funciones descritas anteriormente se pueden implementar usando software ejecutado por un procesador, hardware, firmware, preprogramación o combinaciones de cualquiera de estos. Las características que implementan funciones también pueden estar ubicadas físicamente en diversas posiciones, lo que incluye estar distribuidas de modo que partes de las funciones se implementan en diferentes ubicaciones físicas. Además, como se usa en el presente documento, incluso en las reivindicaciones, "o", como se usa en una lista de elementos precedida por "al menos uno de" indica una lista disyuntiva de tal forma que, por ejemplo, una lista de "al menos uno de A, B o C" significa A o B o C o AB o AC o BC o ABC (es decir, A y B y C).

[0179] Los medios legibles por ordenador incluyen tanto medios de almacenamiento informático como medios de comunicación, incluido cualquier medio que facilite la transferencia de un programa informático de un lugar a otro. Un medio de almacenamiento puede ser cualquier medio disponible al que se pueda acceder mediante un ordenador de propósito general o de propósito especial. A modo de ejemplo, y no de manera limitativa, los medios legibles por ordenador pueden comprender rAm , ROM, EEPROM, CD-ROM u otro almacenamiento de disco óptico, almacenamiento de disco magnético u otros dispositivos de almacenamiento magnético, o cualquier otro medio que pueda usarse para transportar o almacenar medios de código de programa deseado en forma de instrucciones o estructuras de datos y al que pueda accederse mediante un ordenador de propósito general o de propósito especial, o mediante un procesador de propósito general o de propósito especial. Además, cualquier conexión recibe adecuadamente la denominación de medio legible por ordenador. Por ejemplo, si el software se transmite desde un sitio web, un servidor u otro origen remoto usando un cable coaxial, un cable de fibra óptica, un par trenzado, una línea de abonado digital (DSL) o tecnologías inalámbricas tales como infrarrojos, radio y microondas, entonces el cable coaxial, el cable de fibra óptica, el par trenzado, la DSL o las tecnologías inalámbricas, tales como infrarrojos, radio y microondas, se incluyen en la definición de medio. Los discos, como se usan en el presente documento, incluyen el disco compacto (CD), el disco láser, el disco óptico, el disco versátil digital (DVD), el disco flexible y el disco Blu-ray, donde algunos discos reproducen normalmente los datos magnéticamente, mientras que otros discos reproducen los datos ópticamente con láseres. Combinaciones de lo anterior también están incluidas dentro del alcance de los medios legibles por ordenador.

[0180] Las técnicas descritas en el presente documento se pueden usar en diversos sistemas de comunicaciones inalámbricas, tales como CDMA, TDMA, FDMA, OFDMA, SC-FDMA y otros sistemas. Los términos "sistema" y "red" a menudo se usan de manera intercambiable. Un sistema CDMA puede implementar una tecnología de radio tal como CDMA2000, acceso radioeléctrico terrestre universal (UTRA), etc. CDMA2000 incluye las normas IS-2000, IS-95 e IS-856. Las Versiones 0 y A de la norma IS-2000 se denominan comúnmente CDMA2000 IX, IX, etc. La norma IS-856 (TIA-856) se denomina comúnmente CDMA2000 IxEV-DO, datos en paquetes de alta velocidad (HRPD), etc. UTRA incluye CDMA de banda ancha (WCDMA) y otras variantes de CDMA. Un sistema TDMA puede implementar una tecnología de radio tal como el sistema global para comunicaciones móviles (GSM). Un sistema OFDMA puede implementar una tecnología de radio tal como la banda ancha ultramóvil (UMB), UTRA evolucionado (E-UTRA), IEEE 802,11 (Wi-Fi), IEEE 802,16 (WiMAX), IEEE 802,20, Flash-OFDM, etc. UTRA y E-UTRA forman parte del sistema universal de telecomunicaciones móviles (UMTS). La evolución a largo plazo (LTE) y la LTE avanzada (LTE-A) de 3GPP son versiones nuevas de UMTS que usan E-UTRA. UTRA, E-UTRA, UMTS, lTe , LTE-A y GSM se describen en documentos de una organización llamada "Proyecto de Asociación de Tercera Generación" (3GPP). CDMA2000 y UMB se describen en documentos de una organización llamada "Segundo Proyecto de Asociación de Tercera Generación" (3GPP2). Las técnicas descritas en el presente documento se pueden utilizar en sistemas y tecnologías de radio que se han mencionado anteriormente, así como en otros sistemas y tecnologías de radio.

[0181] La anterior descripción de la divulgación se proporciona para permitir que un experto en la técnica realice o use la divulgación. Diversas modificaciones de la divulgación resultarán fácilmente evidentes a los expertos en la técnica, y los principios genéricos definidos en el presente documento pueden aplicarse a otras variantes sin apartarse del alcance de la divulgación. A lo largo de esta divulgación, la expresión "ejemplo" o "a modo de ejemplo" indica un ejemplo o instancia y no implica ni requiere ninguna preferencia para el ejemplo señalado. Por lo tanto, la divulgación no ha de limitarse a los ejemplos y diseños descritos en el presente documento, sino que se le ha de otorgar el más amplio alcance congruente con los principios y las características novedosas divulgados en el presente documento.

Claims

REIVINDICACIONES

1. Un procedimiento de comunicación de datos telemáticos (1800), que comprende:

transmitir un primer mensaje de señalización (500) desde un primer dispositivo (110) a un segundo dispositivo (160) a través de un protocolo de señalización de sesión de comunicación, donde el primer mensaje de señalización (500) comprende al menos un primer conjunto de información de sesión (515) relacionada con una sesión de comunicación entre el primer dispositivo (110) y el segundo dispositivo (160) y un primer conjunto de datos telemáticos (520) para el primer dispositivo (110); y

recibir un segundo mensaje de señalización (900) en el primer dispositivo (110) a través del protocolo de señalización de sesión de comunicación, donde el segundo mensaje de señalización (900) comprende metadatos (920) basados en un contenido del primer conjunto de datos telemáticos (520) transmitidos en el primer mensaje de señalización (500).

2. El procedimiento según la reivindicación 1, en el que el segundo mensaje de señalización incluye un segundo conjunto de información de sesión relacionada con la sesión de comunicación.

3. El procedimiento según la reivindicación 1, en el que la recepción del segundo mensaje de señalización a través del protocolo de señalización de sesión de comunicación comprende:

recibir una indicación de si el primer conjunto de datos telemáticos se recibió satisfactoriamente en el segundo dispositivo, donde la indicación comprende los metadatos basados en el contenido del primer conjunto de datos telemáticos.

4. El procedimiento según la reivindicación 1, en el que la recepción del segundo mensaje de señalización a través del protocolo de señalización de sesión de comunicación comprende además:

recibir una solicitud con respecto al primer conjunto de datos telemáticos, comprendiendo la solicitud los metadatos basados en el contenido del primer conjunto de datos telemáticos; y preferentemente

la solicitud comprende al menos una de: una solicitud para retransmitir el primer conjunto de datos telemáticos, una solicitud para transmitir una versión actualizada del primer conjunto de datos telemáticos, o una solicitud para transmitir un conjunto diferente de datos telemáticos; y/o preferentemente

comprende además:

transmitir un tercer mensaje de señalización desde el primer dispositivo al segundo dispositivo a través del protocolo de señalización de sesión de comunicación, donde el tercer mensaje de señalización comprende al menos una respuesta a la solicitud recibida con respecto al primer conjunto de datos telemáticos.

5. El procedimiento según la reivindicación 1, en el que la recepción del segundo mensaje de señalización a través del protocolo de señalización de sesión de comunicación comprende además:

recibir una instrucción desde el segundo dispositivo para realizar al menos una acción basándose en el contenido del primer conjunto de datos telemáticos, comprendiendo la instrucción los metadatos basados en el contenido del primer conjunto de datos telemáticos; y preferentemente

en el que la al menos una acción comprende al menos una de: recopilar datos telemáticos adicionales, realizar una acción que afecte al estado de un vehículo, activar un componente de un vehículo, desactivar un componente de un vehículo, apagar el motor de un vehículo, encender el motor de un vehículo, interrumpir el suministro de combustible de un vehículo, iniciar el suministro de combustible de un vehículo, abrir una puerta, cerrar una puerta, hacer sonar el claxon de un vehículo, activar un sonido audible externamente, encender las luces de un vehículo, encender los intermitentes de un vehículo, accionar una ventana eléctrica, reproducir un mensaje grabado, reproducir información multimedia o mostrar un mensaje de texto.

6. El procedimiento según la reivindicación 3, que comprende además:

determinar a partir de una cabecera del segundo mensaje de señalización que al menos una parte de un cuerpo del segundo mensaje de señalización comprende los metadatos; y preferentemente

comprende además:

determinar a partir de la cabecera del segundo mensaje de señalización que el cuerpo del segundo mensaje de señalización comprende un formato multiparte;

identificar una primera parte del cuerpo del segundo mensaje de señalización conforme a la información de la cabecera, donde la primera parte del cuerpo del segundo mensaje de señalización comprende al menos el segundo conjunto de información de sesión relacionada con la sesión de comunicación; e

identificar una segunda parte del cuerpo del segundo mensaje de señalización conforme a la información de la cabecera, donde la segunda parte del cuerpo del segundo mensaje de señalización comprende al menos los metadatos basados en el contenido del primer conjunto de datos telemáticos transmitidos en el primer mensaje de señalización.

7. El procedimiento según la reivindicación 1, que comprende además:

generar una cabecera para el primer mensaje de señalización basándose en el protocolo de señalización de sesión de comunicación, comprendiendo la cabecera una indicación de que al menos una parte de un cuerpo del primer mensaje de señalización comprende el primer conjunto de datos telemáticos; y preferentemente

comprende además:

formatear el primer conjunto de información de sesión de acuerdo con un primer protocolo;

formatear el primer conjunto de datos telemáticos de acuerdo con un segundo protocolo;

y

combinar al menos el primer conjunto formateado de información de sesión y el primer conjunto formateado de datos telemáticos para generar el cuerpo del primer mensaje de señalización.

8. Un aparato para comunicar datos telemáticos (110-k), que comprende:

medios (210-c, 1625) para transmitir un primer mensaje de señalización (500) desde un primer dispositivo (110) a un segundo dispositivo (160) a través de un protocolo de señalización de sesión de comunicación, donde el primer mensaje de señalización (500) comprende al menos un primer conjunto de información de sesión (515) relacionada con una sesión de comunicación entre el primer dispositivo (110) y el segundo dispositivo (160) y un primer conjunto de datos telemáticos (520) para el primer dispositivo (110);

y

medios (1625) para recibir un segundo mensaje de señalización (900) en el primer dispositivo (110) a través del protocolo de señalización de sesión de comunicación, donde el segundo mensaje de señalización (900) comprende metadatos (920) basados en un contenido del primer conjunto de datos telemáticos (520) transmitidos en el primer mensaje de señalización (500).

9. Un procedimiento de comunicación de datos telemáticos (2000), que comprende:

recibir al menos una parte de un primer mensaje de señalización (500) desde un primer dispositivo (110) en un segundo dispositivo (160) a través de un protocolo de señalización de sesión de comunicación, donde el primer mensaje de señalización (500) comprende al menos un primer conjunto de información de sesión (515) relacionada con una sesión de comunicación entre el primer dispositivo (110) y el segundo dispositivo (160) y un primer conjunto de datos telemáticos (520) para el primer dispositivo (110); y

transmitir un segundo mensaje de señalización (900) al primer dispositivo (110) a través del protocolo de señalización de sesión de comunicación en respuesta al primer mensaje de señalización (500), donde el segundo mensaje de señalización (900) comprende metadatos (920) basados en un contenido del primer conjunto de datos telemáticos (520) recibidos en el primer mensaje de señalización (500).

10. El procedimiento según la reivindicación 1 o 9, en el que el primer conjunto de información de sesión comprende al menos uno de una solicitud para iniciar la sesión de comunicación o información asociada a la sesión de comunicación.

11. El procedimiento según la reivindicación 9, en el que el segundo mensaje de señalización incluye un segundo conjunto de información de sesión relacionada con la sesión de comunicación; y/o

en el que la transmisión del segundo mensaje de señalización a través del protocolo de señalización de sesión de comunicación comprende:

transmitir una indicación de si el primer conjunto de datos telemáticos se recibió satisfactoriamente en el segundo dispositivo, donde la indicación comprende los metadatos basados en el contenido del primer conjunto de datos telemáticos.

12. El procedimiento según la reivindicación 9, en el que la transmisión del segundo mensaje de señalización a través del protocolo de señalización de sesión de comunicación comprende:

transmitir una solicitud con respecto al primer conjunto de datos telemáticos, comprendiendo la solicitud los metadatos basados en el contenido del primer conjunto de datos telemáticos; y preferentemente

comprende además:

recibir un tercer mensaje de señalización desde el primer dispositivo a través del protocolo de señalización de sesión de comunicación, donde el tercer mensaje de señalización comprende al menos una respuesta a la solicitud transmitida con respecto al primer conjunto de datos telemáticos.

13. El procedimiento según la reivindicación 1 o 9, en el que el primer mensaje de señalización comprende una invitación para iniciar la sesión de comunicación y el segundo mensaje de señalización comprende un rechazo de la invitación; o

en el que el protocolo de señalización de sesión de comunicación comprende al menos uno de: protocolo de inicio de sesión (SIP), protocolo de presencia y de mensajería extensible (XMPP), Google Talk o Skype; o

en el que la sesión de comunicación comprende una llamada de voz sobre protocolo de Internet (VoIP); o en el que la sesión de comunicación transporta uno o más de entre voz, texto de un carácter a la vez, texto de un mensaje a la vez, vídeo y mensajería de texto utilizando al menos uno de entre medios de flujo continuo o sin flujo continuo.

14. Un aparato para comunicar datos telemáticos (160-k), que comprende:

medios (610-c, 1705) para recibir al menos una parte de un primer mensaje de señalización (500) desde un primer dispositivo (110) en un segundo dispositivo (160) a través de un protocolo de señalización de sesión de comunicación, donde el primer mensaje de señalización (500) comprende al menos un primer conjunto de información de sesión (515) relacionada con una sesión de comunicación entre el primer dispositivo (110) y el segundo dispositivo (160) y un primer conjunto de datos telemáticos (520) para el primer dispositivo; y

medios (1705) para transmitir un segundo mensaje de señalización (900) al primer dispositivo (110) a través del protocolo de señalización de sesión de comunicación en respuesta al primer mensaje de señalización (500), donde el segundo mensaje de señalización (900) comprende metadatos (920) basados en un contenido del primer conjunto de datos telemáticos (520) recibidos en el primer mensaje de señalización (500).

15. Un producto de programa informático para comunicar datos telemáticos, comprendiendo el producto de programa informático un medio no transitorio legible por ordenador que almacena instrucciones ejecutables por un procesador para llevar a cabo las etapas de procedimiento de cualquiera de las reivindicaciones 1 a 7 o 9 a 13.