ES2749750T3

ES2749750T3 - Transferencia selectiva de datos de alta prioridad que no son de audio a través de un canal de calidad de servicio

Info

Publication number: ES2749750T3
Application number: ES14747740T
Authority: ES
Inventors: Vijay A Suryavanshi
Original assignee: Qualcomm Inc
Current assignee: Qualcomm Inc
Priority date: 2013-06-25
Filing date: 2014-06-24
Publication date: 2020-03-23
Anticipated expiration: 2034-06-24
Also published as: CN105324967B; US9444746B2; US20160352641A1; WO2014210011A1; JP6577461B2; JP2016525304A; EP3014825A1; US10187311B2; US20140376563A1; CN105324967A; HUE047111T2; EP3014825B1

Abstract

Un procedimiento de hacer funcionar un equipo de usuario, UE, que participa en una sesión de comunicación con uno o más otros UE, que comprende: obtener (700A) datos de audio y datos que no son de audio para su transmisión a uno o más otros UE durante la sesión de comunicación, en el que se presta soporte a la sesión de comunicación en el UE al menos en parte por medio de un canal de calidad de servicio, QoS, canal en el que el tráfico de audio se lleva principalmente y caracterizado por que se presta soporte a la sesión de comunicación en el UE al menos en parte por medio de un canal que no es QoS en el que se lleva tráfico que no es de audio; además caracterizado por identificar (715A) un primer subconjunto de datos de prioridad más alta que no son de audio dentro de los datos que no son de audio obtenidos; detectar un nivel de utilización en el canal QoS durante la sesión de comunicación; determinar (730A) transmitir el primer subconjunto de datos de prioridad más alta que no son de audio identificado a través del canal QoS en lugar del canal que no es QoS basado al menos en parte en la identificación mientras el nivel de utilización está por debajo de un umbral; y transmitir (735A) un primer flujo de paquetes al uno o más otros UE en el canal QoS en respuesta a la determinación, incluyendo el primer flujo de paquetes los datos de audio obtenidos y el primer subconjunto de datos de prioridad más alta que no son de audio identificado.

Description

DESCRIPCIÓN

Transferencia selectiva de datos de alta prioridad que no son de audio a través de un canal de calidad de servicio

ANTECEDENTES DE LA INVENCIÓN

1. Campo de la invención

[0001] Los modos de realización de la invención se refieren a la transferencia selectiva de datos de alta prioridad que no son de audio a través de un canal de calidad de servicio (QoS).

2. Descripción de la técnica relacionada

[0002] Los sistemas de comunicación inalámbrica se han desarrollado a través de diversas generaciones, incluyendo un servicio telefonía inalámbrica analógica de primera generación (1G), un servicio de telefonía inalámbrica digital de segunda generación (2G) (incluyendo las redes 2,5G y 2,75G intermedias) y servicios inalámbricos de tercera generación (3G) y cuarta generación (4G) de datos de alta velocidad/compatibles con internet. En la actualidad, existen muchos tipos diferentes de sistemas de comunicación inalámbrica en uso, incluyendo sistemas de servicio de comunicación personal (PCS) y celular. Ejemplos de sistemas celulares conocidos incluyen el Sistema Telefónico Móvil Avanzado (AMPS) analógico y sistemas celulares digitales basados en el Acceso Múltiple por División de Código (CDMA), en el Acceso Múltiple por División de Frecuencia (FDMA), en el Acceso Múltiple por División de Tiempo (TDMA), en el Sistema Global para el Acceso Móvil (GSM), una variante del TDMA, y sistemas híbridos de comunicación digital más nuevos que usan tanto la tecnología TDMA como la CDMA.

[0003] Más recientemente, la evolución a largo plazo (LTE) se ha desarrollado como un protocolo de comunicaciones inalámbricas para la comunicación inalámbrica de datos de alta velocidad para los teléfonos móviles y otros terminales de datos. LTE está basado en GSM e incluye contribuciones de varios protocolos relacionados con GSM, tales como velocidades de transferencia de datos mejoradas para la evolución de GSM (EDGE) y protocolos del sistema universal de telecomunicaciones móviles (UMTS), tal como el acceso a paquetes de alta velocidad (HSPA).

[0004] Los servicios de aplicaciones de usuario que implican la transmisión concurrente de voz y alguna otra forma de medios (ultrarrápida o no) se implementan típicamente enviando medios de voz como un flujo independiente separado. Esto se hace por varios motivos, incluyendo proporcionar la experiencia positiva del usuario asignando un tratamiento preferente a los paquetes de voz (por ejemplo, calidad de servicio (QoS), etc.). Cuando los paquetes de voz se transmiten simultáneamente con medios ultrarrápidos como vídeo (por ejemplo, en una videoconferencia), el flujo de vídeo típicamente se le asigna un mejor esfuerzo (BE) sin QoS. Por tanto, dependiendo de las condiciones de red, los paquetes de vídeo pueden sufrir pérdida de paquetes, fluctuación del retardo y/o retardo. Esto da como resultado en una experiencia de usuario irregular.05678

[0005] La publicación de solicitud de patente europea número EP 1 148 687 se refiere a un dispositivo de comunicación que tiene una pluralidad de flujos de medios, cada uno asociado con un tipo de medios. La publicación de solicitud de patente de Estados Unidos número US 2002/145924 se refiere a un sistema, procedimiento y artículo de fabricación para usar un componente reemplazable para seleccionar un componente de canal de comunicación de red compatible con calidad de servicio reemplazable. La publicación de solicitud de patente europea número EP 2043 372 se refiere a un procedimiento para sincronización de audio y vídeo, y un dispositivo receptor y transmisor. La publicación de solicitud de patente de los Estados Unidos número US 2007/0053445 se refiere a un sistema y procedimiento para proporcionar contenido de vídeo y algoritmos de programación y protección de errores dependientes de ocultación.

SUMARIO

[0006] La presente invención está definida en las reivindicaciones independientes adjuntas, a las cuales se debería hacer referencia.

[0007] Los rasgos característicos ventajosos están expuestos en las reivindicaciones dependientes adjuntas.

BREVE DESCRIPCIÓN DE LOS DIBUJOS

[0008] Una apreciación más completa de los modos de realización de la invención y de muchas de las ventajas intrínsecas de los mismos se obtendrá fácilmente según la misma llegue a ser mejor entendida al hacer referencia a la siguiente descripción detallada cuando se considere en relación con los dibujos adjuntos, que se presentan solamente como ilustración, y no limitación, de la invención, y en los que:

La figura 1 ilustra una arquitectura de sistema de alto nivel de un sistema de comunicaciones inalámbricas de acuerdo con un modo de realización de la invención.

La figura 2A ilustra una configuración de ejemplo de una red de acceso por radio (RAN) y una parte de conmutación de paquetes de una red central para una red 1x EV-DO de acuerdo con un modo de realización de la invención.

La figura 2B ilustra una configuración de ejemplo de la RAN y una parte de conmutación de paquetes de una red central de servicio general de paquetes vía radio (GPRS) dentro de un sistema 3G UMTS W-CDMA de acuerdo con un modo de realización de la invención.

La figura 2C ilustra otra configuración de ejemplo de la RAN y una parte de conmutación de paquetes de una red central GPRS dentro de un sistema 3G UMTS W-CDMA de acuerdo con un modo de realización de la invención.

La figura 2D ilustra una configuración de ejemplo de la RAN y una parte de conmutación de paquetes de la red central que está basada en una red de sistema de paquetes evolucionado (EPS) o evolución a largo plazo (LTE) de acuerdo con un modo de realización de la invención.

La figura 2E ilustra una configuración de ejemplo de una RAN de datos de paquete de alta velocidad de transferencia (HRPD) potenciada conectada a una red EPS o LTE y también una parte de conmutación de paquetes de una red central HRPD de acuerdo con un modo de realización de la invención.

La figura 3 ilustra ejemplos de equipos de usuario (UE) de acuerdo con los modos de realización de la invención. La figura 4 ilustra un dispositivo de comunicación que incluye lógica configurada para realizar la funcionalidad de acuerdo con un modo de realización de la invención.

La figura 5 ilustra un servidor de acuerdo con un modo de realización de la invención.

La figura 6 ilustra un proceso convencional de prestar soporte a una sesión de comunicación arbitrada por servidor con la asignación de recursos anteriormente mencionada para datos de audio y que no son de audio. La figura 7A ilustra un proceso por el cual un UE transmisor identifica y reasigna un subconjunto de datos de más alta prioridad (HP) que no son de audio desde un canal que no es de calidad de servicio (QoS) a un canal QoS para la transmisión a un UE diana durante un sesión de comunicación de acuerdo con un modo de realización de la invención.

La figura 7B ilustra una configuración de ejemplo del UE transmisor que realiza el proceso de la figura 7A de acuerdo con un modo de realización de la invención.

La figura 8A ilustra un proceso por el cual un UE diana identifica y extrae datos HP que no son de audio del canal QoS de acuerdo con un modo de realización de la invención.

La figura 8B ilustra una configuración de ejemplo del UE diana que realiza el proceso de la figura 8A de acuerdo con un modo de realización de la invención.

La figura 9 ilustra un ejemplo de implementación de las figuras 7A y 8A con respecto a una videoconferencia de acuerdo con un modo de realización de la invención.

La figura 10 ilustra un ejemplo de implementación de las figuras 7A y 8A con respecto a una audioconferencia de acuerdo con un modo de realización de la invención.

La figura 11 ilustra un ejemplo de implementación de las figuras 7A y 8A con respecto a una audioconferencia de acuerdo con otro modo de realización de la invención.

La figura 12 ilustra un proceso de ajuste a cambios de estado del canal QoS durante cualquiera de las sesiones de comunicación de la figura 7A, 8A, 9, 10 u 11 de acuerdo con un modo de realización de la invención. DESCRIPCIÓN DETALLADA

[0009] Se divulgan aspectos de la invención en la siguiente descripción y en dibujos relacionados, orientados a modos de realización específicos de la invención. Pueden concebirse modos de realización alternativos sin apartarse del alcance de la invención. Adicionalmente, no se describirán con detalle elementos bien conocidos de la invención, o se omitirán para no oscurecer los detalles pertinentes de la invención.

[0010] Las expresiones "ejemplar(es)" y/o "de ejemplo" se usan en el presente documento en el sentido de que "sirve(n) como ejemplo, caso o ilustración". No debe considerarse necesariamente que cualquier modo de realización descrito en el presente documento como "ejemplar" y/o "de ejemplo" sea preferente o ventajoso con respecto a otros modos de realización. Asimismo, el término "modos de realización de la invención" no requiere que todos los modos de realización de la invención incluyan el rasgo característico, la ventaja o el modo de funcionamiento analizados.

[0011] Además, muchos modos de realización se describen en términos de secuencias de acciones a realizar, por ejemplo, mediante elementos de un dispositivo informático. Se reconocerá que diversas acciones descritas en el presente documento se pueden realizar mediante circuitos específicos (por ejemplo, circuitos integrados específicos de la aplicación (ASIC)), mediante instrucciones de programa ejecutadas por uno o más procesadores, o mediante una combinación de ambos. Adicionalmente, se puede considerar que estas secuencias de acciones descritas en el presente documento se realizan por completo dentro de cualquier forma de medio de almacenamiento legible por ordenador que tenga almacenado en el mismo un conjunto correspondiente de instrucciones de ordenador que, tras su ejecución, provocarían que un procesador asociado realizara la funcionalidad descrita en el presente documento. Por tanto, los diversos aspectos de la invención se pueden realizar de varias formas diferentes, todas las cuales se ha contemplado que estén dentro del alcance de la materia objeto reivindicada. Además, para cada uno de los modos de realización descritos en el presente documento, la forma correspondiente de cualquiera de dichos modos de realización se puede describir en el presente documento como, por ejemplo, "lógica configurada para" realizar la acción descrita.

[0012] Un dispositivo cliente, denominado en el presente documento como equipo de usuario (UE), puede ser móvil o estacionario, y se puede comunicar con una red de acceso por radio (rA n ). Como se usa en el presente documento, el término "UE" se puede referir de manera intercambiable a un "terminal de acceso" o "AT", un "dispositivo inalámbrico", un "dispositivo de abonado", un "terminal de abonado", una "estación de abonado", un "terminal de usuario" o UT, un "terminal móvil", una "estación móvil" y variaciones de los mismos. En general, los UE se pueden comunicar con una red central por medio de la RAN, y a través de la red central los UE se pueden conectar con redes externas tales como la internet. Por supuesto, otros mecanismos de conexión a la red central y/o internet también son posibles para los UE, tales como las redes de acceso por cable, las redes wifi (por ejemplo, basadas en IEEE 802.11, etc.), y así sucesivamente. Los UE se pueden realizar mediante cualquiera de una cantidad de tipos de dispositivos, incluyendo pero sin limitarse a tarjetas de PC, dispositivos flash compactos, módems internos o externos, teléfonos inalámbricos o alámbricos, y así sucesivamente. Un enlace de comunicación a través del cual los UE pueden enviar señales a la RAN se llama canal de enlace ascendente (por ejemplo, un canal de tráfico inverso, un canal de control inverso, un canal de acceso, etc.). Un enlace de comunicación a través del cual la RAN puede enviar señales a los UE se llama canal de enlace descendente o directo (por ejemplo, un canal de radiobúsqueda, un canal de control, un canal de radiodifusión, un canal de tráfico directo, etc.). Como se usa en el presente documento, el término canal de tráfico (TCH) se puede referir a un canal de tráfico de enlace ascendente/inverso o de enlace descendente/directo.

