ES2749222T3 - Terminal y procedimiento de selección de modo de codificación - Google Patents

Terminal y procedimiento de selección de modo de codificación Download PDF

Info

Publication number
ES2749222T3
ES2749222T3 ES11840382T ES11840382T ES2749222T3 ES 2749222 T3 ES2749222 T3 ES 2749222T3 ES 11840382 T ES11840382 T ES 11840382T ES 11840382 T ES11840382 T ES 11840382T ES 2749222 T3 ES2749222 T3 ES 2749222T3
Authority
ES
Spain
Prior art keywords
codec
communication
terminal
mode
codec mode
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES11840382T
Other languages
English (en)
Inventor
Takako Hori
Hiroyuki Ehara
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Intellectual Property Corp of America
Original Assignee
Panasonic Intellectual Property Corp of America
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Panasonic Intellectual Property Corp of America filed Critical Panasonic Intellectual Property Corp of America
Application granted granted Critical
Publication of ES2749222T3 publication Critical patent/ES2749222T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/08—Protocols for interworking; Protocol conversion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/24—Negotiation of communication capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H04W28/18—Negotiating wireless communication parameters
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0083—Determination of parameters used for hand-off, e.g. generation or modification of neighbour cell lists
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0083—Determination of parameters used for hand-off, e.g. generation or modification of neighbour cell lists
    • H04W36/00837—Determination of triggering parameters for hand-off
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/12—Setup of transport tunnels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/04—Large scale networks; Deep hierarchical networks
    • H04W84/042—Public Land Mobile systems, e.g. cellular systems
    • H04W84/045—Public Land Mobile systems, e.g. cellular systems using private Base Stations, e.g. femto Base Stations, home Node B
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/18—Service support devices; Network management devices
    • H04W88/181—Transcoding devices; Rate adaptation devices

Abstract

Un terminal (102) de comunicación, que comprende; un cambiador de modo configurado para cambiar un modo de códec o un conjunto de modos de códec del terminal (100) de comunicación o un terminal (102) asociado que es un destino de comunicación, el terminal (100) de comunicación está configurado para configurarse mediante un mensaje de señalización para negociación recibido desde el terminal (102) asociado cuando comienza la comunicación entre el terminal (100) de comunicación y el terminal (102) asociado, el mensaje de señalización para la negociación de códec incluye un códec y un modo de códec o un conjunto de modos de códec; y un transmisor (2702) configurado para transmitir, durante la comunicación con el terminal (102) asociado, un modo de códec del terminal (100) de comunicación actualmente en uso, utilizando una carga útil del protocolo de transporte en tiempo real RTP, en el que el transmisor (2702) está configurado para transmitir una solicitud de modo de códec CMR para solicitar al terminal (102) asociado que cambie el modo de códec del terminal (102) asociado utilizando la carga útil RTP, la carga útil RTP incluye un campo de solicitud de modo de códec que solo está presente cuando es necesario cambiar el modo de códec o el conjunto de modos de códec del terminal (102) asociado.

Description

