ES2902151T3 - Alternativa mejorada a modo en banda para llamadas de emergencia - Google Patents

Alternativa mejorada a modo en banda para llamadas de emergencia Download PDF

Info

Publication number
ES2902151T3
ES2902151T3 ES16823112T ES16823112T ES2902151T3 ES 2902151 T3 ES2902151 T3 ES 2902151T3 ES 16823112 T ES16823112 T ES 16823112T ES 16823112 T ES16823112 T ES 16823112T ES 2902151 T3 ES2902151 T3 ES 2902151T3
Authority
ES
Spain
Prior art keywords
ecall
band
audio
psap
band signaling
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES16823112T
Other languages
English (en)
Inventor
Stephen William Edge
Nikolai Konrad Leung
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Qualcomm Inc
Original Assignee
Qualcomm Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Qualcomm Inc filed Critical Qualcomm Inc
Application granted granted Critical
Publication of ES2902151T3 publication Critical patent/ES2902151T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/90—Services for handling of emergency or hazardous situations, e.g. earthquake and tsunami warning systems [ETWS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B1/00—Details of transmission systems, not covered by a single one of groups H04B3/00 - H04B13/00; Details of transmission systems not characterised by the medium used for transmission
    • H04B1/005—Details of transmission systems, not covered by a single one of groups H04B3/00 - H04B13/00; Details of transmission systems not characterised by the medium used for transmission adapting radio receivers, transmitters andtransceivers for operation on two or more bands, i.e. frequency ranges
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04J—MULTIPLEX COMMUNICATION
    • H04J11/00—Orthogonal multiplex systems, e.g. using WALSH codes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0014—Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the source coding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829—Arrangements specially adapted for the receiver end
    • H04L1/1835—Buffer management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/20—Arrangements for detecting or preventing errors in the information received using signal quality detector
    • H04L1/205—Arrangements for detecting or preventing errors in the information received using signal quality detector jitter monitoring
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852—Delays
    • H04L43/087—Jitter
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/10—Flow control between communication endpoints
    • H04W28/14—Flow control between communication endpoints using intermediate storage
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/18—Information format or content conversion, e.g. adaptation by the network of the transmitted or received information for the purpose of wireless delivery to users or terminals
    • H04W4/185—Information format or content conversion, e.g. adaptation by the network of the transmitted or received information for the purpose of wireless delivery to users or terminals by embedding added-value information into content, e.g. geo-tagging
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/16—Gateway arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L27/00—Modulated-carrier systems
    • H04L27/0014—Carrier regulation
    • H04L2027/0083—Signalling arrangements
    • H04L2027/0089—In-band signals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/50—Centralised arrangements for answering calls; Centralised arrangements for recording messages for absent or busy subscribers ; Centralised arrangements for recording messages
    • H04M3/51—Centralised call answering arrangements requiring operator intervention, e.g. call or contact centers for telemarketing
    • H04M3/5116—Centralised call answering arrangements requiring operator intervention, e.g. call or contact centers for telemarketing for emergency applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W52/00—Power management, e.g. TPC [Transmission Power Control], power saving or power classes
    • H04W52/02—Power saving arrangements
    • H04W52/0209—Power saving arrangements in terminal devices
    • H04W52/0225—Power saving arrangements in terminal devices using monitoring of external events, e.g. the presence of a signal

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Environmental & Geological Engineering (AREA)
  • Business, Economics & Management (AREA)
  • Quality & Reliability (AREA)
  • Emergency Management (AREA)
  • Public Health (AREA)
  • Health & Medical Sciences (AREA)
  • Marketing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Other Investigation Or Analysis Of Materials By Electrical Means (AREA)

Abstract

Un método (700) en un dispositivo (105, 107) de comunicaciones de aumento de fiabilidad de la transferencia de datos recibidos a través de la señalización en banda durante una eCall o una eCall de próxima generación, comprendiendo el método: obtener (710) una indicación de señalización en banda, produciéndose la señalización en banda en un canal de audio de una red (102) de comunicación y transfiriendo dicha señalización en banda un conjunto mínimo de datos, MSD, durante la eCall o la eCall de próxima generación; y en respuesta a la obtención de la indicación de señalización en banda, utilizar un proceso de decodificación modificado para decodificar señales de audio para el canal de audio, en donde el proceso de decodificación modificado comprende inhabilitar un búfer (410) de eliminación de variación rápida adaptativo; o aumentar un intervalo de tiempo para almacenamiento en búfer de paquetes de audio en un búfer (410) de eliminación de variación rápida adaptativo.

Description

DESCRIPCIÓN
Alternativa mejorada a modo en banda para llamadas de emergencia
Referencias cruzadas con solicitudes relacionadas
Antecedentes
Lo siguiente se relaciona en general con la comunicación inalámbrica, y más específicamente con la transmisión y recepción inalámbrica 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 procesamiento. Por ejemplo, un terminal asociado con un vehículo que experimenta una colisión puede transmitir datos de ubicación medidos y datos preconfigurados de vehículo sobre 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 proveedor de servicios de terceros (TSP), que luego puede transmitir algunos o todos los datos a un PSAP.
Se dirige la atención al documento US 6,600,740 (B1), que describe una red de comunicación que tiene múltiples códecs que comunican llamadas de voz entre una red de origen y una red de terminación. La red de comunicación incluye un códec de origen y un códec de terminación. La red proporciona señalización que indica el algoritmo de decodificación a la red de origen, y que indica el algoritmo de codificación a la red de terminación. Los algoritmos de codificación originales y los algoritmos de decodificación originales luego se alteran desde el estándar como una función de esta señalización para producir una coincidencia de codificación que mejor se ajuste para mejorar la calidad de voz.
Se dirige la atención además al documento US 2011/287736 (A1), que describe la señalización en banda, es decir, la transmisión de datos en un canal de voz de una red inalámbrica digital durante una sesión de llamada de voz. Se describe una familia de métodos de señalización de banda estrecha, empleando algunas formas de onda ahusadas, para pasar con éxito señales portadoras de datos a través de los modos de baja tasa de bits del vocodificador EVRC-B comúnmente usado en canales inalámbricos de CDMA.
Resumen
De acuerdo con la presente invención, se proporciona un método y un dispositivo, como se establece en las reivindicaciones independientes. Realizaciones de la invención se reivindican en las reivindicaciones dependientes. Estos y otros aspectos de la divulgación se divulgan en la siguiente descripción y dibujos relacionados dirigidos a aspectos específicos de la divulgación. Pueden concebirse aspectos alternativos sin apartarse del alcance de la divulgación. Adicionalmente, los elementos bien conocidos de la divulgación no se describirán en detalle o se omitirán de tal manera que no oculten los detalles relevantes de la divulgación.
Breve descripción de los dibujos
Se puede obtener un entendimiento de la naturaleza y ventajas de diversas realizaciones mediante referencia a las siguientes figuras.
La figura 1 es un diagrama de bloques simplificado que ilustra la arquitectura de un sistema para habilitar eCalls de NG para LTE, de acuerdo con una realización.
La figura 2 es un flujo de señalización que ilustra cómo, de acuerdo con una realización, diversos componentes de un sistema de LTE pueden interactuar para establecer una eCall de NG, dando como resultado una transferencia de MSD en banda.
La figura 3 es un flujo de señalización que ilustra el flujo de llamadas entre componentes de un sistema de LTE para transferir el MSD, de acuerdo con una realización.
La figura 4 es un diagrama de bloques simplificado que ilustra un proceso de almacenamiento en búfer y decodificación, de acuerdo con una realización.
La figura 5 es un diagrama de bloques simplificado que ilustra un proceso de transcodificación, de acuerdo con una realización.
La figura 6 es un diagrama de flujo que ilustra un método de aumento de la fiabilidad de la transferencia de datos recibidos a través de señalización en banda, de acuerdo con una realización.
La figura 7 es un diagrama de flujo que ilustra un método de aumento de la fiabilidad de la transferencia de datos recibidos a través de señalización en banda, de acuerdo con otra realización.
La figura 8 es un diagrama de bloques de una realización de un dispositivo móvil o UE.
La figura 9 es un diagrama de bloques de una realización de un sistema de ordenador.
Descripción detallada
Los terminales asociados con vehículos que ofrecen funcionalidad de llamada de emergencia manual y automática típicamente establecen un canal de voz (también denominado como una trayectoria de medios de voz o canal de audio) entre un ocupante de vehículo y un operador de PSAP y usan el canal de voz para transferir datos telemáticos en banda al operador de PSAP. Los datos telemáticos también pueden transmitirse desde el terminal a un servicio central (por ejemplo, un servidor de TSP) en banda usando un canal de voz. Los metadatos asociados con los datos telemáticos, tales como un acuse de recibo de que los datos telemáticos fueron recibidos satisfactoriamente (por ejemplo, con éxito) o una solicitud de datos telemáticos actualizados, también pueden comunicarse en banda sobre el canal de voz desde un servicio central o PSAP al Terminal.
En un sistema de comunicación inalámbrica que proporciona acceso inalámbrico basado en IP, tal como el sistema de LTE 3GPP, puede ser más eficiente y menos obstructivo para los ocupantes del vehículo y el centro de servicio (por ejemplo un TSP o PSAP) transferir los datos y metadatos telemáticos usando medios de señalización fuera de banda tales como usando señalización de SIP, IMS y/o un canal de datos dedicado separado en lugar de transferir los datos en banda sobre el canal de voz. Sin embargo, en algunos escenarios, un centro de servicio (por ejemplo un servidor de PSAP o TSP) puede no soportar la señalización fuera de banda - por ejemplo, si el centro de servicio está conectado a la Red Telefónica Pública Conmutada o a un enrutador selectivo Conmutado por Circuitos (CS) en lugar de al Internet o a un enrutador de IP. En ese caso, los datos y metadatos telemáticos pueden necesitar ser transferidos en banda sobre el canal de voz - por ejemplo modulando el canal de voz usando señalización en banda, tonos Baudot, o alguna otra técnica de módem en banda.
La transmisión de datos y metadatos telemáticos sobre un canal de voz por medios en banda puede ser problemática ya que la comunicación de voz puede bloquearse o experimentar 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 rendimiento de datos limitado o no ser fiable debido a las funciones de procesamiento de voz en la red (por ejemplo, canceladores de eco incorrectamente sintonizados y uso de compresión en troncales de red). Estas limitaciones pueden ser particularmente agudas en sistemas tales como Evolución a Largo Plazo (LTE) y Acceso a Paquetes de Alta Velocidad (HSPA) cuando un canal de voz se proporciona a través de medios de paquetes en lugar de circuitos debido al uso de vocodificación y transcodificación adicionales incluyendo el uso de almacenamiento en búfer de eliminación de variación rápida que puede distorsionar además la señalización de audio en banda llevando a una transferencia aún menos fiable de datos y metadatos telemáticos y más interferencia a la comunicación de voz.
Esta divulgación generalmente está relacionada con técnicas para aumentar la fiabilidad y velocidad de la transferencia de datos, tales como datos y metadatos telemáticos, recibidos a través de señalización en banda. La divulgación usa un número de abreviaturas para describir diversas realizaciones específicas, aunque se entenderá que las realizaciones no están limitadas a ello. La Tabla 1 proporciona una lista de abreviaturas usadas en esta divulgación.
Tabla 1 - Abreviaturas
Figure imgf000003_0001
continuación
Figure imgf000004_0001
Una llamada relacionada con emergencia activada automática o manualmente desde un terminal asociado con un vehículo a un PSAP o TSP a veces se denomina como una eCall. Esto se aplica en Europa donde el término "eCall" denota un tipo particular de llamada de emergencia desde un Sistema En Vehículo (IVS) a un PSAP sobre una red de comunicación inalámbrica tal como una red de GSM, UMTS o LTE. Una eCall puede iniciarse desde un IVS en un vehículo ya sea automáticamente cuando los sensores detectan una situación de emergencia (por ejemplo despliegue de bolsas de aire) o manualmente mediante invocación por conductor o un pasajero en el vehículo. Como parte de la eCall, datos telemáticos, denominados como un conjunto mínimo de datos (MSD), se transfieren desde el componente de Equipo de Usuario (UE) del IVS al PSAP ya sea durante el establecimiento de eCall o inmediatamente (por ejemplo unos pocos segundos) después del establecimiento de eCall. El MSD puede incluir información útil o crítica para el PSAP (que no se puede obtener de otra manera, en el caso donde un conductor o pasajero en un vehículo esté inconsciente o no pueda de otro modo proporcionar información verbalmente), que incluye, por ejemplo: ubicación del vehículo, información de identificación de vehículo, tipo de vehículo, posible carga peligrosa en el vehículo, número de cinturones de seguridad que se usan (y/u otra información que pueda ser indicativa del número de pasajeros en el vehículo), información de sensor, y similares. Después de la transferencia exitosa del MSD, el PSAP puede retornar metadatos al IVS confirmando la transferencia exitosa. En algún momento posterior en la llamada, el PSAP puede enviar metadatos al IVS para solicitarle al IVS que envíe un MSD actualizado al PSAP (por ejemplo que contenga una nueva ubicación para el vehículo y/o una indicación de un número diferente de ocupantes de vehículo). El MSD y los metadatos asociados (por ejemplo confirmación de MSD o solicitud de MSD) pueden transferirse usando medios en banda o fuera de banda que pueden depender de si el sistema de comunicación inalámbrica que está siendo usado soporta o no soporta la transferencia fuera de banda.
Con eCall de Próxima Generación (NG) (también denominada como eCall sobre IMS), la transferencia del MSD típicamente se produce usando medios fuera de banda y puede ser aplicable cuando el sistema de comunicación inalámbrica usa LTE. La transferencia fuera de banda puede ser típicamente tanto más rápida como más fiable que transferir el MSD por medios en banda usando la trayectoria de medios de voz desde el IVS al PSAP, que puede necesitar soportarse para eCall sobre tecnologías más antiguas tales como GSM o UMTS. Sin embargo, la transferencia fuera de banda de MSD (por ejemplo usando SIP o usando un canal de datos dedicado separado) puede depender de que un PSAP sea compatible con IP (por ejemplo SIP).
Cuando eCall de NG se libera inicialmente en Europa, lo cual podría producirse ya en 2018 para cumplir con un mandato del Parlamento Europeo, muchos PSAPs aún pueden ser "heredados", solo capaces de aceptar llamadas conmutadas por circuitos (por ejemplo, a través de una interfaz de ISDN o DTMF). De este modo, para asegurar la compatibilidad con versiones anteriores de eCall de NG con sistemas heredados, la señalización basada en IP, tal como señalización de SIP, puede necesitar ser convertida para comunicarse dentro de una red conmutada por circuitos. Por ejemplo, en estos casos, una red de IMS de origen puede usar una Función de Control de Pasarela de Medios (MGCF) para convertir la señalización de SIP en el lado de red de origen a la Parte de Usuario de ISDN de SS7 (ISUP) o señalización de multifrecuencia (MF) en el PSAP (o lado de Red Telefónica Pública Conmutada (PSTN)) y una Pasarela de Medios (MGW) asociada pueden usarse para convertir VoIP en el lado de red en voz basada en circuitos (por ejemplo ley de PCM A) en el lado de PSAP (o PsTN).
Cuando tiene lugar esta conversión de señalización de SIP (por ejemplo, cuando se envía una eCall a un PSAP heredado), el MSD no puede ser transferido por la MGCF si se incluye en la señalización de SIP (por ejemplo en un mensaje de SIP INVITE) y en su lugar puede ser descartado por la MGCF. Puede haber una ocurrencia similar cuando el MSD se transfiere usando otros medios fuera de banda - por ejemplo si el MSD va a ser transferido usando un canal de datos dedicado separado, la MGCF puede indicar al IVS que no se puede establecer el canal de datos separado. Cuando el elemento de UE en el IVS no recibe entonces metadatos desde el PSAP confirmando la recepción del MSD por el PSAP (o cuando el UE es informado por otros medios de que la transferencia fuera de banda del MSD no es posible), el UE puede enviar el MSD en banda (por ejemplo, a través de un módem de datos) como parte de la trayectoria de medios de voz. El PSAP, si es compatible con eCall, puede entonces recibir y acusar recibo del MSD por medios en banda.
Con GSM y UMTS, se ha demostrado que la transferencia en banda del MSD usado para eCall es altamente fiable e interrumpe la trayectoria de voz durante solo alrededor de 5 a 10 segundos. Sin embargo, con el acceso de LTE, como se puede usar para eCall de NG, se conoce que la transferencia es mucho menos fiable y típicamente interrumpe la trayectoria de voz durante más tiempo. Esto se debe al uso de un módem de datos para codificar los datos de MSD como audio en banda que es sensible al empaquetado y desempaquetado de voz (por ejemplo uso de Búferes de Eliminación de Variación Rápida (DJBs) adaptativos en un receptor) y los códecs particulares usados para LTE. El resultado es que eCall de NG puede transferir el MSD de manera menos fiable y causar más interrupción de comunicación de voz que el sistema de eCall en banda para GSM y UMTS que es reemplazado por eCall de NG en el caso de LTE. Este problema puede surgir siempre que un IVS tenga acceso a una red de LTE pero no a una red de GSM o UMTS y el PSAP al cual se enruta la eCall solo es capaz de soportar eCall donde el MSD se transfiere en banda sobre el canal de voz. En este escenario, el IVS puede necesitar iniciar una llamada de emergencia basada en IP como para eCall de NG pero transferir el MSD por medios en banda sobre la trayectoria de medios de voz, arriesgando de esa manera fiabilidad reducida, transferencia más lenta del MSD y un período más largo de interferencia (por ejemplo bloqueo) de la trayectoria de medios de voz para la comunicación de voz entre el PSAP y los ocupantes del vehículo.
Esta divulgación proporciona técnicas para aumentar la fiabilidad de eCall de NG para LTE en el caso donde los datos telemáticos en la forma de MSD necesiten ser transferidos en banda desde el componente de UE de un IVS a un PSAP o TSP y/o donde los metadatos en la forma de una confirmación de MSD de recepción o solicitud de MSD actualizado necesita transferirse en banda desde un PSAP o TSP a un IVS. Sin embargo, realizaciones no están limitadas a ello y pueden usarse para ayudar a otras aplicaciones donde los datos no pueden transferirse por medios fuera de banda y necesitan en su lugar ser transferidos por medios en banda sobre una trayectoria de medios tal como una trayectoria de medios de voz. Por ejemplo, las técnicas en este documento se pueden utilizar para transferir datos telemáticos que pueden diferir del MSD actualmente definido para Europa, y/o para transferir metadatos que pueden diferir de los metadatos actualmente definidos para el MSD en Europa, desde un IVS ya sea a un PSAP o a un TSP y/o desde un PSAP o TSP a un IVS. Además, las técnicas pueden usarse para soportar otros tipos de comunicación de NG entre un UE y un proveedor de servicios donde se transfiere alguna información entre el UE y el proveedor de servicios por medios fuera de banda (por ejemplo usando un canal de datos separado o usando mensajes de señalización de SIP) y donde la información necesita ser transferida en banda sobre una trayectoria de medios de voz u otros (por ejemplo trayectoria de video) entre el UE y el proveedor de servicios cuando el proveedor de servicios no es compatible con IP o solo se puede acceder desde el UE por medios CS.
Estos y otros aspectos de la divulgación se divulgan en la siguiente descripción y dibujos relacionados dirigidos a aspectos específicos de la divulgación. Pueden concebirse aspectos alternativos sin apartarse del alcance de la divulgación. Adicionalmente, los elementos bien conocidos de la divulgación no se describirán en detalle o se omitirán de tal manera que no oculten los detalles relevantes de la divulgación.
Debe anotarse que los términos 'eCall" y "eCall de NG" como se usan en este documento pueden ser sinónimos en ciertos contextos tal como cuando una eCall de NG se enruta a un PSAP heredado sobre el dominio CS. La eCall resultante (o eCall de NG) puede entonces tener características tanto de una eCall como de una eCall de NG. Por ejemplo, el componente de UE del IVS que origina la eCall de NG puede continuar usando señalización basada en SIP e IP para establecer y liberar más adelante la eCall (o eCall de NG) pero puede transferir cualquier dato telemático (por ejemplo MSD) por medios en banda, lo mismo que para una eCall normal (no NG). Además, una entidad intermedia (por ejemplo una MGCF) puede convertir la señalización basada en SIP e IP usada por el UE en señalización basada en CS (por ejemplo ISUP de SS7) usada por una red basada en CS a la que se acceder por el PSAP heredado. De este modo, en la descripción en este documento, los términos "eCall" y "eCall de NG" se usan de manera intercambiable para escenarios donde un componente de UE de un IVS origina una eCall de NG que se enruta a un PSAP heredado - tal como se describe más adelante en este documento para la figura 2 para un eCall desde UE 105 a un PSAP 150 heredado.
La figura 1 es un diagrama de bloques simplificado que ilustra la arquitectura de un sistema 100 para habilitar eCall de NG para LTE, de acuerdo con una realización. Entre otros componentes, el sistema incluye un Ue 105, que puede incorporarse en y/o conectarse de otro modo con un Sistema En Vehículo (IVS) 107, una red de LTE (también denominada como un Sistema de Paquetes Evolucionado (EPS)) 102, una Red 145 de Servicios de Emergencia (ES) Heredada con un PSAP 150 Heredado, y una red de IP de servicios de emergencia i3 de Asociación Nacional de Números de Emergencia (NENA) (ESInet) 155 con un PSAP 160 compatible con NENA i3. La red 102 de LTE puede incluir un Nodo Evolucionado B (eNodoB, o eNB) 110, una Pasarela 115 de Servicio, una Pasarela de Red de Datos por Paquetes (PDN) 120, una Entidad de Gestión de Movilidad (MME) 170, una Función de Control de Sesión de Llamada de Proxy (P-CSCF) 125, una Función de Control de Sesión de Llamada de Emergencia (E-CSCF) 130, una Función de Control de Pasarela de Medios (MGCF) 135, y una Pasarela de Medios (MGW) 140. En algunas realizaciones, la MGCF 135 puede incorporarse en o unirse de otro modo con la MGW 140. En otras realizaciones, tal como la realización mostrada en la figura 1, pueden implementarse y/o mantenerse por separado. Como se muestra, el sistema 100 puede comprender otros componentes (algunos de los cuales se muestran en la figura 1 pero que no se discuten en esta divulgación), y otras realizaciones pueden agregar, omitir, unir, separar, redisponer, o alterar de otro modo componentes dependiendo de la funcionalidad deseada. Una persona de experiencia normal en la técnica reconocerá tales variaciones.
El IVS 107 puede ser parte de un vehículo (por ejemplo un coche o camión) y puede soportar servicios telemáticos para eCall de NG como se describió previamente. El IVS 107 puede incluir un UE 105 como un componente incorporado o puede estar conectado a (por ejemplo acoplado a) el UE 105 (por ejemplo a través de Bluetooth®). El UE 105 puede soportar las funciones de señalización y transferencia de voz para eCall de NG y puede ser similar o igual a otros terminales inalámbricos (por ejemplo un teléfono celular o teléfono inteligente) en términos de capacidad de comunicaciones inalámbricas. El IVS 107 puede incluir otros componentes (no se muestran en la figura 1) tales como sensores que pueden detectar diferentes tipos de situaciones de emergencia para el vehículo asociado, para los cuales puede ser necesaria una eCall de NG, tal como aceleración o desaceleración violenta, despliegue de bolsas de aire o un fuego. El eNB 110 puede ser un eNB de servicio para el UE 105 y puede proporcionar acceso de comunicaciones inalámbricas a la red 102 de LTE en nombre del UE 105. La MME 170 puede ser una MME de servicio para el UE 105 y puede soportar la movilidad de UE 105 y la provisión de trayectorias de acceso de señalización y portador de voz. La pasarela 115 de servicio y pasarela 120 de PDN pueden proporcionar señalización basada en IP y soporte de transporte de IP para el UE 105 - por ejemplo con la pasarela 120 de PDN asignando una dirección de IP para UE 105 y proporcionando acceso de IP a otras entidades en la red 102 de LTE tales como MGW 140 y P-CSCF 125.
La red 102 de LTE puede incluir un Subsistema Multimedia de IP (IMS) 180 que puede incluir la P-CSCF 125, E-CSCF 130, MGCF 135 y LRF 190. IMS 180 puede soportar una eCall de NG desde Ue 105 a un PSAP tal como i3 PSAP 160 o PSAP 150 heredado. Por ejemplo, en el caso de una eCall de NG desde UE 105 a i3 PSAP 160, una trayectoria de señalización desde UE 105 (no se muestra en figura 1) puede pasar a través del eNB 110, pasarela 115 de servicio, pasarela 120 de PDN, P-CSCF 125, E-CSCF 130, una IbCf , la i3 ESInet 155 e i3 PSAP 160. En el caso de una eCall de NG desde UE 105 a PSAP 150 heredado, una trayectoria de señalización desde UE 105 (se muestra en figura 1 mediante la línea discontinua en negrita) puede pasar a través del eNB 110, pasarela 115 de servicio, pasarela 120 de PDN, P-CSCF 125, E-CSCF 130, una BGCF, MGCF 135, la Red 145 de ES heredada y PSAP 150 heredado. Los elementos en IMS 180 puede proporcionar manejo de llamadas y soporte de enrutamiento de llamadas para habilitar una eCall de NG desde UE 105 ya sea a i3 PSAP 160 o PSAP 150 heredado. Por ejemplo, P-CSCF 125 puede detectar una eCall de NG cuando es instigada por UE 105 (por ejemplo al recibir, decodificar e interpretar un mensaje de SIP INVITE enviado por UE 105). E-CSCF 130 puede soportar el enrutamiento de una eCall de NG desde UE 105 (por ejemplo enviando un SIP INVITE desde UE 105 recibido a través de P-CSCF 125 ya sea hacia PSAP 150 heredado a través de MGCF 135 o i3 PSAP 160 a través de una IBCF). La LRF 190 puede ayudar al enrutamiento de una eCall de NG desde UE 105 cuando es consultada por E-CSCF 130. Por ejemplo, LRF 190 puede determinar una ubicación para UE 105 (por ejemplo a partir de información proporcionada por UE 105 en un SIP INVITE) y puede determinar un PSAP (por ejemplo PSAP 150 heredado o i3 PSAP 160) que soporta una eCall de NG para esa ubicación y puede retornar una identidad o dirección para este PSAP a E-CSCF 130. MGCF 135 puede realizar la conversión de señalización basada en SIP, recibida desde o enviada a UE 105, hacia o desde la señalización usada por la red 145 de ES tal como la señalización de ISUP en el caso de una eCall de NG a un PSAP 150 heredado. Por ejemplo, MGCF 135 puede convertir parcialmente una eCall de NG recibida desde UE 105 en una eCall Conmutada por Circuitos (CS) en el caso de una eCall de NG enrutada a PSAP 150 heredado.
13 ESlnet 155 puede soportar llamadas de emergencia basadas en IP incluyendo una eCall de NG desde UE 105 en nombre de i3 PSAP 160 - por ejemplo puede enrutar una eCall de NG desde UE 105 a i3 PSAP 160. La red 145 de ES heredada puede soportar de manera similar llamadas de emergencia basadas en conmutadas por circuitos (CS) en nombre de PSAP 150 heredado incluyendo una eCall CS (también denominada como simplemente una eCall) recibida a través de MGCF 135 desde UE 105 - por ejemplo puede enrutar una eCall CS desde UE 105 recibida a través de MGCF 135 a PSAP 150 heredado. MGW 140 puede convertir entre VoIP recibida desde o enviada a UE 105 y voz basada en CS enviada a o recibida desde PSAP 150 heredado en el caso de una eCall de NG desde UE 105 a PSAP 150 heredado.
En el caso de una eCall de NG desde UE 105 a PSAP 150 heredado, la trayectoria de señalización desde el UE 105 al PSAP 150 heredado, marcada con una línea discontinua en negrita, conecta comunicativamente el UE 105 con el PSAP 150 heredado y se usa para transferir mensajes de señalización (por ejemplo mensajes de SIP, mensajes de ISUP) y/u otras señales (por ejemplo tonos de MF). Como se describió previamente, esta trayectoria incluye la siguiente cadena de elementos: UE 105, eNB 110, Pasarela 115 de Servicio, Pasarela 120 de Pd N, P-CSCF 125, E-CSCF 130, MGCF 135, Red 145 de ES Heredada, y PSAP 150 Heredado. La trayectoria de voz (también denominada como una trayectoria de medios de voz, trayectoria de medios, trayectoria de datos, canal de voz, canal de audio, trayectoria de audio) para una eCall de NG desde el UE 105 al PSAP 150 heredado, marcada con una línea sólida en negrita, conecta comunicativamente el UE con el PSAP 150 heredado. Esta trayectoria incluye la siguiente cadena de componentes: UE 105, eNB 110, Pasarela 115 de Servicio, Pasarela 120 de PDN, MGW 140, Red 145 de ES heredada, y PSAP 150 heredado. La comunicación de señalización (por ejemplo mensajes de SIP) desde el UE 105 a la MGCF 135 es típicamente conmutada por paquetes (PS) (por ejemplo, SIP transportado usando TCP o UDP sobre IP), mientras que la comunicación de señalización desde la MGCF 135 al PSAP 150 heredado puede basarse en SS7 (por ejemplo ISUP) y/o puede usar señalización de MF en banda, aunque las realizaciones pueden variar. La comunicación de voz desde el UE 105 a la MGW 140 es típicamente conmutada por paquetes (PS) (por ejemplo, VoLTE, VoIP), mientras que la comunicación de voz desde la MGW 140 al PSAP 150 heredado es conmutada por circuitos (CS) (por ejemplo ley A de PCM, ley p de PCM), aunque las realizaciones pueden variar.
De acuerdo con la terminología normal para la comunicación inalámbrica, audio, voz, datos, señalización y/u otra comunicación que se envía desde UE 105 a o hacia PSAP 150 heredado o i3 PSAP 160 o a o hacia cualquier elemento en la red 102 de LTE se denomina como "enlace ascendente" transferido, enviado o recibido o en una "dirección de enlace ascendente". De manera similar, audio, voz, datos, señalización y/u otra comunicación que se envía desde el PSAP 150 heredado, i3 PSAP 160 o cualquier elemento en la red 102 de LTE a o hacia el UE 105 se denomina como "enlace descendente" transferido, enviado o recibido o en una "dirección de enlace descendente".
La figura 2 es un flujo de señalización que ilustra cómo diversos componentes del sistema 100 de la figura 1 puede establecer una eCall de NG, dando como resultado una transferencia de MSD en banda, como se discutió previamente. Aquí, se muestran algunos elementos principales pero no todos los elementos de la red 102 de LTE. Algunas acciones atribuidas a o implícitas para ciertos elementos o ciertos grupos de elementos de la red 102 de LTE mostrada en la figura 2 pueden por lo tanto estar soportadas en parte por otros elementos que no se muestran en la figura 2. Por ejemplo, las referencias a acciones realizadas por o que involucran a MME 170 pueden ser asistidas o proporcionadas por el eNB 110, Pasarela 115 de Servicio, Pasarela 120 de PDN, y/u otros componentes de la figura 1, y el IMS 180 puede referirse a la P-CSCF 125 y/o a la E-CSCF 130 de la figura 1, o pueden corresponder a todos los elementos del IMS 180. Como se mencionó previamente, las técnicas divulgadas en este documento no están necesariamente limitadas a la arquitectura ilustrada en la figura 1.
Como se muestra en la figura 2, el establecimiento de una eCall de NG desde UE 105 a PSAP 150 heredado se puede realizar en nueve fases cada una comprendiendo una o más etapas, como sigue.
Fase 1: el IVS 107 (no se muestra en la figura 2) detecta una situación de emergencia ya sea a través de la entrada de usuario manual (por ejemplo, un conductor o pasajero de un vehículo presiona un botón de ayuda de emergencia) o automáticamente usando sensores (por ejemplo, detectando una aceleración/desaceleración abrupta, despliegue de bolsa de aire, fuego, agua, etc.) e informa al UE 105 en la etapa 201.
Fase 2: el UE 105 realiza la selección de dominio en la etapa 202 para seleccionar ya sea el dominio CS o PS y encontrar una red inalámbrica accesible que soporte este dominio. Si se selecciona el dominio CS (no se muestra en la figura 2), se inicia una eCall CS. Si se selecciona el dominio PS, se accede a la red 102 de LTE en este ejemplo y se realizan el resto de las acciones en la figura 2.
Fase 3: UE 105 se une a la red 102 de LTE en la etapa 203 si aún no está unido (por ejemplo si el UE 105 está configurado para el modo solo de eCall y solo se une a una red inalámbrica para iniciar una eCall, llamada de prueba, o llamada a un operador de red doméstica). La unión en la etapa 203 está soportada por MME 170 y por otros elementos que no se muestran en la figura 2 tales como eNB 110 y pasarela 120 de PDN. Durante la unión en la etapa 203, el UE 105 obtiene un portador de emergencia y descubre una P-CSCF 125 adecuada para servicios de emergencia. El UE 105 puede liberar recursos (por ejemplo recursos de portador) para cualquier sesión en curso previa si es necesario para realizar esta fase.
Fase 4: el UE 105 realiza un registro de IMS de emergencia en la etapa 204 con el IMS 180. El registro de IMS de emergencia en la etapa 204 también se puede realizar con el IMS en una red doméstica para el UE 105 (no se muestra en la figura 2) si el UE 105 está iterando (por ejemplo si la red 102 de LTE no es la red doméstica para el UE 105).
Fase 5: el UE 105 envía un mensaje de SIP INVITE al IMS 180 (por ejemplo a la P-CSCF 125) en la etapa 205. El INVITE enviado en la etapa 205 puede contener una indicación de eCall, que puede indicar una llamada de emergencia y si la eCall fue invocada manual o automáticamente, y datos telemáticos que en este ejemplo comprenden MSD. En una realización alternativa, el MSD puede no estar incluido en el SIP INVITE enviado en la etapa 205 y el UE 105 puede en su lugar intentar enviar los datos telemáticos (por ejemplo después de que se establece la eCall de NG) usando técnicas alternativas, tales como usando canal de datos separados que puede establecerse en paralelo con o después del establecimiento de la trayectoria de voz durante la fase 8.
Fase 6: En la etapa 206, el IMS 180 (por ejemplo la E-CSCF 130) puede consultar la LRF 190 para obtener la información de enrutamiento y/o ubicación de llamadas para el UE 105 y la LRF 190 puede obtener la ubicación del UE (por ejemplo a través de una interacción que involucra a la MME 170 y/o UE 105) con el fin de proporcionar información de enrutamiento y/o ubicación de llamadas.
Fase 7: El IMS 180 (por ejemplo la E-CSCF 130) usa cualquier información de enrutamiento obtenida en la fase 6 (por ejemplo proporcionada por LRF 190) o selecciona un centro de emergencia o PSAP con base en la información proporcionada en la fase 5 y envía la solicitud de eCall de NG (por ejemplo mensaje de SIP INVITE) que incluye la indicación de eCall, MSD y cualquier información de ubicación obtenida en la fase 5 o fase 6 a o hacia el centro de emergencia o PSAP. Si se accede al centro de emergencia o al PSAP sobre el dominio CS (es decir, el PSAP es un PSAP 150 heredado), se realizan las acciones 7a y 7b. Para la acción 7a: el SIP INVITE se envía a la MGCF 135 en la etapa 207a. Para la acción 7b: la MGCF 135 envía un Mensaje de Dirección Inicial (IAM) de ISUP hacia el PSAP 150 heredado (por ejemplo envía el IAM a la red 145 de ES heredada) en la etapa 207b. El IAM puede portar una indicación de emergencia (por ejemplo en un parámetro de Categoría de la Parte llamante) y una indicación de eCall. En algunas implementaciones, la indicación de una eCall o una indicación de enrutamiento de llamada a un PSAP que soporta eCall se puede portar como parte de un parámetro de Número de Parte Llamada (por ejemplo al incluir ciertos dígitos en el parámetro de Número de Parte Llamada) y no se puede portar como una indicación separada en el IAM. El MSD puede ser descartado por la MGCF 135 como parte de la etapa 207b. Si se accede al centro de emergencia o al PSAP sobre el dominio PS (es decir, el PSAP es i3 PSAP 160), se realizan las acciones 7c, 7d y 7e. Para la acción 7c: el IMS 180 (por ejemplo la E-CSCF 130) envía el SIP INVITE a o hacia el i3 PSAP 160 en la etapa 207c (por ejemplo a través de una IBCF y la i3 ESInet 155) que porta la indicación de eCall y el MSD. Para la acción 7d, el i3 PSAP 160 retorna un mensaje de SIP STATUS en la etapa 207d (por ejemplo un mensaje de SIP 200 OK) al IMS 180 (por ejemplo a la E-CSCF 130 a través de una IBCF y la i3 ESInet 155). El mensaje de SIP STATUS porta una confirmación de recepción de MSD y posiblemente un acuerdo para establecer la eCall de NG. Para la acción 7e: el IMS 180 (por ejemplo la E-CSCF 130 y P-CSCF 125) envía el mensaje de STATUS al UE 105 en la etapa 207e, confirmando la recepción del MSD. Cuando la eCall se envía al PSAP 150 heredado sobre el dominio CS como en las etapas 701a y 702b, un mensaje de STATUS similar, tal como un mensaje de Respuesta (ANM) de ISUP, puede ser enviado por el PSAP 150 heredado después de realizar las acciones 7a y 7b como parte de la fase 8. Sin embargo, este mensaje de STATUS (por ejemplo mensaje de ANM) no indicaría la confirmación de la transferencia del MSD debido a que el MSD no se envía al PSAP 150 heredado mediante las acciones 7a y 7b.
Fase 8: el establecimiento de llamada de emergencia se completa en la etapa 208. Esto incluye el establecimiento de una trayectoria de voz (también denominada como un canal de voz o canal de audio) entre el UE 105 y el PSAP (ya sea PSAP 150 heredado o i3 PSAP 160). En el caso de una eCall de NG a i3 PSAP 160, la trayectoria de voz puede emplear VoIP y no necesitar ninguna conversión entre diferentes codificaciones de voz. En el caso de una eCall de NG a PSAP 150 heredado, la trayectoria de voz puede pasar a través de la MGW 140 asociada con la MGCF 135 y también puede pasar a través de otras entidades como se describe en la figura 1 y puede someterse a una o más transformaciones tales como conversión entre codificación de VoIP y codificación de voz CS en MGW 140.
Fase 9: si el UE 105 no recibe el mensaje de STATUS para la etapa 207e (por ejemplo la eCall de NG se envía al PSAP 150 heredado a través del dominio CS en las etapas 207a y 207b) o si el mensaje de STATUS recibido en la etapa 207e no contiene una confirmación de recepción exitosa de MSD por el PSAP (por ejemplo por PSAP 150 heredado), entonces en la etapa 209, el UE 105 intenta transferir el MSD al centro de emergencia o PSAP a través de medios en banda sobre la trayectoria de voz establecida en la fase 8, como se mencionó previamente. Por ejemplo, en el caso de una eCall al PSAP 150 heredado, el UE 105 puede enviar el MSD sobre la trayectoria de voz al PSAP 150 heredado sin esperar una solicitud desde el PSAP 150 heredado o puede esperar una solicitud en banda desde el PSAP 150 heredado (enviado sobre la trayectoria de voz al UE 105) antes de enviar el MSD al PSAP 150 heredado sobre la trayectoria de voz.
La figura 3 es un flujo de señalización que ilustra la transferencia de un MSD actualizado desde el UE 105 al PSAP 150 heredado o i3 PSAP 160 - por ejemplo después del establecimiento de una eCall de NG de acuerdo con el ejemplo en la figura 2. Las acciones ilustradas en la figura 3 puede representar un método de ejemplo de transferencia de MSD en banda a PSAP 150 heredado al que se accede a través del dominio CS (por ejemplo, implementando fase 9 en la figura 2 y donde se realizan las acciones 7a y 7b en la figura 2). En algunas realizaciones alternativas, las acciones en la figura 3 pueden representar alternativa o adicionalmente una forma en la cual se envía MSD actualizado a i3 PSAP 160 al que se accede a través del dominio de PS - por ejemplo en el caso de que el MSD tenga que ser enviado en banda al i3 PSAP 160 debido a una falla de, o falta de soporte para, la transferencia fuera de banda del MSD. Aquí, en la acción 1 y en la etapa 301, el PSAP 150 heredado puede enviar una solicitud de MSD al UE 105 usando medios en banda sobre una trayectoria de voz entre el UE 105 y el PSAP 150 heredado. El UE 105 responde, en la acción 2 y en la etapa 302, enviando el MSD al PSAP 150 heredado usando medios en banda sobre la trayectoria de voz. Tanto para la acción 1 como para la acción 2, la trayectoria de voz puede pasar a través de MGW 140 como se describió previamente, en cuyo caso tanto la solicitud de MSD enviada en la etapa 301 como el MSD enviado en la etapa 302 se transfieren en banda a través de la MGW 140.
Cuando el MSD se transfiere desde un UE a un PSAP por medios en banda sobre una trayectoria de voz entre el UE y el PSAP (por ejemplo como en la etapa 209 en la figura 2 y como en la etapa 302 en la figura 3), el MSD se convierte en señales de audio (también denominadas como tonos de audio) usando un módem de datos en el UE. Como ejemplo, un UE podría usar un módem de datos (también denominado como un módem en banda, un módem de datos en banda, un módem de datos de eCall o un módem en banda de eCall) según se define por 3GPP en la Especificación Técnica (TS) de 3GPP 26.267. Las señales de audio emitidas por el módem de datos codifican la secuencia de bits que componen el MSD y habilitan el envío del MSD por medios analógicos sobre la trayectoria de voz en lugar de por medios digitales como una secuencia de bits enviados sobre una trayectoria de señalización. En este caso, las señales de audio se transfieren al PSAP sobre la trayectoria de voz y se convierten de vuelta en el MSD en el PSAP usando el mismo tipo de módem de datos que en el UE pero usado para la transformación inversa. Mientras el MSD está siendo transferido, el habla desde un usuario del Ue (por ejemplo un conductor o pasajero de un vehículo) no puede ser enviado por el UE al PSAP. En algunos casos, el habla desde un operador de PSAP tampoco se puede enviar al usuario del Ue . Esta interrupción de la trayectoria de voz puede ser desconcertante o incluso perturbar al usuario y/o al operador de PSAP y puede hacer que cualquiera de las partes desconecte (o intente desconectar) la llamada si persiste (por ejemplo si dura más de 10 a 15 segundos). Por esta razón, la transferencia de MSD que se produce en banda necesita producirse rápidamente. Por ejemplo, 3GPP ha ordenado que la transferencia de MSD para una eCall se produzca en 4 segundos cuando la transferencia es a través de medios en banda. Sin embargo, como se mencionó previamente, el uso de almacenamiento en búfer de eliminación de variación rápida (DJB) adaptativo en comunicaciones de voz que emplean empaquetado y desempaquetado de voz, tales como para LTE, puede hacer que esta comunicación en banda (por ejemplo fase 9 de la figura 2 y acción 2 de figura 3) sea menos fiable y sujeta a un retraso más largo que en otras tecnologías donde la transferencia en banda es sobre una trayectoria Cs . En el caso de LTE, esto se debe a que LTE emplea transferencia de VoIP de comunicación de voz en lugar de transferencia CS con el fin de mejorar la eficiencia de ancho de banda lo cual requiere el uso de un DJB adaptativo para suministrar marcos de habla a un decodificador de habla a una tasa constante en lugar de variable. Sin embargo, típicamente hay un límite en la cantidad de datos de voz que se almacenan en búfer por un DJB adaptativo debido a que almacenar en búfer demasiados datos de voz llevaría a un retraso notable en la transferencia de voz y por lo tanto un retraso en que un usuario pueda responder al otro. Por esta razón, a un DJB adaptativo se le asigna típicamente un tamaño de búfer limitado (por ejemplo que corresponde a 20-40 milisegundos (ms) de voz empaquetada) para eliminar la variación rápida en las comunicaciones sobre un canal de voz empaquetado. El sobreflujo de búfer (cuando la voz empaquetada entrante está llegando demasiado rápido arriesgando de esa manera pérdida de paquetes) y el subflujo de búfer (cuando la voz empaquetada entrante está llegando demasiado lento arriesgando de esa manera no tener marcos de habla disponibles para enviar a un decodificador de habla) se compensan introduciendo distorsión por deformación del tiempo en las comunicaciones de canal de voz. Con la deformación del tiempo, la voz empaquetada se puede comprimir cuando el sobreflujo de búfer es inminente y se puede expandir cuando el subflujo de búfer es inminente. Aunque la distorsión introducida por la deformación del tiempo en el caso de habla típicamente no es notable para los usuarios humanos, puede interferir con (por ejemplo corromper) las señales de audio de módem de datos que transfieren el MSD sobre el canal de voz (por ejemplo, usando modulación de posición de pulso), reduciendo de esa manera la fiabilidad de la transferencia de MSD sobre LTE. Las referencias al uso de DJB adaptativo en este documento (por ejemplo según lo realizado por MGW 140) pueden incluir el uso de deformación del tiempo incluso cuando no se mencionan específicamente.
Se proporcionan en este documento técnicas para aumentar la fiabilidad de señales de módem de datos sobre un canal de voz de LTE, para eCall de NG y/u otras aplicaciones. Puede anotarse que la funcionalidad del UE 105 se describe en las realizaciones que siguen. Sin embargo, se entenderá que, debido a que el UE 105 puede incorporarse en y/o componer parte del IVS 107, el UE 105 e IVS 107 son virtualmente intercambiables en las descripciones a continuación.
De acuerdo con algunas realizaciones, una llamada desde un UE 105 puede ser recibida por una MGCF 135, que identifica la llamada como una eCall de NG. La MGCF 135 puede luego retransmitir esta información a la MGW 140, instruyendo a la MGW 140 para que inhabilite el DJB adaptativo y en su lugar emplee un DJB estático más profundo, haciendo de esa manera que el MSD transferido en banda sea menos probable que se corrompa por la caída de paquetes y/o la necesidad de distorsión por deformación del tiempo. Para asegurar además la integridad de las señales de voz desde el módem de datos, la MGCF 135 también puede negociar con el UE 105 (por ejemplo como parte de la fase 5, fase 7 y fase 8 en la figura 2) un códec de tasa de bits más alta y/o un tipo de códec que se conoce que soporta la transferencia de MSD mejor que otros y puede reducir los impactos de la compresión de señal.
La negociación del tipo de códec y la tasa de bits puede producirse entre el UE 105 y MGCF 135 usando el Protocolo de Descripción de Sesión (SDP) que puede ser portado en mensajes de SIP (u otros mensajes) como parte del establecimiento de una eCall de n G - por ejemplo tal como el SIP INVITE para la fase 5 y para la acción 7a y el SIP STATUS para la acción 7e en la figura 2. De acuerdo con algunas realizaciones, se notifica a la MGCF 135 de los tipos de códec y tasas de bits que el UE 105 soporta en un cuerpo de SDP portado en el SIP INVITE inicial enviado por el UE 105 para establecer una eCall de n G (por ejemplo como en la acción 7a en la figura 2) y luego puede seleccionar un tipo de códec y una tasa de bits soportados por el UE 105 que minimizarán la degradación y corrupción de la transferencia de MSD en banda. La MGCF 135 puede estar en una posición única para hacer esto debido a que (a) la MGCF 135 puede ser consciente de que una eCall de NG está siendo establecida a través de una indicación de eCall en el SIP INVITE inicial (por ejemplo el SIP INVITE para la acción 7a en la figura 2) y (b) la MGCF 135 puede ser consciente de que la eCall llegará al PSAP 150 heredado a través de los medios de circuito debido a que es el punto de interfuncionamiento de señalización entre el dominio de IMS/PS (en el lado de red) y el dominio CS (en el lado de PSAP 150 heredado). Además, debido a que el UE 105 conoce que una eCall de NG está siendo establecida, el UE 105 puede incluir adicional o alternativamente solo tipos de códec y tasas de bits en el SIP INVITE inicial (por ejemplo enviados en la fase 5 en la figura 2) que son favorables para reducir la degradación y corrupción de transferencia en banda. La MGCF 135 puede transmitir el códec elegido, tasa de bits y opcionalmente una indicación de eCall a la MGW 140. Cuando el UE 105 envía más adelante el MSD en banda hacia el PSAP 150, la MGW 140 puede transferir la información de MSD al PSAP 150 heredado, por ejemplo, desempaquetando, decodificando, y recodificando la comunicación de VoIP recibida desde el UE a la ley A de PCM. El proceso de desempaquetado, decodificación y recodificación por la MGW 140, también denominado como transcodificación, se puede realizar para reducir o minimizar la corrupción en el MSD (todavía codificado como señales de audio cuando se pasa a través de la MGW 140) como ya se mencionó. El MSD convertido (por ejemplo en la forma de señales de audio codificadas usando la ley A de PCM) puede transferirse a través de uno o más conmutadores intermedios al PSAP 150 heredado donde el MSD puede decodificarse usando un módem de datos.
La transferencia en banda del MSD puede producirse como sigue a un nivel más detallado. El UE 105 puede primero convertir el MSD en señales de audio (analógicas) usando un módem de datos de eCall (acción U1), luego codificar las señales de audio resultantes en un flujo (de bits) digital usando un códec negociado entre el UE 105 y MGCF 135 (acción U2), luego empaquetar el flujo digital resultante en paquetes de VoIP (por ejemplo usando el Protocolo de Tiempo Real (RTP)) (acción U3) y finalmente enviar los paquetes de VoIP hacia la MGW 140 (acción U4) usando la trayectoria de voz basada en IP establecida para la eCall (por ejemplo como en la fase 8 en la figura 2). La MGW 140 puede realizar algunas operaciones inversas que comprenden desempaquetar los paquetes de VoIP recibidos en un flujo digital (acción M1), decodificar el flujo digital usando el códec negociado en información que representa señales de audio (acción M2) y recodificar la información que representa señales de audio en un flujo de bits digital conmutado por circuitos usando un códec diferente - por ejemplo para la ley A de PCM (acción M3). El flujo digital transformado (transcodificado) puede enviarse entonces al PSAP 150 (acción M4). En el PSAP 150, el flujo de bits digital conmutado por circuitos se puede convertir de vuelta en señales de audio (acción PI) desde las cuales se puede extraer el MSD usando el módem de datos de eCall (acción P2). La MGW 140 puede usar el conocimiento de una eCall soportada por MGCF 135 para modificar la acción M1 y/o acción M2 para reducir la degradación y corrupción del MSD codificado y facilitar una recuperación de MSD más fiable por PSAP 150 en la acción P2. Las acciones M1, M2 y M3 pueden denominarse como transcodificación.
De acuerdo con algunas realizaciones, una vez que se completa la transferencia de MSD, el DJB adaptativo puede de nuevo ser utilizado por la MGW 140, para ayudar a facilitar cualquier conversación de voz que sigue realizada sobre el canal de voz de LTE durante la eCall. En algunas realizaciones, el UE 105 puede recibir un mensaje de Acuse de recibo de Alto Nivel (HL-ACK) desde el PSAP 150 heredado, indicando que la transmisión de MSD está completa y puede iniciar una conversación de voz. Esto puede hacer que el sistema vuelva a usar el DJB adaptativo. Tal funcionalidad se puede implementar de diversas formas.
En algunas realizaciones, la MGW 140 puede monitorizar e interpretar el canal de voz entre el UE 105 y PSAP 150 con el fin de detectar y reconocer mensajes en banda enviados desde el PSAP 150 heredado al UE 105. En tales realizaciones, la MGW 140 puede configurarse para entender (por ejemplo, decodificar total o parcialmente) los mensajes y protocolo de módem de datos. Cuando la MGW 140 detecta un mensaje en banda desde el PSAP 150, puede habilitar o inhabilitar el DJB adaptativo en la porción de enlace ascendente del canal de voz (dirección de UE 105 a PSAP 150) según sea apropiado para el mensaje en banda detectado. Por ejemplo, si la MGW 140 detecta una solicitud de MSD (por ejemplo como se envía en la acción 1 en la figura 3), puede inhabilitar el DJB adaptativo en el enlace ascendente en la expectativa de que se envíe MSD en el enlace ascendente (por ejemplo como en la acción 2 en la figura 3). De manera similar, cuando la MGW 140 detecta un HL-ACK, puede habilitar el DJB adaptativo en el enlace ascendente con base en suponer que el MSD fue enviado con éxito en el enlace ascendente (por ejemplo como en la fase 9 en la figura 2) y que el enlace ascendente ahora se usará para enviar habla normal.
En algunas otras realizaciones, la MGW 140 puede monitorizar la comunicación de mensajes en banda desde el PSAP 150 heredado y/o desde el UE 105 sin interpretación. En tales realizaciones, la MGW 140 puede no necesitar entender los mensajes en banda (por ejemplo, puede que no necesite estar familiarizado con el protocolo usado), sino que en su lugar puede simplemente detectar su presencia (por ejemplo, a través de análisis de señales determinar si una o más características de señalización en banda está/están presentes). Siempre que la MGW 140 no detecte mensajes en banda durante algún tiempo, puede rehabilitar el DJB adaptativo en la dirección de UE 105 de enlace ascendente a PSAP 150. En algunas realizaciones, la MGW 140 puede inhabilitar más adelante el DJB adaptativo para permitir que la MGW 140 continúe transfiriendo el MSD (por ejemplo en caso de que la MGW 140 rehabilite por error el DJB adaptativo demasiado pronto y detecte más adelante que la señalización en banda todavía está en uso). Por ejemplo, tan pronto como la MGW 140 detecta mensajes en banda puede inhabilitar el DJB adaptativo. En algunas realizaciones, después de que MGW 140 deja de detectar mensajes en banda, MGW 140 puede retrasar la rehabilitación de DJB adaptativo durante un período de tiempo de espera de unos pocos segundos (por ejemplo 5 segundos) con el fin de asegurar que la señalización en banda se haya detenido. Si la señalización en banda se detecta de nuevo antes de la expiración del período de tiempo de espera, la MGW 140 puede no rehabilitar el DJB adaptativo.
En algunas realizaciones, cuando el UE 105 recibe un mensaje de HL-ACK desde PSAP 150 que confirma la transferencia exitosa del MSD desde UE 105 a PSAP 150, el UE 105 puede enviar un mensaje de SIP (por ejemplo un mensaje de SIP INFO) a la MGCF 135, diciéndole a la MGCF 135 que le señalice a la MGW 140 que puede rehabilitar el DJB adaptativo.
En algunas realizaciones, cuando el UE 105 recibe una solicitud de MSD desde PSAP 150 (por ejemplo como en la acción 1 en la figura 3), el UE 105 puede enviar un mensaje de SIP (por ejemplo un mensaje de SIP INFO) a la MGCF 135, diciéndole a la MGCF 135 que le señalice a la MGW 140 que debe inhabilitar el DJB adaptativo. El u E 105 puede entonces enviar MSD en banda a PSAP 150 - por ejemplo posiblemente después de un corto retraso de 1 o 2 segundos para habilitar que MGW 140 inhabilite primero el DJB adaptativo.
Algunas realizaciones pueden emplear además una MGW 140 que detecta un mensaje de START de enlace ascendente desde el PSAP 150 heredado que puede enviarse en banda al UE 105 para solicitar la transferencia de MSD actualizado (por ejemplo como en la acción 1 en la figura 3). Después de detectar un mensaje de START, MGW 140 puede inhabilitar el DJB adaptativo en su enlace ascendente (para la dirección de transferencia de UE 105 a PSAP 150). En tal realización, cuando la MGW 140 detecta un mensaje de START desde el PSAP 150, la MGW 140 puede decirle a la MGCF 135 que señalice esto al UE 105 a través de señalización de SIP (por ejemplo enviando un mensaje de SIP INFO). Cuando el UE 105 recibe esta señal, puede inhabilitar el DJB adaptativo en su enlace descendente (para la dirección de transferencia de PSAP 150 a UE 105). Tal funcionalidad puede habilitar que el PSAP 150 heredado solicite al UE 105 que reenvíe el MSD (por ejemplo, cuando esté disponible una mejor fijación de posición para UE 105). El UE 105 también puede detectar el mensaje de START desde PSAP 150 e inhabilitar el DJB adaptativo en su enlace descendente.
La figura 4 es un diagrama de bloques simplificado que ilustra un proceso 400 de almacenamiento en búfer y decodificación que se puede realizar por el UE 105 para ayudar al UE 105 a detectar y decodificar de manera fiable un mensaje en banda de enlace ascendente (por ejemplo un mensaje de START) que fue enviado al UE 105 por PSAP 150 usando un módem de datos. El proceso 400 de almacenamiento en búfer y decodificación puede implementarse en hardware y/o software en el UE 105, y puede incorporarse en uno o más componentes más grandes del UE 105, tales como un módem u otra interfaz de comunicación, un procesador, y similares.
Como se ilustra en la figura 4, el proceso 400 de almacenamiento en búfer y decodificación puede recibir una entrada de VoIP en una dirección de enlace descendente (por ejemplo, comunicación de VoIP desde el PSAP 150 heredado sobre un canal de voz de LTE). La entrada se proporciona entonces a dos DJBs. Un primer DJB puede comprender un DJB 410 adaptativo que está suministrando marcos de audio codificados (por ejemplo marcos de habla) al decodificador 430 de audio. La salida del decodificador 430 de audio puede comprender un flujo de audio (por ejemplo habla) que se proporciona a un conmutador 450. En un modo de operación normal, el conmutador 450 puede pasar de manera transparente a través del flujo de audio desde el decodificador 430 de audio como la salida del proceso 400 de almacenamiento en búfer y decodificación que se puede proporcionar a un usuario de UE 105 (por ejemplo a través de un dispositivo de reproducción tal como un altavoz o auricular, no se muestra en la figura 4). El DJB 410 adaptativo puede almacenar en búfer paquetes de VoIP recibidos (por ejemplo RTP) durante un tiempo limitado (por ejemplo 20-40 ms) antes de emitir marcos de audio codificados con el fin de limitar el retraso de audio de extremo a extremo y evitar que el usuario de UE 105 y operador en PSAP 150 experimenten un retraso notable en las respuestas de voz desde la otra parte. Esto puede introducir deformación del tiempo y recorte de audio (por ejemplo habla) como se describió previamente. Un segundo DJB puede comprender un DJB 420 estático cuya salida está siendo alimentada a un decodificador 440 de audio que puede ser similar a o el mismo que el decodificador 430 de audio. El DJB 420 estático puede almacenar en búfer paquetes de VoIP recibidos (por ejemplo RTP) durante más tiempo que el DJB 410 adaptativo (por ejemplo 100 ms a 200 ms) con el fin de evitar la pérdida de marcos de audio y deformación del tiempo. La salida de flujo de audio desde el decodificador 440 de audio puede pasarse a un módem 460 de datos que puede detectar cualquier contenido de mensaje enviado en banda. La salida del módem 460 de datos puede pasarse a un decodificador 470 de mensajes que puede determinar si un mensaje en banda está presente y el contenido del mensaje en banda. En algunas implementaciones, el módem 460 de datos y decodificador 470 de mensajes pueden combinarse. El módem 460 de datos combinado con el decodificador 470 de mensajes puede denominarse como un detector 480 de mensajes en banda.
En operación normal, la salida de audio del proceso 400 de almacenamiento en búfer y decodificación puede proporcionarse desde la salida del DJB 410 adaptativo y el decodificador 430 de audio, que puede pasar de manera transparente a través del conmutador 450 como se describió previamente. Sin embargo, cuando el detector 480 de mensajes en banda (por ejemplo el decodificador 470 de mensajes) detecta una señal en banda (por ejemplo un mensaje de START), puede señalizar al conmutador 450 que deje de transferir la salida de audio desde el decodificador 430 de audio al usuario. Esto puede evitar que el usuario escuche los tonos de módem de datos usados para transferir cualquier mensaje enviado a través del módem de datos (por ejemplo un mensaje de START) y de esa manera evitar molestar al usuario. Además, el detector 480 de mensajes en banda (por ejemplo el decodificador 470 de mensajes) puede decodificar el mensaje en banda que fue detectado y proporcionar una indicación del mensaje (por ejemplo la identidad de mensaje y cualquier contenido de mensaje) a uno u otros más elementos en el UE 105 tal como un procesador de aplicación o proceso que está soportando la transferencia de eCall de MSD en UE 105. Debido a que los marcos de audio codificados desde el DJB 420 estático en lugar del DJB 410 adaptativo se pasan al decodificador 440 de audio, puede haber menos o ninguna distorsión por deformación del tiempo de la señal de módem de datos, permitiendo que el detector 480 de mensajes en banda detecte y decodifique de manera más fiable cualquier mensaje en banda. Cuando el detector 480 de mensajes en banda (por ejemplo el decodificador 470 de mensajes) ya no detecta una señal en banda, o posiblemente después de algún período de tiempo de espera (por ejemplo 1 o 2 segundos) durante el cual no se detecta ninguna señal en banda por el detector 480 de mensajes en banda, el detector 480 de mensajes en banda puede señalizar al conmutador 450 que reanude el paso a través del flujo de audio desde el decodificador 430 de audio al usuario de UE 105 (por ejemplo a un dispositivo de reproducción que no se muestra en la figura 4).
El DJB 420 estático, decodificador 440 de audio, detector 480 de mensajes en banda y conmutador 450 pueden ser parte de un subsistema 495 (se muestra por el cuadro discontinuo en la figura 4). Cuando no se conoce que la señalización en banda está presente por el UE 105 para una trayectoria de voz establecida por UE 105 sobre la red 102 de LTE a alguna otra parte (por ejemplo cuando UE 105 establece una trayectoria de voz que no es para una eCall), el proceso 400 de almacenamiento en búfer y decodificación para la trayectoria de voz puede hacer uso solo del DJB 410 adaptativo y el decodificador 430 de audio pero no puede hacer uso de (por ejemplo puede excluir) los elementos que comprenden el subsistema 495. Por ejemplo, la entrada de VoIP solo puede pasar a través del DJB 410 adaptativo y decodificador 430 de audio (y no del DJB 420 estático y decodificador 440 de audio) y la salida del decodificador 430 de audio puede enviarse a un dispositivo de reproducción. Sin embargo, cuando el UE 105 determina que la señalización en banda está presente o puede estar presente (por ejemplo como una consecuencia de establecer una trayectoria de voz para una eCall a PSAP 150 como se describe en asociación con la figura 2), el UE 105 puede modificar el proceso 400 de almacenamiento en búfer y decodificación para la trayectoria de voz incluyendo los elementos de subsistema 495 como parte del proceso 400 de almacenamiento en búfer y decodificación como se describió previamente.
La figura 5 es un diagrama de bloques simplificado que ilustra la transcodificación en MGW 140 usando un proceso 500 de transcodificación. El proceso 500 de transcodificación puede habilitar que MGW 140 convierta un flujo de audio de enlace ascendente recibido desde UE 105 en la forma de paquetes de VoIP (por ejemplo RTP) en un flujo de audio digital conmutado por circuitos (por ejemplo codificado de acuerdo con la ley A de p Cm ) adecuado para transferencia posterior a un PSAP 150 heredado. El proceso 500 de transcodificación puede ser similar al proceso 400 de almacenamiento en búfer y decodificación en la figura 4 y puede emplear ciertos elementos funcionalmente similares. El proceso 500 de transcodificación puede implementarse en hardware y/o software en la MGW 140, y puede incorporarse en uno o más componentes más grandes de la MGW 140, tales como una interfaz de comunicación, un procesador, y similares.
Como se ilustra en la figura 5, el proceso 500 de transcodificación puede recibir una entrada de VoIP en una dirección de enlace ascendente (por ejemplo, comunicación de VoIP desde el UE 105 que es recibida por MGW 140 desde una Pasarela 120 de PDN). La entrada se proporciona entonces a dos DJBs. Un primer DJB puede comprender un DJB 510 adaptativo que está suministrando marcos de audio codificados (por ejemplo marcos de habla) al decodificador 530 de audio. El decodificador 530 de audio puede soportar un códec negociado previamente y acordado con un UE 105 (por ejemplo durante una fase de establecimiento de llamada 8 como se describe para la figura 2). La salida del decodificador 530 de audio puede comprender un flujo de audio (por ejemplo habla), o información representativa de un flujo de audio (por ejemplo audio codificado de PCM), que se proporciona a un conmutador 550. En un modo de operación normal, el conmutador 550 puede pasar de manera transparente a través del flujo de audio desde el decodificador 530 de audio a un codificador 590 de audio CS que puede recodificar el flujo de audio (o información representativa de un flujo de audio) en un flujo digital (por ejemplo ley A de PCM) adecuado para transferir a un PSAP 150 heredado por medios CS (por ejemplo sobre una PSTN). El DJB 510 adaptativo puede almacenar en búfer paquetes de VoIP recibidos (por ejemplo RTP) durante un tiempo limitado (por ejemplo 20-40 ms) antes de emitir marcos de audio codificados con el fin de limitar el retraso de audio de extremo a extremo. Esto puede introducir deformación del tiempo y recorte de audio (por ejemplo habla) en el flujo de audio.
Un segundo DJB para el proceso 500 de transcodificación en la figura 5 puede comprender un DJB 520 estático cuya salida está siendo alimentada a un decodificador 540 de audio que puede ser similar a o el mismo que el decodificador 530 de audio. El DJB 520 estático puede almacenar en búfer paquetes de VoIP recibidos (por ejemplo RTP) durante más tiempo que el DJB 510 adaptativo (por ejemplo 100 ms a 200 ms) con el fin de evitar la pérdida de marcos de audio y deformación del tiempo. La salida de flujo de audio desde el decodificador 540 de audio puede pasarse a un detector 580 de mensajes en banda que puede ser funcionalmente similar a o el mismo que el detector 480 de mensajes en banda descrito en asociación con la figura 4. Sin embargo, en algunas implementaciones, debido a que el detector 580 de mensajes en banda puede no necesitar decodificar e interpretar mensajes en banda (a diferencia del detector 480 de mensajes en banda), el detector 580 de mensajes en banda puede ser más simple que el detector 480 de mensajes en banda (por ejemplo puede no incluir un elemento de módem de datos funcionalmente similar a o el mismo que el módem 460 de datos). La salida del decodificador 540 de audio también se puede pasar al conmutador 550. Sin embargo, en el modo de operación normal, el conmutador 550 puede pasar de manera transparente a través de la salida de audio del decodificador 530 de audio al codificador 590 de audio CS, como se describió previamente, y puede bloquear la transferencia de la salida de audio desde el decodificador 540 de audio. Sin embargo, cuando el detector 580 de mensajes en banda detecta una señal en banda (por ejemplo una señal en banda usada como parte de la transferencia de MSD desde UE 105 a PSAP 150), el detector 580 de mensajes en banda puede señalizar al conmutador 550 para que haga transición desde un modo de operación normal a un modo de operación de señal en banda. Mientras está en el modo de operación de señal en banda, el conmutador 550 puede bloquear la transferencia de la salida de audio desde el decodificador 530 de audio y en su lugar puede pasar de manera transparente la salida de audio del decodificador 540 de audio al codificador 590 de audio CS. Esto puede evitar la deformación del tiempo y recorte de audio en la salida de audio transferida al codificador 590 de audio CS dado que la salida de audio transferida en el modo de operación en banda habrá pasado a través del DJB 520 estático. Como consecuencia, la salida de audio digital del codificador 590 digital CS que se transfiere a PSAP 150 puede habilitar que PSAP 150 detecte y decodifique de manera más fiable cualquier contenido de mensaje en banda (por ejemplo MSD) que si el PSAP 590 estuviera recibiendo una salida de audio digital que hubiera pasado previamente a través del DJB 510 adaptativo. Cuando el detector 580 de mensajes en banda ya no detecta una señal en banda, o posiblemente después de algún período de tiempo de espera (por ejemplo 1 o 2 segundos) durante el cual no se detecta ninguna señal en banda mediante el detector 580 de mensajes en banda, el detector 580 de mensajes en banda puede señalizar al conmutador 550 que reanude el modo de operación normal en el cual el flujo de audio desde el decodificador 530 de audio en lugar del decodificador 540 de audio se transfiere de manera transparente al codificador 590 de audio CS. El modo de operación normal puede reducir el retraso de audio de extremo a extremo lo cual puede evitar que el usuario de UE 105 y un operador de PSAP 150 noten cualquier retraso significativo en la recepción de respuestas (por ejemplo respuestas de habla) desde la otra parte.
En algunas implementaciones del proceso 500 de transcodificación, el conmutador 550 puede configurarse para comenzar a usar el modo de operación de señal en banda (en el cual la salida de audio desde el DJB 520 estático y decodificador 540 de audio en lugar de DJB 510 dinámico y decodificador 530 de audio se pasa a través del conmutador 550 al codificador 590 de audio CS) tan pronto como se establece el canal de audio y comienza a usarse el proceso 500 de transcodificación. Esto puede producirse en MGW 140 con base en que MGW 140 sea consciente de que UE 105 típicamente transferirá señales en banda (por ejemplo que contienen MSD) al destino de PSAP 150 cuando o poco después de que se establezca el canal de audio entre UE 105 y PSAP 150 (por ejemplo como en la fase 8 en la figura 2). Como ejemplo, MGW 140 puede ser consciente de la inminente señalización en banda desde UE 105 a PSAP 150 debido a la recepción de una indicación de una eCall o una indicación de transferencia de señal en banda en el canal de audio desde MGCF 135 (por ejemplo que puede producirse durante el establecimiento de llamada y como parte de la fase 8 en el ejemplo de la figura 2).
El DJB 520 estático, decodificador 540 de audio, detector 580 de mensajes en banda y conmutador 550 pueden ser parte de un subsistema 595 (se muestra por el cuadro discontinuo en la figura 5). Cuando no se conoce que la señalización en banda está presente por MGW 140 en un canal de audio para el cual MGW 140 está realizando la transcodificación desde la entrada de VoIP a la salida CS, el proceso 500 de transcodificación para el canal de audio puede hacer uso solo del DJB 510 adaptativo, el decodificador 530 de audio y el codificador 590 de audio CS pero no pueden hacer uso de (por ejemplo pueden excluir) los elementos que comprenden el subsistema 595. Por ejemplo, la entrada de VoIP al proceso de transcodificación solo puede pasar a través del DJB 510 adaptativo y el decodificador 530 de audio (y no el DJB 520 estático y decodificador 540 de audio) y la salida del decodificador 530 de audio siempre puede enviarse al codificador 590 de audio CS. Sin embargo, cuando MGW 140 determina que la señalización en banda está presente o puede estar presente en el canal de audio (por ejemplo como una consecuencia de recibir una indicación desde MGCF 135 de que se ha establecido un canal de voz a través de MGW 140 para una eCall), MGW 140 puede modificar el proceso 500 de transcodificación al incluir los elementos de subsistema 595 como parte del proceso 500 de transcodificación como se describió previamente.
Además o alternativamente, realizaciones (por ejemplo en las cuales solo se usa un único DJB adaptativo y no un DJB estático adicional) pueden hacer que el UE 105 y/o MGW 140, una vez que se conozca una eCall (por ejemplo debido a la recepción de una indicación de eCall desde MGCF 135 en el caso de MGW 140 o debido al establecimiento de una eCall de NG a un PSAP 150 donde no se recibe una confirmación de transferencia de MSD desde PSAP 150 en el caso de UE 105), aumenten su nivel mínimo de almacenamiento en búfer de eliminación de variación rápida adaptativo en una pequeña cantidad (por ejemplo, en 20 y 40 ms). Este aumento puede dar a su detector de señal en banda tiempo adicional (por ejemplo, uno o más marcos de audio adicionales) para procesar y detectar de manera más fiable una señal en banda. Aunque esto introducirá un retraso adicional a cualquier conversación de habla, un pequeño retraso adicional (por ejemplo, 20-40 ms) puede ser tolerable para un usuario de UE 105 y un operador de PSAP 150. Con este almacenamiento en búfer adicional, el detector de señal en banda puede esperar para procesar uno o dos marcos de voz más antes de decidir si realizar un almacenamiento en búfer aún más profundo para la operación en modo estático, o continuar con el almacenamiento en búfer de eliminación de variación rápida adaptativo.
Como se discutió previamente, las técnicas descritas en este documento se pueden utilizar en la iniciación de eCall de NG en un sistema de LTE, pero realizaciones no están limitadas a ello. Las técnicas divulgadas se pueden utilizar de manera más general para aumentar la fiabilidad de datos recibidos a través de la señalización en banda en una amplia variedad de aplicaciones. Como ejemplo, las técnicas pueden emplearse en sistemas que emplean comunicación basada en IP incluyendo comunicación de VoIP entre dos entidades (por ejemplo un usuario cliente y un proveedor de servicios) donde solo se puede acceder a una de las entidades a través de medios conmutados por de circuitos (por ejemplo sobre una Red Telefónica Pública Conmutada (PSTN)) y donde la transferencia de datos entre las dos entidades necesita emplear señalización en banda sobre el canal de voz (o audio) entre las dos entidades.
La figura 6 es un diagrama 600 de flujo que ilustra un método de aumento de la fiabilidad de la transferencia de datos (por ejemplo datos telemáticos tales como MSD) recibidos a través de señalización en banda, de acuerdo con una realización. El método puede ser empleado por un UE 105, una MGCF 135 o una MGW 140. Al igual que con otras figuras proporcionadas en este documento, la figura 6 se proporciona como ejemplo no limitante. Realizaciones alternativas pueden incluir funcionalidad adicional a la mostrada en la figura, y/o la funcionalidad mostrada en uno o más de los bloques en la figura puede omitirse, combinarse, separarse, y/o realizarse simultáneamente. Los medios para realizar la funcionalidad de los bloques pueden incluir uno o más componentes de hardware y/o software, tales como los descritos con respecto al sistema de ordenador de la figura 9 a continuación. Una persona de experiencia normal en la técnica reconocerá muchas variaciones.
En el bloque 610, se obtiene una indicación de señalización en banda, donde la señalización en banda se produce en un canal de audio (por ejemplo canal de voz) de una red de comunicación. Como ejemplo, el canal de audio puede corresponder al canal de audio establecido de acuerdo con el flujo de señalización en la figura 2 entre un UE 105 y un PSAP 150 heredado.
La funcionalidad en el bloque 620 comprende, en respuesta a la obtención de la indicación de señalización en banda, hacer que un proceso de decodificación modifique la decodificación de señales de audio para el canal de audio. En algunas realizaciones, el proceso de decodificación puede corresponder a parte o todo el proceso 400 de almacenamiento en búfer y decodificación para UE 105 como se describe en asociación con la figura 4. En otras realizaciones, el proceso de decodificación puede corresponder a parte o todo el proceso 500 de transcodificación para MGW 140 como se describe en asociación con la figura 5.
En un bloque 630 opcional que puede ser empleado por un UE 105 o MGW 140, las señales de audio decodificadas, cuya decodificación fue modificada en el bloque 620, se proporcionan a uno de un detector de mensajes en banda (por ejemplo el detector 480 de mensajes en banda en la figura 4 en el caso de un UE 105 o el detector 580 de mensajes en banda en la figura 5 en el caso de una MGW 140), un codificador de audio (por ejemplo el codificador 590 de audio CS en la figura 5 en el caso de MGW 140) o un dispositivo de reproducción de audio (por ejemplo un dispositivo de reproducción de audio para un UE 105) con base en la indicación de señalización en banda obtenida en el bloque 610.
Cuando el método de diagrama 600 de flujo es realizado por un UE 105, la indicación de señalización en banda en el canal de audio puede obtenerse en el bloque 610 por el Ue 105 con base en el establecimiento de una eCall o eCall de NG con un PSAP 150 heredado durante el cual la transferencia de datos telemáticos (por ejemplo MSD) por medios fuera de banda desde UE al PSAP se determina por UE 105 que no se produce. Por ejemplo, en el flujo de señalización descrito en la figura 2, cuando el UE 105 no recibe un mensaje de STATUS para la acción 7e en la etapa 207e confirmando la recepción de la transferencia de MSD, el UE 105 puede determinar que la transferencia de m Sd no se produce por medios fuera de banda. En ciertas otras realizaciones, una indicación de señalización en banda puede ser obtenida por un UE 105 en el bloque 610 desde una MGCF 135 - por ejemplo si el PSAP 150 heredado envía una señal usando señalización conmutada por circuitos (por ejemplo ISUp de s S7) a MGCF 135 cuando el PSAP 150 heredado inicia a enviar señalización en banda hacia UE 105 y si MGCF 135 luego reenvía la señal a UE 105 usando señalización basada en SIP. En respuesta a la obtención de la indicación de señalización en banda en el bloque 610, el UE 105 puede hacer que un proceso de decodificación en el UE 105 modifique la decodificación de señales de audio para el canal de audio recibido en la dirección de enlace descendente desde el PSAP 150 heredado en el bloque 620 empleando un DJB estático en lugar de un DJB adaptativo para el desempaquetado de audio (por ejemplo voz) o aumentando el intervalo de tiempo para el almacenamiento en búfer de paquetes de audio en un DJB adaptativo. Como ejemplo, un UE 105 puede usar un proceso 400 de almacenamiento en búfer y decodificación como se describe para la figura 4 y puede modificar el proceso 400 de almacenamiento en búfer y decodificación en respuesta a la obtención de la indicación de señalización en banda en el bloque 610 incluyendo los elementos que comprenden el subsistema 495 como se describe en asociación con la figura 4. En el bloque 630, el UE 105 puede proporcionar las señales de audio decodificadas desde el bloque 620 a un detector de mensajes en banda y/o a un dispositivo de reproducción de audio. Por ejemplo, cuando el UE 105 emplea un proceso 400 de almacenamiento en búfer y decodificación como se describe en la figura 4 como una consecuencia de modificar la decodificación de señales de audio para el canal de audio en el bloque 620, las señales de audio decodificadas desde el decodificador 440 de audio se proporcionan al detector 480 de mensajes en banda. Además, cuando el detector 480 de mensajes en banda no detecta una señal de audio en banda, la salida de audio desde el decodificador 430 de audio puede ser proporcionada por el proceso 400 de almacenamiento en búfer y decodificación a un dispositivo de reproducción como se describe para la figura 4. En ciertas otras realizaciones, la indicación de señalización en banda puede obtenerse en un UE 105 en el bloque 610 usando un proceso 400 de almacenamiento en búfer y decodificación como se describe en asociación con la figura 4 en el cual un detector 480 de mensajes en banda detecta una señal en banda en el canal de audio.
Cuando el método de diagrama 600 de flujo es realizado por una MGCF 135, la indicación de señalización en banda puede obtenerse en el bloque 610 por la MGCF 135 con base en ayudar a establecer una eCall o una eCall de NG entre un UE 105 y un PSAP 150 heredado como en el ejemplo descrito en la figura 2. En este ejemplo, la MGCF 135 recibe una indicación de una eCall de NG desde IMS 180 (por ejemplo E-CSCF 130 en IMS 180) en una solicitud para establecer una eCall (por ejemplo como en la acción 7a en la figura 2) y reenvía la solicitud para establecer la eCall a un PSAP 150 heredado a través de medios conmutados por circuitos pero no transfiere el MSD (por ejemplo como en la acción 7b en la figura 2). La MGCF 135 puede transferir la indicación de señalización en banda a m Gw 140 (por ejemplo como parte de instrucciones a MGW 140 para soportar el canal de audio entre UE 105 y PSAP 150 heredado usando un códec y tasa de bits negociados por MGCF 135 con UE 105), que puede hacer que MGW 140 modifique un proceso de transcodificación que puede ser usado por MGW 140 para soportar el canal de audio establecido entre el UE 105 y PSAP 150. La modificación del proceso de transcodificación por MGW 140 puede modificar la decodificación de señales de audio para el canal de audio en el bloque 620. Por ejemplo, la MGW 140 puede usar el proceso 500 de transcodificación descrito en asociación con la figura 5 en el cual el almacenamiento en búfer y decodificación de señales de audio se modifican por MGW 140 (como una consecuencia de recibir la indicación de señalización en banda desde MGCF 135) al incluir los elementos desde el subsistema 595 como parte del proceso 500 de transcodificación. Asimismo, en las ciertas otras realizaciones, una indicación de señalización en banda en el bloque 610 puede obtenerse mediante una MGCF 135 desde UE 105 - por ejemplo si el UE 105 envía una señal en un mensaje de SIP (por ejemplo, mensaje de SIP INFO) a MGCF 135 cuando el UE 105 está a punto de iniciar a enviar señalización en banda (por ejemplo, que contiene MSD) hacia el PSAP 150 heredado. MGCF 135 puede entonces provocar un proceso de decodificación en MGW 140 para modificar la decodificación de señales de audio para el canal de audio en el bloque 620 como se describió previamente.
Cuando el método de diagrama 600 de flujo es realizado por una MGW 140, la indicación de señalización en banda puede obtenerse en el bloque 610 por la MGW 140 desde una MGCF 135 cuando la MGCF 135 solicita a la MGW 140 que soporte la transferencia de la trayectoria de audio entre un UE 105 y PSAP 150 heredado como se describió previamente para el establecimiento de una eCall entre un UE 105 y PSAP 150 heredado. En ciertas otras realizaciones, una indicación de señalización en banda puede ser obtenida por la MGW 140 indirectamente a partir del PSAP 150 heredado - por ejemplo si el PSAP 150 heredado envía una indicación de señalización en banda a MGCF 135 usando señalización CS (por ejemplo ISUP de SS7) cuando el PSAP 150 heredado está a punto de enviar señalización en banda a UE 105, entonces MGCF 135 reenvía la indicación de señalización en banda a MGW 140. En respuesta a la obtención de la indicación de señalización en banda en el bloque 610, MGW 140 puede provocar un proceso de decodificación en MGW 140 para modificar la decodificación de señales de audio para el canal de audio en la dirección de enlace ascendente desde UE 105 a PSAP 150 heredado en el bloque 620 empleando un DJB estático en lugar de un DJB adaptativo para desempaquetado de audio (por ejemplo voz) o aumentando el intervalo de tiempo para el almacenamiento en búfer de paquetes de audio en un DJB adaptativo. Como ejemplo, MGW 140 puede usar un proceso 500 de transcodificación como se describe para la figura 5 y puede modificar el proceso 500 de transcodificación en respuesta a la obtención de la indicación de señalización en banda en el bloque 610 incluyendo los elementos que comprenden el subsistema 595 como se describe en asociación con la figura 5. En el bloque 630, MGW 140 puede proporcionar las señales de audio decodificadas desde el bloque 620 a un codificador de audio - por ejemplo para transferencia posterior a PSAP 150 heredado por medios conmutados por circuitos. Por ejemplo, cuando MGW 140 emplea un proceso 500 de transcodificación como se describe en la figura 5 como una consecuencia de modificar la decodificación de señales de audio para el canal de audio en el bloque 620, las señales de audio decodificadas desde el decodificador 540 de audio se proporcionan al codificador 590 de audio CS a través del conmutador 550. Además, cuando el detector 580 de mensajes en banda no detecta una señal de audio en banda, la salida de audio desde el decodificador 530 de audio puede ser proporcionada por el proceso 500 de transcodificación al codificador 590 de audio CS como se describe para la figura 5. En ciertas otras realizaciones, la indicación de señalización en banda puede obtenerse en una MGW 140 en el bloque 610 usando un proceso 500 de transcodificación como se describe en asociación con la figura 5 en el cual un detector 580 de mensajes en banda detecta una señal en banda en el canal de audio.
En algunas realizaciones, se puede enviar un mensaje (por ejemplo, desde una MGCF 135) a un dispositivo (por ejemplo, un UE 105/IVS 107) que genera señalización en banda para un canal de audio, en donde el mensaje es indicativo de un códec a utilizar para el canal de audio que también es adecuado para transmitir la señalización en banda. Adicional o alternativamente, la MGCF 135 puede hacer que se aumente el ancho de banda o tasa de bits del canal de audio (por ejemplo, seleccionando un códec de ancho de banda relativamente alto para ser usado para la comunicación).
La figura 7 es un diagrama 700 de flujo que ilustra un método de aumento de la fiabilidad de la transferencia de datos recibidos a través de señalización en banda, de acuerdo con otra realización. El método es generalmente similar al método mostrado en la figura 6, con la funcionalidad de los bloques 710 y 730 en la figura 7 repitiendo la funcionalidad de los bloques 610 y 630 (en la figura 6) respectivamente. Aquí, sin embargo, la funcionalidad de bloque 720 incluye "utilizar un proceso de decodificación modificado para decodificar señales de audio para el canal de audio", como una consecuencia de lo cual, el uno o más componentes que ejecutan la funcionalidad del bloque 720 pueden utilizar el proceso de decodificación modificado. Por el contrario, para el diagrama 600 de flujo, la funcionalidad del bloque 620 incluye "provocar [la provocación de] un proceso de decodificación para modificar la decodificación de señales de audio para el canal de audio", como una consecuencia de lo cual, el uno o más componentes que ejecutan la funcionalidad del bloque 620 pueden o pueden no utilizar el proceso de decodificación modificado. Al igual que con la figura 6, el método de figura 7 puede ser ejecutado por un UE 105, una MGCF 135, y/o una MGW 140.
Al igual que con otras figuras proporcionadas en este documento, la figura 7 se proporciona como un ejemplo no limitante. Realizaciones alternativas pueden incluir funcionalidad adicional a la mostrada en la figura, y/o la funcionalidad mostrada en uno o más de los bloques de la figura puede omitirse, combinarse, separarse, y/o realizarse simultáneamente. Los medios para realizar la funcionalidad de los bloques pueden incluir uno o más componentes de hardware y/o software, tales como los descritos con respecto al sistema de ordenador de la figura 9 a continuación. Una persona de experiencia normal en la técnica reconocerá muchas variaciones.
La figura 8 ilustra una realización de un UE 105, que se puede utilizar como se describe en este documento anteriormente. Por ejemplo, el UE 105 se puede usar en el sistema 100 para habilitar eCalls de NG para LTE de la figura 1. Como se discutió anteriormente, el UE 105 puede incorporarse además en un IVS 107, que puede incluir rasgos adicionales. Debe anotarse que la figura 8 está prevista solamente para proporcionar una ilustración generalizada de diversos componentes, cualquiera o todos los cuales se pueden utilizar según sea apropiado. Puede anotarse que, en algunos casos, componentes ilustrados por la figura 8 se pueden ubicar en un único dispositivo físico y/o distribuir entre diversos dispositivos en red, que pueden estar dispuestos en diferentes ubicaciones físicas.
Se muestra el UE 105 que comprende elementos de hardware que pueden acoplarse eléctricamente a través de un bus 805 (o pueden estar en comunicación de otro modo, según sea apropiado). Los elementos de hardware pueden incluir unas unidades 810 de procesamiento que pueden incluir sin limitación uno o más procesadores de propósito general, uno o más procesadores de propósito especial (tales como chips de procesamiento de señal digital (DSP), procesadores de aceleración de gráficos, circuitos integrados de aplicación específica (ASICs), y/o similares), y/u otra estructura o medio de procesamiento. Como se muestra en la figura 8, algunas realizaciones pueden tener un DSP 820 separado, dependiendo de la funcionalidad deseada. La lógica de almacenamiento en búfer puede proporcionarse en las unidades 810 de procesamiento y/o en la interfaz 830 de comunicación inalámbrica (se discute a continuación). El UE 105 también puede incluir uno o más dispositivos 870 de entrada, que pueden incluir sin limitación una pantalla táctil, una almohadilla táctil, micrófono, botones, diales, conmutadores, y/o similares; y uno o más dispositivos 815 de salida, que pueden incluir sin limitación una pantalla, diodo emisor de luz (LED), altavoces, y/o similares.
El UE 105 también puede incluir una interfaz 830 de comunicación inalámbrica, que puede incluir sin limitación un módem, una tarjeta de red, un dispositivo de comunicación por infrarrojos, un dispositivo de comunicación inalámbrica, y/o un conjunto de chips (tales como un dispositivo Bluetooth, un dispositivo IEEE 802.11, un dispositivo IEEE 802.15.4, un dispositivo WiFi, un dispositivo WiMax, instalaciones de comunicación celular, etc.), y/o similares. La interfaz 830 de comunicación inalámbrica puede permitir que los datos sean intercambiados con una red, puntos de acceso inalámbricos, otros sistemas de ordenador, y/o cualquier otro dispositivo electrónico descrito en este documento. La comunicación puede llevarse a cabo a través de una o más antenas 832 de comunicación inalámbrica que envían y/o reciben señales 834 inalámbricas.
Dependiendo de la funcionalidad deseada, la interfaz 830 de comunicación inalámbrica puede incluir transceptores separados para comunicarse con una o más redes inalámbricas a través de estaciones base y/o puntos de acceso (por ejemplo, eNB 110 de la figura 1). La una o más redes inalámbricas pueden incluir diversos tipos de redes tales como una red de Acceso Múltiple por División de Código (CDMA), una red de Acceso Múltiple por División de Tiempo (TDMA), una red de Acceso Múltiple por División de Frecuencia (FDMA), una red de Acceso Múltiple por División de Frecuencia Ortogonal (OFDMA), una red de Acceso Múltiple por División de Frecuencia de Portador Único (SC-FDMA), una red WiMax (IEEE 802.16), una Red de Área Local Inalámbrica (WLAN), y así sucesivamente. Una red de CDMA puede implementar una o más tecnologías de acceso por radio (RATs) tales como cdma2000, CDMA de Banda ancha (w -CDm A), y así sucesivamente. Cdma2000 incluye los estándares IS-95, IS-2000, y/o IS-856. Una red de TDMA puede implementar un Sistema Global para Comunicaciones Móviles (GSM), Sistema de Telefonía Móvil Avanzado Digital (D-AMPS), o alguna otra RAT. Una red de OFDMA puede emplear LTE, LTE Avanzada, y así sucesivamente. LTE, LTE Avanzada, GSM, y W-CDMA se describen en documentos de 3GPP. Cdma2000 se describe en documentos de un consorcio denominado "Proyecto de Asociación de 3ra Generación 2" (3GPP2). Los documentos de 3GPP y 3GPP2 están disponibles públicamente. Una WLAN puede ser una red IEEE 802.11*, una red Bluetooth, una red IEEE 802.15x, o algún otro tipo de red. Las técnicas descritas en este documento también se pueden usar para cualquier combinación de dos o más redes inalámbricas o para redes inalámbricas combinadas con redes alámbricas (por ejemplo el Internet y/o PSTN).
El UE 105 puede incluir además sensores 840. Tales sensores pueden incluir, sin limitación, uno o más acelerómetros, giroscopios, cámaras, magnetómetros, altímetros, micrófonos, sensores de proximidad, sensores de luz, y similares.
Algunos o todos los sensores 840 se pueden utilizar, entre otras cosas, para detectar una condición de emergencia que pueda activar una eCall o una eCall de NG, como se describe en este documento.
Realizaciones del UE 105 también pueden incluir un receptor 880 de SPS capaz de recibir señales 884 desde uno o más satélites de SPS usando una antena 882 de SPS. Tal posicionamiento se puede utilizar para complementar y/o incorporar las técnicas descritas en este documento. El receptor 880 de SPS puede extraer una posición del UE 105, usando técnicas convencionales, desde vehículos espaciales (SVs) de SPS de un sistema de s Ps o GNSS tal como el Sistema de Posicionamiento Global (GPS), Galileo, Glonass, Sistema de Satélites CuasiCenit (QZSS) sobre Japón, Sistema Regional de Navegación por Satélite de la India (IRNSS) sobre India, Beidou sobre China, y/o similares. Además, el receptor 880 de SPS puede recibir señales desde diversos sistemas de aumento (por ejemplo, un Sistema de Aumento Basado en Satélites (SBAS)) que pueden estar asociados con o habilitados de otro modo para uso con uno o más sistemas globales y/o regionales de navegación por satélite. A modo de ejemplo pero no de limitación, un SBAS puede incluir unos sistemas de aumento que proporcionen información de integridad, correcciones diferenciales, etc., tales como, por ejemplo, Sistema de Aumento de Área Amplia (WAAS), Servicio Europeo de Superposición de Navegación Geoestacionaria (EGNOS), Sistema de Aumento de Satélite Multifuncional (MSAS), sistema de Navegación GeoAumentada Asistida por GPS o de Navegación por GPS y GeoAumentado (GAGAN), y/o similares. De este modo, como se usa en este documento, un SPS puede incluir cualquier combinación de uno o más sistemas globales y/0 regionales de navegación por satélite y/o sistemas de aumento, y las señales de SPS pueden incluir SPS, similares a SPS, y/u otras señales asociadas con tal uno o más SPS. El receptor 880 de SPS puede configurarse para determinar o ayudar a determinar una ubicación (por ejemplo coordenadas de latitud y longitud) para el UE 105, con base en la medición de señales 884 de SPS, ya sea por sí mismo o en combinación con otros elementos de UE 105 tales como unidades 810 de procesamiento. La ubicación puede determinarse periódicamente (por ejemplo a intervalos de 1 o 2 segundos) y puede incluirse dentro de los datos telemáticos (por ejemplo MSD) que UE 105 envía a un PSAP (por ejemplo PSAP 150 heredado) cuando se inicia una eCall o eCall de NG por UE 105 como en el ejemplo para la figura 2.
El UE 105 puede además incluir y/o estar en comunicación con una memoria 860. La memoria 860 puede incluir, sin limitación, almacenamiento local y/o accesible en red, una unidad de disco, un arreglo de unidades, un dispositivo de almacenamiento óptico, un dispositivo de almacenamiento de estado sólido, tal como una memoria de acceso aleatorio ("RAM"), y/o una memoria de sólo lectura ("ROM"), que puede ser programable, actualizable mediante flash, y/o similares. Tales dispositivos de almacenamiento pueden configurarse para implementar cualquier almacén de datos apropiado, incluyendo sin limitación, diversos sistemas de archivos, estructuras de bases de datos, y/o similares.
La memoria 860 del UE 105 también puede comprender elementos de software (no se muestran), que incluyen un sistema operativo, accionadores de dispositivos, bibliotecas ejecutables, y/u otro código, tales como uno o más programas de aplicación, que pueden comprender programas de ordenador proporcionados por diversas realizaciones, y/o pueden diseñarse para implementar métodos, y/o configurar sistemas, proporcionados por otras realizaciones, como se describe en este documento. Simplemente a modo de ejemplo, uno o más procedimientos descritos con respecto a los métodos discutidos anteriormente pueden implementarse como código y/o instrucciones ejecutables por el UE 105 (y/o una unidad 810 de procesamiento o DSP 820 dentro del UE 105). En un aspecto, entonces, tal código y/o instrucciones pueden usarse para configurar y/o adaptar un ordenador de propósito general (u otro dispositivo) para realizar una o más operaciones de acuerdo con los métodos descritos.
La figura 9 ilustra una realización de un sistema 900 de ordenador, que puede incorporarse, al menos en parte, en dispositivos usados para implementar uno o más de los componentes del sistema 100 para habilitar eCalls de NG para LTE de la figura 1 y/o componentes de un sistema similar configurado para implementar las técnicas divulgadas anteriormente. La figura 9 proporciona una ilustración esquemática de una realización de un sistema 900 de ordenador que puede realizar los métodos proporcionados por diversas otras realizaciones, tales como el método descrito en relación con las figuras 1 a 7 y/o la funcionalidad de MGCF 135, MGW 140, y/u otros componentes de un sistema de LTE. Debe anotarse que la figura 9 está prevista solamente para proporcionar una ilustración generalizada de diversos componentes, cualquiera o todos de los cuales pueden utilizarse según sea apropiado. La figura 9, por lo tanto, ilustra ampliamente cómo los elementos individuales de sistema pueden implementarse de una manera relativamente separada o relativamente más integrada. Además, se puede anotar que los componentes ilustrados por la figura 9 se pueden ubicar en un único dispositivo y/o distribuir entre diversos dispositivos en red, que pueden disponerse en diferentes ubicaciones físicas.
El sistema 900 de ordenador se muestra que comprende elementos de hardware que pueden acoplarse eléctricamente a través de un bus 905 (o pueden de otro modo estar en comunicación, según sea apropiado). Los elementos de hardware pueden incluir las unidades 910 de procesamiento, que pueden incluir sin limitación uno o más procesadores de propósito general, uno o más procesadores de propósito especial (tales como chips de procesamiento de señales digitales, procesadores de aceleración de gráficos, y/o similares), y/u otra estructura de procesamiento, que se puede configurar para realizar uno o más de los métodos descritos en este documento, incluyendo el método descrito en relación con las figuras 1 a 7. El sistema 900 de ordenador también puede incluir uno o más dispositivos 915 de entrada, que pueden incluir sin limitación un ratón, un teclado, una cámara, un micrófono, otros sensores biométricos, y/o similares; y uno o más dispositivos 920 de salida, que pueden incluir sin limitación un dispositivo de visualización, una impresora, y/o similares.
El sistema 900 de ordenador puede incluir además (y/o estar en comunicación con) uno o más dispositivos 925 de almacenamiento no transitorios, que pueden comprender, sin limitación, almacenamiento local y/o accesible en red, y/o pueden incluir, sin limitación, una unidad de disco, un arreglo de unidades, un dispositivo de almacenamiento óptico, un dispositivo de almacenamiento de estado sólido, tal como una memoria de acceso aleatorio ("RAM"), y/o una memoria de solo lectura ("ROM"), que puede ser programable, actualizable mediante flash, y/o similares. Tales dispositivos de almacenamiento pueden configurarse para implementar cualquier almacén de datos apropiado, incluyendo sin limitación, diversos sistemas de archivos, estructuras de bases de datos, y/o similares.
El sistema 900 de ordenador también podría incluir un subsistema 930 de comunicaciones, que puede incluir tecnologías de comunicación inalámbrica gestionadas y controladas por una interfaz 933 de comunicación inalámbrica, así como tecnologías por cable. Como tal, el subsistema de comunicaciones puede incluir un módem, una tarjeta de red (inalámbrica o por cable), un dispositivo de comunicación por infrarrojos, un dispositivo de comunicación inalámbrica, y/o un conjunto de chips, y/o similares. El subsistema 930 de comunicaciones puede incluir una o más interfaces de comunicación de entrada y/o salida, tal como la interfaz 933 de comunicación inalámbrica, para permitir que los datos sean intercambiados con una red, dispositivos móviles (tales como UE 105/IVS 107), otros sistemas de ordenador, y/o cualquier otro dispositivo electrónico descrito en este documento. Nótese que los términos "dispositivo móvil" y "UE" se usan de manera intercambiable en este documento para referirse a cualquier dispositivo de comunicaciones móviles tales como, pero no limitados a, teléfonos móviles, teléfonos inteligentes, dispositivos de uso personal, dispositivos informáticos móviles (por ejemplo, ordenadores portables, PDAs, tabletas), módems incorporados, y dispositivos informáticos para automóviles y otros vehículos.
En muchas realizaciones, el sistema 900 de ordenador comprenderá además una memoria 935 de trabajo, que puede incluir una RAM y/o dispositivo de ROM. Los elementos de software, que se muestran como ubicados dentro de la memoria 935 de trabajo, pueden incluir un sistema 940 operativo, accionadores de dispositivo, bibliotecas ejecutables, y/u otro código, tal como uno o más programas 945 de aplicación, que pueden comprender programas de ordenador proporcionados por diversas realizaciones, y/o pueden diseñarse para implementar métodos, y/o configurar sistemas, proporcionados por otras realizaciones, como se describe en este documento. Simplemente a modo de ejemplo, uno o más procedimientos descritos con respecto a los métodos discutidos anteriormente, tal como el método descrito en relación con las figuras 1 a 7, pueden implementarse como código y/o instrucciones ejecutables por un ordenador (y/o una unidad de procesamiento dentro de un ordenador); en un aspecto, entonces, tal código y/o instrucciones pueden usarse para configurar y/o adaptar un ordenador de propósito general (u otro dispositivo) para realizar una o más operaciones de acuerdo con los métodos descritos.
Un conjunto de estas instrucciones y/o código podría almacenarse en un medio de almacenamiento legible por ordenador no transitorio, tal como los dispositivos 925 de almacenamiento descritos anteriormente. En algunos casos, el medio de almacenamiento podría incorporarse dentro de un sistema de ordenador, tal como sistema 900 de ordenador. En otras realizaciones, el medio de almacenamiento podría estar separado desde un sistema de ordenador (por ejemplo, un medio extraíble, tal como un disco óptico), y/o proporcionarse en un paquete de instalación, de tal manera que el medio de almacenamiento se pueda usar para programar, configurar, y/o adaptar un ordenador de propósito general con las instrucciones/código almacenados en el mismo. Estas instrucciones podrían tomar la forma de código ejecutable, que es ejecutable por el sistema 900 de ordenador y/o podrían tomar la forma de código fuente y/o instalable, que, tras la compilación y/o instalación en el sistema 900 de ordenador (por ejemplo, usando cualquiera de una variedad de compiladores, programas de instalación, utilidades de compresión/descompresión, etc. generalmente disponibles), luego toma la forma de código ejecutable.
Será evidente para los expertos en la técnica que se pueden hacer variaciones sustanciales de acuerdo con requisitos específicos. Por ejemplo, también se puede usar hardware personalizado, y/o se pueden implementar elementos particulares en hardware, software (incluyendo software portátil, tal como subaplicaciones, etc.), o ambos. Adicionalmente, puede emplearse la conexión a otros dispositivos informáticos tales como dispositivos de entrada/salida de red.
Con referencia a las figuras anexas, los componentes que pueden incluir memoria pueden incluir medios legibles por máquina no transitorios. El término "medio legible por máquina" y "medio legible por ordenador" como se usa en este documento, se refiere a cualquier medio de almacenamiento que participa en la provisión de datos que hacen que una máquina opere de una manera específica. En realizaciones proporcionadas anteriormente, diversos medios legibles por máquina podrían estar involucrados en proporcionar instrucciones/código a las unidades de procesamiento y/u otros dispositivos para ejecución. Adicional o alternativamente, los medios legibles por máquina podrían usarse para almacenar y/o portar tales instrucciones/código. En muchas implementaciones, un medio legible por ordenadores un medio de almacenamiento físico y/o tangible. Tal medio puede tomar muchas formas, incluyendo pero no limitados a, medios no volátiles, medios volátiles, y medios de transmisión. Las formas comunes de medios legibles por ordenador incluyen, por ejemplo, medios magnéticos y/u ópticos, tarjetas perforadas, cintas de papel, cualquier otro medio físico con patrones de orificios, una RAM, una PROM, EPROM, una FLASH-EPROM, cualquier otro chip de memoria o cartucho, una onda portadora como se describe de aquí en adelante, o cualquier otro medio desde el cual un ordenador pueda leer instrucciones y/o código.
Los métodos, sistemas, y dispositivos discutidos en este documento son ejemplos. Diversas realizaciones pueden omitir, sustituir, o agregar diversos procedimientos o componentes según sea apropiado. Por ejemplo, los rasgos descritos con respecto a ciertas realizaciones pueden combinarse en diversas otras realizaciones. Se pueden combinar diferentes aspectos y elementos de las realizaciones de una manera similar. Los diversos componentes de las figuras proporcionadas en este documento se pueden realizar en hardware y/o software. También, la tecnología evoluciona y, de este modo, muchos de los elementos son ejemplos que no limitan el alcance de la divulgación a esos ejemplos específicos.
A veces ha resultado conveniente, principalmente por razones de uso común, referirse a tales señales como bits, información, valores, elementos, símbolos, caracteres, variables, términos, números, numerales, o similares. Debe entenderse, sin embargo, que todos estos o similares términos deben asociarse con cantidades físicas apropiadas y son simplemente etiquetas convenientes. A menos que se establezca específicamente otra cosa, como es evidente a partir de la discusión anterior, se aprecia que a lo largo de esta Especificación las discusiones que utilizan términos tales como "procesamiento", "computación", "cálculo", "determinación", "verificación", "identificación", "asociamiento", “medición", "realización", o similares se refieren a acciones o procesos de un aparato específico, tales como un ordenador de propósito especial o un dispositivo informático electrónico de propósito especial similar. En el contexto de esta Especificación, por lo tanto, un ordenador de propósito especial o un dispositivo informático electrónico de propósito especial similar es capaz de manipular o transformar señales, típicamente representadas como cantidades físicas electrónicas, eléctricas, o magnéticas dentro de memorias, registros, u otros dispositivos de almacenamiento de información, dispositivos de transmisión, o dispositivos de visualización del ordenador de propósito especial o dispositivo informático electrónico de propósito especial similar.
Los términos, "y" y "o" como se usan en este documento, pueden incluir una variedad de significados que también se espera que dependan al menos en parte del contexto en el cual se usan tales términos. Típicamente, "o" si se usa para asociar una lista, tal como A, B, o C, está previsto para significar A, B, y C, aquí usado en el sentido inclusivo, así como A, B, o C, aquí usado en el sentido exclusivo. Además, el término "uno o más" como se usa en este documento puede usarse para describir cualquier rasgo, estructura o característica en el singular o puede usarse para describir alguna combinación de rasgos, estructuras, o características. Sin embargo, debe anotarse que este es simplemente un ejemplo ilustrativo y la materia objeto reivindicada no se limita a este ejemplo. Adicionalmente, el término "al menos uno de' si se usa para asociar una lista, tal como A, B, o C, puede interpretarse para significar cualquier combinación de A, B, y/o C, tal como A, AB, AA, AAB, AABBCCC, etc.
Habiendo descrito varias realizaciones, pueden usarse diversas modificaciones, construcciones alternativas, y equivalentes sin apartarse del alcance de la divulgación. Por ejemplo, los elementos anteriores pueden ser simplemente un componente de un sistema más grande, en donde otras reglas pueden tener prioridad sobre o modificar de otro modo la aplicación de las diversas realizaciones. También, se puede emprender un número de etapas antes, durante, o después de que se consideren los elementos anteriores. Por consiguiente, la descripción anterior no limita el alcance de la divulgación. El alcance de protección está definido por las reivindicaciones anexas.

Claims (13)

REIVINDICACIONES
1. Un método (700) en un dispositivo (105, 107) de comunicaciones de aumento de fiabilidad de la transferencia de datos recibidos a través de la señalización en banda durante una eCall o una eCall de próxima generación, comprendiendo el método:
obtener (710) una indicación de señalización en banda, produciéndose la señalización en banda en un canal de audio de una red (102) de comunicación y transfiriendo dicha señalización en banda un conjunto mínimo de datos, MSD, durante la eCall o la eCall de próxima generación; y
en respuesta a la obtención de la indicación de señalización en banda, utilizar un proceso de decodificación modificado para decodificar señales de audio para el canal de audio, en donde el proceso de decodificación modificado comprende inhabilitar un búfer (410) de eliminación de variación rápida adaptativo; o
aumentar un intervalo de tiempo para almacenamiento en búfer de paquetes de audio en un búfer (410) de eliminación de variación rápida adaptativo.
2. El método (700) de la reivindicación 1, en donde la red de comunicación comprende una red (102) de Evolución a Largo Plazo.
3. El método (700) de la reivindicación 1, en donde la indicación de señalización en banda se obtiene a partir de un mensaje recibido desde un dispositivo (150) remoto.
4. El método (700) de la reivindicación 1, en donde la indicación de señalización en banda se obtiene a través de un detector (480) que analiza señales transmitidas en el canal de audio.
5. El método (700) de la reivindicación 1, en donde el proceso de decodificación modificado comprende además inhabilitar el búfer (410) de eliminación de variación rápida adaptativo y usar un búfer (420) de eliminación de variación rápida estático.
6. El método (700) de la reivindicación 1, que comprende además proporcionar las señales de audio decodificadas a al menos uno de un detector (480) de mensajes en banda, un codificador de audio, o un dispositivo de reproducción de audio basado en la indicación de señalización en banda.
7. El método (700) de la reivindicación 6, en donde el dispositivo de comunicaciones es un equipo (105) de usuario.
8. El método (700) de la reivindicación 6, en donde el dispositivo de comunicaciones es una Pasarela de Medios y el proceso de decodificación modificado comprende un proceso de transcodificación.
9. El método (700) de la reivindicación 1, que comprende además, en respuesta a la obtención de la indicación de señalización en banda, enviar un mensaje a un dispositivo (150) que genera la señalización en banda, en donde el mensaje es indicativo de un códec a utilizar para comunicar la señalización en banda.
10. El método (700) de la reivindicación 1, que comprende además, en respuesta a la obtención de la indicación de señalización en banda, hacer que se aumente el ancho de banda del canal de audio.
11. Un dispositivo (900) para aumentar la fiabilidad de la transferencia de datos recibidos a través de la señalización en banda durante una eCall o una eCall de próxima generación, comprendiendo el dispositivo:
un subsistema (930) de comunicaciones; y
una unidad (910) de procesamiento acoplada comunicativamente al subsistema de comunicaciones y configurada para hacer que el dispositivo:
obtenga una indicación de señalización en banda, produciéndose la señalización en banda en un canal de audio de una red (102) de comunicación y transfiriendo dicha señalización en banda un conjunto mínimo de datos, MSD, durante la eCall o la eCall de próxima generación; y
en respuesta a la obtención de la indicación de señalización en banda, utilice un proceso de decodificación modificado para decodificar señales de audio para el canal de audio, en donde el proceso de decodificación modificado comprende inhabilitar un búfer (410) de eliminación de variación rápida adaptativo; o
aumentar un intervalo de tiempo para almacenamiento en búfer de paquetes de audio en un búfer (410) de eliminación de variación rápida adaptativo.
12. El dispositivo (900) de la reivindicación 11, en donde el subsistema (930) de comunicaciones está configurado para obtener la indicación de señalización en banda a partir de un mensaje recibido desde un dispositivo (150) remoto.
13. Un medio legible por ordenador no transitorio que tiene instrucciones incorporadas en el mismo para aumentar la fiabilidad de la transferencia de datos recibidos a través de señalización en banda, incluyendo las instrucciones código de ordenador para hacer que un dispositivo lleve a cabo las etapas de cualquiera de las reivindicaciones 1 a 10 cuando se ejecutan por un procesador.
ES16823112T 2016-01-24 2016-12-15 Alternativa mejorada a modo en banda para llamadas de emergencia Active ES2902151T3 (es)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201662286432P 2016-01-24 2016-01-24
US201662292761P 2016-02-08 2016-02-08
US15/191,923 US10499229B2 (en) 2016-01-24 2016-06-24 Enhanced fallback to in-band mode for emergency calling
PCT/US2016/066834 WO2017127186A1 (en) 2016-01-24 2016-12-15 Enhanced fallback to in-band mode for emergency calling

Publications (1)

Publication Number Publication Date
ES2902151T3 true ES2902151T3 (es) 2022-03-25

Family

ID=59359273

Family Applications (1)

Application Number Title Priority Date Filing Date
ES16823112T Active ES2902151T3 (es) 2016-01-24 2016-12-15 Alternativa mejorada a modo en banda para llamadas de emergencia

Country Status (11)

Country Link
US (1) US10499229B2 (es)
EP (2) EP3406036B1 (es)
KR (1) KR20180107773A (es)
CN (1) CN108476086B (es)
AU (1) AU2016387451A1 (es)
BR (1) BR112018014872A2 (es)
ES (1) ES2902151T3 (es)
HK (1) HK1254089A1 (es)
SG (1) SG11201804900QA (es)
TW (1) TWI712288B (es)
WO (1) WO2017127186A1 (es)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107113584A (zh) * 2014-12-18 2017-08-29 高通股份有限公司 用于利用过顶服务提供商来支持紧急呼叫的技术
EP3316603B1 (en) * 2015-06-26 2023-04-12 Nec Corporation Communication apparatus and method for handling ims emergency calls in a roaming situation
US9894504B2 (en) * 2015-11-30 2018-02-13 Verizon Patent And Licensing Inc. Emergency call support for VoLTE roaming within S8 home routing architecture
WO2018000338A1 (zh) * 2016-06-30 2018-01-04 北京小米移动软件有限公司 编码格式确定方法及装置
US10885781B2 (en) * 2017-09-25 2021-01-05 Blackberry Limited Method and system for a proxy vehicular intelligent transportation system station
KR102504076B1 (ko) * 2018-07-27 2023-02-27 도이체 텔레콤 악티엔 게젤샤프트 패킷 교환 통신 시스템에서 긴급 세션의 향상된 개시 및/또는 라우팅을 위한 방법, 시스템, 이동 통신 디바이스, 패킷 교환 통신 시스템, 프로그램 및 컴퓨터 프로그램 제품
EP3895398B1 (en) * 2018-12-12 2024-06-26 Telefonaktiebolaget Lm Ericsson (Publ) Communication system with de-jitter buffer for reducing jitter
AU2020250940A1 (en) * 2019-03-29 2021-09-30 Nokia Technologies Oy Degradation signaling
CA3074974A1 (en) * 2020-03-06 2021-09-06 IC Events Inc. Apparatus and method for transmitting multiple on-demand audio streams locally to web-enabled devices
CN112055350B (zh) * 2020-08-11 2022-06-03 博泰车联网科技(上海)股份有限公司 一种紧急求援方法及装置

Family Cites Families (35)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3300740A (en) * 1963-07-08 1967-01-24 Collins Radio Co A. c. ripple and noise reduction without increasing current drain
US5748763A (en) * 1993-11-18 1998-05-05 Digimarc Corporation Image steganography system featuring perceptually adaptive and globally scalable signal embedding
US5768308A (en) * 1994-12-19 1998-06-16 Northern Telecom Limited System for TDMA mobile-to-mobile VSELP codec bypass
US6690681B1 (en) * 1997-05-19 2004-02-10 Airbiquity Inc. In-band signaling for data communications over digital wireless telecommunications network
US6600740B1 (en) * 1998-10-03 2003-07-29 Ericsson Inc Voice quality optimization on multi-codec calls
FI107109B (fi) * 1998-10-21 2001-05-31 Nokia Networks Oy Digitaalinen tietoliikennejärjestelmä
CA2290069A1 (en) * 1999-11-19 2001-05-19 Nokia Mobile Phones Ltd. Method for establishing a call in the presence of outband indication of pstn involvement at multimedia call setup
US7738509B2 (en) * 2002-12-27 2010-06-15 General Motors Llc Method and system for inband emergency notification for voice calls
US8665892B2 (en) * 2006-05-30 2014-03-04 Broadcom Corporation Method and system for adaptive queue and buffer control based on monitoring in a packet network switch
US7729381B2 (en) * 2006-09-15 2010-06-01 At&T Intellectual Property I, L.P. In-band media performance monitoring
JP5363488B2 (ja) * 2007-09-19 2013-12-11 テレフオンアクチーボラゲット エル エム エリクソン（パブル） マルチチャネル・オーディオのジョイント強化
US8200185B2 (en) * 2008-04-02 2012-06-12 Qualcomm Incorporated Method and apparatus for supporting emergency calls (eCalls)
US8725502B2 (en) * 2008-06-05 2014-05-13 Qualcomm Incorporated System and method of an in-band modem for data communications over digital wireless communication networks
US8351973B2 (en) * 2008-06-13 2013-01-08 Telefonaktiebolaget L M Ericsson (Publ) Short message service (SMS) over service access point identifier 0 (SAPI-0)
US8594138B2 (en) 2008-09-15 2013-11-26 Airbiquity Inc. Methods for in-band signaling through enhanced variable-rate codecs
US8265022B2 (en) * 2009-02-10 2012-09-11 Apple Inc. Apparatus and methods for transmission of emergency call data over wireless networks
WO2010101943A1 (en) * 2009-03-03 2010-09-10 Airbiquity Inc. In-vehicle system (ivs) control of emergency data communications
GB0915766D0 (en) * 2009-09-09 2009-10-07 Apt Licensing Ltd Apparatus and method for multidimensional adaptive audio coding
US8548460B2 (en) * 2010-05-25 2013-10-01 Qualcomm Incorporated Codec deployment using in-band signals
US9237172B2 (en) * 2010-05-25 2016-01-12 Qualcomm Incorporated Application notification and service selection using in-band signals
CN102934161B (zh) * 2010-06-14 2015-08-26 松下电器产业株式会社 音频混合编码装置以及音频混合解码装置
JP5749462B2 (ja) * 2010-08-13 2015-07-15 株式会社Ｎｔｔドコモ オーディオ復号装置、オーディオ復号方法、オーディオ復号プログラム、オーディオ符号化装置、オーディオ符号化方法、及び、オーディオ符号化プログラム
EP2681963B1 (en) * 2011-03-03 2015-02-25 Telefonaktiebolaget LM Ericsson (PUBL) Methods, devices, system and computer program products for supporting the re-establishment of an emergency communication
US8903355B2 (en) * 2011-09-26 2014-12-02 Solacom Technologies Inc. Answering or releasing emergency calls from a map display for an emergency services platform
US9426304B2 (en) * 2011-09-26 2016-08-23 Solacom Technologies Inc. Answering or releasing emergency calls from a map display for an emergency services platform
CN103548383A (zh) * 2011-12-23 2014-01-29 华为技术有限公司 一种紧急呼叫场景下传输最小数据集的方法、装置及系统
FR2989246B1 (fr) 2012-04-04 2015-06-05 Sagemcom Energy & Telecom Sas Procede de filtrage d'appels entrants destine a etre mis en œuvre par un dispositif embarque dans un vehicule
US20150109997A1 (en) * 2013-10-21 2015-04-23 Alexander Sirotkin Apparatus, system and method of interfacing between a cellular manager and a wlan access device
US20150264548A1 (en) 2014-03-11 2015-09-17 Via Telecom, Inc. Ecall system and method
JP6630719B2 (ja) * 2014-07-23 2020-01-15 クアルコム，インコーポレイテッド 車両開始型緊急呼
EP3183899B1 (en) * 2014-08-22 2021-01-20 Nokia Technologies Oy Method and apparatus for supporting an emergency call service in an ip multimedia subsystem session during handover
US9681282B2 (en) * 2014-10-08 2017-06-13 Qualcomm Incorporated Techniques for supporting telematics-enhanced emergency calls from mobile phones
DE102015218170A1 (de) * 2015-09-22 2017-03-23 digades GmbH, Digitales und analoges Schaltungsdesign Verfahren und System zum Generieren und Übertragen eines Notrufsignals
US9768853B1 (en) * 2016-03-16 2017-09-19 Ibiquity Digital Corporation Method and apparatus for blending an audio signal in an in-band on-channel radio system
EP3229505B1 (de) 2016-04-07 2020-07-01 Volkswagen Aktiengesellschaft Übertragen von informationen bezüglich eines notfalls zwischen einem mobilen endgerät und einer notfallleitstelle

Also Published As

Publication number Publication date
CN108476086A8 (zh) 2021-04-06
CN108476086B (zh) 2022-09-02
TW201728129A (zh) 2017-08-01
EP3406036A1 (en) 2018-11-28
US10499229B2 (en) 2019-12-03
EP3993295A2 (en) 2022-05-04
AU2016387451A1 (en) 2018-07-05
EP3993295B1 (en) 2023-10-04
CN108476086A (zh) 2018-08-31
BR112018014872A2 (pt) 2018-12-11
HK1254089A1 (zh) 2019-07-12
EP3406036B1 (en) 2021-11-24
TWI712288B (zh) 2020-12-01
KR20180107773A (ko) 2018-10-02
WO2017127186A1 (en) 2017-07-27
EP3993295A3 (en) 2022-07-13
SG11201804900QA (en) 2018-08-30
US20170215056A1 (en) 2017-07-27

Similar Documents

Publication Publication Date Title
ES2902151T3 (es) Alternativa mejorada a modo en banda para llamadas de emergencia
US10873844B2 (en) Apparatus and methods for transmission of emergency call data over wireless networks
US10111078B2 (en) Techniques to support emergency calls with over-the-top service provider
CN110945963B (zh) 用于改善针对处于仅eCall模式的移动设备的移动性的系统和方法
WO2019027538A1 (en) NETWORK ELEMENT FOR ENHANCED SMS EMERGENCY CALL
WO2017000132A1 (en) Techniques to support emergency calls with over-the-top service provider
WO2019027537A1 (en) USER EQUIPMENT FOR ENHANCED SMS EMERGENCY CALL