[0013] La figura 1 ilustra una arquitectura de sistema de alto nivel de un sistema de comunicaciones inalámbricas 100 de acuerdo con un modo de realización de la invención. El sistema de comunicaciones inalámbricas 100 contiene los UE 1...N. Los UE 1...N pueden incluir teléfonos celulares, asistente digital personal (PDA), localizadores, un ordenador portátil, un ordenador de escritorio, y así sucesivamente. Por ejemplo en la figura 1, los UE 1...2 se ilustran como teléfonos de llamada celular, los UE 3...5 se ilustran como teléfonos celulares con pantalla táctil o teléfonos inteligentes, y el UE N se ilustra como un ordenador de escritorio o PC.

[0014] En referencia a la figura 1, los UE 1...N están configurados para comunicarse con una red de acceso (por ejemplo, la RAN 120, un punto de acceso 125, etc.) a través de una capa o interfaz física de comunicaciones, que se muestra en la figura 1 como las interfaces aéreas 104, 106, 108 y/o una conexión por cable directa. Las interfaces aéreas 104 y 06 pueden cumplir con un protocolo de comunicaciones celulares dado (por ejemplo, CDMA, EVDO, eHRPD, GSM, EDGE, W-CDMA, LTE, etc.), mientras que la interfaz aérea 108 puede cumplir con un protocolo IP inalámbrico (por ejemplo, IEEE 802.11). La RAN 120 incluye una pluralidad de puntos de acceso que atienden a los UE a través de interfaces aéreas, tales como las interfaces aéreas 104 y 106. Los puntos de acceso en la RAN 120 se pueden denominar nodos de acceso o AN, puntos de acceso o AP, estaciones base o BS, Nodo B, eNodo B, y así sucesivamente. Estos puntos de acceso pueden ser puntos de acceso terrestre (o estaciones terrestres) o puntos de acceso satelital. La RAN 120 está configurada para conectarse a una red central 140 que puede realizar una variedad de funciones, incluyendo unir llamadas conmutadas por circuitos (CS) entre los UE atendidos por la RAN 120 y otros UE atendidos por la RAN 120 o una RAN completamente diferente, y también puede mediar un intercambio de datos de conmutación de paquetes (PS) con redes externas tal como internet 175. El internet 175 incluye varios agentes de enrutamiento y agentes de procesamiento (que no se muestran en la figura 1 por razones de conveniencia). En la figura 1, el UE N se muestra como conectándose a internet 175 directamente (es decir, separado de la red central 140, tal como a través de una conexión Ethernet de wifi o una red basada en 802.11). El internet 175 puede de este modo funcionar para unir comunicaciones de datos por conmutación de paquetes entre el UE N y los UE 1...N por medio de la red central 140. También se muestra en la figura 1 el punto de acceso 125 que está separado de la RAN 120. El punto de acceso 125 puede estar conectado a internet 175 independientemente de la red central 140 (por ejemplo, por medio de un sistema de comunicación óptica tal como FiOS, un módem de cable, etc.). La interfaz aérea 108 puede atender al UE 4 o al UE 5 a través de una conexión inalámbrica local, tal como IEEE 802.11 en un ejemplo. El UE N se muestra como un ordenador de mesa con una conexión por cable a internet 175, tal como una conexión directa a un módem o enrutador, que puede corresponder al propio punto de acceso 125 en un ejemplo (por ejemplo, para un enrutador wifi con conectividad tanto por cable como inalámbrica).

[0015] En referencia a la figura 1, se muestra un servidor de aplicaciones 170 conectado a internet 175, la red central 140 o ambos. El servidor de aplicaciones 170 se puede implementar como una pluralidad de servidores estructuralmente separados, o de forma alternativa puede corresponder a un único servidor. Como se describirá a continuación con más detalle, el servidor de aplicaciones 170 está configurado para prestar soporte a uno o más servicios de comunicación (por ejemplo, sesiones de voz sobre protocolo de internet (VoIP), sesiones de pulsar para hablar (PTT, Push-to-Talk), sesiones de comunicación grupal, servicios de redes sociales, etc.) para los UE que se pueden conectar al servidor de aplicaciones 170 por medio de la red central 140 y/o internet 175.

[0016] Ejemplos de implementaciones específicas de protocolo para la RAN 120 y la red central 140 se proporcionan a continuación con respecto a las figuras 2A a 2D para ayudar a exponer el sistema de comunicaciones inalámbricas 100 con más detalle. En particular, los componentes de la RAN 120 y la red central 140 corresponden a componentes asociados con prestar soporte a las comunicaciones de conmutación de paquetes (PS), con lo que los componentes de conmutación de circuitos (CS) heredados también pueden estar presentes en estas redes, pero cualquier componente específico de CS heredado no se muestra explícitamente en las figuras 2A-2D.

[0017] La figura 2A ilustra una configuración de ejemplo de la RAN 120 y la red central 140 para comunicaciones de conmutación de paquetes en una red CDMA2000 1x evolución de datos optimizados (EV-DO) de acuerdo con un modo de realización de la invención. En referencia a la figura 2A, la RAN 120 incluye una pluralidad de estaciones base (BS) 200A, 205A y 210A que están acopladas a un controlador de estación de base (BSC) 215A a través de una interfaz de retorno por cable. Un grupo de BS controladas por un solo BSC se denomina conjuntamente subred. Como apreciará un experto en la técnica, la RAN 120 puede incluir múltiples BSC y subredes, y se muestra un único BSC en la figura 2A por razones de conveniencia. El BSC 215A se comunica con una función de control de paquetes (PCF) 220A dentro de la red central 140 a través de una conexión A9. La PCF 220A realiza determinadas funciones de procesamiento para el BSC 215A relacionadas con datos de paquetes. La PCF 220A se comunica con un nodo de servicio de datos por paquetes (PDSN) 225A dentro de la red central 140 a través de una conexión A11. El PDSN 225A tiene una variedad de funciones, incluyendo la gestión de sesiones punto a punto (PPP), actuando como agente local (HA) y/o agente externo (FA), y es similar en su función a un Nodo de soporte pasarela de -Servicio general de radio por paquetes (GPRS)- (Gg SN) en redes GSM y UMTS (descrito a continuación con más detalle). El PDSN 225A conecta la red central 140 a redes IP externas, tales como internet 175.

[0018] La figura 2B ilustra una configuración de ejemplo de la RAN 120 y una parte de conmutación de paquetes de la red central 140 que está configurada como una red central GPRS dentro de un sistema 3G UMTS W-CDMA de acuerdo con un modo de realización de la invención. En referencia a la figura 2B, la RAN 120 incluye una pluralidad de Nodos B 200B, 205B y 210B que están acoplados a un Controlador de Red de Radio (RNC) 215B a través de una interfaz de retorno por cable. De forma similar a redes 1x EV-DO, un grupo de Nodos B controlados por un único RNC se denomina conjuntamente una subred. Como apreciará un experto en la técnica, la RAN 120 puede incluir múltiples RNC y subredes, y se muestra un único RNC en la figura 2B por razones de conveniencia. El RNC 215B es responsable de señalar, establecer y destruir canales portadores (es decir, canales de datos) entre un nodo de soporte de servicio GPRS (SGSN) 220B en la red central 140 y los UE atendidos por la RAN 120. Si el cifrado de la capa de enlace está habilitado, el RNC 215B también cifra el contenido antes de reenviarlo a la RAN 120 para su transmisión a través de una interfaz aérea. La función del RNC 215B es bien conocida en la técnica y no se analizará adicionalmente por razones de brevedad.

[0019] En la figura 2B, la red central 140 incluye el SGSN 220B mencionado anteriormente (y potencialmente también una cantidad de otros SGSN) y un GGSN 225B. En general, GPRS es un protocolo usado en GSM para el enrutamiento de paquetes IP. La red central GPRS (por ejemplo, el GGSN 225B y uno o más SGSN 220B) es la parte centralizada del sistema GPRS y también proporciona soporte para redes de acceso 3G basadas en W-CDMA. La red central GPRS es una parte integrada de la red central GSM (es decir, la red central 140) que proporciona gestión de movilidad, gestión de sesión y transporte para servicios de paquetes IP en redes GSM y W-CDMA.

[0020] El protocolo de tunelización de GPRS (GTP) es el protocolo IP de definición de la red central GPRS. El GTP es el protocolo que permite a los usuarios finales (por ejemplo, los UE) de una red GSM o W-CDMA moverse de un lugar a otro mientras continúan conectándose a internet 175 como si fuera desde una localización en el GGSN 225B. Esto se logra transfiriendo los datos del UE respectivo desde el SGSN 220B actual del UE al GGSN 225B, que está manejando la respectiva sesión del UE.

[0021] Tres formas de GTP se usan por la red central GPRS; a saber, (i) GTP-U, (ii) GTP-C y (iii) GTP' (GTP Prime). GTP-U se usa para la transferencia de datos de usuario en túneles separados para cada contexto de protocolo de paquetes de datos (PDP). GTP-C se usa para la señalización de control (por ejemplo, configuración y deleción de contextos PDP, verificación de la capacidad de alcance GSN, actualizaciones o modificaciones, tal como cuando un abonado se mueve de un SGSN a otro, etc.). GTP' se usa para la transferencia de datos de cobro desde los GSN a una función de cobro.

[0022] En referencia a la figura 2B, el GGSN 225B actúa como una interfaz entre una red troncal GPRS (no mostrada) e internet 175. El GGSN 225B extrae datos de paquetes con un formato de protocolo de paquetes de datos (PDP) asociado (por ejemplo, IP o PPP) de paquetes GPRS provenientes del SGSN 220B, y envía los paquetes a una red de datos por paquetes correspondiente. En la otra dirección, los paquetes de datos entrantes son dirigidos por el UE conectado por GGSN al SGSN 220B que gestiona y controla el Portador de acceso por radio (RAB) de un UE diana atendido por la RAN 120. De este modo, el GGSN 225B almacena la dirección SGSN actual del UE diana y su perfil asociado en un registro de localización (por ejemplo, dentro de un contexto PDP). El GGSN 225B es responsable de la asignación de la dirección IP y es el enrutador predeterminado para un UE conectado. El GGSN 225B también realiza funciones de autenticación y cobro.

[0023] El SGSN 220B es representativo de uno de los muchos SGSN dentro de la red central 140, en un ejemplo. Cada SGSN es responsable de la entrega de paquetes de datos desde y hacia los UE dentro de un área geográfica de servicio asociada. Las tareas del SGSN 220B incluyen enrutamiento y transferencia de paquetes, gestión de movilidad (por ejemplo, gestión de anexión/separación y localización), gestión de enlace lógico y funciones de autenticación y cobro. El registro de localización del SGSN 220B almacena información de localización (por ejemplo, célula actual, VLR actual) y perfiles de usuario (por ejemplo, IMSI, dirección o direcciones PDP usadas en la red de datos por paquetes) de todos los usuarios de GPRS registrados con el SGSN 220B, por ejemplo, dentro de uno o más contextos PDP para cada usuario o UE. Por tanto, los SGSN 220B son responsables de (i) eliminar la tunelización de paquetes GTP de enlace descendente desde el GGSN 225B, (ii) paquetes IP de túnel de enlace ascendente hacia el GGSN 225B, (iii) llevar a cabo gestión de movilidad mientras los UE se mueven entre áreas de servicio SGSN y (iv) facturación de abonados móviles. Como apreciará un experto en la técnica, además de (i) -(iv), los SGSN configurados para redes GSM/EDGE tienen una funcionalidad ligeramente diferente en comparación con los SGSN configurados para redes W-CDMA.