DESCRIPCIÓN
Terminal y procedimiento de selección de modo de codificación
Campo técnico
La presente invención se refiere a un terminal y a un procedimiento de selección de modo de códec para seleccionar un modo de códec adecuado usando características de una red de acceso inalámbrico a la que está conectado el terminal.
Antecedentes de la técnica
En el 3GPP (Proyecto de asociación de tercera generación), un servicio de VoIP (Voz sobre IP) está en marcha utilizando un IMS (Subsistema Multimedia IP).
El documento WO 2010/117326 A1 desvela terminales de comunicación que realizan negociación de CODEC SDP y después del establecimiento de la sesión durante la comunicación intercambiando información de un modo de códec del terminal de comunicación actualmente en uso, el modo de códec solicita a CMR que solicite al terminal asociado respectivo que cambie el modo de códec utilizando la carga útil RTP.
El documento WO 02/15627 A1 desvela un procedimiento y un sistema de comunicación que comprende un primer elemento de red, por ejemplo, terminal portátil, conectable a un segundo elemento de red. Uno de los modos seleccionables se utiliza para la comunicación. Un elemento de red está adaptado para realizar un procedimiento de selección de modo para seleccionar el mismo modo para la comunicación bidireccional entre los elementos de red. La selección de modo garantiza el uso de uno y el mismo modo en la dirección de enlace ascendente y descendente y, por lo tanto, permite, por ejemplo, la telefonía IP en UMTS utilizando el protocolo SIP. El documento desvela además un aparato y un procedimiento asociado, para facilitar una sesión de comunicación VoIP a través de un enlace de radio con una estación móvil. La estación móvil forma un elemento de información QoS (Calidad de servicio) para la comunicación a una porción de red de acceso de radio. El elemento de información QoS indica si se debe eliminar la información del encabezado del paquete de los paquetes de datos que se comunicarán en el enlace de radio de acuerdo con la sesión de comunicación.
El documento "3rd Generation Partnership Project: Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS); Multimedia Telephony Media handling and interaction (Versión 9)" especifica un cliente para el Servicio de telefonía multimedia para IMS (MTSI) que admite el habla conversacional (incluyendo DTMF), video y texto transportados a través de RTP con el alcance de ofrecer una experiencia de usuario equivalente o mejor que la de los servicios de conversación de conmutación de circuitos (CS) que utilizan la misma cantidad de recursos de red. Define la gestión de medios (por ejemplo, señalización, transporte, gestión de la memoria intermedia de fluctuaciones, gestión de pérdida de paquetes, adaptación), así como la interactividad (por ejemplo, agregar o quitar medios durante una llamada). El objetivo es garantizar un servicio fiable e interoperable con una calidad de medios predecible, permitiendo flexibilidad en la oferta de servicios.
El documento JP 2003 500907 A desvela un procedimiento para negociar una capacidad de llamada entre puntos de señalización en un sistema de telecomunicaciones. El procedimiento comprende enviar una preferencia de capacidad o una lista de preferencias priorizadas desde un punto de señalización de origen a un punto de señalización de terminación o punto de transferencia de señalización, en el nivel de control de llamadas. Se devuelve una aceptación de capacidad desde el punto de señalización de terminación o el punto de transferencia de señalización al punto de señalización de origen en el nivel de control de llamada, si el punto de señalización de terminación o el punto de transferencia de señalización acepta una preferencia enviada por el punto de señalización de origen.
La figura 1 muestra un ejemplo de configuraciones de red de un servicio VoIP utilizando un IMS 3GPP. La red mostrada en la figura 1 está construida con la red 126 IMS, la red central IP de un operador 124, una estación base (eNB: e Nodo B) y redes 120 y 122 de acceso inalámbrico configuradas bajo el control del eNB. En la figura 1, terminales (UE: Equipo de usuario) 100 y 102 están conectados de forma inalámbrica a los eNB 104 y 106 a través de las redes 120 y 122 de acceso inalámbrico respectivamente, y están conectados a la red 124 central IP a través de los eNB 104 y 106, respectivamente.
La red IMS es una red destinada a realizar la gestión de información para el control de llamadas, enrutamiento de un mensaje de señalización (SIP: Protocolo de inicio de sesión) de control de llamadas y conexiones mutuas entre redes heredadas 3GPP o redes que no sean 3GPP.
En la red 126 IMS mostrada en la figura 1, las P-CSCF (funciones de control de sesión de llamada de proxy) 108 y 116 son CSCF que tienen contacto con los UE 100 y 102. Al transmitir un mensaje de señalización IMS (mensaje REGISTRAR SIP, Mensaje INVITAR SIP o similar), el Ue busca un P-CSCF al que se pueda conectar el UE y transmite el mensaje de señalización de IMS a este P-CSCF.
Los S-CSCF (CSCF de servicio) 110 y 114 son CSCF que gestionan la información de contacto del UE y gestionan sesiones. Los S-CSCF 110 y 114 descargan la información necesaria del HSS (servidor de suscriptor doméstico) 118 cuando gestionan la información de contacto del UE.
I-CSCF (CSCF de interrogación) 112 contiene información de CSCF entre dominios de gestión (cada uno de los cuales es una unidad de red gestionada por cada operador). Por ejemplo, cuando el P-CSCF o S-CSCF no tiene la siguiente información de nodo con la que se debe transferir un mensaje de señalización IMS, el mensaje de señalización IMS se transfiere a través de I-CSCF 112. Asimismo, I-CSCF 112 también puede confirmar información de un CSCF, a la que se transfiere el mensaje, preguntando a HSS 118 la información. Por ejemplo, se describirá un caso en el que se envía un mensaje INVITAR s Ip .
En este caso, el mensaje INVITAR SIP se envía primero desde un UE del lado llamante a una P-CSCF en un dominio donde se encuentra el UE (dominio del lado llamante) a través de la red central IP y se transfiere desde el P-CSCF al S-CSCF del lado llamante. Después de ser sometido a un procesamiento apropiado en el lado llamante S-CSCF, el mensaje INVITAR SIP se transfiere a un S-CFCS en un dominio lateral llamado. En este caso, el mensaje INVITAR SIP puede pasar por I-CSCF 112. El lado llamado S-CSCF transfiere el mensaje INVITAR SIP recibido a un UE del lado llamado a través de un P-CSCF.
La red 124 central IP del operador mostrada en la figura 1 realiza el enrutamiento de datos de comunicación, control de calidad de servicio (QoS) y gestión de la información de posición de un terminal o similar.
La figura 2 es un flujo que ilustra un ejemplo de un procedimiento hasta que se realiza una llamada VoIP utilizando un IMS 3GPP. La figura 2 ilustra un ejemplo de flujo cuando el UE 100 realiza una llamada telefónica al UE 102. Como se muestra en la figura 2, se transmite un mensaje INVITAR SIP del UE 100 al UE 102 a través de la red IMS (etapa (en adelante, denominada "ST") 11), y un mensaje 183 de progreso de sesión SIP se transmite desde el UE 102 al UE 100 a través de la red IMS (ST12). De esta manera, el mensaje INVITAR SIP y el mensaje de progreso de sesión SIP 183 se intercambian entre los UE y, por lo tanto, se realiza una negociación relacionada con la comunicación.
Una oferta de SDP (Protocolo de descripción de sesión) agregada al mensaje INVITAR SIP describe un mecanismo utilizado en la comunicación VoIP. Ejemplos del mecanismo descrito incluyen un esquema de códec o modo de códec y candidatos relacionados con el protocolo. El esquema de códec o el modo de códec incluye un elemento adoptado para este códec, tal como una velocidad de bits, retraso algorítmico, o el número de canales. Asimismo, el protocolo incluye el tipo de formato de carga útil RTP (Protocolo de transporte en tiempo real) o similar. Al recibir el mensaje INVITAR SIP en ST11, el UE 102 selecciona un mecanismo entre una pluralidad de candidatos descritos en la oferta de SDP y describe el mecanismo en una respuesta de SDP. En ST12, el UE 102 agrega la respuesta de SDP al mensaje de progreso de sesión SIP 183 y la envía al UE 100.
La red IMS analiza el mecanismo seleccionado por el UE 102 y emite una instrucción para asignar un recurso correspondiente al resultado del análisis a esta sesión de llamada a la red central IP. De acuerdo con las instrucciones de la red IMS, el procesamiento de asignación de recursos se realiza en la red central IP y en la red de acceso inalámbrico (ST13). Cuando se completa el procesamiento de asignación de recursos, el UE 102 llama al usuario (ST14), y cuando el usuario responde a la llamada, se transmite un mensaje 2000K al UE, 100 (ST15), y se inicia una llamada entre el UE 100 y el UE 102 (ST16).
La figura 3 muestra un ejemplo de la oferta de SDP y la respuesta de SDP. En la figura 3, con la oferta de SDP, el UE 100 ofrece cuatro modos: modo de eficiencia de ancho de banda AMR-WB (banda ancha de múltiples velocidades adaptativa), modo de alineación de octetos AMR-WB, modo de eficiencia de ancho de banda AMR y modo de alineación de octetos AMR. Asimismo, el modo de eficiencia de ancho de banda AMR se selecciona en el UE 102.
El modo de eficiencia de ancho de banda y el modo de alineación de octetos siguen un formato de carga útil RTP utilizado para AMR (o AMR-NB: Banda estrecha) y AMR-WB descritos en Literatura no de patentes (en adelante, abreviada como NPL) 1. Asimismo, NPL 2 define la velocidad de bits del códec en este momento como AMR 4,75, 5,90, 7,40 o 12,2 kbps.
Cuando los recursos necesarios no se asignan en el procesamiento de asignación de recursos (ST13 se muestra en la figura 2), esto se considera un fracaso de negociación y el procedimiento se repite nuevamente a partir de la transmisión del mensaje INVITAR SIP (ST11). Por esta razón, se recomienda usar un rango limitado bastante bajo de velocidades de bits para que la asignación de recursos se realice de manera fiable. Por ejemplo, NPL 3 es compatible con AMR-NB: 4,75, 5,15, 5,90, 6,70, 7,40, 7,95, 10,2 y 12,2 kbps, y NPL 4 admite AMR-WB: 6,60, 8,85, 12,65, 14,25, 15,85, 18,25, 19,85, 23,05 y 23,85 kbps. NPL 2 recomienda el uso de AMR-NB: 4,75, 5,90, 7,40 y 12,2 kbps, y AMR-WB: 6,60, 8,85 y 12,65 kbps.
Listado de citas
Literatura no de patente
NPL 1
IETF RFC 4867, "RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (Am R-WB) Audio Codecs"
3GPP TS 26.114 v9.3.0, "IP Multimedia Subsystem (IMS); Multimedia Telephony; Media handling and interaction" NPL 3
3GPP TS 26.101 v9.0.0, "Mandatory speech codec speech processing functions; Adaptive Multi-Rate (AMR) speech codec frame structure"
NPL 4
3GPP TS 26.201 v9.0.0, "Speech codec speech processing functions; Adaptive Multi-Rate-Wideband (AMR-WB) speech codec Frame structure"
Sumario de la invención
Problema técnico
La selección del modo de códec descrito anteriormente en la negociación al comienzo de una llamada se realiza independientemente de la situación de la red en la que los datos se intercambian realmente. Por esta razón, existe el problema de que un modo de códec apropiado no puede seleccionarse como el modo de códec utilizado al comienzo de una llamada o durante un período de llamada completo. En EVS (Servicios de voz mejorados) actualmente en discusión en 3GPP SA4, soporte de velocidades de bits más altas que las de AMR y AMR-WB, se está estudiando el soporte de una pluralidad de retrasos algorítmicos y el soporte de dos canales (estéreo) o similares. De esta manera, EVS en particular requiere que se seleccione un modo de códec adecuado.
Con respecto al problema descrito anteriormente, se propone un procedimiento mediante el cual un UE notifica a un servidor de un ancho de banda de una interfaz aérea actual y hace que un servidor determine una velocidad de bits basada en el ancho de banda de la interfaz aérea (por ejemplo, ver "Traducción al japonés de una solicitud PCT abierta a inspección pública n.° 2006-500808"). Asimismo, se propone un procedimiento mediante el cual un UE monitoriza la situación de un período inalámbrico y ajusta una longitud de memoria intermedia de eliminación de fluctuaciones adecuada de acuerdo con la situación del período inalámbrico (por ejemplo, véase la memoria descriptiva de la publicación de solicitud de patente de US 2006/0077994).
Sin embargo, dado que el UE monitoriza el estado inalámbrico (situación del ancho de banda o período inalámbrico de la interfaz aérea actual) en cualquiera de los procedimientos, se coloca una carga correspondiente en el UE. Más aún, el procedimiento descrito anteriormente no tiene en cuenta ninguna situación de comunicación de extremo a extremo (calidad de la ruta de comunicación entre los UE).
Asimismo, NPL 2 describe un procedimiento para seleccionar un modo de códec que garantiza una comunicación fiable independientemente de la situación de comunicación durante la negociación (es decir, un modo de códec que es menos probable que provoque un error de negociación). NPL 2 describe además un procedimiento para iniciar una llamada usando una velocidad de bits de códec baja dentro de un rango de velocidades de bits de códec seleccionadas por negociación. En este procedimiento, la velocidad de bits del códec se ajusta dentro del rango seleccionado de velocidades de bits del códec de acuerdo con la situación de comunicación (calidad de la ruta de comunicación entre UE) de una red de extremo a extremo después del inicio de una llamada. Sin embargo, este procedimiento no solo no puede establecer ninguna velocidad de bits de códec apropiada (velocidad de bits de códec adecuada para la situación de comunicación real) desde el inicio de una llamada, sino que también limita un límite superior de velocidades de bits de códec disponibles para todo el período de la llamada.
Por otra parte, también puede haber un procedimiento por el cual un nodo de red realimenta la situación de comunicación de una red (calidad de la ruta de comunicación entre UE) a los UE y los UE seleccionan un modo de códec de acuerdo con la situación de comunicación de la red. Sin embargo, este procedimiento hace que aumente la cantidad de tráfico de la red, cargando la red.
Es un objeto de la presente invención proporcionar un terminal de comunicación y un procedimiento de selección de modo de códec capaz de seleccionar un modo de códec de acuerdo con la calidad de una ruta de comunicación entre terminales desde las etapas iniciales de comunicación mientras se suprime una carga de procesamiento en la red y el terminal (UE).
Solución al problema
Este problema se resuelve con el objeto reivindicado en las reivindicaciones independientes adjuntas.
Efectos ventajosos de la invención
De acuerdo con la presente invención, es posible determinar la situación de una ruta de comunicación entre terminales y seleccionar un modo de códec apropiado utilizando la información contenida en los terminales como información de negociación sin aplicar una carga de procesamiento a la red o al terminal.
Breve descripción de los dibujos
La figura 1 es un diagrama que ilustra un ejemplo de configuraciones de una red IMS, una red central IP y una red de acceso inalámbrico;
La figura 2 es un diagrama que ilustra un ejemplo de operación básica de establecer una sesión de llamada; La figura 3 es un diagrama que ilustra un ejemplo de oferta de SDP y respuesta de SDP;
La figura 4 es un diagrama que ilustra un ejemplo de configuraciones de red de acuerdo con cada realización de la presente invención;
La figura 5 es un diagrama que ilustra un ejemplo de configuraciones de red de acuerdo con cada realización de la presente invención;
La figura 6 es un diagrama que ilustra un paquete RTP de acuerdo con cada realización de la presente invención; La figura 7 es un diagrama de bloques que ilustra una configuración de un terminal (UE) de acuerdo con la realización 1 de la presente invención;
La figura 8 es un diagrama que ilustra un ejemplo de oferta de SDP de acuerdo con la realización 1 de la presente invención;
La figura 9 es un diagrama que ilustra la correspondencia entre un conjunto de modos de códec y un número de acuerdo con la realización 1 de la presente invención;
La figura 10 es un diagrama de flujo que muestra un flujo de procesamiento en la sección de comparación de información y la sección de determinación de modo según la Realización 1 de la presente invención;
La figura 11 es un diagrama que ilustra un ejemplo de respuesta de SDP de acuerdo con la realización 1 de la presente invención;
La figura 12 es un diagrama de bloques que ilustra una configuración de un nodo de red de acuerdo con la realización 2 de la presente invención;
La figura 13 es un diagrama de bloques que ilustra una configuración de un terminal (UE) de acuerdo con la realización 3 de la presente invención;
La figura 14 es un diagrama que ilustra un ejemplo de oferta SDP de acuerdo con la realización 3 de la presente invención;
La figura 15 es un diagrama que ilustra la correspondencia entre un conjunto de modos de códec y un número de acuerdo con la realización 3 de la presente invención;
La figura 16 es un diagrama de flujo que muestra un flujo de procesamiento en la sección de comparación de información y la sección de determinación de modo según la Realización 3 de la presente invención;
La figura 17 es un diagrama que ilustra un ejemplo de respuesta SDP de acuerdo con la realización 3 de la presente invención;
La figura 18 es un diagrama que ilustra un ejemplo del formato de un paquete IP de acuerdo con la realización 3 de la presente invención;
La figura 19 es un diagrama que ilustra la numeración de modo de códec y un formato de carga útil RTP (primer ejemplo) de acuerdo con la realización 4 de la presente invención;
La figura 20 es un diagrama que ilustra la numeración de modo de códec y un formato de carga útil RTP (segundo ejemplo) de acuerdo con la realización 4 de la presente invención;
La figura 21 es un diagrama que ilustra la numeración de modo de códec y un formato de carga útil RTP (tercer ejemplo) de acuerdo con la realización 4 de la presente invención;
La figura 22 es un diagrama que ilustra la numeración de modo de códec y un formato de carga útil RTP (primer ejemplo) de acuerdo con la realización 5 de la presente invención;
La figura 23 es un diagrama que ilustra la numeración de modo de códec y un formato de carga útil RTP (segundo ejemplo) de acuerdo con la realización 5 de la presente invención;
La figura 24 es un diagrama que ilustra un ejemplo de la política del operador y la oferta de SDP de acuerdo con la realización 6 de la presente invención;
La figura 25 es un diagrama que ilustra un ejemplo de la respuesta del operador y la oferta de SDP de acuerdo con la realización 6 de la presente invención;
La figura 26 es un diagrama que ilustra un ejemplo de configuraciones de red de acuerdo con la realización 7 de la presente invención;
La figura 27 es un diagrama de bloques que ilustra una configuración de IP-PBX de acuerdo con la realización 7 de la presente invención;
La figura 28 es un diagrama que ilustra un primer ejemplo de un formato de carga útil RTP de acuerdo con la realización 8 de la presente invención;
La figura 29 es un diagrama que ilustra un segundo ejemplo del formato de carga útil RTP de acuerdo con la realización 8 de la presente invención; y la figura 30 es un diagrama que ilustra un tercer ejemplo del formato de carga útil RTP de acuerdo con la realización 8 de la presente invención.
Descripción de las realizaciones
En lo sucesivo, se describirán las realizaciones de la presente invención en detalle con referencia a los dibujos adjuntos.
La figura 4 es un diagrama que ilustra un ejemplo de configuraciones de red y una relación posicional entre terminales de acuerdo con cada realización de la presente invención. En la figura 4, componentes idénticos a los de la figura 1 se le asignarán números de referencia idénticos y se omitirán sus descripciones.
Se supone que los HeNB (eNodo B doméstico) 400 y 402 son estaciones base pequeñas (aquí estaciones base femto; por ejemplo, ver "3GPP TS 23.830 v9.0.0, "Architecture aspects of Home NodeB and Home eNodeB;" lo mismo se aplicará de aquí en adelante) y tendrá un ID de CSG (Identificador de grupo de abonado cerrado; por ejemplo, ver "3GPP TS 25.401 v9.0.0, "UTRAN overall description") que indica que solo los UE en poder de un número limitado de usuarios pueden conectarse a los respectivos HeNB. El HeNB 400 constituye la red 406 de acceso inalámbrico y HeNB 402 constituye la red 408 de acceso inalámbrico.
En las configuraciones de red mostradas en la figura 4, los HeNB 400 y 402 están conectados a GW (puerta de enlace) 404 locales idénticas. De esta manera, los UE (UE 100 y UE 102) conectados a1HeNB 400 y a1HeNB 402 respectivamente pueden transmitir/recibir datos a través de la GW 404 local sin pasar por la red 124 central IP del operador.
Como solo un número limitado de usuarios está conectado a las redes 406 y 408 de acceso inalámbrico mostradas en la figura 4, la cantidad de recursos inalámbricos asignables por UE en cada red de acceso inalámbrico es grande. Esta configuración es aplicable, por ejemplo, a un caso en el que se construye una red telefónica privada interna utilizando HeNB. La figura 4 muestra un ejemplo donde el GW 404 local es independiente de los HeNB 400 y 402, pero la presente invención no se limita a esto. También se pueden adoptar otras configuraciones, por ejemplo, una configuración en la que se establece la GW 404 local en cada uno de los HeNB 400 y 402 y el conjunto de GW local en cada HeNB se conecta directamente o a través de otro nodo.
La figura 5 es un diagrama que ilustra otro ejemplo de las configuraciones de red y la relación posicional entre terminales de acuerdo con cada realización de la presente invención. En la figura 5, componentes idénticos a los de la figura 1 se le asignarán números de referencia idénticos y se omitirán sus descripciones.
Los HeNB 500 y 502 son estaciones base pequeñas (estaciones base femto), y e1HeNB 500 constituye la red 506 de acceso inalámbrico y el HeNB 502 constituye la red 508 de acceso inalámbrico.
En las configuraciones de red mostradas en la figura 5, el HeNB 500 y el HeNB 502 están conectados a la red 124 principal IP del operador independientemente entre sí. De esta manera, los UE (UE 100 y UE 102) conectados al HeNB 500 y al HeNB 502 respectivamente transmiten/reciben datos a través de la red central IP del operador 124. Sin embargo, como solo un número limitado de usuarios está conectado a las redes 506 y 508 de acceso inalámbrico como en los casos de la figura 4, la cantidad de recursos inalámbricos asignables por UE en cada red de acceso inalámbrico es grande. Esta configuración es aplicable, por ejemplo, a un caso en el que se instala un HeNB en una casa privada o similar.
En la descripción que sigue, el formato de comunicación entre el UE 100 y el UE 102 mostrado en la figura 4 (formato de comunicación a través del HeNB al que está conectado cada UE y el Gw local) se denomina "comunicación HeNB red local".
Asimismo, el formato de comunicación entre el UE 100 y el UE 102 mostrado en la figura 5 (formato de comunicación a través del HeNB al que está conectado cada UE y la red central IP) se denomina "comunicación HeNB red central IP".
En este punto, Los términos relacionados con RTP usados en cada realización de la presente invención se describirán usando la figura 6. Un paquete RTP está formado por un encabezado RTP y una carga útil RTP como se muestra en la figura 6.
El encabezado RTP es como se describe en RFC (Solicitud de comentarios) 3550 de IETF (tarea de fuerza de ingeniería de Internet) y es común independientemente del tipo de carga útil RTP (tipo de códec o similar). El formato de la carga RTP difiere según el tipo de carga RTP. Como se muestra en la figura 6, la carga útil RTP se compone de una porción de encabezado y una porción de datos, pero la porción de encabezado puede no existir dependiendo del tipo de carga RTP. La porción de encabezado de la carga útil RTP incluye información para identificar el número de bits de datos codificados, tal como voz e imágenes en movimiento. La porción de datos de la carga útil RTP incluye, además de los datos codificados, como el habla y las imágenes en movimiento, por ejemplo, relleno agregado cuando la longitud de la carga útil RTP no es múltiplo de un octeto (8 bits). Asimismo, como se muestra en la figura 6, cuando se transmite un paquete RTP, encabezados en capas inferiores (encabezado UDP (Protocolo de datagramas de usuario), el encabezado IP y el encabezado específico de la ruta de transmisión que es equivalente o inferior a IP) también se agregan.
(Realización 1)
La figura 7 es un diagrama de bloques que ilustra una configuración de un terminal (UE 100, 102) de acuerdo con la presente realización. Para evitar explicaciones complicadas, la figura 7 ilustra los componentes principales relacionados con la negociación con respecto a la comunicación entre terminales estrechamente asociados con la presente invención (por ejemplo, componentes relacionados con ST11 a ST15 mostrados en la figura 2).
Cuando el terminal (UE 100, 102) mostrado en la figura 7 opera en el lado de la llamada, la sección 600 de recepción inalámbrica allí recibe un mensaje de señalización (mensaje de progreso de sesión SIP 183) notificado desde un terminal asociado (UE del lado llamado) que es un interlocutor. La sección 600 de recepción inalámbrica envía el mensaje de señalización recibido al modo que determina la sección 608. Este mensaje de señalización incluye, por ejemplo, un conjunto de modos de códec (combinación de velocidad de bits, retraso algorítmico, el número de canales o similares) descritos en una respuesta de SDP. Por otra parte, cuando el terminal opera en un lado llamado, la sección 600 de recepción inalámbrica recibe un mensaje de señalización (mensaje INVITAR SIP) notificado desde el UE (lado llamante) que es el interlocutor. La sección 600 de recepción inalámbrica luego envía el mensaje de señalización recibido a la información que compara la sección 606 y la sección 608 de determinación de modo. Este mensaje de señalización incluye, por ejemplo, candidatos de conjunto de modos de códec (candidatos de una combinación de velocidad de bits, retraso algorítmico, el número de canales o similares) descritos en una oferta de SDP e información relacionada con las características de una red de acceso inalámbrico a la que el UE como interlocutor está conectado actualmente.
La sección 602 de transmisión inalámbrica transmite un mensaje de señalización (mensaje INVITAR SIP o mensaje de progreso de sesión SIP 183) emitido desde la sección de generación de señalización 610 al UE que es el interlocutor.
La sección 604 de determinación del destino de la conexión determina las características de la red de acceso inalámbrico a la que está actualmente conectado el UE y contiene información relacionada con las características de la red de acceso inalámbrico. La sección 604 de determinación del destino de conexión emite información relacionada con las características de la red de acceso inalámbrico con la sección 606 de comparación de información y la sección 610 de generación de señalización.
Cuando el terminal opera en un lado llamado, la sección 606 de comparación de información allí compara información relacionada con las características de la red de acceso inalámbrico a la que está actualmente conectado el UE, con información relacionada con las características de la red de acceso inalámbrico a la que está actualmente conectado el UE (lado llamante) como interlocutor. La primera es información ingresada desde la sección 604 de determinación de destino de conexión y la segunda es información incluida en el mensaje de señalización ingresado desde la sección 600 de recepción inalámbrica.
Para ser más específicos, la sección 606 de comparación de información compara información relacionada con las características de ambas redes de acceso inalámbrico y determina el formato de comunicación entre su propio terminal y el terminal asociado. Por ejemplo, la sección 606 de comparación de información determina cuál corresponde a su propio terminal y al terminal asociado entre la comunicación HeNB red local, comunicación HeNB red central IP o formato de comunicación diferente. En este punto, la comunicación HeNB red local tiene un formato de comunicación en el que los terminales están conectados a través de una red de comunicación construida de un HeNB idéntico, una pluralidad de HeNB, o una pluralidad de HeNB y una red troncal VPN (Red Privada Virtual). Por otra parte, la comunicación HeNB red central IP tiene un formato de comunicación en el que los terminales están conectados a diferentes HeNB (estaciones base femto) a través de la red 124 central IP. La sección 606 de comparación de información envía el formato de comunicación determinado al modo que determina la sección 608.
Cuando el terminal opera en el lado de la llamada, la sección 608 de determinación de modo determina el conjunto de modos de códec descrito en la respuesta de SDP incluida en el mensaje de señalización ingresado desde la sección 600 de recepción inalámbrica, como el conjunto de modos de códec utilizado para la comunicación entre su propio terminal y el interlocutor. Cuando el terminal opera en un lado llamado, la sección 608 de determinación de modo en el mismo selecciona un conjunto de modos de códec utilizado para la comunicación entre su propio terminal y el terminal asociado entre los candidatos del conjunto de modos de códec descritos en la oferta de s Dp incluida en el mensaje de señalización ingresado desde la sección 600 de recepción inalámbrica. Esta selección se realiza en función del formato de comunicación introducido desde la sección 606 de comparación de información.
Cuando el terminal opera en el lado de la llamada, la sección 610 de generación de señalización genera un mensaje de señalización que incluye información que se introduce desde la sección 604 de determinación de destino de conexión y que se relaciona con las características de la red de acceso a la que está conectado el terminal. De esta manera, se notifica al UE del lado llamado la información relacionada con las características de la red de acceso a la que está conectado el UE del lado llamante. Cuando el terminal opera en un lado llamado, la sección 610 de generación de señalización genera un mensaje de señalización que incluye el conjunto de modos de códec determinado por la sección 608 de determinación de modos, la sección 610 de generación de señalización emite el mensaje de señalización generado a la sección 602 de transmisión inalámbrica.
A continuación, el procesamiento de los terminales (UE 100 y UE 102) según la presente realización se describirá en detalle usando la figura 7.
En la descripción que sigue, se supone que en la figura 4 o la figura 5, el UE 100 está actualmente conectado a1HeNB 400 o al HeNB 500, el UE 102 está conectado al HeNB 402 o 502 y el UE 100 realiza una llamada telefónica al UE 102. Cuando comienza una llamada, el UE 100 (UE del lado de la llamada) y el UE 102 (UE del lado de la llamada) no contienen información relacionada con la ubicación del interlocutor del otro (por ejemplo, información de célula que indica una célula (HeNB) a la que está conectado un UE e información de posición que indica la posición del UE).
La sección 604 de determinación del destino de conexión del UE 100 determina las características de la red 406 (o 506) de acceso inalámbrico a la que está conectado el UE 100. Por ejemplo, la sección 604 de determinación del destino de conexión determina la situación de los recursos inalámbricos asignados al UE 100 (recursos inalámbricos asignables o una proporción de recursos inalámbricos), basado en el ID de CSG de HeNB 400 (o 500) al que el UE 100 está conectado actualmente, por ejemplo, cuando la identificación CSG indica una estación base femto, la sección 604 de determinación del destino de conexión determina que la estación base femto tiene una gran cantidad de recursos asignables al UE 100.
Asimismo, como otro ejemplo, la sección 604 de determinación de destino de conexión determina que la red de acceso inalámbrico a la que está conectado actualmente el UE 100 es una red de acceso inalámbrico distinta de una red de acceso inalámbrico dedicada a teléfonos móviles de 3GPP o similares, por ejemplo, uno configurado de una LAN inalámbrica. Esta determinación se realiza en función de las características inalámbricas (banda de frecuencia inalámbrica o señalización o similares) de una red de acceso inalámbrico, en este caso, la sección 604 de determinación de destino de conexión determina que, por ejemplo, el formato de transmisión/recepción (el número de tramas enviadas a la vez, el formato de carga útil RTP o similar) de los datos de comunicación puede ser cualquier formato distinto al limitado a una red de acceso inalámbrico dedicada a teléfonos móviles 3GPP o similar.
La sección 610 de generación de señalización del UE 100 genera un mensaje de señalización para el control de la llamada (por ejemplo, mensaje INVITAR SIP) en el que se describe la información a notificar al interlocutor (UE 102). Por ejemplo, cuando la sección 604 de determinación del destino de conexión determina las características de una red de acceso inalámbrico, la sección 610 de generación de señalización describe, cuando la red de acceso inalámbrico a la que está conectada su propia terminal tiene una ID de CSG, la ID de CSG en la oferta de SDP incluida en el mensaje INVITAR SIP. Como alternativa, la sección 610 de generación de señalización también puede describir la ID de CSG en el encabezado SIP (por ejemplo, campo de encabezado de información de red de acceso P) (por ejemplo, ver "3GPP TS 24.229 v 10.0.0, "Session Initiation Protocol (SIP) and Session Description Protocol (SDP)"").
Asimismo, como la información relacionada con las características de la red de acceso inalámbrico, una identificación de estación base (por ejemplo, ver "3GPP TS 25.401 v9.0.0, "UTRAN overall description"") también se puede usar en lugar de ID de CSG. Cada UE puede identificar las características de la red de acceso inalámbrico (por ejemplo, si el número de recursos inalámbricos asignables por UE en la red de acceso inalámbrico es grande o no) según la ID del CSG o la ID de la estación base (información relacionada con las características de la red de acceso inalámbrico). Por ejemplo, basado en la identificación CSG o la identificación de la estación base, cada UE determina, si la estación base que constituye la red de acceso inalámbrico es una estación base femto, que la cantidad de recursos inalámbricos asignables por UE en la red de acceso inalámbrico es grande.
Asimismo, la sección 610 de generación de señalización del UE 100 crea un candidato del conjunto de modos de códec teniendo en cuenta las posibilidades de todas o algunas características de la red 408 (o 508) de acceso inalámbrico a la que está conectado el interlocutor (UE 102). La sección 610 de generación de señalización del UE 100 describe el candidato de conjunto de modos de códec en la oferta de SDP.
La figura 8 muestra un ejemplo descriptivo de la oferta de SDP. Por ejemplo, cuando la ID de CSG de la red de acceso inalámbrico a la que está conectado el UE 100 es "Alice-femto" "a=csg: Alice-femto" se describe en la oferta de SDP como se muestra en la figura 8. El procedimiento de descripción no se limita a esto, y puede ser diferente. Asimismo, como un procedimiento para describir el modo de códec establece candidatos en consideración de las posibilidades de todas o algunas características de la red de acceso inalámbrico a la que está conectado el interlocutor (UE 102), por ejemplo, solo se pueden describir los valores numéricos asociados con los conjuntos de modos de códec respectivos. Estos valores numéricos son "0x00", "0x01" y "0x02" en la figura 8. Esto hace posible reducir la cantidad de descripción en el SDP. Asimismo, el conjunto de modos de códec también puede expresarse usando símbolos u otros procedimientos además de la correspondencia entre un conjunto de modos de códec y un valor numérico.
Por ejemplo, la figura 9 muestra la correspondencia entre valores numéricos (números) "0x00" "0x01" y "0x02" mostrados en la figura 8, significados representados por estos valores numéricos y los conjuntos de modos de códec correspondientes.
Para ser más específicos, "0x00" mostrado en la figura 9 significa, por ejemplo, comunicación normal que es diferente de la comunicación correspondiente a "0x01" y "0x02" que se describirá más adelante. "0x00" mostrado en la figura 9 corresponde a un conjunto de modos de códec que tiene una velocidad de bits (aprox. 6 kbps, aprox. 8 kbps, aprox.
12 kbps) con un bajo retraso algorítmico. En comunicación normal, por ejemplo, se inicia una llamada a una velocidad de bits baja entre las velocidades de bits seleccionables y luego se selecciona una velocidad de bits de códec de acuerdo con la calidad de una ruta de comunicación entre los UE. "0x01" mostrado en la figura 9 significa comunicación a través de la red central IP (comunicación HeNB red central IP; por ejemplo, ver la figura 5 (casa privada)), y corresponde a un conjunto de modos de códec que tiene una velocidad de bits (aprox. 6 kbps, aprox. 8 kbps, aprox.
12 kbps, aprox. 24 kbps) con un bajo retraso algorítmico. Asimismo, "0x02" significa comunicación a través del GW local (comunicación HeNB red local; por ejemplo, ver la figura 4 (red telefónica interna)) y corresponde a un conjunto de modos de códec que tiene una velocidad de bits (aprox. 6 kbps, aprox. 8 kbps, aprox. 12 kbps, aprox. 24 kbps) con un alto retraso algorítmico.
Es decir, en la figura 9, "0x02" es un conjunto de modos de códec que proporciona códec de la más alta calidad (velocidad de bits alta, retraso largo), seguido por el modo de códec establece "0x01" y "0x00" en orden descendente de calidad (velocidad de bits más baja, menor retraso). Cada terminal (UE 100, 102) puede almacenar la correspondencia mostrada en la figura 9 de antemano.
El mensaje de señalización (mensaje INVITAR SIP) generado en la sección 610 de generación de señalización del UE 100 se transmite al UE 102 a través de la sección 602 de transmisión inalámbrica por medio de la red 126 IMS.
Por otra parte, la sección 600 de recepción inalámbrica del UE 102 recibe el mensaje de señalización (mensaje INVITAR SIP) transmitido desde el UE 100.
La sección 604 de determinación del destino de conexión del UE 102 determina las características de la red 408 (o 508) de acceso inalámbrico a la que está conectado el UE 102 de la misma manera que el UE 100.
La sección 606 de comparación de información del UE 102 verifica si el mensaje de señalización recibido describe o no información relacionada con las características de la red de acceso inalámbrico (red 406 (o 506) de acceso inalámbrico) a la que está conectado el interlocutor (UE 100). Cuando se describe la información relacionada con las características de la red de acceso inalámbrico, la sección 606 de comparación de información compara las características de la red de acceso inalámbrico del interlocutor y las características de la red de acceso inalámbrico a la que está conectado el terminal. La sección 606 de comparación de información determina entonces el formato de comunicación (qué tipo de comunicación es posible) entre el terminal (UE 102) que contiene esta sección 606 de comparación de información y el interlocutor (UE 100). Por ejemplo, la sección 606 de comparación de información compara la ID de CSG transmitida como información relacionada con las características de la red de acceso inalámbrico a la que está conectado el interlocutor (UE 100), con la ID de CSG, que es información relacionada con las características de la red de acceso inalámbrico a la que está conectado su propio terminal (UE 102). La sección 606 de comparación de información luego determina si su propio terminal y el interlocutor están conectados a sus respectivos HeNB de una red telefónica interna idéntica o si están conectados a sus respectivos HeNB privados de la casa, o si alguno o ambos terminales están conectados a una estación base pública (eNB). Como alternativa, la sección 606 de comparación de información también puede comparar las respectivas piezas de información relacionadas con las características de las redes de acceso inalámbrico a las que están conectados el interlocutor (UE 100) y su propio terminal (UE 102) respectivamente, y determinar si ambos terminales están ubicados físicamente cerca entre sí (por ejemplo, si el número de saltos de la ruta de datos es igual o inferior a un umbral predeterminado).
La sección 608 de determinación de modo del UE 102 determina el conjunto de modos de códec (combinación de la velocidad de bits, retraso algorítmico, el número de canales o similares) basado en el resultado de la determinación en la información que compara la sección 606 (formato de comunicación entre su propio terminal y el interlocutor).
La figura 10 muestra un ejemplo del procesamiento en la sección 606 de comparación de información y la sección 608 de determinación de modo de la presente realización. La figura 10 es un diagrama de flujo que muestra un flujo de procesamiento en la información que compara la sección 606 y la sección 608 de determinación de modo.
En la figura 10, la sección 606 de comparación de información determina en ST101 si su propio terminal está conectado o no al HeNB. Cuando su propio terminal no está conectado al HeNB (ST101: NO), la sección 608 de determinación de modo selecciona un conjunto de modos de códec correspondiente a la comunicación normal (0x00) en ST102.
Cuando su propio terminal está conectado al HeNB (ST101: SÍ), la sección 606 de comparación de información determina en ST103 si el interlocutor está o no conectado al HeNB. Cuando el interlocutor no está conectado a1HeNB (ST103: NO), la sección 608 de determinación de modo selecciona un conjunto de modos de códec correspondiente a la comunicación normal (0x00) en ST104. Es decir, la sección 608 de determinación de modo selecciona el conjunto de modos de códec correspondiente a la comunicación normal (0x00) si al menos uno de su propio terminal y el interlocutor no está conectado al HeNB.
Cuando el interlocutor está conectado al HeNB (ST103: SÍ), la sección 606 de comparación de información determina en ST105 si su propio terminal y el interlocutor están conectados dentro de una red local idéntica.
Cuando su propio terminal y el interlocutor no están conectados dentro de una red local idéntica (ST105: NO), la sección 608 de determinación de modo selecciona un conjunto de modos de códec correspondiente a "Comunicación HeNB red central IP (0x01)" en ST106. Cuando su propio terminal y el interlocutor están conectados dentro de una red local idéntica (ST105: SÍ), la sección 608 de determinación de modo selecciona un conjunto de modos de códec correspondiente a "Comunicación HeNB red local (0x02)" en ST107.
Es decir, la sección 608 de determinación de modo selecciona un conjunto de modos de códec de la más alta calidad cuando el formato de comunicación entre su propio terminal y el interlocutor es "comunicación HeNB red local". Asimismo, cuando el formato de comunicación descrito anteriormente es "Comunicación HeNB red central IP", la sección 608 de determinación de modo selecciona un conjunto de modos de códec de mayor calidad que el de "comunicación normal".
De esta manera, la sección 608 de determinación de modo determina un modo de códec (o conjunto de modos de códec) utilizado para la comunicación entre su propio terminal y el interlocutor que se comunica basándose en el resultado de la determinación en la información que compara la sección 606 en cuanto a si es posible o no asegurar una ruta de comunicación buena calidad entre su propio terminal y el interlocutor. Es decir, cuando la sección 608 de determinación de modo determina que es posible asegurar una ruta de comunicación de buena calidad (por ejemplo, ST101: SÍ y ST103: SÍ como se muestra en la figura 10), la sección 608 de determinación de modo selecciona un conjunto de modos de códec ("0x01" o "0x02") de alta calidad (alta velocidad de bits y retardo largo) como el modo de códec (o conjunto de modos de códec) que se utilizará. Por otra parte, cuando la sección 608 de determinación de modo determina que no es claro si es posible asegurar una ruta de comunicación de buena calidad o no (por ejemplo, ST101: NO o ST103: NO como se muestra en la figura 10), la sección 608 de determinación de modo selecciona un conjunto de modos de códec normal (es decir, un conjunto de modos de códec en el que la comunicación es posible en cualquier situación de comunicación como se describe anteriormente) como el modo de códec (o conjunto de modos de códec) que se utilizará.
La sección 610 de generación de señalización del UE 102 describe el conjunto de modos de códec seleccionado por la sección 608 de determinación de modo en parte del mensaje de señalización (por ejemplo, mensaje de progreso de sesión SIP 183) para control de llamadas, por ejemplo, respuesta de SDP. En este caso, la sección 610 de generación de señalización puede describir la ID de CSG de HeNB 402 (o 502) a la que está conectado el UE 102 o una ID de estación base, en la respuesta de SDP o encabezado SIP.
La figura 11 muestra un ejemplo descriptivo de la respuesta de SDP. Por ejemplo, supongamos que la ID CSG de la red de acceso inalámbrico a la que está conectado el UE 100 es "Alice-femto", que se muestra en la figura 8 y la ID de CSG de la red de acceso inalámbrico a la que está conectado el UE 102 es "Bob-femto" (ST101, ST103: SÍ en la figura 10). Asimismo, supongamos que la red de acceso inalámbrico con la ID de CSG ("Bob-femto") y la red de acceso inalámbrico con la ID de CSG ("Alice-femto") no están dentro de una red local idéntica (ST105: NO en la figura 10).
En este caso, la información que compara la sección 606 del UE 102 determina, por ejemplo, que su propio terminal y el interlocutor están conectados a los HeNB instalados en las respectivas casas privadas o similares, y la sección 608 de determinación de modo selecciona un conjunto de modos de códec correspondiente a "Comunicación HeNB red central IP (0x01)". De esta manera, la respuesta de SDP mostrada en la figura 11 describe "0x01" como el conjunto de modos de códec seleccionado. Como se muestra en la figura 11, la información (Bob-femto) relacionada con las características de la red de acceso inalámbrico a la que está conectado el UE 102 también se puede describir en la respuesta de SDP.
El mensaje de señalización (por ejemplo, mensaje de progreso de sesión SIP 183) generado en la sección 610 de generación de señalización del UE 102 se transmite al UE 100 a través de la sección 602 de transmisión inalámbrica por medio de la red 126 IMS.
Al recibir el mensaje de señalización transmitido desde el UE 102 a través de la sección 600 de recepción inalámbrica, la sección 608 de determinación de modo del UE 100 determina un conjunto de modos de códec basado en los contenidos descritos en la respuesta de SDP. En el ejemplo de la figura 11, la sección 608 de determinación de modo del UE 100 determina un conjunto de modos de códec correspondiente a "Comunicación HeNB red central IP (0x01)". En este caso, la ID de CSG de la red de acceso inalámbrico a la que está conectado el interlocutor (UE 102) del UE 100 o la ID de la estación base también se puede usar como información de referencia.
De esta manera, en la presente realización, cuando comienza la comunicación entre los UE, el UE del lado llamante notifica al terminal asociado (UE del lado llamado) que es el interlocutor de la ID de CSG (o ID de la estación base) como información relacionada con las características de la red de acceso inalámbrico a la que está conectado el UE del lado llamante. El UE del lado llamado compara la información (ID de CSG o similar) que se notifica desde el terminal asociado (UE del lado llamante) como el interlocutor y que se relaciona con las características de la red de acceso inalámbrico a la que el terminal asociado (el lado que llama) está conectado, con información (ID de CSG o similar) relacionada con las características de la red de acceso inalámbrico a la que está conectado el UE del lado llamado. El UE del lado llamado determina entonces el formato de comunicación entre el UE del lado llamado y el terminal asociado. Cuando el UE del lado llamado puede determinar que una ruta de comunicación de buena calidad se puede asegurar de manera fiable entre los UE, el UE del lado llamado selecciona un modo de códec (o conjunto de modos de códec) de mayor calidad y con un retraso más prolongado que el modo de códec establecido cuando comienza la comunicación. Esto corresponde, por ejemplo, a un caso donde el formato de comunicación es comunicación en una red telefónica interna o comunicación en una casa privada.
Esto permite que cada UE seleccione un conjunto de modos de códec apropiado (combinación de la velocidad de bits, retraso algorítmico, el número de canales o similares) de acuerdo con la calidad de la ruta de comunicación desde el inicio de la comunicación (etapa inicial de comunicación).
Se ha descrito un caso en la presente realización donde la presente invención se aplica a la selección de un conjunto de modos de códec como ejemplo, pero la presente invención no se limita a esto. La determinación de las características de la red de acceso inalámbrico conectada de acuerdo con la presente invención puede aplicarse a la selección de un formato de transmisión/recepción cuando se realiza otra negociación necesaria para la comunicación, como la negociación de un formato de transmisión/recepción (el número de tramas enviadas a la vez, formato de carga útil RTP o similar) de datos de comunicación.
Asimismo, en la presente realización, solo es necesario notificar al interlocutor la información contenida en cada UE (información relacionada con las características de la red de acceso inalámbrico) y no es necesario monitorizar la situación de la red de acceso inalámbrico (calidad de la ruta de comunicación) en lado de la red o el lado de la UE. De esta manera, es posible reducir la carga puesta en la red y el UE para seleccionar un modo de códec apropiado (o conjunto de modos de códec).
De esta manera, de acuerdo con la presente realización, la información que posee el terminal se utiliza como información de negociación. Esto permite determinar la situación de la ruta de comunicación entre los terminales y seleccionar un modo de códec apropiado (o conjunto de modos de códec) sin aplicar la carga de procesamiento involucrada en la transmisión/recepción de una baliza o señalización o similar en la red o los terminales (UE).
(Realización 2)
En la presente realización, un nodo de red de la red IMS verifica información relacionada con las características de una red de acceso inalámbrico descrita por un UE en parte de un mensaje de señalización en la Realización 1. Este nodo de red es un operador que proporciona una red, es decir, un nodo de red que tiene una función de procesamiento para el control de llamadas.
La figura 12 es un diagrama de bloques que muestra una configuración de un nodo de red de acuerdo con la presente realización.
En el nodo de red mostrado en la figura 12, al recibir un mensaje de señalización de un UE, la sección 700 de recepción envía el mensaje de señalización a la sección 704 de análisis de señalización.
La sección 702 de transmisión transmite un mensaje de señalización introducido desde la sección 708 de generación de señalización a un UE que es el destino del mensaje de señalización.
La sección 704 de análisis de señalización analiza la información descrita en el mensaje de señalización introducido desde la sección 700 de recepción y emite información que requiere confirmación a una sección de confirmación apropiada. Por ejemplo, la sección 704 de análisis de señalización pasa a la sección 706 de conformación de información de posición del terminal, información (por ejemplo, ID de CSG o ID de estación base) relacionada con las características de la red de acceso inalámbrico a la que el UE está conectado actualmente a partir de la información descrita en el mensaje de señalización.
La sección 706 de confirmación de información de posición del terminal confirma la idoneidad de la información (ID de CSG o similar, es decir, información de posición del terminal) en relación con las características de la red de acceso inalámbrico a la que está conectado actualmente el UE que ha transmitido el mensaje de señalización. En este momento, la sección 706 de confirmación de información de posición del terminal puede confirmar la idoneidad utilizando la información contenida en este nodo de red o puede confirmarla en cooperación con otro nodo de red (por ejemplo, MME (entidad de gestión de movilidad) y HSS (servidor de abonado doméstico); ver "3GPP TS 23.002 v10.0.0, "Network Architecture""). La sección 706 de confirmación de información de posición del terminal envía el resultado de confirmación a la sección 708 de generación de señalización.
La sección 708 de generación de señalización sobrescribe los contenidos de descripción que necesitan ser corregidos del mensaje de señalización transmitido desde el UE. Por ejemplo, supongamos que la sección 706 de confirmación de información de posición del terminal determina que la información relacionada con las características de la red de acceso inalámbrico es apropiada. En este caso, la sección 708 de generación de señalización puede agregarse a un mensaje de señalización, información que indica que la idoneidad ha sido confirmada por una entidad de red utilizando un procedimiento de descripción como una señalización, valor numérico, y texto. Asimismo, cuando la sección 706 de confirmación de información de posición del terminal determina que la información relacionada con las características de la red de acceso inalámbrico no es apropiada, la sección 708 de generación de señalización puede eliminar la información relacionada con las características de la red de acceso inalámbrico del mensaje de señalización. Como alternativa, la sección 708 de generación de señalización puede agregarse al mensaje de señalización, información (resultado de confirmación de adecuación) que indica el resultado de confirmación en la sección 706 de confirmación de información de posición del terminal. El mensaje de señalización corregido se transmite al destino del mensaje de señalización a través de la sección 702 de transmisión.
El UE que ha recibido el mensaje de señalización determina que la idoneidad ha sido confirmada por una entidad de red. En este caso, el UE determina el formato de comunicación con el interlocutor utilizando la información que se describe en el mensaje de señalización y que se relaciona con las características de la red de acceso inalámbrico a la que está conectado el interlocutor, de la misma manera que en la realización 1. Por otra parte, supongamos que el UE que ha recibido el mensaje de señalización no ha determinado con éxito, por ejemplo, que la idoneidad ha sido confirmada por la entidad de red. En este caso, el UE no determina el formato de comunicación con el socio comunicante utilizando la información relacionada con las características de la red de acceso inalámbrico a la que está conectado el interlocutor. Es decir, el UE puede decidir si determinar o no el formato de comunicación con el terminal asociado en función del resultado de confirmación de la idoneidad en el nodo de red.
Esto permite que un UE determine con precisión el formato de comunicación entre el UE y el terminal asociado. Es decir, es posible mejorar la certeza de la determinación del formato de comunicación entre el UE y el terminal asociado. Por lo tanto, la presente realización puede determinar la situación de la ruta de comunicación entre terminales con mayor precisión que la Realización 1 y seleccionar un modo de códec apropiado (o conjunto de modos de códec).
En la presente realización, el nodo de red puede ser una entidad de red IMS (P-CSCF y S-CSCF o similar; consulte "3GPp TS 23.002 v10.0,0, "Network Architecture"") o IP-PBX (Intercambio de sucursales privadas de protocolo de Internet) utilizado para construir una red telefónica privada interna o similar. Por ejemplo, el P-CSCF (P-CSCF 108, 116 mostrado en la figura 4 o la figura 5), que es una de las entidades de red IMS, tiene la función de confirmar y reescribir los contenidos SDP. Por lo tanto, si el P-CSCF se usa como nodo de red de acuerdo con la presente realización, la función de confirmación de SDP también se puede usar para confirmar la información relacionada con las características de la red de acceso inalámbrico, y de ese modo es posible obtener efectos similares a los de la presente realización sin aumentar las cargas en el lado de la red.
Asimismo, se ha descrito un caso en la presente realización en el que el nodo de red notifica al UE la información que indica que se ha confirmado la idoneidad, pero no necesariamente notificará al UE la información que indica que se ha confirmado la idoneidad. Por ejemplo, como se ha descrito anteriormente, el nodo de red elimina la información relacionada con las características de la red de acceso inalámbrico que se consideras inapropiadas, del mensaje de señalización. En este caso, el UE al que se transmite el mensaje de señalización ya no determinará el formato de comunicación utilizando información incorrecta. Por lo tanto, incluso si el nodo de red no notifica al UE la información que indica que se ha confirmado la idoneidad, es posible mejorar la certeza en la determinación del formato de comunicación entre los terminales de la misma manera que en la presente realización. Por ejemplo, el nodo de red no necesita enviar la información que indica que se ha confirmado la idoneidad para la comunicación entre los UE conectados a una red central IP de un operador idéntico. En su lugar, el nodo de red puede notificar la información que indica que se ha confirmado la idoneidad para la comunicación entre los UE conectados cada uno a las redes centrales IP de diferentes operadores.
(Realización 3)
La presente realización selecciona un modo de códec (o conjunto de modos de códec) que usa información que indica la presencia o ausencia de una posibilidad de traspaso de UE además de información relacionada con las características de una red de acceso a la que está conectado el UE. Asimismo, la presente realización cambia el modo de códec (o conjunto de modos de códec) cuando se produce un cambio en presencia o ausencia de una posibilidad de traspaso en medio de una llamada.
La figura 13 es un diagrama de bloques que muestra una configuración de un terminal (UE 100, 102) de acuerdo con la presente realización. En la figura 13, componentes idénticos a los de la figura 7 se le asignarán números de referencia idénticos y se omitirán sus descripciones. En el terminal mostrado en la figura 13, la sección 812 de análisis de estado y la sección 814 de cambio de modo se agregan a los componentes del terminal que se muestra en la figura 7.
En el terminal mostrado en la figura 13, la sección de análisis de estado 812 analiza (determina) si existe o no la posibilidad de que su propio terminal realice el traspaso del tipo, estado o similar de su propio terminal. Por ejemplo, cuando el UE es un terminal estacionario para un sistema de conferencia telefónica, la sección 812 de análisis de estado determina que la posibilidad de que su propio terminal realice el traspaso es baja. Asimismo, incluso cuando su propio terminal es un pequeño UE, si está conectado a un equipo estacionario, un altavoz, micrófono o similares, la sección 812 de análisis de estado determina que la posibilidad de que su propio terminal realice el traspaso es baja. Como alternativa, cuando su propio terminal cuenta con una sección de configuración del modo de conferencia telefónica (no se muestra) y el usuario selecciona explícitamente un modo de conferencia telefónica (a través de una operación de la interfaz de usuario del UE), la sección 812 de análisis de estado determina que la posibilidad de que su propio terminal realice el traspaso es baja. La sección 812 de análisis de estado emite información que indica el resultado del análisis cuando comienza la comunicación, a la sección 610 de generación de señalización. De esta manera, el resultado del análisis (información que indica la presencia o ausencia de la posibilidad de que su propio terminal realice el traspaso) se agrega a un mensaje de señalización y se notifica a un interlocutor.
Asimismo, la sección 812 de análisis de estado analiza el estado de su propio terminal durante la comunicación y las salidas, cuando el estado de su propio terminal cambia durante la comunicación, contenido del cambio del estado de su propio terminal a la sección 814 de cambio de modo. Por ejemplo, cuando un UE que se comunica y está conectado a un equipo estacionario, un altavoz, micrófono o similar está desconectado de dicho equipo, la sección 812 de análisis de estado emite información que indica que su propio terminal está desconectado del equipo, a la sección 814 de cambio de modo.
La sección 814 de cambio de modo cambia el modo de códec (o conjunto de modos de códec) actualmente en uso en función de la información ingresada desde la sección 812 de análisis de estado. El cambio en el modo de códec (o conjunto de modos de códec) puede solicitarse al interlocutor que se comunica transmitiendo un mensaje de señalización para el control de la llamada. Asimismo, dicha solicitud también se puede hacer agregando información de cambio que indique el contenido del cambio del modo de códec (o conjunto de modos de códec) al encabezado de los datos de comunicación (por ejemplo, encabezado RTP, porción de encabezado de la carga útil RTP, información de control de datos de comunicación o RTCP (Protocolo de control RTP)).
A continuación, el procesamiento en los terminales (UE 100 y UE 102) según la presente realización se describirá en detalle usando la figura 13.
En la descripción que sigue, como en el caso de la Realización 1, supongamos que el UE 100 está actualmente conectado al HeNB 400 o al HeNB 500, el UE 102 está conectado al HeNB 402 o 502 y el UE 100 realiza una llamada telefónica al UE 102 en la figura 4 o la figura 5.
La sección 812 de análisis de estado del UE 100 analiza (determina) a partir del tipo y estado o similar del UE 100 si existe o no la posibilidad de que el UE 100 realice el traspaso.
La sección 610 de generación de señalización del UE 100 describe información que indica el resultado del análisis en parte de un mensaje de señalización para el control de llamadas, por ejemplo, oferta de SDP (o encabezado SIP). Asimismo, la sección 610 de generación de señalización crea, como en el caso de la Realización 1, candidatos para el modo de códec (o conjunto de modos de códec) teniendo en cuenta las características de la red de acceso inalámbrico a la que está conectado el interlocutor (UE 102). Asimismo, la sección 610 de generación de señalización crea, como en el caso de la Realización 1, candidatos para el modo de códec (o conjunto de modos de códec) teniendo en cuenta la posibilidad de la totalidad o parte de cada pieza de información relacionada con el UE 102, tal como la posibilidad de que el interlocutor (UE 102) realice el traspaso o similar. Un mensaje de señalización (mensaje INVITAR SIP) que incluye la información se transmite al interlocutor (UE 102) a través de la sección 602 de transmisión inalámbrica.
La figura 14 muestra un ejemplo descriptivo de una oferta de SDP. Por ejemplo, cuando la sección 812 de análisis de estado del UE 100 determina que la posibilidad de que el UE 100 realice el traspaso es baja, "a = traspaso: bajo" se describe en la oferta de SDP como se muestra en la figura 14. En lugar de describir la presencia o ausencia de la posibilidad de traspaso como "baja" o "alta", la posibilidad puede expresarse mediante un valor numérico o símbolo o similar. Por ejemplo, cuando se supone que "0x00" representa una "alta posibilidad de traspaso" y "0x01" representa una "baja posibilidad de traspaso", el estado de una baja posibilidad de traspaso se describe como "a = traspaso: 0x01". El procedimiento de descripción no se limita a esto, y puede ser diferente.
A continuación, La figura 15 muestra la correspondencia entre el conjunto de modos de códec (que incluye un conjunto de modos de códec cuando la posibilidad de que el UE realice el traspaso es baja) y un valor numérico (número) que indica el conjunto de modos de códec de acuerdo con la presente realización. En la figura, 15, "0x03" se establece además de la correspondencia mostrada en la figura 9 ("0x00" "0x01" y "0x02"). "0x03" mostrado en la figura 15 significa comunicación de conferencia telefónica y corresponde a una velocidad de bits de aprox. 100 kbps y un modo de códec configurado con un alto retraso algorítmico.
Por otra parte, la sección 606 de comparación de información del UE 102 (lado llamado) compara la información relacionada con el estado del terminal (resultado del análisis en el análisis de estado de la sección 812 del UE 100) y las características de la red de acceso inalámbrico conectada, con información relacionada con el estado del terminal de su propio terminal (resultado del análisis en la sección 812 de análisis de estado del UE 102) y las características de la red de acceso inalámbrico conectada. El primero es información incluida en el mensaje de señalización (mensaje INVITAR SIP) transmitido desde el UE 100. Para ser más específicos, la sección 606 de comparación de información determina el formato de comunicación (qué tipo de comunicación es posible) entre su propio terminal (UE 102) y el interlocutor (UE 100) en función del resultado de la comparación. Por ejemplo, la sección 606 de comparación de información determina que la comunicación como un teléfono fijo (comunicación de alta calidad) es posible cuando los UE 100 y 102 están conectados al HeNB y no hay posibilidad de traspaso.
La sección 608 de determinación de modo del UE 102 determina el conjunto de modos de códec (combinación de la velocidad de bits, retraso algorítmico, el número de canales o similares) en función del resultado de la determinación (formato de comunicación entre su propio terminal y el interlocutor) en la sección 606 de comparación de información.
La figura 16 muestra un ejemplo del procesamiento en la sección 606 de comparación de información y la sección 608 de determinación de modo en la presente realización. La figura 16 es un diagrama de flujo que ilustra un flujo de procesamiento en la información que compara la sección 606 y la sección 608 de determinación de modo. En la figura 16, componentes que realizan un procesamiento idéntico al procesamiento en la figura 10 se asignarán números de referencia idénticos y se omitirán sus descripciones.
En la figura 16, el terminal (UE 102) y el interlocutor (UE 100) están conectados dentro de una red local idéntica (ST105: SÍ). En este caso, la sección 606 de comparación de información determina en ST201 si existe o no la posibilidad de que su propio terminal realice el traspaso y determina en ST202 si existe o no la posibilidad de que el interlocutor realice el traspaso. Cuando existe la posibilidad de que su propio terminal realice el traspaso (ST201: SÍ) o existe la posibilidad de que el interlocutor realice el traspaso (ST202: SÍ), la sección 608 de determinación de modo en ST107 selecciona un conjunto de modos de códec correspondiente a "Comunicación HeNB red local (0x02)".
Por otra parte, cuando no hay posibilidad de que su propio terminal realice el traspaso (ST201: NO) ni posibilidad de que el interlocutor realice el traspaso (ST202: NO), la sección 608 de determinación de modo en ST203 selecciona un conjunto de modos de códec correspondiente a "comunicación de conferencia telefónica (0x03)".
De esta manera, la sección 608 de determinación de modo selecciona un conjunto de modos de códec utilizado para la comunicación entre su propio terminal y el interlocutor en función de si la sección 606 de comparación de información determina o no que se puede asegurar una ruta de comunicación de buena calidad entre su propio terminal y el interlocutor y si existe o no la posibilidad de que cada uno de sus propios terminales y el socio que se comunica realice el traspaso. Más específicamente, cuando se determina que se puede asegurar una ruta de comunicación de buena calidad (por ejemplo, ST101: SÍ y ST103: SÍ que se muestra en la figura 16), y cuando existe la posibilidad de que ninguno realice el traspaso (por ejemplo, ST201: NO y ST202: NO como se muestra en la figura 16), el conjunto de modos de códec (0x03) que tiene la más alta calidad y se selecciona un retraso largo entre los conjuntos de modos de códec seleccionables.
La sección 610 de generación de señalización del UE 102 describe el conjunto de modos de códec seleccionado por la sección 608 de determinación de modo en parte de un mensaje de señalización (por ejemplo, mensaje de progreso de sesión SIP 183) para control de llamadas, por ejemplo, en una respuesta de SDP. En este caso, la sección 610 de generación de señalización también puede describir la ID de CSG de HeNB 402 (o 502) a la que está conectado el UE 102 o la ID de la estación base y la presencia o ausencia de una posibilidad para que el UE 102 realice el traspaso en la respuesta de SDP o encabezado SIP.
La figura 17 muestra un ejemplo descriptivo de la respuesta de SDP. Por ejemplo, supongamos que la ID CSG de la red de acceso inalámbrico a la que está conectado el UE 100 es "Panasonic-femto", que se muestra en la figura 14 y la ID de CSG de la red de acceso inalámbrico a la que está conectado el UE 102 es "Panasonic-femto" (ST101, ST103: SÍ en la figura 16). Asimismo, supongamos que la red de acceso inalámbrico con la ID de CSG ("Panasonic-femto") y la red de acceso inalámbrico con la ID de c Sg ("Panasonic-femto") están dentro de una red local idéntica (ST105: SÍ en la figura 16). Asimismo, supongamos que las posibilidades de que tanto el UE 100 como el UE 102 realicen el traspaso son bajas (ST201, ST202: NO en la figura 16). En este caso, la sección 606 de comparación de información del UE 102 determina que el UE 100 y el UE 102 están conectados cada uno a los HeNB dentro de una red local interna idéntica y que no hay posibilidad de que el UE 100 o el UE 102 realicen el traspaso. La sección 608 de determinación de modo entonces selecciona un conjunto de modos de códec correspondiente a "comunicación de conferencia telefónica (0x03)". De esta manera, la respuesta de SDP mostrada en la figura 17 describe "0x03" como el conjunto de modos de códec seleccionado.
Como se muestra en la figura 17, la información (Panasonic-femto) relacionada con las características de la red de acceso inalámbrico a la que está conectado el UE 102 y la presencia o ausencia (traspaso: bajo) de una posibilidad para que el UE 102 realice el traspaso puede describirse en la respuesta del SDP.
El mensaje de señalización (por ejemplo, mensaje de progreso de sesión SIP 183) generado en la sección 610 de generación de señalización del UE 102 se transmite al UE 100 a través de la sección 602 de transmisión inalámbrica por medio de la red 126 IMS.
Al recibir el mensaje de señalización transmitido desde el UE 102 a través de la sección 600 de recepción inalámbrica, la sección 608 de determinación de modo del UE 100 determina el conjunto de modos de códec basado en los contenidos descritos en la respuesta de SDP. En el ejemplo de la figura 17, la sección 608 de determinación de modo del UE 100 determina un conjunto de modos de códec correspondiente a "comunicación de conferencia telefónica (0x03)".
En este caso, la ID de CSG del destino de la conexión del interlocutor (UE 102) del UE 100 o la ID de la estación base, o la presencia o ausencia de una posibilidad de traspaso también se puede usar como información de referencia.
Asimismo, cuando el estado de UE 100 o UE 102 cambia durante la comunicación, la sección 814 de cambio de modo puede cambiar el conjunto de modos de códec. Por ejemplo, supongamos que el modo de códec actual configurado corresponde a "comunicación de conferencia telefónica (0x03)". En este caso, la sección 814 de cambio de modo describe el conjunto de modos de códec modificado (por ejemplo, "bajo control de comunicación HeNB red local (0x02)" en la parte de encabezado del campo de solicitud de modo de códec o carga útil RTP de retroalimentación RTCP (por ejemplo, véase la figura 18). La sección 814 de cambio de modo luego insta al interlocutor a cambiar el modo de códec (o conjunto de modos de códec) y al mismo tiempo también cambia el modo de códec (o conjunto de modos de códec) de su propio terminal. Asimismo, en lugar de cambiar el modo de códec de destino establecido, modos de códec individuales, como la velocidad de bits de destino de cambio, modo de retraso, el número de canales también puede especificarse directamente en el campo de solicitud de modo de códec. Asimismo, la velocidad de bits de destino de cambio, modo de retraso, el número de canales o similares también puede extenderse sobre una pluralidad de modos de códec (o conjuntos de modos de códec).
De esta manera, el UE usa no solo características de la red de acceso inalámbrico, sino también la presencia o ausencia de una posibilidad de traspaso, y de ese modo puede determinar el formato de comunicación entre su propio terminal y el terminal asociado que es el interlocutor más específicamente que en la Realización 1. De esta manera, el UE puede seleccionar un modo de códec (o conjunto de modos de códec) de mayor calidad de acuerdo con el formato de comunicación determinado.
Asimismo, cuando la posibilidad de traspaso cambia en el UE o terminal asociado durante la comunicación, el UE cambia el modo de códec (o conjunto de modos de códec) actualmente en uso. Es decir, incluso durante la comunicación, si el estado de uno de los UE y el interlocutor cambia, es decir, cuando el formato de comunicación entre el UE y el interlocutor puede cambiar, el UE cambia el modo de códec (o conjunto de modos de códec) de acuerdo con el cambio. Esto permite que el UE use un modo de códec apropiado (o conjunto de modos de códec) de acuerdo con el cambio en el formato de comunicación durante la comunicación.
Por lo tanto, de acuerdo con la presente realización, es posible determinar la situación de la ruta de comunicación entre terminales más específicamente que en la Realización 1 y seleccionar un modo de códec más apropiado (o conjunto de modos de códec).
(Realización 4)
En la presente realización, a continuación se muestra un ejemplo de formato de carga útil RTP, que se recomienda en el caso de un esquema de códec en el que hay muchos tipos de modos de códec, tales como velocidades de bits como en el caso de los esquemas de códec que se muestran en los ejemplos de las Realizaciones 1 a 3. El ejemplo de formato de carga útil RTP en la presente realización no se limita a los casos en los que el procedimiento de negociación o el modo de códec (o conjunto de modos de códec) se selecciona como se describe en las Realizaciones 1 a 3.
En este punto, se supone que 12 y 24 kbps son compatibles con el esquema X (que se supone que es "códec de velocidad múltiple") como velocidades de bits en un esquema (o modo) de códec o una pluralidad de esquemas (o modos) que se pueden usar al cambiar entre esquemas (o modos) dentro de una sesión en tiempo real, tal como una llamada. En el esquema Y (se supone que es "códec escalable"), supongamos que las partes básicas 8, 12 y 24 kbps, las primeras partes expandidas de 4 y 12 kbps, y la segunda parte expandida de 8 kbps son compatibles como tales velocidades de bits. En este punto, el esquema X y el esquema Y pueden ser códecs diferentes o pueden ser modos diferentes dentro de un solo códec.
En este punto, la primera parte expandida y la segunda parte expandida del códec escalable pueden ser, por ejemplo, expansión de banda súper ancha y expansión de banda completa, o expansión compatible con mejora o expansión estéreo o similar. Asimismo, como un modo de retraso, supongamos que tanto el esquema X como el esquema Y tienen ambos o uno de los diferentes retrasos A y B. Además, como el número de canales, supongamos que se admiten dos de 1 canal (mono) y 2 canales (estéreo), o solo 1 canal (mono).
La figura 19 es un primer ejemplo de numeración (Índice de tipo de trama) del modo de códec (tasas de bits y una combinación de los mismos en este ejemplo) y un formato de carga útil RTP en la presente realización.
Como se muestra en la figura 19A, se asignan diferentes índices de tipo de trama respectivos a todas las combinaciones de velocidades binarias. La figura 19B es un ejemplo del formato de carga útil RTP en el primer ejemplo. Como se muestra en la figura 19B, el índice de tipo de trama y el bit Q se agregan en la porción de encabezado de la carga útil RTP además de la porción de datos de la carga útil r Tp , como información sobre la carga útil RTP. En este punto, la porción de datos de la carga útil RTP incluye datos codificados de una trama y bits de relleno añadidos para ajustar la longitud de la carga útil RTP. Se usa el índice de tipo de trama incluido en la porción de encabezado de la carga útil RTP indica qué combinación en la figura 19A. El bit Q incluido en la porción de encabezado de la carga útil RTP es equivalente al bit Q descrito en NPL 1 y es un indicador de la calidad de trama.
El modo de retraso puede o no estar incluido en la porción de encabezado de la carga útil RTP. Cuando el modo de retraso se incluye en la porción de encabezado de la carga útil RTP, el modo de retraso puede incluirse en la tabla de la figura 19A y el índice de tipo de trama se puede asignar. Un bit que indica el modo de retraso (por ejemplo, "0" para el retraso A y "1" para el retraso B) pueden incluirse en el formato de carga útil RTP.
Como se muestra en la figura 19B, el formato de carga útil RTP en el primer ejemplo no tiene un campo como la solicitud de modo de códec descrita en NPL 1. Al omitir este campo, el tamaño de la carga útil RTP se puede reducir, Sin embargo, cuando no hay ningún problema con el tamaño de la carga útil RTP (es decir, cuando no hay ningún problema, incluso si se agregan varios bits al formato de carga RTP), se puede incluir un campo como solicitud de modo de códec. Por ejemplo, RTCP se puede usar cuando no existe un campo como la solicitud de modo de códec y cuando se solicita al interlocutor que cambie el modo de códec (o el conjunto de modos de códec).
Asimismo, se puede enviar una pluralidad de tramas (datos codificados de 1 trama) simultáneamente (en un paquete IP). En este caso, un bit para identificar cuál de la pluralidad de tramas que se envían simultáneamente es la última trama puede incluirse en la porción de encabezado de la carga útil RTP.
Los bits y campos incluidos en el encabezado no se limitan a los que se muestran en este ejemplo.
Se ha descrito un ejemplo en la presente realización como se muestra en la figura 19A, donde se dan una serie de índices de tipo de trama a las tasas de bits respectivas del esquema X y el esquema Y o combinaciones de tasas de bits para que el esquema X y el esquema Y puedan tratarse como si fueran un esquema de códec idéntico. Sin embargo, el índice de tipo de trama y el formato de carga útil RTP también se pueden dar al esquema X y al esquema Y por separado y usarse de forma independiente.
La figura 20 es un segundo ejemplo que ilustra la numeración (Índice de tipo de trama) del modo de códec (velocidad de bits en este ejemplo) y un formato de carga útil RTP en la presente realización.
Como se muestra en la figura 20A, los índices de tipo de trama se asignan solo a las velocidades binarias respectivas. El índice de tipo de trama mostrado en la figura 20A especifica solo una velocidad de bits, pero no describe qué códec o qué combinación de códecs se utiliza. Todos los modos de códec aplicables a las velocidades de bits respectivas corresponden a tales combinaciones entre las combinaciones de la figura 19A (primer ejemplo). Por ejemplo, en la figura 20A, supongamos que el valor del índice de tipo de trama es 1 (velocidad de bits: 12 kbps). En este caso, el contenido de la trama puede ser una combinación del Índice de tipo de trama "0" (12 kbps en el esquema X) que corresponde al códec para el cual la velocidad de bits en la figura 19A se convierte en 12 kbps, "3" (12 kbps en el esquema Y) o "5" (parte básica de 8 kbps y primera parte expandida de 4 kbps en el esquema Y). Sin embargo, cuando la figura 20A corresponde solo al códec en el esquema Y, hay dos posibilidades: Índice de tipo de trama "3" (12 kbps en el esquema Y) e Índice de tipo de trama "5" (parte básica de 8 kbps, y primera parte expandida de 4 kbps en el esquema Y). Un codificador determina qué combinación debe seleccionarse entre estas combinaciones de esquema de códec y velocidad de bits, indicando la información la combinación determinada por el codificador puede incluirse en los datos codificados.
La figura 20B es un ejemplo del formato de carga útil RTP en un segundo ejemplo. Como se muestra en la figura 20B, además de la porción de datos de la carga útil RTP, la porción del encabezado de la carga útil RTP incluye el índice de tipo de trama, Q bit, solicitud de modo de códec y bit R como información sobre la carga útil RTP. La porción de datos de la carga útil RTP incluye datos codificados de una trama y bits de relleno añadidos para ajustar la longitud de la carga útil RTP. Se usa el índice de tipo de trama de la porción de encabezado de la carga útil RTP indica qué velocidad de bits en la figura 19A. El bit Q es equivalente al bit Q descrito en NPL 1.
Se usa la solicitud de modo de códec es un campo para solicitar al interlocutor que cambie el modo de códec (velocidad de bits) y el Índice de tipo de trama en la figura 20B. El codificador del interlocutor que ha recibido la solicitud de modo de códec selecciona y codifica una combinación óptima de las combinaciones de códecs que proporcionan velocidades de bits especificadas. Por ejemplo, cuando el valor del índice de tipo de trama indicado por la solicitud de modo de códec es 1 (12 kbps), el contenido de la trama puede ser una combinación del Índice de tipo de trama "0", "3" o "5" en la figura 19A. Sin embargo, cuando la figura 20A solo corresponde a un códec en el esquema Y, hay dos posibilidades: Índice de tipo de trama "3" (12 kbps en el esquema Y) y "5" (parte básica de 8 kbps y primera parte expandida de 4 kbps en el esquema Y). El codificador realiza la codificación utilizando la combinación determinada como óptima entre las posibles combinaciones.
El bit R que se muestra en la figura 20B es un campo que indica una solicitud que la solicitud de modo de códec no puede solicitar a la otra parte. Por ejemplo, el bit R indica una especificación del número de canales (por ejemplo, mono = "0", estéreo = "1") o una especificación de retraso (por ejemplo, retraso A = "0" y retraso B = "1"). Por ejemplo, para indicar tanto el número de canales como el retraso, el bit R puede tener 2 bits o más. Este bit R puede no existir necesariamente en la porción de encabezado de la carga útil RTP cuando la demora o el número de canales no cambian durante la comunicación.
Asimismo, con respecto al modo de retraso, el modo de retraso también puede incluirse en la tabla de la figura 20A y el índice de tipo de trama se puede asignar. Por ejemplo, el retraso A se asigna con respecto a las velocidades binarias asignadas a los índices de tipo de trama "0" a "8". Asimismo, el valor del Índice de tipo de trama mostrado en la figura 20A puede ampliarse a 31 y puede asignarse un retraso B con respecto a las velocidades binarias asignadas a los índices de tipo de trama "11" a "19" (no mostrado). Además, cuando el modo de retraso no está incluido en la tabla de la figura 20A, un bit que indica el modo de retraso puede incluirse en la porción de encabezado de la carga útil RTP para el lado de codificación (el propio lado del terminal). Asimismo, el número de canales en el lado de codificación (el propio lado del terminal) también puede incluirse en la tabla de la figura 20A (expandiendo el valor del Índice de tipo de trama) como en el caso del modo de retraso. Un bit que indica la especificación del número de canales puede incluirse en la porción de encabezado de la carga útil RTP o puede incluirse en los propios datos codificados.
Al especificar solo la velocidad de bits del códec como se muestra en el segundo ejemplo, el lado de la codificación puede realizar una codificación óptima y reducir la cantidad de bits del índice de tipo de trama y la solicitud de modo de códec en la porción de encabezado de la carga útil RTP. Asimismo, al incluir la solicitud de modo de códec en la porción de encabezado de la carga útil de RTP, una solicitud de cambio de modo de códec (o conjunto de modos de códec) puede transmitirse rápidamente al interlocutor. Sin embargo, cuando la solicitud del interlocutor para cambiar rápidamente el modo de códec (o el conjunto de modos de códec) no es necesaria y cuando la solicitud de modo de códec y el bit R son necesarios, estos pueden no estar incluidos en la porción de encabezado de la carga útil RTP, pero puede incluirse en RTCP y notificarse al interlocutor. Asimismo, se puede enviar simultáneamente una pluralidad de tramas (datos codificados de 1 trama) (en un paquete IP). En este caso, de una pluralidad de tramas enviadas simultáneamente, puede incluirse un bit para identificar qué trama es la última trama en la porción de encabezado de la carga útil RTP. Asimismo, los bits y campos incluidos en la porción de encabezado de la carga útil RTP no se limitan a los que se muestran en este ejemplo.
La figura 21 es un tercer ejemplo que ilustra la numeración (Índice de tipo de trama) de un modo de códec (la velocidad de bits y el tipo de este en este ejemplo) y un formato de carga útil RTP en la presente realización.
Como se muestra en la figura 21A, se asignan diferentes índices de tipo de trama a las partes básicas del códec de velocidad múltiple y códec escalable, y las partes expandidas respectivas del códec escalable.
La figura 21B es un ejemplo del formato de carga útil RTP en el tercer ejemplo.
En el tercer ejemplo, como se muestra en la figura 21, se agrega una porción de encabezado de la carga útil RTP a cada capa (parte básica, primera parte expandida, segunda parte expandida) en el códec escalable. En la figura 21B, un bit C incluido en la porción de encabezado de la carga útil RTP indica si existe o no una parte expandida posterior. De esta manera, la parte básica y cada parte expandida pueden enviarse como paquetes IP separados. Esto proporciona una ventaja de que los paquetes IP de la parte expandida con baja prioridad pueden descartarse cuando la red o el período de acceso inalámbrico o similares están congestionados.
La solicitud de modo de códec y un bit Q pueden agregarse solo a la porción de encabezado de cada carga útil RTP o porción de encabezado de la carga útil RTP de la parte básica. La descripción del modo de retardo y el procedimiento de solicitar al interlocutor que se comunica que cambie el modo de códec (o conjunto de modos de códec) son similares a los del primer ejemplo (figura 19) y el segundo ejemplo (figura 20). Asimismo, se puede enviar una pluralidad de tramas simultáneamente (en un paquete IP). En este caso, la porción de encabezado de la carga útil RTP puede incluir un bit para identificar cuál de la pluralidad de tramas enviadas simultáneamente es la última. Asimismo, los bits y campos incluidos en la porción de encabezado de la carga útil RTP no se limitan a los que se muestran en este ejemplo.
Se ha proporcionado un ejemplo en este ejemplo como se muestra en la figura 21A, donde se dan una serie de índices de tipo de trama a las velocidades binarias respectivas o los tipos de velocidades binarias en el esquema X (por ejemplo, códec de velocidad múltiple) y esquema Y (por ejemplo, códec escalable). Es decir, se ha descrito un ejemplo en el que el esquema X y el esquema Y pueden tratarse como si fueran un esquema de códec idéntico. Sin embargo, el índice de tipo de trama y el formato de carga útil también se pueden dar al esquema X y al esquema Y por separado y usarse de forma independiente.
Se ha descrito un ejemplo en la presente realización donde se incluye un bit Q, pero el bit Q se puede omitir.
(Realización 5)
La presente realización se refiere a un formato de carga útil RTP preferible y a un procedimiento de procesamiento del mismo cuando la longitud de la carga útil RTP está limitada a una pluralidad de longitudes fijas y cuando puede haber una pluralidad de combinaciones que representan una velocidad de bits (o velocidades de bits a su alrededor). Esto corresponde, por ejemplo, a un caso con el esquema Y descrito en la Realización 4.
Un ejemplo en el que la longitud de la carga útil RTP se limita a una pluralidad de longitudes fijas es un caso en el que se define un tamaño de bloque de transmisión como en el caso de un período inalámbrico de una red de telefonía móvil.
La figura 22 es un primer ejemplo que ilustra la numeración (Índice de tipo de trama) de un modo de códec y un formato de carga útil RTP en la presente realización.
En el primer ejemplo, la numeración (asociación con el índice de tipo de trama) se realiza en una velocidad de bits bruta. En este punto, se supone que una velocidad de bits bruta es una longitud de carga útil RTP convertida a la cantidad de kilobits por segundo (kbps: kilobits por segundo). La figura 22A muestra un ejemplo de numeración en la velocidad de bits bruta.
Asimismo, en el primer ejemplo, información o parte de la información incluida en la porción de encabezado de la carga útil RTP (por ejemplo, el campo de solicitud de modo de códec) puede seleccionarse mediante negociación (oferta y respuesta de s Dp ) cuando comienza una llamada. En este momento, cuando se selecciona un modo de códec (o conjunto de modos de códec) (rango de velocidades de bits utilizadas o modo de retardo o similar) en las Realizaciones 1 y 3, la información o parte de la información incluida en la parte de encabezado de la carga útil RTP se puede seleccionar de acuerdo con este modo de códec seleccionado (o conjunto de modos de códec).
Por ejemplo, cuando el rango bajo de velocidades binarias se usa como "comunicación normal" descrita en la figura 9 y la figura 15, se realiza una selección de no incluir el campo de solicitud de modo de códec en la porción de encabezado de la carga útil RTP para suprimir la proporción de la porción de encabezado de la carga útil RTP a un nivel pequeño.
La figura 22B muestra un ejemplo del formato de carga útil RTP cuando se decide que el campo de solicitud de modo de códec no se incluya en la parte de encabezado de la carga útil RTP de antemano mediante negociación o política de un operador de servicio o similar cuando comienza una llamada. Asimismo, la figura 22C muestra un ejemplo del formato de carga útil RTP cuando se decide que el campo de solicitud de modo de códec se incluya en la parte de encabezado de la carga útil RTP de antemano mediante negociación o política de un operador de servicio o similar cuando comienza una llamada. En la figura 22B y la figura 22C, un bit Q incluido en la porción de encabezado de la carga útil RTP es equivalente al bit Q descrito en NPL 1 y es un indicador de la calidad de trama.
El lado del codificador determina una velocidad de bits correspondiente a la longitud de la porción de datos de la carga útil RTP determinada por el índice de tipo de trama y la longitud de la porción de encabezado de la carga útil RTP, y una combinación de los mismos, entre velocidades de bits soportadas por el esquema de códec correspondiente y sus combinaciones. En este punto, la longitud de la porción de encabezado de la carga útil RTP se determina de antemano mediante la negociación o la política de un operador de servicio o similar cuando comienza una llamada. La información que indica la combinación determinada por el codificador puede incluirse en los datos codificados. Cuando la velocidad de bits del códec no cambia desde el principio hasta el final de la comunicación a través de la política de un operador de servicios o similar, la porción de encabezado de la carga útil RTP no necesita incluir el índice de tipo de trama. Una determinada velocidad de bits en este caso puede determinarse mediante negociación cuando se inicia una llamada o puede determinarse de antemano por la política de un operador de servicios o similar.
La figura 23 muestra un ejemplo de numeración de modo de códec (Índice de tipo de trama) y un formato de carga útil RTP (denominado segundo ejemplo en la presente realización) cuando la información incluida en la porción de encabezado de la carga útil r Tp se determina de antemano. Esto es, en concreto, un caso en el que la información incluida en la porción de encabezado de la carga útil RTP como en el primer ejemplo (figura 22) de la presente realización no se determina mediante negociación cuando comienza la comunicación, pero la longitud de la parte de encabezado de la carga útil RTP se determina de antemano.
En este ejemplo, como se muestra en la figura 23A, la numeración (asociación con el índice de tipo de trama) se realiza en tasas de bits obtenidas al convertir la longitud de la porción de datos de la carga útil RTP a la cantidad de kilobits por segundo (kbps: kilobits por segundo). En este ejemplo, los datos codificados de 1 trama por 20 milisegundos se convierten en un paquete RTP. Es decir, se generan 50 paquetes RTP por segundo. Asimismo, la longitud de la porción de encabezado de la carga útil RTP es de 5 bits cuando la velocidad de bits bruta mostrada en la figura 22A es 7,2 kbps, 8 kbps o 9,6 kbps, y 8 bits cuando la velocidad de bits bruta es 13,2 kbps, 16,4 kbps o 24,4 kbps. El número de paquetes RTP por segundo, la longitud de la porción de encabezado de la carga útil, y la correspondencia entre la velocidad de bits bruta y la longitud de la porción de encabezado no se limitan a estos.
La figura 23B y la figura 23C muestran ejemplos del formato de carga útil RTP cuando se incluye el campo de solicitud de modo de códec y cuando no se incluye, respectivamente. Este ejemplo muestra un ejemplo de un caso en el que se supone que el campo Índice de tipo de trama, que es información que se puede incluir en la porción de encabezado de la carga útil RTP, tiene 4 bits, el campo Q bit tiene 1 bit y el campo de solicitud de modo de códec tiene 3 bits.
El campo de Índice de tipo de trama contiene el Índice de tipo de trama correspondiente en la figura 23A. El campo bit Q es equivalente al bit Q descrito en NPL 1. Asimismo, el campo de solicitud de modo de códec contiene "0" a "5" (es decir, solo información necesaria para solicitar al interlocutor que cambie la velocidad de bits) del Índice de tipo de trama en la figura 23A. Asimismo, el campo de solicitud de modo de códec puede usar "6" o "7" como un valor que indica que no hay cambio en la velocidad de bits con respecto al codificador del interlocutor. Cada longitud de campo de la porción de encabezado de la carga útil RTP de este ejemplo o el valor correspondiente no necesita limitarse a esto y la información (campo) incluida en la porción de encabezado de la carga útil RTP en este ejemplo tampoco se limita a esto.
En el primer ejemplo (figura 22) y el segundo ejemplo (figura 23) de la presente realización, la velocidad de bits bruta o la longitud de la porción de datos de la carga útil RTP correspondiente a la velocidad de bits bruta solo se especifican como Índice de tipo de trama. De ese modo, el lado de codificación puede realizar una codificación óptima de acuerdo con la longitud de la porción de datos de la carga útil RTP y reducir el número de bits del índice de tipo de trama en la porción de encabezado de la carga útil RTP.
Asimismo, la longitud de la porción de encabezado de la carga útil RTP se ajusta. Al hacerlo, es posible determinar la longitud de la porción de datos de la carga útil RTP y realizar una codificación adecuada de acuerdo con el rango de velocidades de bits determinadas por las características de la ruta de transmisión o similar (modo de códec (o conjunto de modos de códec) de las Realizaciones 1 a 3). Cuando el campo de Solicitud de modo de códec no se incluye en la porción de encabezado de la carga útil de RTP y cuando es necesario notificar al codificador del lado del interlocutor un cambio en la velocidad de bits, se notifica el cambio de usar RTCP.
(Realización 6)
La presente realización describirá un procedimiento para seleccionar un modo de códec (o conjunto de modos de códec) usando la política de un operador que proporciona a cada UE un servicio de comunicación/llamada.
Ejemplos de la política del operador incluyen códec (esquema de códec) de uso preferencial, velocidad de bits de códec utilizada preferentemente, frecuencia de muestreo utilizada preferentemente, banda de audio utilizada preferentemente (por ejemplo, NB, WB, SWB, FB), demora algorítmica de preferencia y número de canales de preferencia. Asimismo, otros ejemplos de la política del operador incluyen si se permite o no que se cambie la velocidad de bits o el número de canales en medio de una sesión, si se permite o no la operación de velocidad de bits variable controlada por la fuente (VBR) (por ejemplo, consulte "3GPP2 C.S0052-A Versión 1.0 "Source-Controlled Variable-Rate Multimode Wideband Speech Codec (VMR- WB)""), si se permite o no el traspaso a una red de conmutación de línea (por ejemplo, consulte "3GPP TS23.216 v9.6.0 "Single Radio Voice Call Continuity (SRVCC); Etapa 2"") y si se permite o no una trama redundante como se describe en NPL 2.
El UE adquiere la totalidad o parte de la política del operador antes de que comience una llamada, es decir, antes de realizar el procesamiento en ST11 mostrado en la figura 2 y genera una oferta de SDP basada en la política adquirida.
Como procedimiento de adquisición (total o parcial) de una política, por ejemplo, se puede adoptar una técnica que haga que (total o parcialmente) la política se incluya en la señalización enviada desde la red del operador al UE y adquiera la política a partir de dicha señalización.
Esta señalización puede ser, por ejemplo, SIB (bloque de información del sistema, por ejemplo, ver "3GPP TS 36.331 v10.0.0, "Evolved Universal Terrestrial Radio Access (E-UTRA) Radio Resource Control (RRC) Protocol specification""). Asimismo, esta señalización puede ser, por ejemplo, señalización cuando se establece la conexión RRC (Control de recursos de radio) (por ejemplo, configuración de conexión RRC descrita en "3GPP TS 36.331 v10.0.0, "Evolved Universal Terrestrial Radio Access (E-UTRA) Radio Resource Control (RRC) Protocol specification"").
Asimismo, la política puede enviarse junto con la señalización SIP de un IMS como el mensaje de respuesta (200OK) para registrarse (por ejemplo, consulte "3GPP TS 23.228 v10.3.1, "IP Multimedia Subsystem (iMs) Stage 2""). Asimismo, la política también puede incluirse en, por ejemplo, un mensaje de respuesta de búsqueda P-CSCF. Cuando la política se envía al UE mediante un mensaje de respuesta, un parámetro que indica que existe la capacidad de recibir la política del operador utilizando un mensaje de respuesta puede agregarse al mensaje de solicitud del UE (por ejemplo, solicitud de conexión RRC descrita en "3GPP TS 36.331 v10.0.0, "Evolved Universal Terrestrial Radio Access (E- UTRA) Radio Resource Control (RRC) Protocol specification"" o el registro descrito en "3GPP TS 23.228 v10.3.1, "IP Multimedia Subsystem (IMS) Stage 2"").
Asimismo, como otro procedimiento para adquirir una política, el UE también puede determinar (total o parcialmente) la política del operador a partir de la información relacionada con la política que el UE posee localmente en función de la información enviada desde la red del operador al UE. Por ejemplo, el UE posee localmente (total o parcialmente) una política para cada operador, adquiere, cuando está conectado a la red de un determinado operador, información relacionada con el operador (información del operador) y selecciona (total o parcialmente) la política del operador correspondiente de una base de datos local. Se adquiere la información del operador adquirida cuando el Ue está conectado a la red del operador, por ejemplo, de ID de célula (por ejemplo, ver "3GPP TS 23.003 v10.0,0, "Numbering, addressing and identification (Release 10)"").
Asimismo, como un procedimiento adicional para adquirir una política, el UE puede seleccionar una velocidad de bits de códec utilizada preferentemente para una llamada en función de la información de QoS (por ejemplo, ver "3GPP TS 23.401 v10.2.1, "Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access (Release 10)"") permitió una llamada para cada usuario, enviado cuando el UE está conectado a la red del operador.
A continuación, se mostrará un ejemplo del procedimiento de generación de un SDP basado en una política adquirida del operador.
La figura 24 muestra una política del operador (operador A) conectado al UE del lado llamante (figura 24A) y un ejemplo de generación de oferta de SDP por el UE del lado llamante (figura 24B). Asimismo, la figura 25 muestra una política de un operador (operador B) conectado al UE del lado llamado (figura 25A) y un ejemplo de generación de una respuesta de SDP por el UE del lado llamado (figura 25B). En
la figura 24 y la figura 25, valores predeterminados de cada esquema descrito, por ejemplo, en NPL 2 se aplican a artículos y valores o similares que no se describen en la política o SDP. Por otra parte, los procedimientos para describir la política y el SDP que se muestran en la figura 24 y la figura 25 son ejemplos, y también se pueden adoptar otros procedimientos de descripción.
Por ejemplo, como se muestra en la figura 24A, la política del operador A incluye una política (en adelante denominada "política A1") con "códec: esquema 1, banda de audio: SWB, velocidad de bits: [12 kbps, 24 kbps] y VBR: habilitado ". Asimismo, la política del operador A incluye una política (en adelante denominada "política A2") con "códec: esquema 1, banda de audio: WB, velocidad de bits: [12 kbps, 24 kbps] y VBR: habilitado ". Asimismo, la política del operador A incluye una política (en adelante denominada "política A3") con "códec: esquema 2, banda de audio: NB, velocidad de bits: [8 kbps, 12 kbps] y VBR: deshabilitado ".
De esta manera, el UE del lado llamante crea una oferta de SDP que incluye un candidato para el modo de códec (o conjunto de modos de códec) correspondiente a al menos parte de la política (aquí, la política del operador A mostrada en la figura 24A) de un operador que proporciona un servicio de comunicación o llamada al UE del lado llamante.
Por ejemplo, tal como se muestra en la figura 24B, el UE del lado llamante selecciona un candidato para el conjunto de modos de códec, que es parte de la política A1 mostrada en la figura 24A, correspondiente al códec: esquema 1, banda de audio: SWB, velocidad de bits: {12, 24} kbps. Para ser más específicos, candidatos para dos conjuntos de modos de códec (a = rtpmap: 97 y 98) se crean que corresponden al códec: esquema 1, banda de audio: SWB, velocidad de bits: [12 kbps, 24 kbps] y VBR: Sí (habilitado) o VBR: No (deshabilitado) mostrado en la figura 24B.
De manera similar, tal como se muestra en la figura 24B, el UE del lado llamante selecciona un candidato para el conjunto de modos de códec, que es parte de la política A2 mostrada en la figura 24A, correspondiente al códec: esquema 1, banda de audio: WB, velocidad de bits: {12,24} kbps. Para ser más específicos, candidatos para dos conjuntos de modos de códec (a = rtpmap: 99 y 100) se crean que corresponden al códec: esquema 1, banda de audio: WB, velocidad de bits: [12 kbps, 24 kbps] y VBR: Sí (habilitado), o VBR: No (deshabilitado) mostrado en la figura 24B.
De manera similar, tal como se muestra en la figura 24B, el UE del lado llamante crea un candidato para el conjunto de modos de códec (a = rtp- map: 101) correspondiente al códec: esquema 2, banda de audio: NB, velocidad de bits:
[8 kbps, 12 kbps] y VBR: No (deshabilitado), que es la política completa A3 mostrada en la figura 24A.
Como se muestra en la figura 24B, los candidatos para una pluralidad de modos de códec (o conjuntos de modos de códec) incluidos en una oferta de SDP notificada desde el UE del lado llamante al UE del lado llamado incluyen candidatos para el modo de códec (o conjunto de modos de códec) correspondiente al menos a parte de la política de un operador que proporciona un servicio de comunicación o llamada al UE del lado llamante.
Por otra parte, como se muestra en la figura 25A, la política del operador B incluye una política (en adelante denominada "política B1") con "códec: esquema 1, banda de audio: WB, velocidad de bits: 12 kbps y VBR: No (VBR deshabilitado)". Asimismo, la política del operador B incluye una política (en adelante denominada "política B2") con "códec: esquema 2, banda de audio: NB, velocidad de bits: 12 kbps y VBR: No (VBR deshabilitado)".
A continuación, el UE del lado llamado selecciona un conjunto de modos de códec utilizado para comunicarse con el UE del lado llamante entre los candidatos para el conjunto de modos de códec correspondiente a al menos parte de la política del operador B que se muestra en la figura 25A de entre los candidatos para el conjunto de modos de códec incluido en la oferta de SDP mostrada en la figura 24B notificado del UE del lado llamante.
Para ser más específicos, en la figura 25B, el UE del lado llamado selecciona un candidato (códec: esquema 1, banda de audio: WB, velocidad de bits: 12 kbps, y, VBR: No (deshabilitado)) para el conjunto de modo de códec de toda la política B1 que se muestra en la figura 25A, como un conjunto de modos de códec utilizado para comunicarse con el UE del lado llamante.
El procedimiento de selección de modo de códec (o conjunto de modos de códec) en la presente realización puede usarse junto con los procedimientos de selección de modo de códec (o conjunto de modos de códec) mostrados en las Realizaciones 1 a 3.
De acuerdo con la presente realización, esto permite que el UE del lado llamante limite un modo de códec (o conjunto de modos de códec) o similar descrito en la oferta de SDP de acuerdo con la política del operador conectado al UE del lado llamante. Asimismo, el UE del lado llamado puede limitar un modo de códec (o conjunto de modos de códec) o similar seleccionado como modo de códec (o conjunto de modos de códec) utilizado para comunicarse con el UE del lado llamante de acuerdo con la política del operador conectado al UE del lado llamado. Esto puede evitar una negociación SDP complicada entre el UE del lado llamante y el UE del lado llamado. Asimismo, el operador puede hacer que el UE seleccione un servicio (códec) basado en la política.
(Realización 7)
La presente realización describirá un procedimiento de selección de modo de códec (o conjunto de modos de códec) usando un ejemplo de configuración de red que es diferente de las configuraciones de red utilizadas en las Realizaciones 1 a 3.
La figura 26 es un diagrama que ilustra configuraciones de red y un ejemplo de una relación posicional entre UE (terminales) de acuerdo con la presente realización. En la figura 26, como el UE 100, el UE 102, la red 124 central IP y la red 126 IMS son idénticas a las de la figura 1, se les asignarán números de referencia idénticos y se omitirán sus descripciones.
AP 2600 y AP 2602 mostrados en la figura 26 son puntos de acceso, y constituyen la red 2606 de acceso inalámbrico y la red 2608 de acceso inalámbrico respectivamente. Por ejemplo, A p 2600 y 2602 también pueden ser puntos de acceso para Wi-Fi, WiMAX o similar, o pueden ser los HeNB mostrados en la figura 1.
IP-PBX 2604 está conectado a AP 2600 y AP 2602, y es un aparato (nodo de red que tiene una función de procesamiento para el control de llamadas) que implementa una red telefónica interna utilizando teléfonos IP en una LAN dentro de una organización como una empresa. Por ejemplo, IP-PBX 2604 tiene una función de conexión con la red IMS de un operador o parte de la función de la red IMS del operador (por ejemplo, ver "3GPP TS 22.809 v1,0,0, Feasibility Study on Support for 3GPP Voice Interworking with Enterprise IP- PBX (VINE)""). Asimismo, IP-PBX 2604 está conectado al servidor 2612 ubicado dentro de la red 126 IMS del operador, a través de una red 2610 IP externa tal como una red de banda ancha de un proveedor de Internet o similar. Asimismo, IP-PBX 2604 también puede tener una función (no mostrada) que finaliza una función de puerta de enlace o señalización IMS con una red 2610 IP externa.
El servidor 2612 puede ser un CSCF tal como S-CSCF 100 mostrado en la figura 1 o AS (servidor de aplicaciones, descrito en, por ejemplo, "3GPP TS 23.228 v10.3.1, "IP Multimedia Subsystem (IMS) Stage 2") o ambos, o puede ser un aparato que conecta el CSCF o AS con IP-PBX 2604.
AP 2614 es un punto de acceso conectado a la red 124 central IP. AP 2614 también puede ser una estación base (eNB o HeNB). Asimismo, AP 2614 también puede ser un punto de acceso para Wi-Fi o WiMAX o similares (por ejemplo, ver "3GPP TS 23.402 v10.2.1, "Architecture enhancements for non- 3GPP accesses"").
En la figura 26, el UE 100 está conectado al AP 2600 dentro de la red 2606 de acceso inalámbrico. En este momento, se supone que, por ejemplo, la sección 604 de determinación del destino de conexión del UE 100 (figura 7) determina que el UE 100 está conectado a una red de acceso inalámbrico (red 2606 de acceso inalámbrico) que constituye una LAN dentro de una organización tal como una compañía. Cuando el AP 2600 es un HeNB, la sección 604 de determinación de destino de conexión puede determinar el destino de conexión usando una ID de CSG o similar como en el caso de la Realización 1. Asimismo, cuando el AP 2600 es un punto de acceso de LAN inalámbrico para Wi-Fi o similar, la sección 604 de determinación del destino de la conexión puede determinar el destino de la conexión utilizando un SSID (Identificador de conjunto de servicios) o similar.
En la presente realización, cuando el UE 100 (lado llamante) realiza una llamada al UE 102 (lado llamado), el UE 100 puede seleccionar un modo de códec (o conjunto de modos de códec) descrito en una oferta de SDP de acuerdo con una determinación de la sección 604 de determinación de destino de conexión (figura 7, figura 13) como en el caso de las Realizaciones 1 a 3. Asimismo, en lugar de que el UE 100 seleccione el modo de códec (o conjunto de modos de códec), IP-PBX 2604 puede seleccionar el modo de códec (o conjunto de modos de códec).
La figura 27 es un diagrama de bloques que ilustra una configuración de IP-PBX 2604 de acuerdo con la presente realización.
En IP-PBX 2604 que se muestra en la figura 27, al recibir un mensaje de señalización del UE del lado llamante (aquí, UE 100), la sección 2700 de recepción envía el mensaje de señalización a la sección 2704 de interceptación de señalización.
La sección 2702 de transmisión transmite el mensaje de señalización introducido desde la sección 2710 de generación de señalización a un UE (UE del lado llamado; UE 102 aquí) que es el destino del mensaje de señalización.
Incluso si el mensaje de señalización ingresado desde la sección 2700 de recepción no se dirige a su propio terminal (dirección IP de IP-PBX 2604), la sección 2704 de interceptación de señalización intercepta temporalmente el mensaje de señalización. La sección 2704 de interceptación de señalización envía el mensaje de señalización interceptada a la sección 2706 de análisis de señalización.
La sección 2706 de análisis de señalización analiza la información descrita en el mensaje de señalización introducido y envía información que requiere confirmación a una sección de confirmación apropiada. Por ejemplo, la sección 2706 de análisis de señalización entrega información de destino de llamada de la información descrita en el mensaje de señalización a la información de posición del terminal que confirma la sección 2708 para determinar si una red de acceso inalámbrico a la que está conectado actualmente el UE del lado llamado (UE 102) está bajo el control de IP-PBX 2604.
La sección 2708 de conformación de información de posición del terminal confirma si la red de acceso inalámbrico a la que está actualmente conectado el UE del lado llamado (UE 102) está bajo el control de IP-PBX 2604 (por ejemplo, si el UE 102 está o no conectado a una red telefónica interna idéntica). Esta confirmación se realiza basándose en la información de destino de la llamada recibida de la sección 2706 de análisis de señalización. En este momento, la sección 2708 de confirmación de información de posición del terminal puede confirmar utilizando información de registro o similar del UE 102 en IP-PBX 2604 o confirmar utilizando toda o parte de la información de registro o similar del UE 102 ubicado en la red 126 del IMS a través del servidor 2612. Como alternativa, la sección 2708 de confirmación de información de posición del terminal puede hacer la confirmación usando ambas partes de la información. La sección 2708 de confirmación de información de posición del terminal envía el resultado de confirmación a la sección 2710 de generación de señalización.
La sección 2710 de generación de señalización sobrescribe o crea de nuevo contenido de descripción que requiere la corrección del mensaje de señalización transmitido desde el UE del lado llamante (UE 100). Por ejemplo, suponga que la sección 2708 de confirmación de información de posición del terminal determina que el UE del lado llamado (UE 102) está ubicado dentro de una red telefónica interna idéntica (bajo el control de IP-PBX 2604 aquí). En este caso, la sección 2710 de generación de señalización describe o sobrescribe los contenidos de descripción de la oferta de SDP en el mensaje de señalización para incluir el modo de códec (o conjunto de modos de códec) o similares utilizados para una llamada dentro de la red telefónica interna idéntica. En este caso, la sección 2710 de generación de señalización puede agregar información que indica que IP-PBX 2604 ha confirmado la oferta de SDP, al mensaje de señalización utilizando un procedimiento de descripción como un indicador, valor numérico y texto.
Asimismo, supongamos que la sección 2708 de confirmación de información de posición del terminal determina que el UE del lado llamado (Ue 102) está ubicado, por ejemplo, fuera de la red telefónica interna idéntica (aquí bajo el control de IP-PBX 2604). En este caso, la sección 2710 de generación de señalización también puede describir o sobrescribir nuevamente los contenidos de descripción de la oferta de SDP en el mensaje de señalización para incluir un modo de códec (o conjunto de modos de códec) o similares utilizados para una llamada normal. En este caso, la sección 2710 de generación de señalización puede agregar información que indica que IP-PBX 2604 ha confirmado la oferta de SDP, al mensaje de señalización utilizando un procedimiento de descripción como un indicador, valor numérico y texto.
El mensaje de señalización recién creado o corregido se transmite al destino del mensaje de señalización (UE 102) a través de la sección 2702 de transmisión.
Se supone que el UE del lado llamado (UE 102) que ha recibido el mensaje de señalización determina que el destino de la conexión (red de acceso inalámbrico) al que está conectado el UE 102 es una red de acceso inalámbrico que constituye una LAN en una organización como una empresa, y determina que la IP-PBX ha confirmado la oferta de SDP en el mensaje de señalización recibido. En este caso, el UE del lado llamado (UE 102) se refiere a la oferta de SDP (oferta de SDP sobrescrita o recién creada por IP-PBX 2604) y selecciona un modo de códec (o conjunto de modos de códec) o similar utilizado para una llamada en la misma red telefónica de la casa. En este caso, el UE del lado llamado (UE 102) puede seleccionar un modo de códec (o conjunto de modos de códec) usando la presencia o ausencia de una posibilidad de traspaso o similar, como en el caso de la Realización 3.
Por otra parte, se supone que el UE del lado llamado (UE 102) ha determinado que el destino de la conexión (red de acceso inalámbrico) al que está conectado el UE 102 es una red de acceso inalámbrico que constituye una LAN en una organización como una empresa, pero no ha determinado con éxito que la oferta de SDP en el mensaje de señalización recibido haya sido confirmada por el IP-PBX. En este caso, el UE del lado llamado (UE 102) también puede seleccionar un modo de códec (o conjunto de modos de códec) o similar utilizado para la comunicación normal 0 una llamada normal entre los candidatos de modo de códec (o conjunto de modos de códec) descritos en la oferta de SDP.
Asimismo, cuando el destino de la conexión del UE del lado llamado (UE 102) está fuera de una red de acceso inalámbrico que constituye una LAN en una organización como una empresa, el UE del lado llamado (UE 102) aplica un procedimiento de selección de modo de códec (o conjunto de modos de códec) similar a los de las Realizaciones 1 a 3.
El UE del lado llamado (UE 102) genera una respuesta de SDP que incluye el modo de códec seleccionado (o conjunto de modos de códec) y transmite la respuesta de SDP al UE del lado llamante (UE 100).
De esta manera, de acuerdo con la presente realización, cuando la red de acceso inalámbrico a la que está conectado actualmente el UE del lado llamado está bajo el control de IP-PBX 2604, el IP-PBX 2604 cambia (crea o sobrescribe) una pluralidad de candidatos de modo de códec (o conjunto de modos de códec) que se muestran en la oferta de SDP notificada desde el UE del lado llamante y genera una nueva oferta de SDP. El UE del lado llamado luego selecciona un modo de códec (o conjunto de modos de códec) utilizado para comunicarse con el UE del lado de la llamada entre la pluralidad de candidatos de modo de códec (o conjunto de modos de códec) incluidos en la oferta de SDP modificada en el IP-PBX 2604.
De esta manera, cuando la red de acceso inalámbrico a la que está conectado actualmente el UE del lado llamado está bajo el control de IP-PBX 2604, es posible limitar los candidatos para el modo de códec (o conjunto de modos de códec) descrito en la oferta de SDP o similar a un modo de códec apropiado (o conjunto de modos de códec) (por ejemplo, modo de códec (o conjunto de modos de códec) o similar utilizado para una llamada dentro de una red telefónica interna idéntica) para el UE bajo el control de IP-PBX 2604. Esto hace posible evitar una negociación SDP complicada entre el UE del lado llamante y el UE del lado llamado.
Asimismo, el IP-PBX 2604 transmite información que indica si una oferta de SDP está o no confirmada, al UE del lado llamado. Al determinar que el IP-PBX 2604 ha confirmado la oferta de SDP, el UE del lado llamado selecciona un modo de códec (o conjunto de modos de códec) utilizado para comunicarse con el UE del lado llamante entre una pluralidad de candidatos de modo de códec (o conjunto de modos de códec) incluidos en la oferta de SDP modificada que se modifica en el IP-PBX 2604.
Esto hace posible determinar con precisión si el UE está o no bajo el control del IP-PBX 2604 (red telefónica interna idéntica). Cuando, por ejemplo, el UE está ubicado bajo el control de IP-PBX 2604 (red telefónica interna idéntica), el UE puede seleccionar un modo de códec (o conjunto de modos de códec) limitando el modo de códec a un modo de códec (o conjunto de modos de códec) utilizado para una llamada dentro de la red telefónica interna idéntica o similar. Asimismo, cuando, por ejemplo, el UE no está ubicado bajo el control del IP-PBX 2604 (dentro de la red telefónica interna idéntica), el UE puede seleccionar un modo de códec (o conjunto de modos de códec) limitando el modo de códec a un modo de códec (o conjunto de modos de códec) utilizado para la comunicación normal (llamada normal) o similar.
Al hacerlo, la presente realización puede determinar con precisión un UE ubicado dentro de una red telefónica interna idéntica y permite que el UE seleccione un modo de códec adecuado (o conjunto de modos de códec) o similar.
Se ha descrito un caso en la presente realización donde el IP-PBX 2604 realiza una nueva descripción o sobrescritura con respecto a una oferta de SDP del UE del lado llamante. Sin embargo, en la presente realización, cuando el UE 102 se encuentra dentro de una red telefónica interna idéntica (bajo el control de IP-PBX 2604 aquí), el IP-PBX 2604 también puede realizar una nueva descripción o sobrescritura con respecto a una respuesta de SDP del UE del lado llamado como se describió anteriormente.
Asimismo, cuando el UE 100, el UE 102 y el IP-PBX 2604 crean o sobrescriben una oferta de SDP o una respuesta de SDP, la política de un operador también puede usarse como en el caso de la Realización 6.
(Realización 8)
La presente realización describirá cómo proporcionar un campo que no necesita ser incluido en las cargas útiles RTP (porción de encabezado o parte de una porción de datos) de todos los paquetes RTP con respecto al formato de carga útil RTP que se muestra en las Realizaciones 4 y 5.
Por ejemplo, hay un campo de solicitud de modo de códec que se muestra en las Realizaciones 4 y 5, o un campo para solicitar a un interlocutor que cambie entre modo/estéreo (especificación del número de canales) y un modo de retardo (especificación de retardo) o similar. Estos pueden incluirse en una carga útil RTP (porción de encabezado o parte de una porción de datos) solo cuando se genera una solicitud.
SID (Descriptor de inserción de silencio), sin datos y pérdida de voz descritos en NPL 3 o NPL 4 en la carga útil de RTP (porción de encabezado) no pueden incluirse como parte del Índice de tipo de trama descrito en la figura 19 a la figura 23 o similar. En este caso, solo cuando se genera una solicitud para enviar SID, sin datos, pérdida de voz o similar, la solicitud puede incluirse en la carga útil de RTP (la porción de encabezado o parte de la porción de datos).
La figura 28 muestra un ejemplo de un formato de carga útil RTP cuando se usa el índice de tipo de trama mostrado en la figura 23A. Aunque el SID descrito anteriormente no está incluido en el Índice de tipo de trama en la figura 23A, se supone que, por ejemplo, un SID se establece como Índice de tipo de trama de 8 aquí. La figura 28A muestra un ejemplo de un formato de carga útil RTP cuando el campo descrito anteriormente (el campo de solicitud de modo de códec o un campo para solicitar al interlocutor que cambie entre mono/estéreo, cambiar el modo de retraso o similar) no existe. La figura 28B muestra un ejemplo de un formato de carga útil RTP cuando existe el campo descrito anteriormente.
En este punto, la porción de encabezado de la carga útil RTP mostrada en la figura 28A tiene una longitud fija de, por ejemplo, un octeto. La porción de encabezado mostrada en la figura 28A incluye un "campo que indica la presencia o ausencia de una porción de encabezado posterior" de una longitud fija, campo "otro" e "Índice de tipo de trama" o similar. En este punto, la "porción de encabezado" y la "porción de encabezado posterior" pueden interpretarse como parte de la porción de datos de carga útil RTP.
El "campo que indica la presencia o ausencia de una porción de encabezado posterior" que se muestra en la figura 28A contiene información que indica si la porción del encabezado de una longitud fija mostrada en la figura 28A es seguido por otra porción de encabezado de longitud fija en forma de, por ejemplo, un indicador o valor numérico. En la figura 28A, como no existe otra porción de encabezado posterior, el "campo que indica la presencia o ausencia de una porción de encabezado posterior" contiene información que indica la "ausencia" de cualquier otra porción de encabezado posterior.
El campo "otro" mostrado en la figura 28A contiene cualquier campo que no sea tanto el "campo que indica la presencia o ausencia de una porción de encabezado posterior" como el "Índice de tipo de trama".
El "índice de tipo de trama" mostrado en la figura 28A contiene, por ejemplo, Índice de tipo de trama mostrado en la figura 23A.
La porción de datos de la carga útil RTP mostrada en la figura 28A contiene una velocidad de bits y una combinación apropiadas, y la información de combinación o similar seleccionada por el codificador como se muestra, por ejemplo, en la realización 5.
Por otra parte, el "campo que indica la presencia o ausencia de una porción de encabezado posterior" mostrado en la figura 28B contiene información que indica la "presencia" de otra porción de encabezado de longitud fija (encabezado posterior) después de la porción de encabezado de longitud fija mostrada en la figura 28B.
El campo "otro" y el "Índice de tipo de trama" mostrados en la figura 28B son equivalentes a los de la figura 28A.
El encabezado posterior que se muestra en la figura 28B tiene una longitud fija de, por ejemplo, un octeto. El encabezado posterior que se muestra en la figura 28B contiene el "tipo de un encabezado posterior" "contenido del encabezado posterior" y "otro" campo.
El "tipo de encabezado posterior" mostrado en la figura 28B muestra información que indica lo que indica el encabezado posterior en forma de, por ejemplo, un indicador o valor numérico. Por ejemplo, el "tipo de encabezado posterior" también puede mostrar solicitud de modo de códec, solicitud para cambiar el número de canales, como mono/estéreo o solicitud para cambiar el modo de retraso, y también puede mostrar datos redundantes para ocultar la pérdida de paquetes.
El "contenido del encabezado posterior" mostrado en la figura 28B contiene contenidos correspondientes al tipo que se muestra en el "tipo de un encabezado posterior". Por ejemplo, cuando el "tipo de encabezado posterior" es la solicitud de modo de códec, un valor que indica la velocidad de bits del códec que se solicitará al interlocutor (por ejemplo, Índice de tipo de trama mostrado en la figura 23A o similar) está contenido. Asimismo, cuando el "tipo de encabezado posterior" es una solicitud para cambiar el número de canales de mono/estéreo o similar o una solicitud para cambiar el modo de retardo o similar, información sobre el destino de conmutación solicitado (por ejemplo, se incluye información que indica el cambio a "mono" o información que indica el cambio a "retraso A" o similar). Asimismo, cuando el "tipo de encabezado posterior" son datos redundantes, la longitud de datos de los datos redundantes o similares está contenida.
Cuando el "contenido del encabezado posterior" descrito anteriormente puede determinarse de manera única por el "tipo de encabezado posterior" mostrado en la figura 28B, el encabezado posterior se puede omitir. Asimismo, aunque el campo de "tipo de encabezado posterior" mostrado en la figura 28B tiene una longitud fija, la "longitud de campo" del "contenido del encabezado posterior" puede tener un valor que difiere según el "tipo de encabezado posterior".
El campo "otro" mostrado en la figura 28B contiene campos distintos de "tipo de encabezado posterior" y "contenido de un encabezado posterior", pero este campo se puede omitir si no es necesario.
La porción de datos de la carga útil RTP mostrada en la figura 28B contiene una velocidad de bits y una combinación apropiadas, y la información de combinación o similar seleccionada por el codificador como se muestra, por ejemplo, en la realización 5. Asimismo, cuando el "tipo de encabezado posterior" es un paquete redundante, la porción de datos también contiene el paquete redundante. En este caso, el codificador selecciona velocidades de bits apropiadas y una combinación de las mismas que se ajustan a la longitud resultante de restar la longitud del paquete redundante de la longitud de la porción de datos como datos principales, y genera un flujo de bits.
De esta manera, en el primer ejemplo de la presente realización, en la carga útil RTP compuesta por una porción de encabezado y una porción de datos, la porción de encabezado incluye una porción de encabezado que siempre se proporciona en todas las cargas útiles de RTP y una porción de encabezado (la porción de encabezado posterior que se muestra en la figura 28B) que no siempre se proporciona en todas las cargas de RTP. Asimismo, como se muestra en la figura 28A y la figura 28B, la porción de encabezado que siempre se proporciona en todas las cargas útiles RTP incluye un campo que indica si se proporciona o no una porción de encabezado posterior (campo que indica la presencia o ausencia de una porción de encabezado posterior).
El formato de carga útil RTP en la presente realización puede adoptar una configuración diferente.
La figura 29 muestra un segundo ejemplo del formato de carga útil RTP en la presente realización. En este ejemplo, suponiendo que toda la información que necesita ser transportada por una carga útil RTP en particular se transporta como parte de la porción de datos de la carga útil RTP, la información de datos distintos a los codificados se denomina "señalización (o porción de señalización)". Asimismo, en este ejemplo, se supone que la información que indica la velocidad de bits del códec (Índice de tipo de trama o similar) no se incluye explícitamente en la carga útil RTP.
La figura 29A muestra un ejemplo del formato de carga útil RTP cuando solo existe el campo que indica la presencia o ausencia de una porción de señalización posterior como la porción de señalización. La figura 29b muestra un ejemplo del formato de carga útil RTP cuando existe el campo que indica la presencia o ausencia de una porción de señalización posterior y la porción de señalización posterior.
En este punto, la longitud fija (por ejemplo, 1 bit o similar) del bit más significativo de la carga útil RTP que se muestra en la figura 29A incluye un "campo que indica la presencia o ausencia de una porción de señalización posterior". En este punto, la "longitud fija desde el bit más significativo" y la porción de señalización posterior "puede ser parte de la porción de datos de carga útil RTP descrita anteriormente o puede ser la porción de encabezado de la carga útil RTP.
El "campo que indica la presencia o ausencia de una porción de señalización posterior" que se muestra en la figura 29A contiene información que indica si este campo es seguido o no por otra parte de señalización en forma de, por ejemplo, un indicador o valor numérico. Por ejemplo, cuando este campo tiene 1 bit, "0" en este campo indica que la señalización posterior no está presente y "1" en este campo indica que la parte de señalización posterior está presente.
En la figura 29A, como no hay otra porción de señalización posterior, el "campo que indica la presencia o ausencia de una parte de señalización posterior" contiene información que indica la "ausencia" de la otra parte de señalización posterior (es decir, "0" en este ejemplo).
Por otra parte, el "campo que indica la presencia o ausencia de una porción de señalización posterior" mostrada en la figura 29B contiene información que indica la "presencia" de otra porción de señalización (señalización posterior) que tiene una longitud fija o una longitud variable después de la porción de señalización que tiene una longitud fija mostrada en la figura 29B (es decir, "1" en este ejemplo).
La porción de señalización posterior mostrada en la figura 29B tiene una longitud fija o una longitud variable y contiene campos de "tipo de señalización posterior" y "contenido de señalización posterior".
El "tipo de señalización posterior" mostrado en la figura 29B muestra información que indica lo que indica la señalización posterior en forma de, por ejemplo, un indicador o valor numérico. Por ejemplo, el "tipo de señalización posterior" también puede indicar la solicitud de modo de códec (solicitud para cambiar una velocidad de bits de códec, solicitud para cambiar el número de canales, solicitud para cambiar el ancho de banda o similar) o puede indicar la presencia de datos redundantes para ocultar la pérdida de paquetes. Asimismo, el "tipo de señalización posterior" también puede indicar SID, sin datos y pérdida de voz descritos en la figura 19 a la figura 23 o similar.
El "contenido de la señalización posterior" mostrado en la figura 29B contiene contenidos correspondientes al tipo que se muestra en el "tipo de señalización posterior". Por ejemplo, cuando el "tipo de señalización posterior" es una solicitud para cambiar la velocidad de bits del códec de la solicitud de modo de códec, este campo contiene un valor que indica la velocidad de bits del códec que se debe solicitar al interlocutor (por ejemplo, Índice de tipo de trama mostrado en la figura 23A o similar). Asimismo, cuando el "tipo de señalización posterior" es una solicitud para cambiar el número de canales de solicitud de modo de códec, el "contenido de señalización posterior" contiene información sobre el destino de conmutación solicitado (por ejemplo, información que indica cambiar a "mono", información que indica el cambio a "estéreo" o similar). Asimismo, cuando el "tipo de señalización posterior" es la presencia de datos redundantes, el "contenido de la señalización posterior" contiene una longitud de datos de datos redundantes o similares. Cuando el "contenido de la señalización posterior" tiene una longitud variable, su longitud varía según el tipo indicado en el "tipo de señalización posterior".
Cuando el "contenido de la señalización posterior" descrito anteriormente puede determinarse de manera única por el "tipo de señalización posterior" que se muestra en la figura 29B o cuando no es necesario determinar el "contenido de la señalización posterior", el "contenido de señalización posterior" se puede omitir. Por ejemplo, esto se aplica a un caso donde el "tipo de señalización posterior" indica SID, sin datos o pérdida de voz descritos en la figura 19 a la figura 23 o similar. Asimismo, mientras que el campo "tipo de señalización posterior" mostrado en la figura 29B tiene una longitud fija, la longitud del campo "contenido de señalización posterior" puede tener un valor diferente según el "tipo de señalización posterior". Cuando el "contenido de señalización posterior" tiene un valor diferente según el "tipo de señalización posterior", la señalización posterior tiene una longitud variable.
Asimismo, el formato de carga útil RTP en la figura 29B también puede estar provisto de un "campo que indica la presencia o ausencia de una porción de señalización posterior" después del "tipo de señalización posterior" y del "contenido de señalización posterior". El formato de carga útil RTP puede incluir además "tipo de señalización posterior" adicional, "contenido de señalización posterior" y "campo que indica la presencia o ausencia de una porción de señalización posterior" (no se muestra).
La porción de datos de la carga útil RTP mostrada en la figura 29B puede contener una velocidad de bits y una combinación apropiadas, y la información de combinación o similar seleccionada por el codificador como se muestra, por ejemplo, en la realización 5. Asimismo, cuando el "tipo de señalización posterior" es un paquete redundante, también se puede contener un paquete redundante. En este caso, el codificador selecciona velocidades de bits apropiadas y una combinación de las mismas que se ajustan a la longitud resultante de restar la longitud del paquete redundante de la longitud de la porción de datos como datos principales, y genera un flujo de bits. Asimismo, cuando el "tipo de señalización posterior" es un SID, la porción de datos de la carga útil RTP contiene datos generados en el caso del SID. Por otra parte, cuando el "tipo de señalización posterior" es sin datos o pérdida de voz descrita en la figura 19 a la figura 23 o similar, la porción de datos de la carga útil RTP no contiene datos (la propia porción de datos puede no estar presente).
Este ejemplo supone que la información que indica la velocidad de bits del códec (Índice de tipo de trama o similar) no está explícitamente contenida en la carga útil RTP. En este caso, el lado receptor calcula la longitud de la carga útil RTP (calcula la longitud de la carga útil RTP a partir de la información de longitud de datos incluida en el encabezado IP o el encabezado UDP o mide la propia longitud de la carga útil RTP), elimina la longitud de la porción de señalización en la figura 29 y de este modo calcula la velocidad de bits del códec.
Asimismo, se ha mostrado un ejemplo en el ejemplo de la figura 29 donde el "campo que indica la presencia o ausencia de una porción de señalización posterior" está contenido al comienzo de la carga útil RTP como una longitud fija desde el bit más significativo, pero este campo puede estar contenido en cualquier posición de la carga útil RTP (por ejemplo, al final de la carga útil RTP). En este caso, el "campo que indica la presencia o ausencia de una porción de señalización posterior" no significa que "indica la presencia o ausencia de una porción de señalización posterior" sino que significa que "indica si la porción de señalización está o no al comienzo del RTP carga útil".
De esta manera, en el segundo ejemplo de la presente realización, la carga útil RTP está compuesta por la porción de datos y la porción de señalización incluida en la misma. En dicha carga útil RTP, la porción de señalización incluye el "campo que indica la presencia o ausencia de una porción de señalización posterior" que siempre se proporciona en todas las cargas útiles RTP y la porción de señalización (señalización posterior mostrada en la figura 29B) que no siempre se proporciona en todas las cargas útiles RTP.
La figura 30 muestra un tercer ejemplo del formato de carga útil RTP de la presente realización. En este ejemplo, se proporciona un campo que indica la presencia o ausencia de una porción de encabezado en la longitud fija desde el bit más significativo de la carga útil RTP, para así cambiar la presencia o ausencia de la porción de encabezado en la carga útil RTP. De esta manera, cuando se genera un campo (señalización) que no necesita ser incluido en la carga útil RTP de todos los paquetes RTP, la porción de encabezado de la carga útil RTP se usa para incluir información (señalización) en esta porción de encabezado.
La figura 30A muestra un ejemplo del formato de carga útil RTP cuando solo existe el campo que indica la presencia o ausencia de una porción de encabezado como la porción de señalización. La figura 30B muestra un ejemplo del formato de carga r Tp cuando la porción de encabezado está presente.
En este punto, el "campo que indica la presencia o ausencia de una porción de encabezado" se incluye en la longitud fija (por ejemplo, 1 bit o similar) del bit más significativo de la carga útil RTP que se muestra en la figura 30A. El "campo que indica la presencia o ausencia de una porción de encabezado" mostrado en la figura 30A contiene información que indica la presencia o ausencia de la porción de encabezado en la carga útil RTP en forma de, por ejemplo, un indicador o valor numérico. Por ejemplo, cuando este campo tiene 1 bit, "0" en este campo indica que la porción de encabezado no está presente y "1" en este campo indica que la porción de encabezado está presente.
Como la porción de encabezado no está presente en la figura 30A, el "campo que indica la presencia o ausencia de una porción de encabezado" contiene información que indica que el encabezado no está presente (es decir, "0" en este ejemplo). Como se muestra en la figura 30A, cuando el "campo que indica la presencia o ausencia de una porción de encabezado" indica que el encabezado no está presente, supongamos que este "campo que indica la presencia o ausencia de una porción de encabezado" es parte de la porción de datos de la carga útil RTP.
Por otra parte, el "campo que indica la presencia o ausencia de una porción de encabezado" mostrado en la figura 30B contiene información que indica que la porción de encabezado mostrada en la figura 30B está "presente" (es decir, "1" en este ejemplo). Cuando la porción de encabezado está presente, tal como se muestra en la figura 30B, la figura 30C y la figura 30D, la porción de encabezado está compuesta por el "encabezado básico" y el "encabezado de extensión". Cuando la porción de encabezado está presente, el encabezado básico siempre está presente, pero el encabezado de extensión puede no estar presente dependiendo del contenido de la información del encabezado básico.
La figura 30C muestra un ejemplo del encabezado básico. Este ejemplo muestra un ejemplo donde cuando la porción de encabezado está presente, el "campo que indica la presencia o ausencia de una porción de encabezado" se incluye como porción de encabezado básico, pero este campo puede ser parte de la porción de datos en lugar de ser parte de la porción de encabezado. Es decir, el "campo que indica la presencia o ausencia de una porción de encabezado" no necesariamente se puede incluir en el encabezado básico. El encabezado básico tiene una longitud fija, y el resto del encabezado básico contiene, por ejemplo, un campo "mono/multi", campo "Tipo de trama" y un campo que indica la "presencia o ausencia de un encabezado posterior".
El campo "mono/multi" contiene, por ejemplo, información que indica que los datos que transporta esta carga útil RTP son mono (1 canal) o multicanal, tal como estéreo en forma de, por ejemplo, un indicador o valor numérico. Por ejemplo, cuando este campo tiene 1 bit, "0" en este campo indica mono y "1" en este campo indica multicanal.
Cuando, por ejemplo, el campo "mono/multi" mencionado anteriormente indica mono, el campo "Tipo de trama" contiene información de la velocidad de bits del códec como se muestra en el Índice de tipo de trama descrito en la figura 19 a la figura 23 o similares e información como el SID (Descriptor de inserción de silencio) mencionado anteriormente o sin datos. Asimismo, cuando el campo "mono/multi" descrito anteriormente indica multicanal, "Tipo de trama" contiene información de varios canales, velocidad de bits o similar. La información de multicanal es información que indica el número de canales o esquema de codificación multicanal (por ejemplo, en el caso de 2 canales, si se trata de un esquema en el que los canales derecho e izquierdo se codifican por separado o un esquema en el que se agrega una parte expandida de 2 canales o similar).
El campo "presencia o ausencia de encabezado posterior" contiene información que indica si un encabezado de extensión está presente o no, por ejemplo, después del encabezado básico en forma de, por ejemplo, un indicador o valor numérico. Por ejemplo, cuando este campo tiene 1 bit, "0" en este campo indica que no hay un encabezado posterior y "1" en este campo indica que hay un encabezado posterior.
Aunque el encabezado básico tiene una longitud fija, el valor de la longitud fija puede variar según el contenido indicado por el campo "mono/multi", es decir, dependiendo de si el canal es mono o multicanal.
La figura 30D muestra un ejemplo del encabezado de extensión cuando está presente un encabezado posterior. El encabezado de extensión tiene una longitud fija y contiene, por ejemplo, un campo "tipo de encabezado", campo "información" y un campo "presencia o ausencia de encabezado posterior".
El campo "tipo de encabezado" contiene información que indica el tipo de encabezado de esta extensión en forma de, por ejemplo, un indicador o valor numérico. Por ejemplo, cuando este campo tiene 3 bits, por ejemplo, "000" en este campo indica que el tipo de encabezado de extensión es "información de datos redundante". El campo "tipo de encabezado" que contiene "001" indica que el tipo de encabezado de extensión es "Solicitud de modo de códec (velocidad de bits)". El campo "tipo de encabezado" que contiene "010" indica que el tipo de encabezado de extensión es "Solicitud de modo de códec (número de canales)". El campo "tipo de encabezado" que contiene "011" indica que el tipo del encabezado de extensión es "Solicitud de modo de códec (banda)".
El campo "información" contiene diferentes elementos de información según el contenido del "tipo de encabezado". Por ejemplo, como se ha descrito anteriormente, cuando el "tipo de encabezado" es "información de datos redundante", por ejemplo, el campo "información" contiene el índice de tipo de trama que indica la velocidad de bits de los datos redundantes. Como se describe en NPL 2, este es un caso en el que un paquete RTP contiene datos de una pluralidad de tramas. Asimismo, por ejemplo, como se ha descrito anteriormente, cuando el "tipo de encabezado" es "Solicitud de modo de códec (velocidad de bits)", el campo "información" contiene el índice de tipo de trama que indica la velocidad de bits del códec que se solicitará al terminal asociado. Asimismo, por ejemplo, como se ha descrito anteriormente, cuando el "tipo de encabezado" es "Solicitud de modo de códec (número de canales)", el campo "información" contiene el número de canales que se solicitarán al terminal asociado o un esquema de codificación multicanal. Asimismo, por ejemplo, como se ha descrito anteriormente, cuando el "tipo de encabezado" es "Solicitud de modo de códec (banda)", el campo "información" contiene información que indica una banda de codificación que se solicitará al terminal asociado.
Asimismo, por ejemplo, el campo que indica el multicanal y la información del multicanal pueden estar contenidos en el encabezado de extensión en lugar del encabezado básico. Por el contrario, los campos que indican "Solicitud de modo de códec" y los datos redundantes, y su información puede estar contenida en el encabezado básico en lugar del encabezado de extensión.
El campo "presencia o ausencia de encabezado posterior" contiene además información sobre si un encabezado de extensión adicional está presente o no, por ejemplo, después de este encabezado de extensión en forma de un indicador o valor numérico o similar. Por ejemplo, cuando este campo tiene 1 bit, "0" en este campo indica que el encabezado posterior no está presente y "1" en este campo indica que el encabezado posterior está presente.
Aunque el encabezado de extensión tiene una longitud fija, el valor de la longitud fija puede diferir dependiendo del contenido indicado por el campo "tipo de encabezado".
Cuando el tipo de encabezado del encabezado de extensión es, por ejemplo, "información de datos redundantes" o "información multicanal", la porción de datos de la carga útil RTP mostrada en la figura 30B también contiene datos redundantes, el número de canales y datos multicanal que se ajustan al esquema de codificación multicanal. Asimismo, cuando tipo de trama del encabezado básico es, por ejemplo, no se pierden datos o voz, como se describe en la figura 19 a la figura 23, la porción de datos de la carga útil RTP se puede omitir.
Asimismo, el ejemplo en la figura 30 ha mostrado un caso en el que el "campo que indica la presencia o ausencia de una porción de encabezado" está contenido al comienzo de la carga útil r Tp como la longitud fija desde el bit más significativo, pero este campo puede estar contenido en cualquier posición de la carga útil RTP (por ejemplo, al final de la carga útil RTP).
De esta manera, el tercer ejemplo de la presente realización incluye un caso en el que la porción de encabezado no está presente (figura 30A) y un caso en el que la porción de encabezado está presente (figura 30B) en la carga útil RTP compuesta por la porción de encabezado y la porción de datos. Asimismo, como se muestra en la figura 30A y la figura 30B, se incluye un campo (campo que indica la presencia o ausencia de una porción de encabezado) que indica si la porción de encabezado siempre se proporciona o no en todas las cargas de RTP.
Como se describe en la Realización 5, dado que se determina el tamaño del bloque de transmisión o similar, la longitud de la carga útil RTP, y la longitud de una carga útil RTP que transporta datos como la voz normal, en particular, puede limitarse a una pluralidad de longitudes fijas. En un caso de este tipo, como la presente realización, si la solicitud de modo de códec se incluye en la carga útil RTP que transporta datos como la voz normal, la longitud de la carga útil RTP puede ser mayor que el tamaño del bloque de transmisión correspondiente.
Para resolver este problema, en el momento de enviar una carga útil RTP cuya porción de datos no está presente o una carga útil RTP cuya porción de datos es más corta que cuando se envían datos normales, el terminal puede enviar la solicitud de modo de códec incluida en estas cargas útiles RTP. El caso donde la porción de datos no está presente o el caso donde la porción de datos es más corta que cuando se envían datos normales se refiere a, por ejemplo, un caso donde SID, no se pierden datos o voz, como se describe en la figura 19 a la figura 23 se usa.
De esta manera, de acuerdo con la presente realización, es posible proporcionar un campo necesario a la carga útil RTP solo cuando sea necesario y hacer que el codificador seleccione velocidades de bits apropiadas y una combinación de las mismas que se ajuste a la longitud de la porción de datos.
Las realizaciones de la presente invención se han descrito hasta ahora.
El índice de tipo de trama no necesita describir todos los modos de códec proporcionados (las propias velocidades de bits o una combinación de velocidades de bits), y solo se pueden definir algunos modos de códec.
Asimismo, se ha descrito un caso en las realizaciones anteriores donde se define la correspondencia entre un modo de códec real (o conjunto de modos de códec) y un número (valor numérico) que indica el modo de códec (o conjunto de modos de códec). También se ha descrito un caso en el que el número (valor numérico) que indica el modo de códec (o conjunto de modos de códec) se describe en el SDP (figura 8 y figura 11). Sin embargo, el modo de códec real (o conjunto de modos de códec) también puede describirse directamente en el SDP.
Asimismo, el "esquema 1" descrito en la figura 8, la figura 11, la figura 14 y la figura 17 representa el nombre de códec específico. Por ejemplo, "esquema 1" puede ser EVS, AMR o AMR-WB, o también pueden ser otros códecs. Asimismo, la figura 8 y la figura 14 muestran descripciones en las que solo se ofrece el códec del esquema 1, pero otros esquemas (esquema 2, esquema 3...) también se puede describir de la misma manera y se puede incluir en la oferta de SDP.
Diferentes tipos en un determinado códec y la cantidad de canales (mono, estéreo o similar) puede describirse en el SDP como el nombre del códec o puede definirse en la correspondencia del conjunto de modos de códec mostrado en la figura 9 y la figura 15. En este punto, ejemplos de los diferentes tipos en el códec incluyen el modo interoperable AMR-WB o el modo no interoperable AMR-WB en EVS y la banda de audio (banda estrecha, banda ancha, banda súper ancha, banda completa).
Asimismo, se ha descrito un caso en las realizaciones anteriores donde se usa una ID de CSG o ID de estación base como información relacionada con las características de una red de acceso inalámbrico. Sin embargo, la información relacionada con las características de la red de acceso inalámbrico no se limita a esto, y ejemplos de la misma incluyen información de célula que indica una célula (HeNB) a la que está conectado un UE e información de posición que indica la posición del UE.
Asimismo, se ha descrito un caso en las realizaciones anteriores en las que se selecciona un modo de códec (o conjunto de modos de códec) (que incluye una velocidad de bits y un retraso algorítmico) cuando comienza la comunicación entre los UE, pero la presente invención no se limita a esto. Las realizaciones anteriores también son aplicables a, por ejemplo, un caso donde la capacidad del UE (por ejemplo, tamaño de la pantalla) está seleccionada.
Asimismo, las realizaciones anteriores se han descrito utilizando un códec relacionado principalmente con el habla. Sin embargo, la presente invención no se limita a esto, pero también es aplicable a música, acústica, imagen o similar.
Asimismo, la presente invención no está limitada a las realizaciones anteriores, pero puede implementarse usando varias modificaciones.
En las realizaciones anteriores, la presente invención está configurada con hardware a modo de ejemplo, pero la invención también puede proporcionarse por software en cooperación con hardware.
Asimismo, cada bloque de función empleado en la descripción de cada una de las realizaciones anteriormente mencionadas puede típicamente implementarse como un LSI constituido por un circuito integrado. Estos pueden ser chips individuales parcial o totalmente contenidos en un único chip. El término "LSI" se adopta en el presente documento, pero también puede denominarse "IC", "sistema LSI", "súper LSI", o "ultra LSI" dependiendo de los diferentes puntos de integración.
Adicionalmente, el procedimiento de implementación del circuito integrado no se limita a LSI, y la implementación mediante un circuito dedicado o un procesador de propósito general también puede ser posible. Después de la fabricación de LSI, la utilización de un FPGA de campo de matriz de puertas programables o un procesador reconfigurable donde las conexiones y ajustes de células de circuito dentro de un LSI pueden reconfigurarse también es posible.
Si se introduce una nueva tecnología de implementación de circuito integrado que reemplaza a LSI debido al avance en la tecnología de semiconductores o una tecnología diferente derivada de la misma, los bloques de funciones pueden, por supuesto, integrarse utilizando esa tecnología. Por ejemplo, la aplicación de la biotecnología es posible.
La divulgación de la solicitud de Patente Japonesa n.° 2010-252113, presentada el 10 de noviembre de 2010, la solicitud de Patente Japonesa n.° 2010-278222, presentada el 14 de diciembre de 2010, la solicitud de Patente Japonesa n.° 2011-84442, presentada el 6 de abril de 2011 y la solicitud de Patente Japonesa n.° 2011-173910, presentada el 9 de agosto de 2011 hacen referencia.
Aplicabilidad industrial
La presente invención es particularmente adecuada para su uso en un terminal o similar que realiza una negociación utilizando un mensaje de señalización cuando comienza la comunicación.
Lista de signos de referencia
100, 102 UE
104, 106 eNB
108, 116 P-CSCF
110, 114 S-CSCF
112 t-CSCF
118 HSS
120, 122, 406, 408, 506, 508, 2606, 2608 red de acceso inalámbrico 124 red central IP
126 red IMS
400, 402, 500, 502 HeNB
404 GW local
600 sección de recepción inalámbrica
602 sección de transmisión inalámbrica
604 sección de determinación del destino de la conexión
606 sección de comparación de información
608 sección de determinación del modo
610, 708, 2710 sección de generación de señalización
700, 2700 sección de recepción
702, 2702 sección de transmisión
704, 2706 sección de análisis de señalización
706, 2708 sección de confirmación de información de posición del terminal 812 sección de análisis de estado
814 sección de cambio de modo
2600, 2602, 2614 AP
2604IP-PBX
2610 red IP
2612 servidor
2704 sección de interceptación de señalización

Claims (8)

REIVINDICACIONES
1. Un terminal (102) de comunicación, que comprende;
un cambiador de modo configurado para cambiar un modo de códec o un conjunto de modos de códec del terminal (100) de comunicación o un terminal (102) asociado que es un destino de comunicación, el terminal (100) de comunicación está configurado para configurarse mediante un mensaje de señalización para negociación recibido desde el terminal (102) asociado cuando comienza la comunicación entre el terminal (100) de comunicación y el terminal (102) asociado, el mensaje de señalización para la negociación de códec incluye un códec y un modo de códec o un conjunto de modos de códec; y
un transmisor (2702) configurado para transmitir, durante la comunicación con el terminal (102) asociado, un modo de códec del terminal (100) de comunicación actualmente en uso, utilizando una carga útil del protocolo de transporte en tiempo real RTP,
en el que el transmisor (2702) está configurado para transmitir una solicitud de modo de códec CMR para solicitar al terminal (102) asociado que cambie el modo de códec del terminal (102) asociado utilizando la carga útil RTP, la carga útil RTP incluye un campo de solicitud de modo de códec que solo está presente cuando es necesario cambiar el modo de códec o el conjunto de modos de códec del terminal (102) asociado.
2. El terminal de comunicación de acuerdo con la reivindicación 1, en el que el cambiador de modo está configurado para generar la solicitud de modo de códec para solicitar al terminal (102) asociado que cambie el modo de códec solo cuando el modo de códec o el conjunto de modos de códec del terminal (100, 102) asociado necesita cambiarse.
3. El terminal (100) de comunicación de acuerdo con la reivindicación 1,
en el que la carga útil RTP consiste en una porción de encabezado y una porción de datos, y la solicitud de modo de códec se incluye en la porción de encabezado.
4. El terminal (100) de acuerdo con la reivindicación 3,
en el que la porción de encabezado incluye información que indica una velocidad de bits de una parte básica y una parte expandida en la porción de datos, la porción de datos incluye información que indica una combinación de códecs de la parte básica y la parte expandida.
5. Un terminal (100) de comunicación, que comprende
un receptor configurado para recibir, durante la comunicación con un terminal (102) asociado que es un destino de comunicación, un mensaje de señalización desde el terminal asociado, incluyendo el mensaje de señalización una solicitud de modo de códec CMR del terminal asociado cuando se necesita cambiar un modo de códec o un conjunto de modos de códec del terminal (100) de comunicación; y un cambiador de modo configurado para cambiar el modo de códec o el conjunto de modos de códec del terminal (100) de comunicación en función de la solicitud de modo de códec recibida,
en el que una carga útil del protocolo de transporte en tiempo real RTP incluye un campo de solicitud de modo de códec que solo está presente cuando el modo de códec o el conjunto de modos de códec del terminal (100) de comunicación necesita cambiarse.
6. Un procedimiento de comunicación realizado por un terminal (100) de comunicación, que comprende:
cambiar un modo de códec o un conjunto de modos de códec del terminal (100) de comunicación o un terminal (102) asociado que es un destino de comunicación basado en un mensaje de señalización recibido del terminal (102) asociado cuando comienza la comunicación entre el terminal (100) de comunicación y el terminal (102) asociado, el mensaje de señalización incluye un códec y un nuevo modo de códec o un nuevo modo de códec establecido para el terminal (102) asociado; y
transmitir, durante la comunicación con el terminal (102) asociado, un modo de códec del terminal (100) de comunicación actualmente en uso, utilizando una carga útil del protocolo de transporte en tiempo real RTP, en el que una solicitud de modo de códec CMR para solicitar al terminal (102) asociado que cambie el modo de códec del terminal (102) asociado se transmite utilizando la carga útil RTP, la carga útil RTP incluye un campo de solicitud de modo de códec que solo está presente cuando es necesario cambiar el modo de códec o el conjunto de modos de códec del terminal (102) asociado.
7. El procedimiento de comunicación de acuerdo con la reivindicación 6, en el que la carga útil RTP consiste en una porción de encabezado y una porción de datos, y la solicitud de modo de códec se incluye en la porción de encabezado.
8. El procedimiento de comunicación de acuerdo con la reivindicación 7, en el que la porción de encabezado incluye información que indica una velocidad de bits de una parte básica y una parte expandida en la porción de datos, la porción de datos incluye información que indica una combinación de códecs de la parte básica y la parte expandida.
ES11840382T 2010-11-10 2011-10-26 Terminal y procedimiento de selección de modo de codificación Active ES2749222T3 (es)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
JP2010252113 2010-11-10
JP2010278222 2010-12-14
JP2011084442 2011-04-06
JP2011173910 2011-08-09
PCT/JP2011/005986 WO2012063417A1 (ja) 2010-11-10 2011-10-26 端末及びコーデックモード選択方法

Publications (1)

Publication Number Publication Date
ES2749222T3 true ES2749222T3 (es) 2020-03-19

Family

ID=46050588

Family Applications (1)

Application Number Title Priority Date Filing Date
ES11840382T Active ES2749222T3 (es) 2010-11-10 2011-10-26 Terminal y procedimiento de selección de modo de codificación

Country Status (6)

Country Link
US (2) US9401975B2 (es)
EP (2) EP2640052B1 (es)
JP (3) JP6061679B2 (es)
ES (1) ES2749222T3 (es)
PL (1) PL2640052T3 (es)
WO (1) WO2012063417A1 (es)

Families Citing this family (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8542802B2 (en) 2007-02-15 2013-09-24 Global Tel*Link Corporation System and method for three-way call detection
US9225838B2 (en) 2009-02-12 2015-12-29 Value-Added Communications, Inc. System and method for detecting three-way call circumvention attempts
EP2590164B1 (en) * 2010-07-01 2016-12-21 LG Electronics Inc. Audio signal processing
WO2012063417A1 (ja) * 2010-11-10 2012-05-18 パナソニック株式会社 端末及びコーデックモード選択方法
EP2745499B1 (en) * 2011-08-17 2019-03-27 Telefonaktiebolaget LM Ericsson (publ) Mechanism for dynamic signaling of encoder capabilities
USRE49284E1 (en) 2013-10-17 2022-11-08 Panasonic Intellectual Property Corporation Of America Method for controlling cordless telephone device, handset of cordless telephone device, and cordless telephone device
JP6309382B2 (ja) * 2013-10-17 2018-04-11 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ コードレス電話機器の制御方法、コードレス電話機器の子機及びコードレス電話機器
EP3917112B1 (en) * 2013-11-27 2022-10-05 Telefonaktiebolaget LM Ericsson (publ) Hybrid rtp payload format
KR101864122B1 (ko) 2014-02-20 2018-06-05 삼성전자주식회사 전자 장치 및 전자 장치의 제어 방법
US9397947B2 (en) 2014-03-11 2016-07-19 International Business Machines Corporation Quality of experience for communication sessions
US9680507B2 (en) * 2014-07-22 2017-06-13 Qualcomm Incorporated Offset selection for error correction data
KR102318763B1 (ko) 2014-08-28 2021-10-28 삼성전자주식회사 기능 제어 방법 및 이를 지원하는 전자 장치
JP6634686B2 (ja) * 2015-03-11 2020-01-22 株式会社リコー 情報処理装置、プログラム、通信プラットフォーム決定方法、伝送システム
US9917673B2 (en) * 2015-03-12 2018-03-13 Telefonaktiebolaget Lm Ericsson (Publ) Rate control in circuit switched systems
CN105100046A (zh) * 2015-05-19 2015-11-25 华为技术有限公司 一种媒体互通方法及其装置
WO2016185649A1 (ja) * 2015-05-20 2016-11-24 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 通信ノード、端末及び通信制御方法
WO2017045115A1 (zh) * 2015-09-15 2017-03-23 华为技术有限公司 一种建立无线承载的方法及网络设备
KR102477464B1 (ko) * 2015-11-12 2022-12-14 삼성전자주식회사 무선 통신 시스템에서 음성 패킷의 크기를 제어하기 위한 장치 및 방법
KR102401477B1 (ko) * 2015-11-24 2022-05-25 삼성전자주식회사 사용자 단말 장치 및 그 제어 방법
US10035438B2 (en) * 2016-02-22 2018-07-31 Ford Global Technologies, Llc Vehicle seat bottom with independently deployable devices
JP7019561B2 (ja) * 2016-03-28 2022-02-15 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 端末及びコーデックモード切替方法
US10057393B2 (en) 2016-04-05 2018-08-21 T-Mobile Usa, Inc. Codec-specific radio link adaptation
WO2017177382A1 (zh) * 2016-04-12 2017-10-19 广东欧珀移动通信有限公司 用于确定业务通信的编解码模式集的方法和装置
CN111224857A (zh) * 2016-06-29 2020-06-02 华为技术有限公司 用于实现组合虚拟专用网vpn的方法与装置
US10616376B2 (en) * 2016-07-20 2020-04-07 Vivint, Inc. Communications protocol
WO2018031614A1 (en) * 2016-08-11 2018-02-15 Kyocera Corporation Ran-assisted rate adaptation
WO2018064386A1 (en) * 2016-09-30 2018-04-05 Kyocera Corporation Ran-assisted rate adaptation under mobility
US9930088B1 (en) * 2017-06-22 2018-03-27 Global Tel*Link Corporation Utilizing VoIP codec negotiation during a controlled environment call
US10469668B1 (en) * 2017-08-30 2019-11-05 Sprint Spectrum L.P. Determining access parameters based on likelihood of HD voice service
JP2019066205A (ja) * 2017-09-28 2019-04-25 サトーホールディングス株式会社 検査システム、検査方法
US10728303B2 (en) 2017-12-05 2020-07-28 At&T Intellectual Property I, L.P. Codec selection for end-to-end communication without intermediate transcoding
CN116566958A (zh) * 2018-09-07 2023-08-08 苹果公司 用于在ims多媒体电话会话中发信号通知ran辅助的编解码器自适应能力的设备和方法
KR102526699B1 (ko) * 2018-09-13 2023-04-27 라인플러스 주식회사 통화 품질 정보를 제공하는 방법 및 장치
WO2020092818A1 (en) 2018-11-02 2020-05-07 Intel Corporation Signaling codec mode notifications for multimedia telephony sessions
US11689583B2 (en) * 2018-12-10 2023-06-27 Telefonaktiebolaget Lm Ericsson (Publ) Network node, entity and methods performed therein for handling a communication session in a communication network
CN114040130A (zh) * 2021-11-05 2022-02-11 深圳市瑞云科技有限公司 动态切换单双声道的方法、系统及计算机可读存储介质
WO2023219210A1 (ko) * 2022-05-10 2023-11-16 삼성전자 주식회사 적응형 polar coding configuration 송수신 방법 및 장치

Family Cites Families (41)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB9616237D0 (en) 1996-08-01 1996-09-11 Norton Healthcare Ltd Aerosol formulations
JP3310205B2 (ja) 1997-10-01 2002-08-05 株式会社エヌ・ティ・ティ・ドコモ 移動通信システム
US6512924B2 (en) 1997-10-01 2003-01-28 Ntt Mobile Communications Network Inc. Mobile communications system
CN101917745B (zh) * 1999-05-17 2013-05-01 艾利森电话股份有限公司 用于电信网络中的能力协商的系统、设备和方法
EP2043375B1 (en) 1999-05-17 2011-10-26 Telefonaktiebolaget LM Ericsson (publ) Capability negotiation in a telecommunications network
US20010041981A1 (en) * 2000-02-22 2001-11-15 Erik Ekudden Partial redundancy encoding of speech
EP1968282A3 (en) * 2000-08-14 2008-11-26 Nokia Siemens Networks Oy System, method and devices providing a communication mode selection procedure
US20020163908A1 (en) * 2001-05-07 2002-11-07 Ari Lakaniemi Apparatus, and associated method, for synchronizing operation of codecs operable pursuant to a communicaton session
WO2003041408A1 (fr) * 2001-11-05 2003-05-15 Matsushita Electric Industrial Co., Ltd. Terminal utilise dans un systeme de transmission video
US7778242B1 (en) * 2001-11-27 2010-08-17 Alcatel Lucent Protecting content of a packet containing speech data using unequal error protection
BR0215544A (pt) 2002-06-07 2004-12-28 Siemens Ag Processo e disposição para a transmissão de pacotes-ip entre um rádio controlada de rede e uma outra instalação de uma rede de rádio móvel
FI116498B (fi) 2002-09-23 2005-11-30 Nokia Corp Kaistanleveyden mukauttaminen
TWI517649B (zh) 2003-12-01 2016-01-11 內數位科技公司 以會話初始化協定為基礎之使用者啟動換手
JP2005167458A (ja) * 2003-12-01 2005-06-23 Matsushita Electric Ind Co Ltd 音声画像伝送方法
JP2005175694A (ja) 2003-12-09 2005-06-30 Toyota Motor Corp 音声通信装置、及び、音声通信方法
US8085678B2 (en) 2004-10-13 2011-12-27 Qualcomm Incorporated Media (voice) playback (de-jitter) buffer adjustments based on air interface
JP4507822B2 (ja) 2004-10-21 2010-07-21 日本電気株式会社 音楽提供システム、音楽提供方法及び音楽提供用プログラム
WO2006066246A2 (en) * 2004-12-15 2006-06-22 Dilithium Networks Pty Ltd. Fast session setup extensions to h.324
KR100800794B1 (ko) * 2005-07-01 2008-02-04 삼성전자주식회사 패킷망을 통해 음성 서비스를 지원하는 이동통신시스템에서 음성 서비스의 전송률을 제어하는 방법 및 장치
WO2007034809A1 (ja) * 2005-09-20 2007-03-29 Taisho Pharmaceutical Co., Ltd. 組み換え蛋白質産生のための宿主細胞
EP1768337A1 (en) 2005-09-26 2007-03-28 Alcatel Intelligent border element
DE102005050586B3 (de) * 2005-10-21 2006-11-02 Siemens Ag Verfahren zum Aufbau einer Videotelefonverbindung und/oder Multimediatelefonverbindung in einem Datennetz
JP4782847B2 (ja) 2006-03-02 2011-09-28 テレフオンアクチーボラゲット エル エム エリクソン（パブル） 広帯域コーデック・ネゴシエーション
US20080077410A1 (en) * 2006-09-26 2008-03-27 Nokia Corporation System and method for providing redundancy management
US20080117906A1 (en) * 2006-11-20 2008-05-22 Motorola, Inc. Payload header compression in an rtp session
JP4937005B2 (ja) 2007-06-13 2012-05-23 三菱電機株式会社 音声伝送装置
KR101167523B1 (ko) * 2008-01-17 2012-07-20 노키아 코포레이션 무선 시스템에서의 적응적 멀티-레이트 코덱 비트 레이트 제어
CN102077558A (zh) 2008-07-16 2011-05-25 日本电气株式会社 用于网关的装置和方法及程序
KR101523590B1 (ko) * 2009-01-09 2015-05-29 한국전자통신연구원 통합 인터넷 프로토콜망의 코덱 모드 제어방법 및 단말기
US9454973B2 (en) * 2009-04-07 2016-09-27 Telefonaktiebolaget Lm Ericsson (Publ) Method and arrangement for providing a backwards compatible payload format
WO2010117326A1 (en) * 2009-04-07 2010-10-14 Telefonaktiebolaget Lm Ericsson (Publ) Method and arrangement for session negotiation
JP5019234B2 (ja) 2009-04-16 2012-09-05 Ｎｅｃアクセステクニカ株式会社 通信システムおよび障害切り分け試験方法
JP5303364B2 (ja) 2009-05-28 2013-10-02 日東電工株式会社 両面配線回路基板およびその製造方法
WO2010142312A1 (en) * 2009-06-12 2010-12-16 Telefonaktiebolaget L M Ericsson (Publ) Monitoring of delay in packet-switched networks
US9432414B2 (en) * 2009-08-25 2016-08-30 Nokia Solutions And Networks Oy Control of codec negotiation for communication connection
JP2011084442A (ja) 2009-10-16 2011-04-28 Doshisha 細線状チタン化合物、色素増感型太陽電池用チタニア電極および色素増感型太陽電池
US8416690B2 (en) * 2010-01-11 2013-04-09 Research In Motion Limited Explicit congestion notification based rate adaptation using binary marking in communication systems
US9398517B2 (en) * 2010-01-11 2016-07-19 Blackberry Limited System and method for enabling discovery of local service availability in local cellular coverage
WO2012063417A1 (ja) * 2010-11-10 2012-05-18 パナソニック株式会社 端末及びコーデックモード選択方法
WO2012077701A1 (ja) * 2010-12-07 2012-06-14 日本電気株式会社 ゲートウェイ装置および音声通信方法
US9031679B2 (en) * 2012-05-15 2015-05-12 Ixia Methods, systems, and computer readable media for utilizing a plurality of pre-encoded payloads to generate a packet stream transmission

Also Published As

Publication number Publication date
WO2012063417A1 (ja) 2012-05-18
US20130230057A1 (en) 2013-09-05
JP2018121357A (ja) 2018-08-02
US9401975B2 (en) 2016-07-26
EP3554127B1 (en) 2020-09-09
JP6313839B2 (ja) 2018-04-18
EP3554127A1 (en) 2019-10-16
PL2640052T3 (pl) 2019-12-31
EP2640052A1 (en) 2013-09-18
JP2017060191A (ja) 2017-03-23
EP2640052B1 (en) 2019-07-24
JP6061679B2 (ja) 2017-01-18
JPWO2012063417A1 (ja) 2014-05-12
US20160301777A1 (en) 2016-10-13
US10645198B2 (en) 2020-05-05
JP6595650B2 (ja) 2019-10-23
EP2640052A4 (en) 2017-11-29

Similar Documents

Publication Publication Date Title
ES2749222T3 (es) Terminal y procedimiento de selección de modo de codificación
US11647428B2 (en) Communication terminal apparatus and communication method
US11405432B2 (en) Communication apparatus, base station, and codec mode switching method
US11799922B2 (en) Network core facilitating terminal interoperation
ES2251613T3 (es) Procedimiento y dispositivo para la transmision de paquetes ip entre un controlador de red de radio (rnc) y otro elemento de una red telefonica movil.
ES2730709T3 (es) Mecanismo para la señalización dinámica de las capacidades del codificador
JPWO2015129181A1 (ja) 音声通信端末、中間ノード、処理装置、接続方法およびプログラム
US10911988B2 (en) Communication node, terminal, and communication control method
WO2012063890A1 (ja) コアネットワークおよび通信システム
ES2881704T3 (es) Dispositivo de red de gestión