[0024] La RAN 120 (por ejemplo, o UTRAN, en arquitectura del sistema UMTS) se comunica con el SGSN 220B por medio de un protocolo de parte de aplicación de red de acceso por radio (RANAP). RANAP opera a través de una interfaz Iu (Iu-ps), con un protocolo de transmisión tal como Frame Relay o IP. El SGSN 220B se comunica con el GGSN 225B por medio de una interfaz Gn, que es una interfaz basada en IP entre SGSN 220B y otros SGSN (no mostrados) y GGSN internos (no mostrados), y usa el protocolo GTP definido anteriormente (por ejemplo, GTP-U, GTP-C, GTP', etc.). En el modo de realización de la figura 2B, el Gn entre el SGSN 220B y el GGSN 225B lleva tanto el GTP-C como el GTP-U. Aunque no se muestra en la figura 2B, la interfaz Gn también se usa por el sistema de nombres de dominio (DNS). El GGSN 225B está conectado a una red pública de datos (PDN) (no mostrada), y a su vez a internet 175, por medio de una interfaz Gi con protocolos IP, bien directamente o a través de una pasarela de protocolo de aplicación inalámbrica (WAP).

[0025] La figura 2C ilustra otra configuración de ejemplo de la RAN 120 y una parte de conmutación de paquetes de la red central 140 que está configurada como una red central GPRS dentro de un sistema 3G UMTS W-CDMA de acuerdo con un modo de realización de la invención. De forma similar a la figura 2B, la red central 140 incluye el SGSN 220B y el GGSN 225B. Sin embargo, en la figura 2C, el túnel directo es una función opcional en el modo Iu que permite al SGSN 220B establecer un túnel de plano de usuario directo, GTP-U, entre la RAN 120 y el GGSN 225b dentro de un dominio PS. Un SGSN compatible con el túnel directo tal como SGSN 220B en la figura 2C, se puede configurar sobre una base por GGSN y por RNC, ya sea que el SGSN 220B pueda o no usar una conexión de plano de usuario directa. El SGSN 220B in la figura 2c maneja la señalización del plano de control y toma la decisión de cuándo establecer el túnel directo. Cuando se libera el RAB asignado para un contexto PDP (es decir, se conserva el contexto PDP), se establece el túnel GTP-U entre el GGSN 225B y el SGSN 220B a fin de poder manejar los paquetes del enlace descendente.

[0026] La figura 2D ilustra una configuración de ejemplo de la RAN 120 y una parte de conmutación de paquetes de la red central 140 basada en una red de sistema de paquetes evolucionado (EPS) o LTE, de acuerdo con un modo de realización de la invención. En referencia a la figura 2D, a diferencia de la RAN 120 mostrada en las figuras 2B-2C la RAN 120 en la red EPS/LTE está configurada con una pluralidad de Nodos B evolucionados (ENodoB o eNB) 200D, 205D y 210D, sin el RNC 215B de las figuras 2B-2C. Esto es porque los ENodoB en redes EPS/LTE no requieren un controlador separado (es decir, el RNC 215B) dentro de la RAN 120 para comunicarse con la red central 140. En otras palabras, parte de la funcionalidad del RNC 215B de las figuras 2B-2C está integrado en cada eNodoB respectivo de la RAN 120 en la figura 2D.

[0027] En la figura 2D, la red central 140 incluye una pluralidad de entidades de gestión de movilidad (MME) 215D y 220D, un servidor de abonado local (HSS) 225D, una pasarela de servicio (S-GW) 230D, una pasarela de red de datos por paquetes (P-GW) 235D y una función de política y reglas de cobro (PCRF) 240D. Las interfaces de red entre estos componentes, la RAN 120 e internet 175 se ilustran en la figura 2D y se definen en la Tabla 1 (a continuación) como sigue:

Tabla 1 - Definiciones de conexión de red central de EPS/LTE

[0028] Se describirá ahora una descripción de alto nivel de los componentes mostrados en la RAN 120 y la red central 140 de la figura 2D. Sin embargo, estos componentes son bien conocidos en la técnica a partir de diversas normas de 3GPP TS, y la descripción contenida en el presente documento no pretende ser una descripción exhaustiva de todas las funcionalidades realizadas por estos componentes.

[0029] En referencia a la figura 2D, las MME 215D y 220D están configuradas para gestionar la señalización del plano de control para los portadores de EPS. Las funciones de MME incluyen: Señalización de estrato de no acceso (NAS), seguridad de señalización NAS, gestión de movilidad para traspasos inter- e intra-tecnología, selección de P-GW y S-GW, y selección de MME para traspasos con cambio de m Me .

[0030] En referencia a la figura 2D, la S-GW 230D es la pasarela que termina la interfaz hacia la RAN 120. Para cada Ue asociado con la red central 140 para un sistema basado en EPS, en un punto de tiempo dado, existe una única S-GW. Las funciones de la S-GW 230D, tanto para S5/S8 basado en Gt P como en Proxy Mobile IPv6 (PMIP), incluyen: El punto de anclaje de movilidad, el enrutamiento y reenvío de paquetes, y la configuración del Punto de Código DiffServ (DSCP) en base a un identificador de clase de QoS (QCI) del portador de EPS asociado.

[0031] En referencia a la figura 2D, la P-GW 235D es la pasarela que termina la interfaz SGi hacia la red de datos por paquetes (PDN), por ejemplo, internet 175. Si un UE está accediendo a múltiples PDN, puede existir más de una P-Gw para ese UE; sin embargo, típicamente no se presta soporte a una mezcla de conectividad S5/S8 y conectividad Gn/Gp para ese UE simultáneamente. Las funciones de P-GW incluyen para ambos S5/S8 basados en GTP: Filtrado de paquetes (por inspección profunda de paquetes), asignación de direcciones IP del UE, configuración del DSCp basado en el QCI del portador de EPS asociado, contabilización para el cobro entre operadores, vinculación de portador de enlace ascendente (UL) y enlace descendente (DL) como se define en 3GPP TS 23.203, verificación de vinculación de portador de UL como se define en 3GPP TS 23.203. La P-GW 235D proporciona conectividad PDN tanto a los u E con solo red de acceso por radio GSM/EDGE (GERAN)/UTRAN como a los UE compatibles con E-UTRAN que usan cualquiera de E-UTRAN, GERAN o UTRa N. La P-Gw 235D proporciona conectividad PDN a los UE compatibles con E-UTRAN que usan E-UTRAN solo a través de la interfaz S5/S8.

[0032] En referencia a la figura 2D, la PCRF 240 es el elemento de control de políticas y cobros de la red central 140 basada en EPS. En un escenario no itinerante, existe una única PCRF en la HPLMN asociada con una sesión de la red de acceso a la conectividad del protocolo de internet (IP-CAN) del UE. La PCRF termina la interfaz Rx y la interfaz Gx. En un escenario de itinerancia con fuga local del tráfico, pueden existir dos PCRF asociadas con una sesión de IP-CAN del UE: Una PCRF doméstica (H-PCRF) es una PCRF que reside dentro de una HPLMN, y una PCRF visitada (V-PCRF) es una PCRF que reside dentro de una VPLMN visitada. La PCRF se describe con más detalle en 3GPP TS 23.203, y como tal no se describirá más en aras de la brevedad. En la figura 2D, el servidor de aplicaciones 170 (por ejemplo, que puede denominarse la AF en la terminología 3GPP) se muestra como conectado a la red central 140 por medio de internet 175, o de forma alternativa a la PCRF 240D directamente por medio de una interfaz Rx. En general, el servidor de aplicaciones 170 (o AF) es un elemento que ofrece aplicaciones que usan recursos portadores de IP con la red central (por ejemplo, recursos de dominio UMTS PS/recursos de dominio GPRS/servicios de datos LTE PS). Un ejemplo de una función de aplicación es la función de control de sesión de llamada proxy (P-CSCF) del subsistema de red central del subsistema multimedia IP (IMS). La AF usa el punto de referencia Rx para proporcionar información de sesión a la PCRF 240D. Cualquier otro servidor de aplicaciones que ofrezca servicios de datos IP a través de una red celular también se puede conectar a la PCRF 240D por medio del punto de referencia Rx.

[0033] La figura 2E ilustra un ejemplo de la RAN 120 configurada como una RAN de datos de paquete de alta velocidad potenciada (HRPD) conectada a una red EPS o LTE 140A y también una parte de conmutación de paquetes de una red central de HRPD 140B de acuerdo con un modo de realización de la invención. La red central 140A es una red central EPS o LTE, similar a la red central descrita anteriormente con respecto a la figura 2D.

[0034] En la figura 2E, la RAN eHRPD incluye una pluralidad de estaciones transceptoras base (BTS) 200E, 205E y 210E, que están conectadas a un b Sc potenciado (eBSC) y una PCF potenciada (ePCF) 215E. El eBSC/ePCF 215E se puede conectar a una de las MME 215D o 220D dentro de la red central e Ps 140a a través de una interfaz S101, y a una pasarela de servicio HRPD (HSGW) 220E a través de las interfaces A10 y/o A11 para interactuar con otras entidades en el red central EPS 140A (por ejemplo, la S-GW 220D a través de una interfaz S103, la P-GW 235D a través de una interfaz S2a, la PCRF 240D a través de una interfaz Gxa, un servidor 3GPP AAA (no mostrado explícitamente en la figura 2D a través de una interfaz STa, etc.). La HSGW 220E se define en 3GPP2 para proporcionar el interfuncionamiento entre redes HRPD y redes EPS/LTE. Como se apreciará, la RAN eHRPD y la HSGW 220E están configurados con una funcionalidad de interfaz para las redes EPC/LTE que no está disponible en las redes HRPD heredadas.

[0035] Volviendo a la RAN eHRPD, además de interactuar con la red EPS/LTE 140A, la RAN eHRPD también puede interactuar con redes HRPD heredadas tal como la red HRPD 140B. Como se apreciará, la red HRPD 140B es una implementación de ejemplo de una red HRPD heredada, tal como la red EV-DO de la figura 2A. Por ejemplo, la eBSC/ePCF 215E puede interactuar con un servidor de autenticación, autorización y contabilización (AAA) 225E por medio de una interfaz A12, o con un PDSN/FA 230E por medio de una interfaz A10 o A11. El PDSN/FA 230E a su vez se conecta al HA 235A, a través del cual se puede acceder a internet 175. En la figura 2E, determinadas interfaces (por ejemplo, A13, A16, HI, H2, etc.) no se describen explícitamente, pero se muestran en aras de una información completa y se entenderían por un experto en la técnica familiarizado con HRPD o eHRPD.

[0036] En referencia a las figuras 2B-2E, se apreciará que las redes centrales LTE (por ejemplo, la figura 2D) y las redes centrales HRPD que interactúan con las RAN eHRPD y HSGW (por ejemplo, la figura 2E) pueden prestar soporte a la calidad de servicio (QoS) iniciada por la red (por ejemplo, por la P-GW, GGSN, SGSN, etc.) en determinados casos.

[0037] La figura 3 ilustra ejemplos de los UE de acuerdo con modos de realización de la invención. En referencia a la figura 3, el UE 300A se ilustra como un teléfono de llamada y el UE 300B se ilustra como un dispositivo de pantalla táctil (por ejemplo, un teléfono inteligente, un ordenador de tableta, etc.). Como se muestra en la figura 3, una carcasa externa del UE 300A está configurada con una antena 305A, una pantalla de visualización 310A, al menos un botón 315A (por ejemplo, un botón PTT, un botón de encendido, un botón de control de volumen, etc.) y un teclado 320A, entre otros componentes, como se conoce en la técnica. Además, una carcasa externa del UE 300B está configurada con una pantalla táctil 305B, botones periféricos 310B, 315B, 320B y 325B (por ejemplo, un botón de control de encendido, un botón de control de volumen o vibración, un botón de conmutación de la modalidad de avión, etc.), al menos un botón de panel frontal 330B (por ejemplo, un botón de inicio, etc.), entre otros componentes, como se conoce en la técnica. Si bien no se muestran explícitamente como parte del UE 300B, el UE 300B puede incluir una o más antenas externas y/o una o más antenas integradas que están incorporadas en la carcasa externa del UE 300B, incluyendo, pero sin limitarse a, antenas wifi, antenas celulares, antenas del sistema de posicionamiento satelital (SPS) (por ejemplo, antenas del sistema de posicionamiento global (GPS)), etc.

[0038] Si bien los componentes internos de los UE tales como los UE 300A y 300B se pueden realizar con diferentes configuraciones de hardware, una configuración básica de alto nivel de UE para los componentes de hardware internos se muestra como la plataforma 302 en la figura 3. La plataforma 302 puede recibir y ejecutar aplicaciones de programas informáticos, datos y/o comandos transmitidos desde la RAN 120 que pueden provenir en última instancia de la red central 140, internet 175 y/u otros servidores y redes remotos (por ejemplo, el servidor de aplicaciones 170, URL de internet, etc.). La plataforma 302 también puede ejecutar independientemente aplicaciones almacenadas de forma local sin interacción con la RAN. La plataforma 302 puede incluir un transceptor 306 acoplado de forma operativa a un circuito integrado para aplicaciones específicas (ASIC) 308 u otro procesador, microprocesador, circuito lógico u otro dispositivo de procesamiento de datos. El ASIC 308 u otro procesador ejecuta la capa de interfaz de programación de aplicaciones (API) 310 que interactúa con cualquier programa que resida en la memoria 312 del dispositivo inalámbrico. La memoria 312 puede comprender una memoria de acceso aleatorio o de solo lectura (RAM y ROM), una memoria EEPROM, tarjetas flash o cualquier memoria común a plataformas informáticas. La plataforma 302 puede incluir también una base de datos local 314 que puede almacenar aplicaciones no usadas de forma activa en la memoria 312, así como otros datos. La base de datos local 314 es típicamente una célula de memoria flash, pero puede ser cualquier dispositivo de almacenamiento secundario conocido en la técnica, tal como medios magnéticos, EEPROM, medios ópticos, cinta, disco flexible o duro o similares.

[0039] Por consiguiente, un modo de realización de la invención puede incluir un UE (por ejemplo, el UE 300A, 300B, etc.) que incluya la capacidad de realizar las funciones descritas en el presente documento. Como apreciarán los expertos en la técnica, los diversos elementos lógicos pueden realizarse en elementos discretos, en módulos de programas informáticos ejecutados en un procesador o en cualquier combinación de programas informáticos y hardware para lograr la funcionalidad divulgada en el presente documento. Por ejemplo, el ASIC 308, la memoria 312, la API 310 y la base de datos local 314 se pueden usar, todos, de forma cooperativa para cargar, almacenar y ejecutar las diversas funciones divulgadas en el presente documento y, por tanto, la lógica para realizar estas funciones se puede distribuir a través de diversos elementos. De forma alternativa, la funcionalidad se podría incorporar a un componente discreto. Por lo tanto, los rasgos característicos de los UE 300A y 300B en la figura 3 se han de considerar meramente ilustrativas y la invención no se limita a los rasgos característicos o disposición ilustrados.

[0040] La comunicación inalámbrica entre los UE 300A y/o 300B y la RAN 120 puede estar basado en tecnologías diferentes, tales como CDMA, W-CDMA, acceso múltiple por división de tiempo (TDMA), acceso múltiple por división de frecuencia (FDMA), multiplexación por división ortogonal de frecuencia (OFDM), GSM u otros protocolos que se puedan usar en una red de comunicaciones inalámbrica o en una red de comunicaciones de datos. Como se ha analizado en lo que precede y conocido en la técnica, las transmisiones de voz y/o datos se pueden transmitir a los UE desde la rA n usando una variedad de redes y configuraciones. En consecuencia, las ilustraciones proporcionadas en el presente documento no pretenden limitar los modos de realización de la invención y son meramente para ayudar en la descripción de los aspectos de los modos de realización de la invención.

[0041] La figura 4 ilustra un dispositivo de comunicación 400 que incluye la lógica configurada para realizar la funcionalidad. El dispositivo de comunicación 400 puede corresponder a cualquiera de los dispositivos de comunicación mencionados anteriormente, incluyendo pero sin limitarse al UE 300A o 300B, cualquier componente de la RAN 120 (por ejemplo, BS 200A a 210A, BSC 215A, Nodos B 200B a 210B, RNC 215B, eNodoB 200D a 210D, etc.), cualquier componente de la red central 140 (por ejemplo, PCF 220A, PDSN 225A, SGSN 220B, GGSN 225B, MME 215D o 220D, HSS 225D, S-GW 230D, P-GW 235D, PCRF 240D), cualesquiera componentes acoplados con la red central 140 y/o internet 175 (por ejemplo, el servidor de aplicaciones 170), y así sucesivamente. Por tanto, el dispositivo de comunicación 400 puede corresponder a cualquier dispositivo electrónico que esté configurado para comunicarse con (o facilitar la comunicación con) una o más otras entidades diferentes a través del sistema de comunicaciones inalámbricas 100 de la figura 1.

[0042] En referencia a la figura 4, el dispositivo de comunicación 400 incluye lógica configurada para recibir y/o transmitir información 405. En un ejemplo, si el dispositivo de comunicación 400 corresponde a un dispositivo de comunicaciones inalámbrica (por ejemplo, el UE 300A o 300B, uno de los BS 200A a 210A, uno de los nodos B 200B a 210B, uno de los eNodoB 200D a 210D, etc.), la lógica configurada para recibir y/o transmitir información 405 puede incluir una interfaz de comunicación inalámbrica (por ejemplo, Bluetooth, WiFi, 2G, CDMA, W-CDMA, 3G, 4G, LTE, etc.) tal como un transceptor inalámbrico y un hardware asociado (por ejemplo, una antena RF, un MÓDEM, un modulador y/o desmodulador, etc.). En otro ejemplo, la lógica configurada para recibir y/o transmitir información 405 puede corresponder a una interfaz de comunicaciones por cable (por ejemplo, una conexión en serie, una conexión USB o Firewire, una conexión de Ethernet a través de la cual se pueda acceder a internet 175, etc.). Por tanto, si el dispositivo de comunicación 400 corresponde a algún tipo de servidor basado en la red (por ejemplo, PDSN, SGSN, GGSN, S-GW, P-GW, MME, HSS, PCRF, la aplicación 170, etc.), la lógica configurada para recibir y/o transmitir la información 405 puede corresponder a una tarjeta de Ethernet, en un ejemplo, que conecte el servidor basado en la red con otras entidades de comunicación por medio de un protocolo de Ethernet.

En otro ejemplo, la lógica configurada para recibir y/o transmitir información 405 puede incluir hardware sensorial o de medición, por el cual el dispositivo de comunicación 400 pueda monitorizar su entorno local (por ejemplo, un acelerómetro, un sensor de temperatura, un sensor de luz, una antena para monitorizar señales de Rf locales, etc.). La lógica configurada para recibir y/o transmitir información 405 puede incluir también programas informáticos que, cuando se ejecuten, permitan al hardware asociado, de la lógica configurada para recibir y/o transmitir información 405, realizar su función o funciones de recepción y/o transmisión. Sin embargo, la lógica configurada para recibir y/o transmitir información 405 no corresponde solamente a programas informáticos, y la lógica configurada para recibir y/o transmitir la información 405 se basa, al menos en parte, en el hardware para lograr su funcionalidad.

[0043] En referencia a la figura 4, el dispositivo de comunicación 400 incluye, además, lógica configurada para procesar información 410. En un ejemplo, la lógica configurada para procesar información 410 puede incluir al menos un procesador. Los ejemplos de implementaciones del tipo de procesado que se puede realizar mediante la lógica configurada para procesar información 410 incluyen, sin limitarse a, realizar determinaciones, establecer conexiones, hacer selecciones entre diferentes opciones de información, realizar evaluaciones referidas a los datos, interactuar con sensores acoplados al dispositivo de comunicación 400 para realizar operaciones de medición, convertir la información de un formato a otro (por ejemplo, entre protocolos diferentes tales como .wmv a .avi, etc.), y así sucesivamente. Por ejemplo, el procesador incluido en la lógica configurada para procesar información 410 puede corresponder a un procesador de propósito general, a un procesador de señales digitales (DSP), a un ASIC, a un arreglo de compuertas programable en el campo (FPGA) o a otro dispositivo de lógica programable, a lógica de transistores o de compuertas discretas, a componentes de hardware discretos o a cualquier combinación de los mismos diseñada para realizar las funciones descritas en el presente documento. Un procesador de propósito general puede ser un microprocesador pero, como alternativa, el procesador puede ser cualquier procesador, controlador, microcontrolador o máquina de estados convencional. Un procesador también se puede implementar como una combinación de dispositivos informáticos, por ejemplo, una combinación de un DSP y un microprocesador, una pluralidad de microprocesadores, uno o más microprocesadores junto con un núcleo de DSP o cualquier otra configuración de este tipo. La lógica configurada para procesar información 410 también puede incluir programas informáticos que, cuando se ejecuten, permitan al hardware asociado, de la lógica configurada para procesar información 410, realizar su función o sus funciones de procesamiento. Sin embargo, la lógica configurada para procesar información 410 no corresponde solamente a programas informáticos, y la lógica configurada para procesar información 410 se basa al menos en parte, en el hardware para lograr su funcionalidad.

[0044] En referencia a la figura 4, el dispositivo de comunicación 400 incluye, además, lógica configurada para almacenar información 415. En un ejemplo, la lógica configurada para almacenar información 415 puede incluir al menos una memoria no transitoria y hardware asociado (por ejemplo, un controlador de memoria, etc.). Por ejemplo, la memoria no transitoria incluida en la lógica configurada para almacenar información 415 puede corresponder a una memoria RAM, a una memoria flash, a una memoria ROM, a una memoria EPROM, a una memoria EEPROM, a registros, a un disco duro, a un disco extraíble, a un CD-ROM o a cualquier otro medio de almacenamiento conocido en la técnica. La lógica configurada para almacenar información 415 puede incluir también programas informáticos que, cuando se ejecuten, permitan al hardware asociado, de la lógica configurada para almacenar información 415, realizar su función o sus funciones de almacenamiento. Sin embargo, la lógica configurada para almacenar información 415 no corresponde solamente a programas informáticos, y la lógica configurada para almacenar información 415 se basa al menos en parte, en el hardware para lograr su funcionalidad.

[0045] En referencia a la figura 4, el dispositivo de comunicación 400 además incluye opcionalmente lógica configurada para presentar información 420. En un ejemplo, la lógica configurada para presentar información 420 puede incluir al menos un dispositivo de salida y hardware asociado. Por ejemplo, el dispositivo de salida puede incluir un dispositivo de salida de vídeo (por ejemplo, una pantalla de visualización, un puerto que pueda llevar información de vídeo, tal como USB, HDMI, etc.), un dispositivo de salida de audio (por ejemplo, altavoces, un puerto que pueda llevar información de audio, tal como un conector de micrófono, USB, HDMI, etc.), un dispositivo de vibración y/o cualquier otro dispositivo por el cual se pueda formatear la información para su envío o pueda de hecho ser enviada por un usuario u operador del dispositivo de comunicación 400. Por ejemplo, si el dispositivo de comunicación 400 corresponde al UE 300A o al UE 300B, como se muestra en la figura 3, la lógica configurada para presentar información 420 puede incluir la pantalla de visualización 310A del UE 300A o la pantalla táctil 305B del UE 300B. En otro ejemplo, la lógica configurada para presentar la información 420 se puede omitir para determinados dispositivos de comunicación, tales como los dispositivos de comunicación de red que no tengan un usuario local (por ejemplo, conmutadores de red o enrutadores, servidores remotos, etc.). La lógica configurada para presentar información 420 puede incluir también programas informáticos que, cuando se ejecuten, permitan al hardware asociado, de la lógica configurada para presentar información 420, realizar su función o sus funciones de presentación. Sin embargo, la lógica configurada para presentar información 420 no corresponde solamente a programas informáticos y la lógica configurada para presentar información 420 se basa, al menos en parte, en hardware para lograr su funcionalidad.

[0046] En referencia a la figura 4, el dispositivo de comunicación 400 además incluye opcionalmente lógica configurada para recibir la entrada de usuario local 425. En un ejemplo, la lógica configurada para recibir entrada de usuario local 425 puede incluir al menos un dispositivo de entrada de usuario y hardware asociado. Por ejemplo, el dispositivo de entrada de usuario puede incluir botones, una pantalla táctil, un teclado, una cámara, un dispositivo de entrada de audio (por ejemplo, un micrófono o un puerto que pueda llevar información de audio, tal como un conector de micrófono, etc.), y/o cualquier otro dispositivo mediante el cual se pueda recibir información desde un usuario u operador del dispositivo de comunicación 400. Por ejemplo, si el dispositivo de comunicación 400 corresponde al UE 300A o al UE 300B como se muestra en la figura 3, la lógica configurada para recibir la entrada de usuario local 425 puede incluir el teclado 320A, cualquiera de los botones 315A o 310B a 325B, la pantalla táctil 305B, etc. En otro ejemplo, la lógica configurada para recibir la entrada de usuario local 425 se puede omitir para determinados dispositivos de comunicación, tales como los dispositivos de comunicación de red que no tienen un usuario local (por ejemplo, conmutadores o enrutadores de red, servidores remotos, etc.). La lógica configurada para recibir la entrada de usuario local 425 puede incluir también programas informáticos que, cuando se ejecuten, permitan al hardware asociado, de la lógica configurada recibir la entrada de usuario local 425, realizar su función o sus funciones de recepción de entrada. Sin embargo, la lógica configurada para recibir la entrada de usuario local 425 no corresponde solamente a programas informáticos y la lógica configurada para recibir la entrada de usuario local 425 se basa, al menos en parte, en el hardware para lograr su funcionalidad.

[0047] En referencia a la figura 4, mientras que las lógicas configuradas de 405 a 425 se muestran como bloques separados o distintos en la figura 4, se apreciará que el hardware y/o programas informáticos mediante los cuales la lógica configurada respectiva realiza su funcionalidad pueden superponerse en parte. Por ejemplo, cualquier programa informático usado para facilitar la funcionalidad de las lógicas configuradas de 405 a 425 se puede almacenar en la memoria no transitoria asociada con la lógica configurada para almacenar información 415, de modo que cada una de las lógicas configuradas de 405 a 425 realiza su funcionalidad (es decir, en este caso, la ejecución de programas informáticos) basada en parte en el funcionamiento de programas informáticos almacenados por la lógica configurada para almacenar información 415. Asimismo, el hardware que está directamente asociado con una de las lógicas configuradas se puede prestar a, o se puede usar por, otras lógicas configuradas de vez en cuando. Por ejemplo, el procesador de la lógica configurada para procesar información 410 puede formatear datos en un formato adecuado antes de transmitirse mediante la lógica configurada para recibir y/o transmitir información 405, de tal manera que la lógica configurada para recibir y/o transmitir información 405 realice su funcionalidad (es decir, en este caso, la transmisión de datos) basándose parcialmente en el funcionamiento del hardware (es decir, el procesador) asociado con la lógica configurada para procesar información 410.

[0048] En general, a menos que se establezca de otro modo de forma explícita, la frase "lógica configurada para" como se usa en toda esta divulgación, pretende invocar un modo de realización que se implementa, al menos parcialmente, con hardware, y no pretende aplicarse a implementaciones solo de programas informáticos que son independientes del hardware. También se apreciará que la lógica configurada o la "lógica configurada para" en los diversos bloques no está limitada a compuertas o elementos lógicos específicos, sino que se refieren en general a la capacidad de realizar la funcionalidad descrita en el presente documento (bien por medio de hardware o una combinación de hardware y programas informáticos). Por tanto, las lógicas configuradas o la "lógica configurada para", como se ilustra en los diversos bloques, no se implementan necesariamente como compuertas lógicas o elementos lógicos, a pesar de compartir la palabra "lógica". Otras interacciones u otra cooperación entre la lógica en los diversos bloques se tornarán evidentes para un experto en la técnica, a partir de una revisión de los modos de realización descritos a continuación con más detalle.

[0049] Los diversos modos de realización también se pueden implementar en cualquiera de una variedad de dispositivos de servidor disponibles comercialmente, tal como el servidor 500 ilustrado en la figura 5. En un ejemplo, el servidor 500 puede corresponder a una configuración de ejemplo del servidor de aplicaciones 170 descrito anteriormente. En la figura 5, el servidor 500 incluye un procesador 500 acoplado a la memoria volátil 502 y una memoria no volátil de gran capacidad, tal como una unidad de disco 503. El servidor 500 también puede incluir una unidad de disco flexible, una unidad de disco compacto (CD) o una unidad de disco DVD 506 acoplada al procesador 501. El servidor 500 también puede incluir puertos de acceso a la red 504 acoplados al procesador 501 para establecer conexiones de datos con una red 507, tal como una red de área local acoplada a otros ordenadores y servidores del sistema de radiodifusión o a internet. En contexto con la figura 4, se apreciará que el servidor 500 de la figura 5 ilustra una implementación de ejemplo del dispositivo de comunicación 400, con lo que la lógica configurada para transmitir y/o recibir información 405 corresponde a los puertos de acceso a la red 504 usados por el servidor 500 para comunicarse con la red 507, la lógica configurada para procesar información 410 corresponde al procesador 501, y la configuración lógica para almacenar información 415 corresponde a cualquier combinación de la memoria volátil 502, la unidad de disco 503 y/o la unidad de disco 506. La lógica opcional configurada para presentar la información 420 y la lógica opcional configurada para recibir la entrada de usuario local 425 no se muestran explícitamente en la figura 5 y pueden o no estar incluidas en el mismo. Por tanto, la figura 5 ayuda a demostrar que el dispositivo de comunicación 400 puede implementarse como un servidor, además de una implementación de UE como en 305A o 305B como en la figura 3.

[0050] Los servicios de aplicaciones de usuario que implican la transmisión concurrente de voz y alguna otra forma de medios (ultrarrápida o no) se implementan típicamente enviando medios de voz como un flujo independiente separado. Esto se hace por varias razones, incluyendo la provisión de experiencia de usuario positiva asignando un tratamiento preferente, tal como QoS, a los paquetes de voz. Cuando los paquetes de voz se transmiten simultáneamente con medios ultrarrápidos como el vídeo, al flujo de vídeo típicamente se le asigna un mejor esfuerzo (BE) sin QoS. Por tanto, dependiendo de las condiciones de red, los paquetes de vídeo pueden sufrir pérdida de paquetes, fluctuación del retardo y/o retardo. Esto da como resultado en una experiencia de usuario irregular.

[0051] Como se usa en el presente documento, un "canal QoS" se usa para referirse a un enlace de comunicación de QoS a través de cualquier tipo de red (por ejemplo, un portador GBR QoS en LTE, un canal de tráfico (TCH) con QoS reservado por medio de un mensaje RonR en EV-DO, etc.), y se usa un "canal que no es QoS" para referirse a un enlace de comunicación sin QoS a través de cualquier tipo de red (por ejemplo, un portador no GBR predeterminado en LTE, un TCH sin QoS reservado en EV-DO, etc.) Además, en determinadas configuraciones de red (por ejemplo, EV-DO como en la figura 2A, UMTS/W-CDMA como en las figuras 2B-2C, etc.), la RAN 120 es responsable de asignar la QoS usada por los UE, y en otras configuraciones de red (por ^{ejemplo, LTE como en la figura 2D, etc.), la red central 140 es responsable de asignar la QoS usada por los}Ue. En consecuencia, la referencia a una "RAN-red central", indicada en las figuras respectivas como RAN/red central 120/140, se usa para referirse a una entidad en cualquier tipo de red que atiende a los UE y es responsable de asignar QoS a los mismos.

[0052] En las redes LTE como un ejemplo, los datos de audio (por ejemplo, medios de voz) se llevan típicamente a través de un portador dedicado con una determinada GBR o QoS. Los datos que no son de audio (por ejemplo, archivos o vídeo) pueden esperar el mismo tratamiento, pero sus requisitos de velocidad de bits pueden ser más altos en este caso. Por lo tanto, es poco probable que a un UE se le pueda asignar GBR suficiente para manejar todos sus datos de audio y que no son de audio para la sesión. La figura 6 ilustra un proceso convencional de prestar soporte a una sesión de comunicación arbitrada por servidor con la asignación de recursos anteriormente mencionada para datos de audio y que no son de audio.

[0053] En referencia a la figura 6, el servidor de aplicaciones 170 configura una sesión de comunicación entre al menos los UE 1 y 2, 600. En un ejemplo, la sesión de comunicación (por ejemplo, una llamada PTT, una llamada VoIP, etc.) también puede incluir uno o más UE adicionales, en cuyo caso la sesión de comunicación es una sesión de comunicación grupal. Junto con la configuración de la sesión de comunicación, la RAN/red central que atiende al UE 1 asigna y/o mantiene un canal que no es QoS para prestar soporte a las transferencias de datos que no son de audio del UE 1 para la sesión de comunicación, 605, y la RAN/red central que atiende al UE 1 también asigna un canal QoS para prestar soporte a las transferencias de datos de audio del UE 1 para la sesión de comunicación, 610. De forma similar, junto con la configuración de la sesión de comunicación, la RAN/red central que atiende al UE 2 asigna y/o mantiene un canal que no es QoS para prestar soporte a las transferencias de datos que no son de audio del UE 2 para la sesión de comunicación, 615 y la RAN/red central que atiende al UE 2 también asigna un canal QoS para prestar soporte a las transferencias de datos de audio del UE 2 para la sesión de comunicación, 620. En un ejemplo, en 605 o 615, si UE 1 y/o UE 2 han establecido previamente el canal que no es QoS (por ejemplo, un portador no GBR predeterminado en LTE), el canal preestablecido que no es QoS simplemente se puede mantener sin que se asignen nuevos recursos a UE 1 y/o UE 2 para prestar soporte a transferencias de datos que no son de audio para la sesión de comunicación. El resto de la figura 6 proporciona una ilustración de dos tipos distintos de datos que no son de audio (es decir, datos de vídeo y datos de archivo) que se pueden enviar a través del canal que no es QoS durante la sesión de comunicación.

[0054] En referencia a la figura 6, durante la sesión de comunicación, el UE 1 obtiene datos de audio y vídeo para su transmisión al UE 2, 625. De este modo, el UE 1 transmite un primer flujo de paquetes que llevan los datos de audio que se obtienen en 625 a través del canal QoS asignado en 610, 630, y un segundo flujo de paquetes que llevan los datos de vídeo que se obtienen en 625 a través del canal que no es QoS 610, 635. Como se apreciará, determinados tipos de datos de vídeo tienen un mayor impacto en el rendimiento de reproducción de vídeo que otros tipos de datos de vídeo. Por ejemplo, las tramas I o cortes I intermitentes son tramas de vídeo relativamente importantes que ayudan a calibrar la reproducción de vídeo. En la figura 6, supóngase que uno o más paquetes en el segundo flujo de paquetes que llevan una o más tramas I se pierden en algún punto durante la transferencia debido al menos en parte a la falta de QoS en el canal que no es QoS, 640. En consecuencia, el UE 2 recibe el primer y el segundo flujo de paquetes y reproduce los datos de audio y vídeo respectivos contenidos en ellos, 645. Sin embargo, en 645, la pérdida de la(s) trama(s) I de 640 provoca la degradación de la calidad del vídeo que se reproduce por UE 2.

[0055] En referencia a la figura 6, durante la sesión de comunicación, el UE 1 obtiene un archivo cifrado que está configurado para ser descifrado (o desbloqueado) con una clave de descifrado para su transmisión al UE 2, 650. De este modo, el UE 1 transmite tanto el archivo cifrado como su clave de descifrado asociada dentro del segundo flujo de paquetes a través del canal que no es QoS desde 610, 655. En la figura 6, supóngase que uno o más paquetes en el segundo flujo de paquetes que llevan la clave de descifrado se pierden en algún punto entre la RAN/red central que atiende al UE 2 y el servidor de aplicaciones 170 debido al menos en parte a la falta de QoS en el canal que no es QoS, 660. En consecuencia, en 665, el UE 2 recibe el segundo flujo de paquetes en 655 con el archivo cifrado, pero UE 2 no puede descifrar el archivo cifrado porque la clave de descifrado se perdió en 660.

Por tanto, aunque todo el archivo cifrado se transfirió con éxito, la pérdida de la clave de descifrado hace que el archivo cifrado quede inutilizable.

[0056] Como se apreciará, mientras que el canal que no es QoS se usa en la figura 6 porque típicamente no está disponible QoS suficiente para manejar tanto los datos de audio como los que no son de audio, las pérdidas de determinados datos que no son de audio de prioridad más alta (por ejemplo, claves de descifrado, tramas I, información de encabezado, etc.) en el canal que no es QoS puede provocar una degradación desproporcionadamente alta de la experiencia del usuario en el UE diana en comparación con los datos que no son de audio de prioridad más baja (por ejemplo, tramas B, archivos cifrados en masa, etc.). En consecuencia, los modos de realización de la invención se dirigen a identificar un subconjunto de datos que no son de audio de prioridad más alta (HP) y asignar los datos que no son de audio HP al canal QoS en lugar de al canal que no es QoS, mientras que cualesquiera otros datos que no son de audio de prioridad más baja (LP) restantes (si están presentes) pueden permanecer en el canal que no es QoS. De este modo, los datos HP que no son de audio se pueden sumar y/o intercalar con los datos de audio que se llevan en el canal QoS durante la sesión de comunicación (por ejemplo, en momentos en que el canal QoS se está infrautilizando) y los datos HP que no son de audio se pueden marcar para que el UE diana pueda distinguir entre los datos HP que no son de audio y los datos de audio en el canal QoS. Estos aspectos se analizan con mayor detalle a continuación con respecto a las figuras 7A a 12.

[0057] La figura 7A ilustra un proceso mediante el cual un UE transmisor identifica y reasigna un subconjunto de datos HP que no son de audio desde un canal que no es QoS a un canal QoS para su transmisión a un UE diana durante una sesión de comunicación de acuerdo con un modo de realización de la invención. En referencia a la figura 7A, el UE transmisor obtiene datos de audio y que no son de audio para su transmisión al UE diana, 700A. Los datos de audio y que no son de audio obtenidos en 700A no necesariamente se deben obtener contemporáneamente en un ejemplo (aunque esto es ciertamente posible). Por ejemplo, los datos que no son de audio (por ejemplo, un archivo, vídeo ultrarrápido, etc.) se pueden obtener o capturar durante una pausa en la transmisión de audio, tal como cuando un usuario de la transmisión está en silencio, cuando el UE transmisor no hace uso de la palabra en una sesión semidúplex y/o cuando el UE transmisor está silenciado.

[0058] En 705A, el UE transmisor determina qué canales están disponibles actualmente para la transmisión de los datos de audio y que no son de audio, 705A. En particular, en el modo de realización de la figura 7A, se supone que el UE transmisor tendrá acceso al canal que no es QoS durante toda la sesión de comunicación, pero que el canal QoS puede o no estar disponible. Por ejemplo, el canal QoS puede no estar disponible durante un período de tiempo durante la configuración de la sesión de comunicación, o el canal QoS se puede asignar y luego retirarse y reconvertirse por la red. En 705A, si el UE transmisor determina que actualmente tiene acceso al canal que no es QoS y no al canal QoS, el UE transmisor envía los datos de audio y que no son de audio a través del canal que no es QoS usando un protocolo de mejor esfuerzo (BE), 710A. De otro modo, en 705A, si el UE transmisor determina que actualmente tiene acceso tanto al canal que no es QoS como al canal QoS, en lugar de simplemente asignar los datos de audio al canal QoS y asignar los datos que no son de audio al canal que no es QoS como en la figura 6, el UE transmisor evalúa los datos que no son de audio para identificar si los datos que no son de audio incluyen un primer subconjunto de datos HP que no son de audio y (opcionalmente) un segundo subconjunto de datos LP que no son de audio, 715A. Con respecto a la figura 7, la evaluación de 715A puede identificar si los datos que no son de audio incluyen tanto el primer y el segundo subconjuntos de datos LP y HP que no son de audio, o de forma alternativa que los datos que no son de audio incluyen solo datos LP que no son de audio (por ejemplo, ninguno de los datos que no son de audio son particularmente importantes) o solo los datos HP que no son de audio (por ejemplo, los datos que no son de audio corresponden a un archivo que tiene alta prioridad en su totalidad).

[0059] Muchos tipos diferentes de datos que no son de audio se pueden calificar potencialmente como datos HP que no son de audio. Como se usa en el presente documento, los datos HP que no son de audio se definen como datos que no son de audio con suficiente prioridad para desencadenar la entrega en el canal QoS en lugar del canal que no es QoS, mientras que los datos LP que no son de audio se definen como datos que no son de audio sin suficiente prioridad para desencadenar la entrega en el canal QoS en lugar del canal que no es QoS, incluso cuando el canal QoS está disponible. La Tabla 2 (a continuación) muestra ejemplos específicos de datos que no son de audio que se pueden calificar como datos HP que no son de audio en el contexto del proceso de la figura 7A:

Tabla 2: Ejemplos de datos HP que no son de audio

[0060] En referencia a la figura 7A, basado en la evaluación en 715A, el UE transmisor determina si se han identificado datos HP que no son de audio, 720A. Si el UE transmisor determina que no se han identificado datos HP que no son de audio en 720A, los datos de audio se envían a través del canal QoS y los datos que no son de audio se envían a través del canal que no es QoS, 725A (por ejemplo, similar a 630 y 635 en la figura 6). De forma alternativa, si el UE transmisor determina que los datos HP que no son de audio se identifican en 720A, el UE transmisor determina si se transmiten los datos HP que no son de audio identificados a través del canal QoS en lugar del canal que no es QoS, 730A.

[0061] En referencia a la figura 7A, la lógica de decisión de 730A se puede basar en una regla de asignación de canales. En un ejemplo, la regla de asignación de canales puede indicar al UE transmisor que transmita todos los datos HP que no son de audio identificados a través del canal QoS (es decir, independientemente de un nivel de utilización en el canal QoS). De forma alternativa, la regla de asignación de canales puede indicar al UE transmisor que transmita cualquier dato HP que no es audio identificado a través del canal QoS solo si se está infrautilizando el canal QoS. Por ejemplo, es probable que el canal QoS sea altamente utilizado si un usuario del UE transmisor ^{está hablando y el}Ue ^{transmisor está transmitiendo activamente audio al UE diana. Sin embargo, el tráfico de voz}es típicamente de naturaleza a ráfagas, de modo que se puede inferir una baja utilización si la actividad de voz es baja (o si el UE transmisor no tiene uso de la palabra para una llamada semidúplex). Como se describirá con más detalle con respecto a la figura 7B a continuación, se puede notificar a un motor de decisión con respecto al nivel de actividad de voz actual para facilitar la regla de asignación de canal que desencadena los datos HP que no son de audio a través del canal QoS. Si el UE transmisor determina no transmitir los datos HP que no son de audio identificados a través del canal QoS en 730A, los datos audio se envían a través del canal QoS y los datos que no son de audio (por ejemplo, los datos HP que no son de audio y cualesquiera datos LP que no son de audio) se envían a través del canal que no es QoS, 725A (por ejemplo, similar a 630 y 635 en la figura 6). De forma alternativa, si el UE transmisor determina transmitir los datos HP que no son de audio identificados a través del canal QoS en 730A, el proceso avanza a 735A.

[0062] En 735A, el UE transmisor transmite un primer flujo de paquetes a través del canal QoS, con lo que el primer flujo de paquetes incluye tanto (i) los datos de audio obtenidos en 700A, como (ii) los datos HP que no son de audio identificados en 715A. Como se analiza anteriormente, los datos HP que no son de audio identificados se pueden insertar en el primer flujo de paquetes durante un período donde la utilización de audio o voz en el canal QoS es baja, de modo que la transmisión del 735A puede incluir principalmente los datos de audio (por ejemplo, durante una alta utilización de audio en el canal QoS) por un período de tiempo y puede incluir principalmente los datos HP que no son de audio durante otro período de tiempo (por ejemplo, durante una baja utilización de audio en el canal QoS). Por tanto, la proporción de los datos de audio con respecto a los datos HP que no son de audio puede variar, y en determinados momentos se puede asociar con una transmisión exclusiva de los datos de audio o los datos HP que no son de audio dentro del primer flujo de paquetes.

[0063] Además, junto con la transmisión de 735A, el UE transmisor puede marcar los paquetes dentro del primer flujo de paquetes para identificar qué paquetes transportan los datos de audio y qué paquetes transportan los datos HP que no son de audio para permitir que el UE diana asocie correctamente datos de audio y datos HP que no son de audio dentro del primer flujo de paquetes. Por ejemplo, el marcado se puede lograr añadiendo una bandera a los encabezados de los paquetes que llevan los datos Hp que no son de audio, añadiendo una bandera a los encabezados de los paquetes que llevan los datos de audio, o ambos. También es posible que determinados paquetes 'híbridos' (por ejemplo, paquetes RTP) incluyan algunos datos de audio y algunos datos HP que no son de audio. En este caso, los paquetes híbridos se pueden marcar para indicar su estado híbrido o, de forma alternativa, las tramas de audio y de HP que no son audio individuales dentro de los paquetes híbridos se pueden marcar para indicar su asociación con audio o HP no audio sobre una base específica de la trama. En otro ejemplo, el marcado de paquetes se puede implementar para paquetes RTP asignando un tipo de carga útil especial en el encabezado r Tp para datos que no son de audio (por ejemplo, datos de vídeo, etc.) de modo que los paquetes que no son de audio en el primer flujo de paquetes pueden utilizar el canal QoS usando la misma sesión RTP que los datos de audio a la vez que todavía indican su estado de no audio al UE diana. En un ejemplo alternativo, el marcado de paquetes se puede implementar para paquetes RTP por medio de un encabezado de extensión RTP para los paquetes que no son de audio dentro del primer flujo de paquetes, de modo que los paquetes que no son de audio pueden usar la misma sesión RTP que los datos de audio a la vez que todavía indican su estado de no audio al UE diana.

[0064] En 740A, el UE transmisor también transmite opcionalmente un segundo flujo de paquetes que incluye al menos el segundo subconjunto de datos LP que no son de audio. La transmisión de 740A es opcional porque los datos HP que no son de audio identificados pueden incluir potencialmente la totalidad de los datos que no son de audio obtenidos en 700A (por ejemplo, véase el ejemplo #3 de transferencia de archivos de la tabla 2, visto anteriormente). Sin embargo, si los datos HP que no son de audio corresponden solo a una parte de los datos que no son de audio obtenidos en 700A, cualquier dato LP que no es de audio restante se puede transmitir dentro del segundo flujo de paquetes en 740A. También, en otro ejemplo, los datos HP que no son de audio que se transmiten en el primer flujo de paquetes a través del canal QoS en 735A también se pueden transmitir de forma redundante a través del canal que no es QoS en 740A.

[0065] La figura 7B ilustra una configuración de ejemplo del UE transmisor de acuerdo con un modo de realización de la invención. En particular, la figura 7B ilustra el proceso de la figura 7A implementándose sobre la configuración de UE asociada usando el protocolo de transporte en tiempo real (RTP) donde los datos de audio son datos de voz.

[0066] En referencia a la figura 7B, una capa de aplicación 700B del UE transmisor incluye una fuente que no es de audio 705B, una fuente de audio 710B, un motor de decisión 715B, un módulo de detección de actividad de voz 720B, un módulo de paquetización RTP que no es de audio 725B y un módulo de paquetización RTP de voz 730B. La fuente que no es de audio 705B (por ejemplo, una aplicación cliente configurada para capturar vídeo o para identificar archivos para transferir, etc.) proporciona datos que no son de audio (por ejemplo, vídeo, archivos, etc.) al motor de decisión 715B y también al módulo de paquetización RTP que no es de audio 725B por medio de la interfaz 1 (por ejemplo, como en 700A de la figura 7A). La fuente de audio 710B (por ejemplo, una aplicación cliente configurada para capturar audio o gestionar sesiones de audio, que puede ser la misma que la fuente que no es de audio 705B en un ejemplo) proporciona datos de audio al módulo de detección de actividad de voz 720B y también al módulo de paquetización RTP de voz 730B por medio de las interfaces 2 y 3, respectivamente (por ejemplo, como en 700A de la figura 7A).

[0067] El módulo de detección de actividad de voz 720B analiza los datos de audio de la interfaz 2 y determina si un nivel umbral de actividad de voz está presente en los datos de audio. El módulo de detección de actividad de voz 720B notifica al motor de decisión 715B si se supera el nivel umbral de actividad de voz por medio de la interfaz 4. En el modo de realización de la figura 4, supóngase que el motor de decisión 715B decide mover datos HP que no son de audio desde el canal que no es QoS al canal QoS basado en una indicación del módulo de detección de actividad de voz 720B que indica que se supera el nivel umbral de actividad de voz (por ejemplo, como en 730A de la figura 7A). En consecuencia, el motor de decisión 715B identifica cualquier dato que no es de audio en los datos que no son de audio recibidos a través de la interfaz 1 (por ejemplo, como en 715A y 720A de la figura 7A) e le indica al módulo de paquetización RTP que no es de audio 725B, por medio de la interfaz 5 que reenvíe los datos HP que no son de audio identificados al módulo de paquetización RTP de voz 730B por medio de la interfaz 6. Mientras tanto, el motor de decisión 715B también notifica al módulo de detección de actividad de voz 720B que los datos HP que no son de audio se paquetizarán junto con los datos de audio en el canal QoS, y el módulo de detección de actividad de voz 720B reenvía esta información al módulo de paquetización RTP de voz 730B por medio de la interfaz 7. El módulo de paquetización RTP que no es de audio 725b paquetiza los datos LP que no son de audio y envía los datos LP que no son de audio paquetizados a una pila IP 735B por medio de la interfaz 8. El módulo de paquetización RTP que no es de audio 725b paquetiza tanto los datos de audio como los datos HP que no son de audio y envía los datos de audio y los datos h P que no son de audio paquetizados a la pila IP 735B por medio de la interfaz 9. La pila IP 735B entrega los datos de audio paquetizados, los datos de HP que no son de audio y los datos de LP que no son de audio a un módulo de plantilla de flujo de tráfico de enlace ascendente (TFT) 740B por medio de la interfaz 10. El módulo TFT de enlace ascendente 740B transmite un primer flujo de paquetes que incluye los datos de audio paquetizados y los datos HP que no son de audio por medio del canal QoS o la interfaz 11 (por ejemplo, como en 735A de la figura 7A), y el módulo TFT de enlace ascendente 740B también transmite un segundo flujo de paquetes que incluye los datos LP que no son de audio paquetizados por medio del canal que no es QoS o la interfaz 12 (como en 740A de la figura 7a ).

[0068] La figura 8A ilustra un proceso por el cual un UE diana identifica y extrae datos HP que no son de audio del canal QoS de acuerdo con un modo de realización de la invención. En particular, la figura 8A ilustra el funcionamiento del UE diana cuando el UE transmisor transmite los datos HP que no son de audio por medio del canal QoS en 735A de la figura 7A.

[0069] En referencia a la figura 8A, supóngase que tanto el canal que no es QoS como el canal QoS entre los UE diana y transmisor están activos. Bajo este supuesto, el UE diana recibe un primer flujo de paquetes a través del canal QoS, 800A, con lo que el primer flujo de paquetes corresponde al primer flujo de paquetes transmitidos por el UE transmisor en 735A de la figura 7A. El UE diana también recibe opcionalmente un segundo flujo de paquetes, 805A, con lo que el segundo flujo de paquetes corresponde al segundo flujo de paquetes opcionalmente transmitido por el UE transmisor en 740A de la figura 7A. Como se indica anteriormente, la recepción de 805A es opcional porque los datos HP que no son de audio identificados pueden incluir la totalidad de los datos que no son de audio obtenidos en 700A de la figura 7A (por ejemplo, véase el ejemplo #3 de transferencia de archivos de la tabla 2, visto anteriormente). Sin embargo, si los datos HP que no son de audio corresponden solo a una parte de los datos que no son de audio obtenidos en 700A de la figura 7A, cualquier dato LP que no es de audio restante se puede recibir dentro del segundo flujo de paquetes en 800A. También en otro ejemplo, los datos HP que no son de audio recibidos en el primer flujo de paquetes a través del canal QoS en 800A también se pueden recibir de manera redundante a través del canal que no es QoS en 805A como parte del segundo flujo de paquetes.

[0070] En referencia a la figura 8A, el UE diana evalúa el primer conjunto de paquetes para identificar un primer conjunto de paquetes que llevan los datos de audio para la sesión de comunicación y un segundo conjunto de paquetes que llevan los datos HP que no son de audio para la sesión de comunicación, 810A. Por ejemplo, como se analiza anteriormente con respecto a la figura 7A, el UE transmisor puede marcar cualquier paquete Hp que no es de audio con banderas para facilitar que el UE diana distinga entre el primer y el segundo conjuntos de paquetes dentro del primer flujo de paquetes en el canal QoS. El UE diana puede a continuación identificar estas banderas en 810A para extraer el primer y el segundo conjuntos de paquetes. En consecuencia, en 815A, el UE diana extrae el primer y el segundo conjuntos de paquetes del primer flujo de paquetes. El UE diana reproduce el audio del primer conjunto de paquetes extraído, 820A, y el UE diana también procesa los datos HP que no son de audio del segundo conjunto de paquetes extraído junto con cualesquiera datos LP que no son de audio del segundo flujo de paquetes, 825A. Por ejemplo, si los datos LP y HP que no son de audio corresponden a datos de vídeo, el procesamiento que se produce en 825A puede incluir la fusión de los datos de vídeo LP y HP recibidos en los canales no QoS y QoS, respectivamente, y a continuación reproducir el vídeo fusionado junto con la reproducción del audio en 820A. En otro ejemplo, si los datos LP y HP que no son de audio corresponden a un archivo cifrado y una clave de descifrado, respectivamente, el procesamiento que se produce en 825A puede incluir descifrar el archivo cifrado usando la clave de cifrado.

[0071] La figura 8B ilustra una configuración de ejemplo del UE diana de acuerdo con un modo de realización de la invención. En particular, la figura 8B ilustra el proceso de la figura 8A implementándose sobre la configuración de UE asociada usando RTP donde los datos de audio son datos de voz. El UE diana en la figura 8B incluye un módulo TFT de enlace descendente 800B, una pila IP 805B y una capa de aplicación 810B. La capa de aplicación 810B incluye un módulo de despaquetización RTP que no es de audio 815B, un módulo de despaquetización RTP de voz 820B, un descodificador que no es de audio 825B y un descodificador de audio 830B.

[0072] En referencia a la figura 8B, el módulo TFT de enlace descendente 800B recibe el primer flujo de paquetes con los datos de audio y los datos HP que no son de audio por medio del canal QoS (o la interfaz 1) (por ejemplo, como en 800A de la figura 8A), y el módulo TFT de enlace descendente 800B también recibe los datos LP que no son de audio por medio del canal que no es QoS (o la interfaz 2) (por ejemplo, como en 805A de la figura 8A). El módulo TFT de enlace descendente 800B reenvía el primer y segundo flujos de paquetes a la pila IP 805B por medio de la interfaz 3. La pila IP 805B reenvía el primer flujo de paquetes al módulo de despaquetización RTP de voz 820B por medio de la interfaz 4, y la pila 805B reenvía el segundo flujo de paquetes al módulo de despaquetización RTP que no es de audio 815B por medio de la interfaz 5. El módulo de despaquetización RTP que no es de audio 815B despaquetiza el segundo flujo de paquetes y reenvía el segundo flujo de paquetes despaquetizados al descodificador que no es de audio 825B por medio de la interfaz 6. El módulo de despaquetización RTP de voz 820B identifica, dentro del flujo de paquetes, un primer conjunto de paquetes que llevan los datos de audio y un segundo conjunto de paquetes que llevan los datos HP que no son de audio (por ejemplo, basado en las marcas de paquetes como se analiza anteriormente). El módulo de despaquetización RTP 820B despaquetiza el primer y el segundo conjuntos de paquetes del primer flujo de paquetes (por ejemplo, como en 815A de la figura 8A), y a continuación reenvía el primer conjunto de paquetes despaquetizado al descodificador de audio 830B por medio de la interfaz 7 y reenvía el segundo conjunto de paquetes despaquetizado al descodificador que no es de audio 825B por medio de la interfaz 8. El descodificador de audio 830B descodifica el primer conjunto de paquetes despaquetizado para facilitar la reproducción de los datos de audio, mientras que el descodificador que no es de audio 825B descodifica el segundo flujo de paquetes despaquetizado y el primer conjunto de paquetes despaquetizado para facilitar el procesamiento de datos LP y HP que no son de audio (por ejemplo, como en 825A de la figura 8A).

[0073] La figura 9 ilustra un ejemplo de implementación de las figuras 7A y 8A con respecto a una videoconferencia de acuerdo con un modo de realización de la invención. En la figura 9, el UE 1 corresponde al UE transmisor de la figura 7A y el UE 2 corresponde al UE diana de la figura 8A. 900 a 920 de la figura 9 corresponden sustancialmente a 600 a 620 de la figura 6 y no se describirán más por razones de brevedad.

[0074] En referencia a la figura 9, bajo el supuesto de que los datos que no son de audio obtenidos en 700A son datos de vídeo que incluyen datos de vídeo Hp y datos de vídeo LP, el UE 1 ejecuta 700A, 705A, 715A, 720A y 730A de la figura 7A en 925. En este punto, en lugar de transmitir los datos de audio a través del canal QoS y transmitir todos los datos de vídeo a través del canal que no es QoS como en 630 y 635 de la figura 6, el UE 1 transmite los datos de audio y los datos de vídeo HP a través del canal QoS, 930 (por ejemplo, como en 735A de la figura 7A), y el UE 1 transmite los datos de vídeo LP a través del canal que no es QoS, 935 (por ejemplo, como en 740A de la figura 7A). En particular, supóngase que los datos de vídeo HP incluyen una o más tramas I, que a diferencia de 640 de la figura 6, no se pierden en el proceso de la figura 9 porque los datos de vídeo HP se envían por medio del canal QoS en lugar del canal que no es QoS, 945. A continuación, en 950, el UE 2 ejecuta 800A a 815A de la figura 8A. El UE 2 a continuación reproduce el audio y el vídeo recibido a través del primer y segundo flujos de paquetes en los canales QoS y no QoS, 955 (por ejemplo, como en 820A y 825A de la figura 8a ), con lo que la reproducción de vídeo no experimenta los errores analizados anteriormente con respecto a 645 de la figura 6 porque la trama I en la figura 9 se transfiere sin error por medio del canal QoS.

[0075] La figura 10 ilustra un ejemplo de implementación de las figuras 7A y 8A con respecto a una audioconferencia de acuerdo con un modo de realización de la invención. En la figura 10, el UE 1 corresponde al UE transmisor de la figura 7A y el UE 2 corresponde al UE diana de la figura 8A. 1000 a 1020 de la figura 10 corresponden sustancialmente a 600 a 620 de la figura 6 y no se describirán más por razones de brevedad.

[0076] En referencia a la figura 10, bajo el supuesto de que los datos que no son de audio obtenidos en 700A son un paquete de archivos que incluye un archivo cifrado como los datos LP que no son de audio y una clave de descifrado como los datos Hp que no son de audio, el UE 1 ejecuta 700A, 705A, 715A, 720A y 730a de la figura 7A en 1025. En este punto, en lugar de transmitir los datos de audio a través del canal QoS y transmitir todo el paquete de archivos a través del canal que no es QoS como en 655 de la figura 6, el UE 1 transmite los datos de audio y la clave de descifrado a través del canal QoS, 1030 (por ejemplo, como en 735A de la figura 7A), y el UE 1 transmite el archivo cifrado a través del canal que no es QoS, 1035 (por ejemplo, como en 740A de la figura 7A). Por lo tanto, a diferencia de 655 de la figura 6, la clave de descifrado no se pierde en el proceso de la figura 10 porque la clave de descifrado se envía por medio del canal QoS en lugar del canal que no es QoS, 1040. A continuación, en 1045, el UE 2 ejecuta 800A a 815A de la figura 8A. El UE 2 a continuación reproduce el audio recibido a través del primer flujo de paquetes en el canal QoS, 1050 (por ejemplo, como en 820A de la figura 8A), y el UE 2 también descifra el archivo cifrado basado en la clave de descifrado, 1055 (por ejemplo, como en 825A de la figura 8A).

[0077] Como se apreciará, la figura 10 corresponde a una implementación de ejemplo basada en el ejemplo #2 de transferencia de archivos de la tabla 2 (visto anteriormente), con lo cual los datos HP que no son de audio corresponden a una clave de descifrado para descifrar un archivo cifrado asociado. En este caso, tanto el archivo cifrado como la clave de descifrado se deben transmitir al UE 2 para que el UE 2 pueda descifrar el archivo cifrado. En una alternativa a la figura 10, el proceso de la figura 10 se puede modificar ligeramente para atenerse al aspecto de imagen en miniatura del ejemplo #2 de transferencia de archivos de la tabla 2 (visto anteriormente) con lo cual los datos HP que no son de audio se generan específicamente basado en la disponibilidad del canal QoS y no se enviarían de otro modo si solo estuviera disponible el canal que no es QoS. En otras palabras, se puede transferir un archivo de imagen relativamente grande en el canal que no es QoS, y si el canal QoS se considera disponible (y no se está utilizando por completo), se puede generar una imagen en miniatura basada en la imagen de archivo grande y transmitirla en el canal QoS como datos HP que no son de audio para que el UE 2 pueda cargar rápidamente la imagen en miniatura mientras el UE 2 espera para recibir el archivo de imagen grande en el canal que no es QoS, más lento. De este modo, los datos HP que no son de audio no corresponden necesariamente a un subconjunto de los datos que no son de audio que se obtienen para la transmisión en el canal QoS, pero en al menos un modo de realización se pueden configurar para complementar o potenciar los datos LP que no son de audio para escenarios donde el canal QoS está disponible.

[0078] Mientras que las figuras 9 y 10 están dirigidos a implementaciones de los procesos de las figuras 7A y 8A con lo que los datos HP que no son de audio se envían junto con datos LP que no son de audio, también es posible que los datos que no son de audio en su totalidad se consideren HP, en cuyo caso los datos HP que no son de audio se pueden enviar sin ningún dato LP que no es de audio adjunto (por ejemplo, véase el ejemplo #3 de transferencia de archivos de la tabla 2, visto anteriormente). Con esto en mente, a figura 11 ilustra un ejemplo de implementación de las figuras 7A y 8A con respecto a una audioconferencia de acuerdo con otro modo de realización de la invención. En la figura 11, el UE 1 corresponde al UE transmisor de la figura 7A y el UE 2 corresponde al UE diana de la figura 8A. 1100 a 1120 de la figura 11 corresponden sustancialmente a 600 a 620 de la figura 6 y no se describirán más por razones de brevedad.

[0079] En referencia a la figura 11, bajo el supuesto de que los datos que no son de audio obtenidos en 700A son un pequeño paquete de archivos HP independiente, el UE 1 ejecuta 700A, 705A, 715A, 720A y 730A de la figura 7A en 1125. El UE 1 transmite los datos de audio y la totalidad del pequeño paquete de archivos HP independiente a través del canal QoS, 1130 (por ejemplo, como en 735A de la figura 7A), y el UE 1 no transmite ninguna parte del pequeño paquete de archivos HP independiente a través del canal que no es QoS (por ejemplo, el 740A opcional de la figura 7A no se realiza, aunque es posible que los datos no relacionados con el pequeño paquete de archivos HP independiente se envíen a través del canal que no es QoS y/o, de forma alternativa, que el pequeño paquete de archivos HP independiente se envía de forma redundante en el canal que no es QoS). A continuación, en 1135, el UE 2 ejecuta 800A a 815A de la figura 8A. El UE 2 a continuación reproduce el audio recibido a través del primer flujo de paquetes en el canal QoS, 1140 (por ejemplo, como en 820A de la figura 8A), y el UE 2 también procesa el pequeño paquete de archivos HP independiente, 1145 (por ejemplo, como en 825A de la figura 8A).

[0080] Mientras que las figuras 9, 10 y 11 están dirigidos a implementaciones de los procesos de las figuras 7A y 8A con lo que se supone que el canal QoS está disponible durante toda la sesión de comunicación, también es posible que el canal QoS no esté disponible (o que esté inactivo) durante al menos una parte de la sesión de comunicación. Por ejemplo, el canal QoS puede no estar disponible durante un período de tiempo durante la configuración de la sesión de comunicación, o el canal QoS se puede asignar y luego retirarse y reconvertirse por la red. Por lo tanto, el estado del canal QoS puede ser potencialmente algo variable o impredecible durante la sesión de comunicación, como se muestra a continuación con respecto a la figura 12.

[0081] En referencia a la figura 12, supóngase que cualquiera de las sesiones de comunicación mencionadas anteriormente de las figuras 7A a 11 está activa, y que un estado actual de sesión QoS corresponde a un canal que no es de QoS activo y un canal QoS inactivo, 1200. En otras palabras, en 1200, el UE 1 no tiene acceso al canal QoS para su sesión de comunicación con el UE 2. Con esto en mente, el UE 1 ejecuta 700A, 705A y 710A de la figura 7A y transmite tanto los datos de audio como los que no son de audio para la sesión de comunicación a través del canal que no es QoS, 1205. El UE 2 recibe tanto los datos de audio como los que no son de audio para la sesión de comunicación a través del canal que no es QoS, reproduce los datos de audio recibidos y procesa los datos no son de audio recibidos, 1210.

[0082] En algún punto posterior durante la sesión de comunicación, supóngase que el UE 1 experimenta a una transición de estado de sesión QoS que establece el estado actual de la sesión QoS en un canal que no es QoS activo y un canal QoS activo, 1215. Por ejemplo, la transición de estado de sesión QoS se puede desencadenar por la RAN/red central que otorga QoS al UE 1 durante la configuración de la llamada, otorgando la RAN/red central QoS al UE 1 durante una fase de llamada entrante de la sesión de comunicación, y así sucesivamente. En este punto, el UE 1 tiene acceso al canal QoS para su sesión de comunicación con el UE 2. Con esto en mente, el UE 1 ejecuta 700A, 705A, 715A, 720A, 730A y 735A de la figura 7A y transmite los datos de audio y HP que no son de audio para la sesión de comunicación a través del canal QoS, 1220. El UE 1 también puede ejecutar 740A de la figura 7A para transmitir los datos LP que no son de audio al UE 2 a través del canal que no es QoS, 1225. El UE 2 recibe los datos de audio y HP que no son de audio a través del canal QoS y (opcionalmente) recibe los datos LP que no son de audio a través del canal que no es QoS, de modo que el UE 2 ejecuta 800A y 815A a 820A, con lo que el UE 2 reproduce los datos de audio recibidos y procesa los datos HP que no son de audio recibidos, 1230 (por ejemplo, y potencialmente los datos LP que no son de audio también si se ejecutan 805A y 825A de la figura 8A).

[0083] En algún punto posterior durante la sesión de comunicación, supóngase que el UE 1 experimenta otra transición de estado de sesión QoS que restablece el estado de sesión QoS actual a un canal que no es QoS activo y un canal QoS inactivo, 1235 (por ejemplo, similar al estado de sesión QoS de 1200). Por ejemplo, la transición de estado de sesión QoS se puede desencadenar por la RAN/red central retirando una asignación previa de QoS al UE 1 durante una fase de llamada entrante de la sesión de comunicación, y así sucesivamente. En respuesta a la transición del estado de sesión QoS de 1235, el proceso vuelve a 1205.

[0084] Si bien los modos de realización de la invención descritas anteriormente se refieren principalmente a sesiones de comunicación arbitradas por el servidor, se apreciará que otros modos de realización de la invención pueden corresponder a sesiones que no son arbitradas por un servidor externo a la red del operador, tales como las sesiones arbitradas por la red de operadores por sí misma, sesiones P2P o sesiones a través de una red de malla, y así sucesivamente. Además, los expertos en la técnica apreciarán que la información y las señales pueden representarse usando cualquiera entre una variedad de tecnologías y técnicas diferentes. Por ejemplo, los datos, las instrucciones, los comandos, la información, las señales, los bits, los símbolos y chips que pueden haber sido mencionados a lo largo de la descripción anterior, pueden representarse mediante tensiones, corrientes, ondas electromagnéticas, campos o partículas magnéticos, campos o partículas ópticos, o cualquier combinación de los mismos.

[0085] Además, los expertos en la técnica apreciarán que los diversos bloques lógicos, módulos, circuitos y etapas de algoritmo ilustrativos, descritos en relación con los modos de realización divulgados en el presente documento, pueden implementarse como hardware electrónico, programas informáticos o combinaciones de ambos. Para ilustrar claramente esta intercambiabilidad de hardware y software, anteriormente se han descrito diversos componentes, bloques, módulos, circuitos y etapas ilustrativos en lo que respecta, en general, a su funcionalidad. Que dicha funcionalidad se implemente como hardware o software depende de la aplicación particular y las restricciones de diseño impuestas al sistema completo. Los expertos en la técnica pueden implementar la funcionalidad descrita de formas variadas para cada aplicación particular, pero no debería interpretarse que dichas decisiones de implementación suponen apartarse del alcance de la presente invención.

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

[0087] Los procedimientos, las secuencias y/o los algoritmos descritos en relación con los modos de realización divulgados en el presente documento se pueden realizar directamente en hardware, en un módulo de programa informático ejecutado por un procesador o en una combinación de los dos. Un módulo de programa informático puede residir en memoria RAM, memoria flash, memoria ROM, memoria EPROM, memoria EEPROM, registros, un disco duro, un disco extraíble, un CD-ROM o en cualquier otra forma de medio de almacenamiento conocida en la técnica. Un medio de almacenamiento ejemplar está acoplado al procesador de modo que el procesador pueda leer información de, y escribir información en, el medio de almacenamiento. De forma alternativa, el medio de almacenamiento puede estar integrado en el procesador. El procesador y el medio de almacenamiento pueden residir en un ASIC. El ASIC puede residir en un terminal de usuario (por ejemplo, un UE). De forma alternativa, el procesador y el medio de almacenamiento pueden residir como componentes discretos en un terminal de usuario.

[0088] En uno o más de los modos de realización ejemplares, las funciones descritas se pueden implementar en hardware, programas informáticos, firmware o cualquier combinación de los mismos. Si se implementan en programas informáticos, las funciones se pueden almacenar en, o transmitir por, un medio legible por ordenador como una o más instrucciones o código. Los medios legibles por ordenador incluyen tanto medios de almacenamiento informático como medios de comunicación, incluyendo cualquier medio que facilite la transferencia de un programa informático desde un lugar a otro. Un medio de almacenamiento puede ser cualquier medio disponible al que se pueda acceder mediante un ordenador. A modo de ejemplo, y no de manera limitativa, dichos medios legibles por ordenador pueden comprender RAM, ROM, EEPROM, CD-ROM u otro almacenamiento de disco óptico, almacenamiento de disco magnético u otros dispositivos de almacenamiento magnético, o cualquier otro medio que se pueda usar para llevar o almacenar código de programa deseado en forma de instrucciones o estructuras de datos y al que se pueda acceder mediante un ordenador. También cualquier conexión recibe adecuadamente la denominación de medio legible por ordenador. Por ejemplo, si el programa informático se transmite desde un sitio web, un servidor u otra fuente remota, usando un cable coaxial, un cable de fibra óptica, un par trenzado, una línea digital de abonado ("DSL") o tecnologías inalámbricas tales como infrarrojos, radio y microondas, entonces el cable coaxial, el cable de fibra óptica, el par trenzado, la DSL o las tecnologías inalámbricas, tales como infrarrojos, radio y microondas, se incluyen en la definición de medio. Los discos, como se usan en el presente documento, incluyen el disco compacto (CD), el disco láser, el disco óptico, el disco versátil digital (DVD), el disco flexible y el disco Blu-ray, donde algunos discos reproducen habitualmente los datos magnéticamente, mientras que otros discos reproducen los datos ópticamente con láseres. Las combinaciones de lo anterior se deberían incluir también dentro del alcance de los medios legibles por ordenador.

[0089] Si bien la divulgación precedente muestra modos de realización ilustrativos de la invención, cabe destacar que diversos cambios y modificaciones se podrían hacer en el presente documento sin apartarse del alcance de la invención, como se define en las reivindicaciones adjuntas. Las funciones, etapas y/o acciones de las reivindicaciones de procedimiento, de acuerdo a los modos de realización de la invención, descritos en el presente documento, no necesitan realizarse en ningún orden particular. Además, aunque los elementos de la invención se puedan describir o reivindicar en singular, se contempla el plural a menos que se indique explícitamente la limitación al singular.

Claims

REIVINDICACIONES

i . Un procedimiento de hacer funcionar un equipo de usuario, UE, que participa en una sesión de comunicación con uno o más otros UE, que comprende:

obtener (700A) datos de audio y datos que no son de audio para su transmisión a uno o más otros UE durante la sesión de comunicación, en el que se presta soporte a la sesión de comunicación en el UE al menos en parte por medio de un canal de calidad de servicio, QoS, canal en el que el tráfico de audio se lleva principalmente y caracterizado por que se presta soporte a la sesión de comunicación en el UE al menos en parte por medio de un canal que no es QoS en el que se lleva tráfico que no es de audio;

además caracterizado por identificar (715A) un primer subconjunto de datos de prioridad más alta que no son de audio dentro de los datos que no son de audio obtenidos;

detectar un nivel de utilización en el canal QoS durante la sesión de comunicación;

determinar (730A) transmitir el primer subconjunto de datos de prioridad más alta que no son de audio identificado a través del canal QoS en lugar del canal que no es QoS basado al menos en parte en la identificación mientras el nivel de utilización está por debajo de un umbral; y

transmitir (735A) un primer flujo de paquetes al uno o más otros UE en el canal QoS en respuesta a la determinación, incluyendo el primer flujo de paquetes los datos de audio obtenidos y el primer subconjunto de datos de prioridad más alta que no son de audio identificado.
2. El procedimiento de la reivindicación 1, en el que la identificación también identifica un segundo subconjunto de datos de prioridad más baja que no son de audio dentro de los datos que no son de audio obtenidos que está asociado con el primer subconjunto de datos de prioridad más alta que no son de audio identificado.
3. El procedimiento de la reivindicación 2, que comprende además:

transmitir (740A) un segundo flujo de paquetes al uno o más otros UE en el canal que no es QoS, incluyendo el segundo flujo de paquetes al menos el segundo subconjunto de datos de prioridad más baja que no son de audio identificado.
4. El procedimiento de la reivindicación 1, en el que la detección detecta el nivel de utilización basado en un nivel de actividad de voz detectado por el UE y/o un estado de tener el uso de la palabra del UE si la sesión de comunicación es semidúplex.
5. El procedimiento de la reivindicación 1, en el que la transmisión incluye marcar qué paquetes dentro del primer flujo de paquetes incluyen el primer subconjunto de datos de prioridad más alta que no son de audio identificado para permitir que uno o más otros UE distingan entre un primer conjunto de paquetes dentro del primer flujo de paquetes que incluye los datos de audio obtenidos y un segundo conjunto de paquetes dentro del primer flujo de paquetes que incluye datos que no son de audio del primer subconjunto de datos de prioridad más altano son de audio identificado.
6. El procedimiento de la reivindicación 1,

en el que el canal QoS no está disponible durante al menos una parte de la sesión de comunicación, que comprende además:

enviar los datos de audio y el primer subconjunto de datos de prioridad más alta que no son de audio identificado dentro de un segundo flujo de paquetes al uno o más otros UE en el canal que no es QoS mientras el canal QoS no esté disponible.
7. El procedimiento de la reivindicación 6,

en el que la parte de la sesión de comunicación donde el canal QoS no está disponible se produce durante la configuración de la sesión de comunicación,

que comprende además:

detectar la activación del canal QoS en algún punto durante o después de la configuración de la sesión de comunicación; y pasar de la etapa de envío a las etapas de determinación y transmisión en respuesta a la activación detectada del canal QoS.
8. El procedimiento de la reivindicación 6, que comprende además:

detectar la desactivación del canal QoS en algún punto durante una fase de llamada entrante de la sesión de comunicación; y

pasar de las etapas de determinación y transmisión a la etapa de envío en respuesta a la desactivación detectada del canal QoS.
9. Un equipo de usuario, UE, configurado para participar en una sesión de comunicación con uno o más otros UE, que comprende:

medios para obtener datos de audio y datos que no son de audio para su transmisión a uno o más otros UE durante la sesión de comunicación, en el que se presta soporte a la sesión de comunicación en el UE al menos en parte por medio de un canal de calidad de servicio, QoS, canal en el que el tráfico de audio se lleva principalmente y caracterizado por que se presta soporte a la sesión de comunicación en el UE al menos en parte por medio de un canal que no es QoS en el que se lleva tráfico que no es de audio;

caracterizado además por identificar un subconjunto de datos de prioridad más alta que no son de audio dentro de los datos que no son de audio obtenidos;

medios para detectar un nivel de utilización en el canal QoS durante la sesión de comunicación; medios para determinar transmitir el subconjunto de datos de prioridad más alta que no son de audio identificado a través del canal QoS en lugar del canal que no es QoS basado al menos en parte en la identificación mientras el nivel de utilización está por debajo de un umbral; y

medios para transmitir un flujo de paquetes al uno o más otros UE en el canal QoS en respuesta a la determinación, incluyendo el flujo de paquetes los datos de audio obtenidos y el subconjunto de datos de prioridad más alta que no son de audio identificado.
10. Un medio legible por ordenador no transitorio que contiene instrucciones almacenadas en el mismo, que, cuando se ejecutan por un equipo de usuario, UE, configurado para participar en una sesión de comunicación con uno o más otros UE, provoca que el UE realice todos las etapas del procedimiento de acuerdo con cualquiera de las reivindicaciones 1 a 8.