ES2728678T3 - Nodo de red y procedimiento de comunicación - Google Patents

Nodo de red y procedimiento de comunicación Download PDF

Info

Publication number
ES2728678T3
ES2728678T3 ES12853666T ES12853666T ES2728678T3 ES 2728678 T3 ES2728678 T3 ES 2728678T3 ES 12853666 T ES12853666 T ES 12853666T ES 12853666 T ES12853666 T ES 12853666T ES 2728678 T3 ES2728678 T3 ES 2728678T3
Authority
ES
Spain
Prior art keywords
codec
terminal
mode
compatible
unsupported
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
ES12853666T
Other languages
English (en)
Inventor
Takako Hori
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 ES2728678T3 publication Critical patent/ES2728678T3/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
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • 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/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0022—Control or signalling for completing the hand-off for data sessions of end-to-end connection for transferring data sessions between adjacent core network technologies
    • H04W36/00224—Control or signalling for completing the hand-off for data sessions of end-to-end connection for transferring data sessions between adjacent core network technologies between packet switched [PS] and circuit switched [CS] network technologies, e.g. circuit switched fallback [CSFB]
    • H04W36/00226—Control or signalling for completing the hand-off for data sessions of end-to-end connection for transferring data sessions between adjacent core network technologies between packet switched [PS] and circuit switched [CS] network technologies, e.g. circuit switched fallback [CSFB] wherein the core network technologies comprise IP multimedia system [IMS], e.g. single radio voice call continuity [SRVCC]
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Un sistema de comunicación que comprende: un nodo (110) de red; un primer terminal (100) que soporta un primer códec y un segundo códec; y un terminal (102) que soporta el primer códec y otro códec, en el que: el primer códec es un códec diferente de un códec heredado, el primer códec soporta un modo compatible y un modo no compatible, el modo compatible que es compatible con el segundo códec y puede utilizarse como el segundo códec y el modo no compatible que no es compatible con el segundo códec y no puede utilizarse como el segundo códec, el segundo códec que es el códec heredado, el primer terminal y el terminal están adaptados para negociar el modo no compatible en una negociación de sesión para comunicar datos entre el primer terminal y el terminal cuando dicha comunicación comienza en una red de conmutación de paquetes, PS, el nodo (110) de red que está adaptado para detectar si el modo no compatible negociado del primer terminal es conmutado al modo compatible o al segundo códec en la comunicación de datos entre el primer terminal y el terminal y, después de dicha detección, para transmitir una señal para que el terminal conmute el modo no compatible negociado del terminal al modo compatible mediante el uso de un formato de carga útil del primer códec; y el terminal está adaptado para conmutar el modo no compatible negociado del terminal al modo compatible sin cambiar el primer códec, en base a la señal.

Description

DESCRIPCIÓN
Nodo de red y procedimiento de comunicación
Campo técnico
La presente invención se refiere a una técnica para continuar la comunicación cuando se cambia un códec utilizado por uno de los terminales en un sistema de comunicación móvil.
Técnica antecedente
En la técnica relacionada, las llamadas de voz en un sistema de comunicación móvil del proyecto asociación de tercera generación (3GPP) se realizan utilizando una red de conmutación de circuitos (CS) 3GPP. En los últimos años, se ha iniciado un servicio de Voz sobre Evolución a Largo Plazo (VoLTE), que proporciona una llamada de voz utilizando una red de conmutación de paquetes (PS) 3GPP.
Sin embargo, el área donde el servicio VoLTE está disponible está limitada por un tiempo. Por este motivo, cuando un usuario sale del área de servicio de VoLTE durante una llamada de voz utilizando VoLTE (de aquí en adelante, denominado como llamada VoLTE), es necesario conmutar esta llamada a una llamada basada en una técnica de conmutación de circuitos de acuerdo con la técnica relacionada. Como técnica que permite esta conmutación, se divulga la continuidad de llamada de voz de radio única (SRVCC) en la Literatura Distinta de las Patentes (de aquí en adelante, abreviada como "NPL") 1. De aquí en adelante, se describirá una operación de traspaso basada en SRVCC haciendo referencia a las figuras 1 y 2.
La figura 1 es un diagrama que ilustra una parte de una configuración de una red de comunicación móvil 3GPP. La red de comunicación móvil mostrada en la figura 1 se configura utilizando una red de acceso de radio terrestre universal evolucionada (e-UTRAN), una estación base e-UTRAN (enodeB), una red PS, una red CS, un subsistema de estación base de la red CS y un Subsistema multimedia IP (IMS).
Específicamente, en la figura 1, e-UTRAN es una red de acceso de radio que es capaz de proporcionar el servicio VoLTE. La red PS proporciona el servicio VoLTE e incluye una puerta de enlace de red de paquetes de datos (P-GW), una puerta de enlace de servicio (S-GW) y una entidad de gestión de movilidad (MME). La red CS incluye un centro de conmutación móvil (MSC) y una pasarela de medios (MGW). El subsistema de estación base de la red CS incluye un controlador de red de radio (RNC) y nodeB. El IMS realiza un control de llamada o similar e incluye una función de control de sesión de llamada (CSCF) y un servidor de aplicaciones de centralización y continuidad de servicio (SCC AS). Cabe señalar que en la figura 1 y la figura 2, MSC y MGW se representan como un solo nodo (MSC/MGW 110), pero pueden proporcionarse como nodos separados.
En la figura 1, se asume que el UE 100 y el UE 102 que son terminales de comunicación móvil (equipo de usuario) están conectados inicialmente a la red PS, respectivamente (aquí, una red de acceso por radio, una estación base y una red PS en el lado del UE 102 no se muestran). Es decir, se supone que se realiza una llamada VoLTE entre el UE 100 y el UE 102. Aquí, se supone que el UE 100 se traspasa (TR) a la red CS durante la llamada.
La Ruta A, la Ruta B y la Ruta C indicadas por líneas continuas en la figura 1 representan rutas a través de las cuales pasan los datos de voz. Además, los números de referencia 200, 202, 204 y 206 indicados por líneas discontinuas en la figura 1 representan las rutas a través de las cuales pasan las señales en un proceso de traspaso SRVCC.
La figura 2 es un diagrama de secuencia que ilustra una operación del proceso de traspaso SRVCC. El UE 100 y el UE 102 están conectados inicialmente a la red PS (e-UTRAN), respectivamente, y los datos de voz entre el UE 100 y el UE 102 se transmiten y reciben a través de la Ruta A. Si el Ue 100 está alejado de un área de cobertura de la e-UTRAN, enodeB detecta el hecho e intercambia señalización con RNC/nodeB a través de MME y MSC/MGW 110 (señalización 200 mostrada en la figura 1 y etapa (de aquí en adelante, denominada como "ST") 200 mostrada en la figura 2). En ST200, se prepara una ruta de datos en la red CS entre nodeB y MSC/MGW 110. Si se termina la preparación, se da un comando al UE 100 desde MME hasta e-nodeB para el traspaso a UTRAN (red CS).
Al mismo tiempo que con el proceso de ST200, el MSC/MGW 110 intercambia señalización con el UE 102 a través de CSCF/SCC AS (la señalización 202 mostrada en la figura 1 y ST202 mostrada en la figura 2). Por tanto, se da un comando para conmutar un destino de transmisión/recepción de datos de voz del UE 102 desde el UE 100 al MSC/MGW 110, y se establece la Ruta B.
Después del traspaso a UTRAN, el UE 100 intercambia señalización con el MSC/MGW 110 a través de RNC/nodeB (la señalización 204 mostrada en la figura 1 y ST204 mostrada en la figura 2). Por tanto, se establece la Ruta C.
Después del establecimiento de la Ruta C, el MSC/MGW 110 intercambia señalización con P-GW/S-GW a través de MME (la señalización 206 mostrada en la figura 1 y ST206 mostrada en la figura 2). Por tanto, la Ruta A se elimina.
En lo anteriormente mencionado, se ha descrito el funcionamiento del traspaso SRVCC.
Además, como una técnica que mejora SRVCC para reducir el tiempo necesario para conmutar las rutas de datos, existe un procedimiento SRVCC (eSRVCC: SRVCC mejorada) que utiliza la mejora de la función de control de transferencia de acceso (ATCF), como se divulga en la NPL 3. Un ejemplo de una operación de eSRVCC se describirá haciendo referencia a las figuras 3 y 4.
La figura 3 muestra una parte de una configuración de una red de comunicación móvil 3GPP que permite eSRVCC. La red de comunicación móvil mostrada en la figura 3, de manera similar a la figura 1, incluye e-UTRAN, e-nodeB, una red PS, una red CS, un subsistema de estaciones base de la red CS e IMS. Aquí, una función de control de transferencia de acceso (ATCF) y una pasarela de transferencia de acceso (ATGW), además de CSCF y SCC AS, están presentes en IMS. En las figuras 3 y 4, ATCF y ATGW se representan como un solo nodo (ATCF/ATGW 320), pero pueden proporcionarse como nodos separados.
En la figura 3, el UE 100 y el UE 102 están inicialmente conectados a la red PS, respectivamente (aquí, no se muestran una red de acceso inalámbrica, una estación base y la red PS en el lado del UE 102). Es decir, se supone que se realiza una llamada VoLTE entre el UE 100 y el UE 102. Aquí, se supone que el UE 100 se traspasa a la red CS durante una llamada.
La Ruta A, la Ruta B, la Ruta C y la Ruta D indicadas por líneas continuas en la figura 3 representan rutas a través de las cuales pasan los datos de voz. Además, los números de referencia 300, 302, 304 y 306 indicados por líneas discontinuas en la figura 3 representan rutas a través de las cuales pasan las señales en un proceso de traspaso de eSRVCC.
La figura 4 es un diagrama de secuencia que ilustra una operación de traspaso de eSRVCC. Inicialmente, el UE 100 y el UE 102 están conectados a la red PS (e-UTRAN). En un sistema en el que se realiza el traspaso eSRVCC, en la ATCF/ATGW 320, la ATCF ancla la señalización de IMS (señalización IMS), y la ATGW ancla los datos de voz. Es decir, cuando se inicia una llamada entre el UE 100 y el UE 102, la señalización IMS para el inicio de la llamada es retransmitida por la ATCF, y en un caso donde la ATCF determina que el anclaje de los datos de voz en la ATGW es necesario, la ATGW se asigna como un punto de anclaje de los datos de voz. Por lo tanto, los datos de voz entre el UE 100 y el UE 102 se transmiten y reciben a través de la Ruta A y la Ruta B. Si el UE 100 está alejado de un área de cobertura de eUTRAN, e-nodeB detecta este hecho e intercambia la señalización con RNC/nodeB a través de MME y MSC/MGW 110 (la señalización 300 mostrada en la figura 3 y ST300 mostrada en la figura 4). En ST300, se prepara una ruta de datos en la red CS entre nodeB y MSC/MGW 110. Si se termina la preparación, se da un comando para el traspaso a UTRAN (red CS) al UE 100 desde MME a través de e-nodeB.
De manera simultánea con el proceso de ST300, el MSC/MGW 110 transmite la señalización a la ATCF. Por tanto, se da un comando para la conmutación de ruta a la ATGW desde la ATCF, y un destino de transmisión/recepción de datos de voz de la ATGW se conmuta desde el UE 100 al m Sc /MGW 100 (la señalización 302 mostrada en la figura 3 y ST302 mostrada en la figura 4). Es decir, se establece la Ruta C. Además, si el proceso de conmutación de ruta a la ATGW finaliza, la ATCF transmite la señalización de indicación al SCC-AS (la señalización 302 mostrada en la figura 3 y ST302 mostrada en la figura 4).
Después del traspaso a UTRAN, el UE 100 intercambia la señalización con el MSC/MGW 110 a través de RNC/nodeB (la señalización 304 mostrada en la figura 3 y ST304 mostrada en la figura 4). Por tanto, se establece la Ruta D
Después del establecimiento de la Ruta D, el MSC/MGW 110 intercambia señalización con P-GW/S-GW a través de MME (la señalización 306 mostrada en la figura 3 y ST306 mostrada en la figura 4). Por tanto, la Ruta B se elimina.
En lo anteriormente mencionado, se ha descrito el funcionamiento del traspaso de eSRVCC.
Como códec de voz utilizado en la red CS, se usa generalmente un códec de banda ancha adaptativa de múltiples velocidades (AMR-WB) que es un códec de banda ancha (WB). AMR-WB se puede usar en una técnica de intercambio de paquetes y, por tanto, también se puede considerar que se usa en la red PS (VoLTE).
También hay un códec que soporta un modo compatible con AMR-WB como otro códec a parte de AMR-WB utilizado en la red PS (VoLTE) como el servicio de voz mejorado (EVS) descrito, por ejemplo, en la NPL 4. Se supone que el modo compatible con AMR-WB se utilizará como un códec AMR-Wb con un terminal heredado que normalmente soporta un códec AMR-WB. Por lo tanto, cuando el códec se usa en la red PS (VoLTE), se puede usar un formato de carga útil de RTP del códec AMR-WB descrito en la NPL 2.
En la técnica relacionada, el códec de banda estrecha (NB) es un códec que realiza el procesamiento de codificación y decodificación en una señal acústica digital muestreada a 8kHz. El códec de banda estrecha generalmente tiene una banda de frecuencia de 300Hz a 3,4kHz, pero la banda de frecuencia no se limita a esto y puede estar dentro de un rango de 0 a 4kHz. Por otro lado, el códec de banda ancha es un códec que realiza el procesamiento de codificación y decodificación en una señal acústica digital muestreada a 16kHz. El códec de banda ancha generalmente tiene una banda de frecuencia de 50Hz a 7kHz, pero la banda de frecuencia no se limita a esto y puede estar dentro de un rango de 0 a 8kHz. Un códec de banda superancha (SWB) es un códec que realiza el proceso de codificación y decodificación de una señal acústica digital muestreada a 32kHz. El códec de banda superancha generalmente tiene una banda de frecuencia de 50Hz a 14kHz, pero la banda de frecuencia no se limita a esto y puede estar dentro de un rango de 0 a 16kHz.
Además, el documento US 2007/173239 divulga una técnica para un primer terminal móvil que tiene una llamada en curso con un segundo terminal bajo un primer servicio de comunicaciones a través de una estación base de la red de acceso de un primer subsistema. Se detecta una condición para transferir la llamada a una estación base de la red de acceso de radio de un segundo subsistema en un controlador de red de radio del primer subsistema. Se informa a un conmutador de red central que está vinculado al controlador de red de radio del primer subsistema de dicha detección de una condición de transferencia de llamada. Si el segundo subsistema no puede procesar la llamada bajo el primer servicio de comunicaciones, se solicita un cambio de servicio para que dicha llamada pueda continuar bajo el segundo servicio de comunicaciones.
Lista de citas
Literatura no de Patente
NPL 13GPP TS23.216 v9.6.0 "Single Radio Voice Call Continuity (SRVCC)"
NPL 2 IETF RFC 4867, "RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs"
NPL 33GPP TS23.237 v11.0.0 "IP Multimedia Subsystem (IMS) Service Continuity"
NPL 43GPP TR22.813 v10.0.0 "Study of Use Cases and Requirements for Enhanced Voice Codecs for the Evolved Packet System (EPS)"
NPL 5Takashi Koshimizu and Katsutoshi Nishida, "Audio Video Call Application of Single Radio Voice Call Continuity", General meeting of the Institute of Electronics, Information and Communication Engineers in 2011, B-6-77
NPL 63GPP TS26.114 v10.0.0 "IP Multimedia Subsystem (IMS); Multimedia Telephony; Media handling and interaction"
NPL 7 G. Zorn (Ed), "RTP Payload Format for G.718 Speech/Audio," November 15, 2011, work in progress
NPL 83GPP TR23.885 v11.0.0 "Feasibility Study of Single Radio Voice Call Continuity (SRVCC) from UTRAN/GERAN to E-UTRAN/HSPA"
Sumario de la invención
Problema técnico
En la figura 1 o la figura 3, cuando el UE 100 se traspasa de la red PS a la red CS, en el caso de que el códec utilizado en la red PS no sea compatible con la red Cs, el códec utilizado por el UE 100 se cambia a un códec soportado por la red CS. En el caso de que se produzca un cambio del códec en el UE 100, para permitir la continuidad de la llamada entre el UE 100 y el UE 102, se pueden considerar los dos procedimientos siguientes. El primer procedimiento es un procedimiento para realizar la transcodificación en el MSC/MGW o la ATCF/ATGW. El segundo procedimiento es un procedimiento para cambiar el códec utilizado por el UE 102 al mismo códec que el códec cambiado del UE 100.
En el procedimiento para realizar la transcodificación, que se mencionó primero, la calidad de la llamada se deteriora debido a la transcodificación.
Por otro lado, en el procedimiento de cambio del códec, que se mencionó posteriormente, aunque no se produce un deterioro de la calidad de la llamada que se produce en el procedimiento que realiza la transcodificación, la señalización utilizada para cambiar el códec del UE 102 lleva tiempo y prolonga el tiempo de desconexión de la llamada, lo que no es favorable. Además, en el traspaso de eSRVCC, debido a que la señalización para la conmutación de ruta en el traspaso del UE 100 es finalizada en la ATCF, es difícil transmitir la señalización para cambiar el códec del UE 102. Es decir, en el traspaso de eSRVCC, es difícil cambiar el códec del UE 102 utilizando la señalización existente.
Un objeto de la presente invención es proporcionar una técnica que permita continuar la comunicación y también reducir el tiempo de desconexión de una llamada sin deteriorar la calidad de la llamada incluso cuando se cambia un códec utilizado por uno de los terminales en comunicación.
Solución al problema
La invención se presenta mediante el contenido de las reivindicaciones independientes. Los modos de realización preferentes se reivindican en las reivindicaciones dependientes.
En un ejemplo útil para comprender los antecedentes de la presente invención, un nodo de red transfiere datos entre los dos terminales, cuando uno de los dos terminales que realizan la comunicación en una primera red realiza un traspaso a una segunda red que es diferente de la primera red, el nodo de red que incluye: una sección de detección que detecta un primer códec utilizado por uno de los dos terminales en la primera red y un segundo códec para ser usado por uno de los dos terminales en la segunda red; una sección de generación que genera, cuando el primer códec es un códec que tiene un modo compatible que es compatible con el segundo códec, datos para el otro de los dos terminales conmutando un códec de datos transmitidos desde uno de los dos terminales al modo compatible del primer códec; y una sección de transmisión que transmite datos para el otro de los dos terminales al otro de los dos terminales.
En otro ejemplo, un procedimiento de comunicación para transferir datos entre los dos terminales, cuando uno de los dos terminales que realizan la comunicación en una primera red realiza un traspaso a una segunda red que es diferente de la primera red, el procedimiento de comunicación que incluye: detectar un primer códec usado por uno de los dos terminales en la primera red y un segundo códec para ser usado por uno de los dos terminales en la segunda red; generar, cuando el primer códec es un códec que tiene un modo compatible que es compatible con el segundo códec, datos para el otro de los dos terminales conmutando un códec de datos transmitidos desde uno de los dos terminales al modo compatible del primer códec; y transmitir, al otro de los dos terminales, datos para el otro de los dos terminales.
Efectos ventajosos de la invención
De acuerdo con la presente invención, incluso cuando uno de los terminales en comunicación cambia un códec en uso, es posible continuar la comunicación y también reducir el tiempo de desconexión de una llamada sin causar el deterioro de la calidad de la llamada.
Breve descripción de los dibujos
La figura 1 es un diagrama de configuración que ilustra parte de una red de comunicación móvil 3GPP; La figura 2 es un diagrama de secuencia que ilustra una operación de traspaso de SRVCC;
La figura 3 es un diagrama de configuración que ilustra parte de una red de comunicación móvil 3GPP que permite eSRVCC;
La figura 4 es un diagrama de secuencia que ilustra una operación de traspaso de eSRVCC;
La figura 5 ilustra un ejemplo de un formato de carga útil de RTP de acuerdo con el Modo de Realización 1 de la presente invención;
La figura 6 ilustra un ejemplo de un ofrecimiento de SDP y una respuesta de SDP de acuerdo con el Modo de Realización 1 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 el Modo de Realización 1 de la presente invención;
La figura 8 es un diagrama de bloques que ilustra una configuración de un nodo de red (MSC/MGW) de acuerdo con el Modo de Realización 1 de la presente invención;
La figura 9 es un diagrama de flujo que ilustra un ejemplo de procesamiento de conmutación de códec en el MSC/MGW de acuerdo con el Modo de Realización 1 de la presente invención;
La figura 10 ilustra un ejemplo de cómo se indica una solicitud de conmutación de códec en el Modo de Realización 1 de la presente invención; y
La figura 11 es un diagrama de bloques que ilustra una configuración de un terminal (UE) de acuerdo con el Modo de Realización 3 de la presente invención.
Descripción de los modos de realización
Los modos de realización de la presente invención se describirán en detalle haciendo referencia a los dibujos adjuntos.
En la siguiente descripción, el término "ancho de banda" se refiere a un ancho de banda de una señal que sirve como entrada/salida de un códec.
En la siguiente descripción, un códec disponible tanto en una red PS como en una red CS está representado mediante "códec A". El códec A tiene un formato de carga útil dedicado. El códec A es, por ejemplo, AMR-WB o AMR-NB.
Un códec disponible para la red PS está representado mediante "códec B". El códec B incluye un modo no compatible (modo no compatible con el códec A) y un modo compatible (modo compatible con el códec A) con respecto al códec A. Sin embargo, el códec B puede usarse en la red CS. El códec B es, por ejemplo, EVS o G.718 descritos en la NPL 7.
(Modo de realización 1)
La figura 5 ilustra un ejemplo de un formato de carga útil (formato de carga útil de RTP) del códec B. Como se muestra en la figura 5, el formato de carga útil consiste en una porción de datos y una porción de encabezamiento. La porción de datos incluye datos codificados por un codificador y la porción de encabezamiento incluye información necesaria para que un decodificador decodifique datos de la porción de datos.
El formato de carga útil del códec B en el presente modo de realización está configurado para permitir que el lado receptor de carga útil identifique si la porción de datos incluye datos en el modo no compatible con el códec A o datos en el modo compatible con el códec A. Por ejemplo, como se muestra en la figura 5, la porción de encabezamiento incluye un campo de "tipo de códec" y un campo de "velocidad de bits". El "tipo de códec" incluye información que indica si el códec está en el modo no compatible con el códec A o en el modo compatible con el códec A. La "velocidad de bits" incluye información que indica a qué velocidad de bits se codifican los datos entre las velocidades de bits soportadas en el modo no compatible con el códec A o velocidades de bits soportadas en el modo compatible con el códec A.
Como se muestra en la figura 5, además de los campos descritos anteriormente, también es posible incluir un campo para emitir, a un terminal homólogo en el lado receptor de la carga útil, la solicitud de conmutación del tipo de códec o la velocidad de bits (campo "solicitud de cambio de tipo de códec/velocidad de bits"). Cabe señalar que este campo no necesita incluirse para cada trama, y puede incluirse solo cuando sea necesario. El procedimiento se ha descrito hasta ahora con el formato de carga útil del códec B mostrado en la figura 5 en el que la porción de encabezamiento incluye explícitamente el campo para implementar la configuración que permite que el lado receptor de la carga útil identifique si la porción de datos incluye datos en el modo no compatible con el códec A o datos en el modo compatible con el códec A (campo "tipo de códec", campo "velocidad de bits") y el campo para emitir, al terminal homólogo, una solicitud de conmutación del tipo de códec o velocidad de bits (campo "solicitud de conmutación de tipo de códec/velocidad de bits"). Sin embargo, el procedimiento no siempre tiene que ser el procedimiento mostrado en la figura 5. Además, se ha descrito un ejemplo en el formato de carga útil que se muestra en la figura 5, donde el formato de carga útil consta de la porción de encabezamiento y la porción de datos, pero la porción de encabezamiento se puede omitir en el formato de carga útil si el terminal en el lado receptor que ha recibido la carga útil puede decodificar correctamente datos sin la porción de encabezamiento.
El formato de carga útil del códec B no se limita al ejemplo mostrado en la figura 5, y una combinación de capas (correspondientes a velocidades de bits) puede describirse como valores separados como, por ejemplo, en el caso del formato de carga útil de G.718 descrito en NPL 7.
A continuación, la figura 6 ilustra un ejemplo de un ofrecimiento de protocolo de descripción de sesión (SDP) y una respuesta de SDP intercambiada entre terminales en la negociación de sesión cuando comienza una llamada.
Aquí, se supone que ambos UE que hacen una llamada soportan el códec B y que ambos UE están conectados a la red PS cuando se inicia la llamada.
Como se muestra en la figura 6, el UE que soporta el códec B describe el códec A y el códec B en un ofrecimiento de SDP incluso cuando el UE no soporta el códec A. Esto se debe a que cuando el terminal homólogo soporta el códec A pero no soporta el códec B, el códec A se selecciona en negociación de códec para permitir el uso del modo compatible con el códec A del códec B utilizando el formato de carga útil de RTP del códec A. En la figura 6, el UE que ha recibido el ofrecimiento de SDP selecciona el códec B y describe el códec B seleccionado en la respuesta de SDP.
El ofrecimiento de SDP y la respuesta de SDP también pueden incluir la descripción de un modo preferencial (modo no compatible con el códec A o modo compatible con el códec A, velocidad de bits, ancho de banda o similar) cuando se selecciona el códec B. El modo preferencial puede ser predeterminado por un operador que realiza un servicio de comunicación e incorporado en el UE en forma de software, o similar. En el presente modo de realización, cuando se selecciona el códec B, se supone que el modo no compatible con el códec A se usa como un modo preferencial.
A continuación, se describirá la red de comunicación móvil (figura 1) de acuerdo con el presente modo de realización.
En primer lugar, se describirá el UE 100 o 102 mostrado en la figura 1.
La figura 7 es un diagrama de bloques que ilustra una configuración de los UE 100 y 102 (terminal) de acuerdo con el presente modo de realización. Los UE 100 y 102 están cada uno configurados por la sección 700 de recepción, la sección 702 de transmisión, la sección 704 de negociación de códec, la sección 706 de análisis de carga útil de RTP, la sección 708 de generación de carga útil de RTP y la sección 710 de informe de códec. En los UE 100 y 102 mostrados en la figura 7, la sección 700 de recepción recibe datos de comunicación (incluyendo la carga útil de RTP) y señalización o similares. Por ejemplo, cuando se recibe una carga útil de RTP (por ejemplo, véase figura 5) transmitida desde el MSC/MGW 110, la sección 700 de recepción envía la carga útil de RTP recibida a la sección 706 de análisis de carga útil de RTP.
La sección 702 de transmisión transmite datos de comunicación (incluyendo la carga útil de RTP) y señalización o similares.
La sección 704 de negociación de códec negocia un códec para usarlo para la comunicación entre terminales (UE 100 y UE 102). Más específicamente, la sección 704 de negociación de códec crea un ofrecimiento de SDP o una respuesta de SDP (por ejemplo, véase figura 6) y realiza la negociación de códec. En este caso, al crear un ofrecimiento de SDP, la sección 704 de negociación de códec incluye el códec A en el ofrecimiento de SDP como se muestra en la figura 6 incluso cuando el terminal soporta el códec B pero no soporta el códec A como se describió anteriormente. Cuando se selecciona el códec B en la negociación, la sección 704 de negociación de códec selecciona un modo preferencial (modo no compatible con el códec A o modo compatible con el códec A, velocidad de bits, ancho de banda o similar) de acuerdo con la información descrita en el ofrecimiento y la respuesta del SDP como se describió anteriormente o información incorporada previamente en el software o similar y envía el modo preferencial a la sección 708 de generación de carga útil de RTP.
La sección 706 de análisis de carga útil de RTP analiza la porción de encabezamiento de la carga útil de RTP recibida de la sección 700 de recepción e identifica la información relativa a los datos incluidos en la porción de datos de la carga útil de RTP (por ejemplo, tipo de códec, velocidad de bits o similar). La sección 706 de análisis de carga útil de RTP envía la información identificada y los datos incluidos en la porción de datos a un decodificador (no mostrado). Cuando la carga útil de RTP recibida de la sección 700 de recepción incluye una instrucción de "solicitud de conmutación de tipo de códec/velocidad de bits", la sección 706 de análisis de carga útil de RTP envía la instrucción a un codificador (no mostrado) y a la sección 708 de generación de carga útil de RTP. El codificador codifica los datos en base a la información e instrucciones de la sección 706 de análisis de carga útil de RTP.
La sección 708 de generación de carga útil de RTP genera una carga útil de RTP (por ejemplo, véase figura 5) que incluye información (por ejemplo, tipo de códec, velocidad de bits) relacionada con los datos recibidos del codificador y los datos recibidos de la sección 704 de negociación de códec. En este caso, al recibir una instrucción de una "solicitud de conmutación de tipo de códec/ velocidad de bits" de la sección 706 de análisis de carga útil de RTP, la sección 708 de generación de carga útil de RTP genera una carga útil de RTP en base a la instrucción. La carga útil de RTP generada se transmite a través de la sección 702 de transmisión.
Cuando el UE de la sección 710 de informe de códec realiza el traspaso de la red PS a la red CS, la sección 710 de informe de códec informa, al nodo de red (por ejemplo, MME) de la red PS, del códec utilizado por el UE en la red PS. El códec informado se indica al MSC/MGW 110 a través de un nodo de red (MME) de la red PS.
A continuación, se describirá el MSC/MGW 110 mostrado en la figura 1. La figura 8 es un diagrama de bloques que ilustra una configuración del MSC/MGW 110 (nodo de red) de acuerdo con el presente modo de realización. El MSC/MGW 110 está configurado por la sección 800 de recepción, la sección 802 de transmisión, la sección 804 de detección de códec, la sección 806 de negociación de códec, la sección 808 de generación de carga útil de RTP y la sección 810 de análisis de carga útil de RTP.
En el MSC/MGW 110 mostrado en la figura 8, la sección 800 de recepción recibe datos de comunicación (incluyendo la carga útil de RTP) y señalización o similares. Por ejemplo, al recibir la carga útil de RTP (por ejemplo, véase figura 5) transmitida desde el UE 102, la sección 800 de recepción envía la carga útil de RTP recibida a la sección 810 de análisis de carga útil de RTP.
La sección 802 de transmisión transmite los datos de comunicación (incluyendo la carga útil de RTP) y señalización o similares.
La sección 804 de detección de códec detecta un códec para ser usado por un terminal que ha realizado el traspaso desde la red PS a la red CS (UE 100 en la figura 1) en la red CS. La sección 804 de detección de códec también detecta un códec usado por un terminal que ha realizado el traspaso de la red PS a la red CS (UE 100 en la figura 1) en la red PS. El procedimiento de detección del códec utilizado por el terminal (UE 100) en la red PS puede ser un procedimiento como el divulgado en la NPL 5 que es indicado desde el nodo de red (MME o similar) en la red Ps cuando el UE 100 (sección 710 de informe de códec) realiza el traspaso a la red CS. Como alternativa, el procedimiento de detección de códec utilizado por el terminal (UE 100) en la red PS puede ser un procedimiento por el cual el códec se adquiere de otros nodos de red como el SCC AS. El procedimiento de detección de códec utilizado por el terminal (UE 100) en la red CS puede ser un procedimiento que utiliza información negociada a través de la señalización transmitida/recibida entre el UE 100 y el nodo de red (RNC y MSC/MGW 110) en la red CS cuando el UE 100 realiza el traspaso a la red CS. La sección 804 de detección de códec envía el resultado de detección de códec a la sección 808 de generación de carga útil de RTP.
La sección 806 de negociación de códec negocia el códec a usar con el UE de acuerdo con una instrucción, por ejemplo, de la sección 808 de generación de carga útil de RTP. Por ejemplo, la sección 806 de negociación de códec negocia (renegocia) el códec para ser usado con el terminal (UE 102 en la figura 1) que es el homólogo de comunicación del terminal (UE 100 en la figura 1) que ha realizado el traspaso desde la red PS a la red CS. La sección 808 de generación de carga útil de RTP genera datos (carga útil de RTP) para el homólogo de comunicación del terminal (UE 102 en la figura 1) utilizando los datos recibidos desde el terminal (UE 100 en la figura 1) en base al resultado de detección de códec recibido desde la sección 804 de detección de códec. Por ejemplo, cuando el códec utilizado por el terminal que ha realizado el traspaso de la red PS a la red CS en la red CS es el códec A y cuando el códec utilizado por el terminal en la red PS es el códec B, la sección 808 de generación de carga útil de RTP conmuta el códec de los datos (datos del códec A) recibidos del terminal a un modo compatible con el códec A del códec B. Es decir, el MSC/MGW 110 transmite los datos del códec A recibidos del terminal mientras el modo compatible con el códec A del códec B usando el formato de carga útil de RTP del códec B (véase figura 5) a través de la sección 802 de transmisión.
Cuando el resultado de detección de códec recibido de la sección 804 de detección de códec es diferente al descrito anteriormente, la sección 808 de generación de carga útil de RTP instruye a la sección 806 de negociación de códec para que negocie (renegociar) un códec con el homólogo de comunicación (UE 102 en la figura 1) cuál es el destino de transmisión de los datos recibidos. La sección 808 de generación de carga útil de RTP realiza la transcodificación, si es necesario, de los datos de comunicación recibidos del terminal que ha realizado el traspaso, en base al resultado de la negociación y conmuta el modo a un modo de códec en base al resultado de la negociación. Los datos después de la conmutación de códec (carga útil de RTP generada) se transmiten a través de la sección 802 de transmisión.
La sección 810 de análisis de carga útil de RTP analiza la porción del encabezamiento de la carga útil de RTP transmitida desde el terminal (UE 102) e identifica la información relativa a los datos (por ejemplo, tipo de códec, velocidad de bits) incluidos en la porción de datos de la carga útil de RTP. La sección 810 de análisis de carga útil de RTP envía la información especificada a la sección 804 de detección de códec.
A continuación, se describirán los detalles del procesamiento del códec en el MSC/MGW 110 (figura 8) utilizando la figura 9. Aquí, se describirá un caso donde como se muestra en la figura 1, el UE 100 realiza el traspaso de la red PS a la red CS mientras que tanto el UE 100 como el UE 102 están conectados a la red PS y están haciendo una llamada. Es decir, el MSC/MGW 110 es un nodo de red que transfiere datos entre dos terminales cuando un UE 100 de los dos terminales (UE 100 y 102) que realiza la comunicación en la red PS realiza el traspaso a la red CS.
En ST900 mostrada en la figura 9, la sección 808 de generación de carga útil de RTP determina si el códec utilizado por el UE 100 en la red CS es el códec A o no en base al resultado de detección en la sección 804 de detección de códec.
Cuando el códec utilizado por el UE 100 en la red CS es el códec A (ST900: SI), en ST902, la sección 808 de generación de carga útil de RTP determina si el códec utilizado por el UE 100 en la red PS (antes del traspaso) es el códec B o no en base al resultado de detección en la sección 804 de detección de códec.
Cuando el códec utilizado por el UE 100 en la red PS es el códec B (ST902: SI), en ST904, la sección 808 de generación de carga útil de RTP conmuta el códec de datos (códec A) transmitido desde el UE 100 a un modo compatible con el códec A del códec B. Es decir, la sección 808 de generación de carga útil de RTP transforma los datos del códec A transmitidos desde el UE 100 en un modo compatible con el códec A del códec B usando el formato de carga útil de RTP del códec B y transmite los datos al UE 102 a través de la sección 802 de transmisión.
Esto permite que el UE 102 que usa el códec B maneje los datos transmitidos desde el MSC/MGW 110 al UE 102 como los datos del códec B (modo compatible con el códec A del códec B).
Por otra parte, cuando el códec utilizado por el UE 100 en la red CS no es el códec A (ST900: NO) o cuando el códec utilizado por el UE 100 en la red PS no es el códec B (ST902: NO), en sT906, la sección 806 de negociación de códec realiza una renegociación de sesión con el UE 102 y determina el códec. La sección 808 de generación de carga útil de RTP genera una carga útil de RTP del códec determinado.
Como alternativa, en ST906, el MSC/MGW 110 puede realizar la transcodificación de los datos transmitidos desde el UE 100 y transmitir los datos transcodificados (datos para el UE 102) al UE 102.
Por tanto, cuando se detecta un cambio en el códec de un UE, el MSC/MGW 110 determina si el códec de datos para el otro UE puede conmutarse en base al códec después del cambio del UE y el códec antes del cambio del UE.
A continuación, se describirá un ejemplo de funcionamiento del UE 100 o 102 (figura 7) y el MSC/MGW 110 (figura 8) en el presente modo de realización.
En la siguiente descripción, en la figura 1 y la figura 2, tanto el UE 100 como el UE 102 están conectados a la red PS e inician una llamada. Aquí, supongamos que se realiza una llamada desde el UE 100 al UE 102.
Cuando se inicia una llamada, se negocia un códec para utilizar entre el UE 100 y el UE 102. Por ejemplo, el UE 100 (sección 704 de negociación de códec) genera un ofrecimiento de SDP (por ejemplo, véase figura 6) y transmite el ofrecimiento de SDP al UE 102. Por el contrario, el UE 102 (sección 704 de negociación de códec) genera una respuesta de SDP (por ejemplo, véase figura 6, el códec B es seleccionado en la figura 6), y transmite la respuesta de SDP al UE 100. Al completar la operación de un ejemplo asociado con este inicio de llamada, el UE 100 o 102 realiza una llamada utilizando un modo no compatible con el códec A del códec B (modo preferencial cuando se selecciona el códec B) (figura 2: Sesión de Voz sobre PS).
A continuación, como se muestra en la figura 1, el UE 100 realiza el traspaso de la red PS a la red CS (ST200 y ST204 mostradas en la figura 2). Aquí, supongamos que el códec utilizado por el UE 100 en la red CS es el códec A.
Simultáneamente con el procesamiento de traspaso del UE 100, el MSC/MGW 110 (sección 804 de detección de códec) detecta el códec que utilizará el UE 100 cuando realice el traspaso a la red CS. El MSC/MGW 110 (sección 804 de detección de códec) también detecta el códec utilizado por el UE 100 en la red PS. Como se describió anteriormente, el MSC/MGW 110 detecta que el códec utilizado por el UE 100 en la red CS es el códec A y el códec utilizado por el UE 100 en la red PS es el códec B (es decir, ST900 mostrada en la figura 9: SÍ y ST902: SÍ).
En este caso, el MSC/MGW 110 (sección 808 de generación de carga útil de RTP) conmuta el códec de los datos transmitidos desde el UE 100 (códec A) a un modo compatible con el códec A del códec B y, de este modo, genera una carga útil de RTP para el UE 102. Es decir, el MSC/MGW 110 transmite los datos del códec A transmitido desde el UE 100 como un modo compatible con el códec A del códec B al UE 102 usando el formato de carga útil de RTP del códec B.
En este caso, cuando la sección 808 de generación de carga útil de RTP conmuta el códec de los datos transmitidos desde el UE 100, el MSC/MGW 110 puede transmitir una solicitud para conmutar de un modo no compatible con el códec A a un modo compatible con el códec A al UE 102, que es el homólogo de comunicación del UE 100. Por ejemplo, en el formato de carga útil de RTP del códec B (por ejemplo, véase figura 5), el MSC/MGW 110 (sección 808 de generación de carga útil de RTP) puede incluir una instrucción para conmutar desde el modo no compatible con el códec A al modo compatible con el códec A en la porción de encabezamiento (campo "solicitud de cambio de tipo de códec/velocidad de bits").
Por otra parte, el UE 102 (sección 706 de análisis de carga útil de RTP) determina que los datos incluidos en la porción de datos de la carga útil de RTP es el códec A (códec que puede manejarse como un modo compatible con el códec A) a partir de la información incluida en los datos recibidos del m Sc /MGW 110 (información de la porción de encabezamiento de la carga útil de RTP) y traspasa la información y los datos al decodificador. Esto hace que el decodificador del UE 102 reconozca que el códec de los datos recibidos es el códec A (modo compatible con el códec A del códec B) y decodifica los datos.
Cuando la carga útil de RTP recibida incluye una solicitud para conmutar del modo no compatible con el códec A al modo compatible con el códec A, el UE 102 (por ejemplo, la sección 706 de análisis de carga útil de RTP) envía la solicitud para conmutar a un codificador (no mostrado) y la sección 708 de generación de carga útil de RTP. Esto hace que el UE 102 determine el uso del modo compatible con el códec A del códec B también para datos transmitidos desde el UE 102. Es decir, el UE 102 (sección 708 de generación de carga útil de RTP) almacena los datos del modo compatible con el códec A recibido del codificador en el formato de carga útil del códec B y transmite los datos al m Sc /MGW 110.
Por tanto, de acuerdo con el presente modo de realización, en el MSC/MGW 110, la sección 804 de detección de códec detecta el códec utilizado por el UE 100 en la red PS y el códec a ser usado por el UE 100 en la red CS, y cuando el códec utilizado por el UE 100 en la red PS es un códec que tiene un modo compatible con el códec utilizado por el UE 100 en la red CS, la sección 808 de generación de carga útil de RTP genera datos para el UE 102 conmutando el códec de datos transmitidos desde el UE 100 a un modo compatible del códec usado por el UE 100 en la red PS. Es decir, cuando el códec utilizado por el UE 100 en la red PS es un códec que tiene un modo compatible con el códec utilizado por el UE 100 en la red CS, el MSC/MGW 110 transmite los datos del códec A transmitido desde el UE 100 en el modo compatible con el códec A usando el formato de carga útil de RTP del códec B. Esto permite que el UE 102 que usa el códec B reciba datos desde el UE 100 sin cambiar el códec del UE 102.
Es decir, el MSC/MGW 110 conmuta los datos del códec después del traspaso desde el UE 100 a parte de un códec antes del traspaso (uno de los modos de códec antes del traspaso), elimina la necesidad de señalizar para cambiar el códec entre el UE 100 y UE 102 y puede, de este modo, evitar que el tiempo de desconexión de una llamada se prolongue. El MSC/MGW 110 conmuta solo el modo de códec sin cambiar los datos del códec entre el UE 100 y el UE 102 y puede, de este modo, prevenir el deterioro de la calidad de la llamada a diferencia de con la transcodificación. Por tanto, de acuerdo con el presente modo de realización, incluso cuando se cambia el códec utilizado por uno de los terminales en la comunicación, es posible continuar la comunicación y también reducir el tiempo de desconexión de una llamada sin causar el deterioro de la calidad de la llamada.
De acuerdo con el presente modo de realización, cuando un códec de datos transmitidos desde un terminal (UE 100) es conmutado, el MSC/MGW 110 transmite, al otro terminal (UE 102), una solicitud para conmutar a un modo compatible para los datos transmitidos por el otro terminal (UE 102). El UE 102 transmite entonces datos en el modo compatible con el códec A de acuerdo con la solicitud para conmutar al modo compatible con el códec A desde el MSC/MGW 110. Esto permite que el MSC/MGW 110 y el UE 100 manejen los datos transmitidos desde el UE 102 (modo compatible con el códec A del códec B) como datos del códec A.
Cabe señalar que la indicación de la solicitud de conmutación desde el modo no compatible con el códec A al modo compatible con el códec A al UE 102 no siempre necesita incluirse en la carga útil de RTP desde el MSC/MGW 110 al UE 102. Por ejemplo, la solicitud de conmutación puede indicarse al UE 102 como un ofrecimiento de SDP mostrado en la figura 10 en el SDP de INVITAR con el SDP-MGW transmitido desde el MSC/MGW 110 en la ST202 mostrado en la figura 2. Además, la solicitud de conmutación descrita anteriormente puede indicarse desde el MSC/MGW 110 al UE 102 utilizando el RTCP-APP divulgado en la NPL 6.
Cuando el UE 102 recibe datos del códec A en el formato de carga útil de RTP del códec B, el UE 102 puede determinar que los datos desde el UE 102 (datos de transmisión) también deberían codificarse en el modo compatible con el códec A después de recibir los datos. En este caso, la solicitud de conmutación descrita anteriormente se vuelve innecesaria.
(Modo de realización 2)
El presente modo de realización se describirá usando la figura 3 y la figura 4. En la siguiente descripción, al igual que en el Modo de realización 1, supongamos que el UE 100 y el UE 102 realizan una llamada utilizando el códec B en la red PS primero, y solo el UE 100 realiza el traspaso de la red PS a la red CS. Además, el códec utilizado por el UE 100 en la red CS es el códec A.
La ATCF/ATGW 320 mostrada en la figura 3 y la figura 4 es simplemente un punto de anclaje de datos. Por lo tanto, cuando la ATCF/ATGW 320 mostrada en la figura 3 y la figura 4 está renviando datos desde el UE 100 al UE 102 o datos desde el UE 102 al UE 100, las funciones del MSC/MGW 110 (figura 8) y UE 100, UE 102 (figura 7) son idénticas a las del Modo de realización 1 (figura 5 a figura 9). Sin embargo, el MSC/MGW 110 es diferente de el del Modo de realización 1 solo porque INVITAR con SDP en la ST202 mostrado en la figura 2 no se puede utilizar cuando una solicitud de conmutación de códec (solicitud para conmutar desde un modo no compatible con el códec A a un modo compatible con el códec A) se indica al Ue 102.
Supongamos que la ATCF/ATGW 320 tiene información sobre un códec utilizado por el UE 100 en la Ruta B mostrada en la figura 3 y un códec utilizado por el UE 102 en la Ruta A mostrada en la figura 3 o está provisto de medios capaces de obtener la información desde otro nodo.
En este caso, incluso cuando la sección 804 de detección de códec del MSC/MGW 110 no tiene información sobre el códec utilizado por el UE 100 en la red PS (Ruta B mostrada en la figura 3), la ATCF/ATGW 320 puede indicar, al MSC/MGW 110, la información sobre el códec utilizado por el UE 100 en la red PS como mensaje de respuesta de INVITAR con el SDP-MGW en la ST302 mostrada en la figura 4.
Por tanto, el MSC/MGW 110 (sección 808 de generación de carga útil de RTP) puede identificar inmediatamente un códec utilizado por el UE 100 (terminal que ha realizado el traspaso) en la red PS. Es decir, el MSC/MGW 110 puede establecer los datos transmitidos desde el UE 100, en base al códec utilizado por el UE 100 (terminal que ha realizado el traspaso) en la red PS en un modo compatible con el códec A usando el formato de carga útil de RTP del códec B, y transmitir inmediatamente los datos al UE 102. De manera similar, el MSC/MGW 110 puede transmitir inmediatamente, al UE 102, una solicitud de conmutación al UE 102.
De acuerdo con el presente modo de realización, incluso en el caso de un esquema eSRVCC o un caso en el que el códec usado por uno de los terminales en comunicación es cambiado como en el Modo de realización 1, es posible continuar la comunicación mientras se reduce el tiempo de desconexión de una llamada sin causar deterioro de la calidad de la llamada.
(Modo de realización 3)
En este modo de realización, se proporcionará una descripción de un caso en el que un terminal que ha realizado el traspaso desde la red PS a la red CS (UE 100 en la figura 1) vuelve a la red PS.
La figura 11 es un diagrama de bloques que ilustra una configuración de los UE 100 y 102 (terminal) de acuerdo con el presente modo de realización. En la figura 11, a los componentes idénticos a los del Modo de realización 1 (figura 7) se les asignarán los mismos números de referencia y se omitirá la descripción de los mismos.
En el UE 100 (102) mostrado en la figura 11, la sección 1100 de identificación de posición del terminal identifica una red (red PS o red CS) a la que está conectado el UE 100 (102) de la sección 1100 de identificación de la posición del terminal, es decir, la sección 1100 de identificación de la posición del terminal identifica la posición del UE 100 (102). Esto permite al UE 100 (102) realizar el traspaso. La sección 1100 de identificación de posición del terminal puede determinar la posición del UE 100 (102) de la sección 1100 de identificación de la posición del terminal desde el ID de la estación base del destino (por ejemplo, e-nodeB o nodeB) o determinar la posición del UE 100 o 102 desde el establecimiento de la conexión en la red central PS.
Por ejemplo, supongamos que el UE 100 que ha realizado el traspaso de la red PS a la red CS vuelve de nuevo a la red Ps . Además, supongamos que el UE 100 utiliza el códec A en la red CS. En este momento, la sección 1100 de identificación de posición del terminal identifica que el UE 100 se ha conectado a la red PS.
El UE 100 que ha identificado a través de la sección 1100 de identificación de posición del terminal que el UE 100 se ha conectado a la red PS, conmuta el códec del UE 100 del códec A al códec B (modo no compatible con el códec A). La sección 708 de generación de carga útil de RTP del UE 100 genera una carga útil de RTP utilizando el formato de carga útil del códec B. Esta carga útil de RTP se transmite al UE 102 a través de la sección 702 de transmisión.
Por otra parte, la sección 706 de análisis de carga útil de RTP del UE 102 detecta que el códec de los datos recibidos del UE 100 se ha cambiado de un modo compatible con el códec A a un modo no compatible con el códec A. La sección 706 de análisis de carga útil de RTP traspasa entonces información a un decodificador indicando que el códec del UE 100 se ha conmutado y los datos. Por tanto, el decodificador del UE 102 decodifica los datos recibidos del UE 100 en el modo no compatible con el códec A del códec B.
Cuando la carga útil de RTP recibida incluye una solicitud para conmutar del modo compatible con el códec A al modo no compatible con el códec A, la sección 706 de análisis de carga útil de RTP de UE 102 traspasa esta solicitud de conmutación al codificador y la sección 708 de generación de carga útil de RTP. Por consiguiente, el UE 102 determina utilizar el modo no compatible con el códec A del códec B también en los datos transmitidos desde el UE 102. Es decir, la sección 708 de generación de carga útil de RTP de UE 102 almacena los datos en el modo no compatible con el códec A traspasado por el codificador en el formato de carga útil del códec B y transmite los datos al UE 100.
La indicación de la solicitud de conmutación del modo compatible con el códec A al modo no compatible con el códec A al UE 102 no siempre necesita incluirse en la carga útil de RTP desde el UE 100 al UE 102. Por ejemplo, la solicitud de conmutación puede incluirse en un mensaje IMS descrito en la NPL 8. La solicitud de conmutación puede indicarse desde el MSC/MGW 110 al UE 102 usando el RTCP-APP descrito en la NPL 6. Al recibir los datos en el modo no compatible con el códec A en el formato de carga útil de RTP del códec B, el UE 102 puede determinar que los datos del UE 102 (datos de transmisión) también deberían codificarse en el modo no compatible con el códec A después de recibir los datos. En este caso, la solicitud de conmutación descrita anteriormente se vuelve innecesaria.
De este modo, incluso cuando el terminal que ha realizado el traspaso de la red PS a la red CS vuelve de nuevo a la red PS, el terminal cambia el códec en base a la posición actual del terminal y, de este modo, puede continuar la comunicación mientras se reduce el tiempo de desconexión de una llamada sin causar un deterioro de la calidad de la llamada.
En lo anteriormente mencionado, se han descrito modos de realización de la invención.
En los modos de realización descritos anteriormente, la ATCF/ATGW 320, el MSC/MGW 110, y el SCC AS/CSCF se han descrito como un solo nodo. Sin embargo, la ATCF/ATGW 320, el MSC/MGW 110 y el SCC AS/CSCF pueden estar configurados cada uno por dos o más nodos diferentes que estén conectados entre sí a través de una interfaz. Es decir, la función descrita anteriormente puede distribuirse sobre una pluralidad de nodos entre la ATCF y ATGW, entre el MSC y MGW, y entre el SCC As y CSCF.
Además, en los modos de realización respectivos descritos anteriormente, la descripción se ha realizado principalmente utilizando el códec relativo a la voz. Sin embargo, la invención no se limita a esto, y puede aplicarse a música, sonido, imágenes o similares.
Además, la presente invención no está limitada de ninguna manera a los modos de realización descritos anteriormente, y son posibles diversas modificaciones.
Aunque los modos de realización anteriores se han descrito para el ejemplo de implementación de hardware de la presente invención, la presente invención se puede implementar con software, de manera conjunta con hardware.
Cada uno de los bloques funcionales utilizados en las descripciones de los modos de realización se realiza normalmente mediante LSI (integración a gran escala), que es un circuito integrado. Cada uno de los bloques funcionales puede ser un único chip separado, o algunos o todos los bloques funcionales se pueden hacer de manera conjunta en un solo chip. En el presente documento se usa el término "LSI", pero el circuito integrado puede denominarse CI (circuito integrado), un dispositivo LSI de sistema, un dispositivo super-LSI o un dispositivo ultra-LSI dependiendo de la diferencia en el grado de integración.
Además, el circuito integrado no está limitado a la LSI y puede ser implementado mediante un circuito dedicado o mediante un procesador de propósito general. Además, se puede usar una FPGA (matriz de puertas programables por campo), que es programable, o un procesador reconfigurable que permita la reconfiguración de las conexiones o configuraciones de las celdas del circuito en la LSI después de la producción de la LSI. Además, en el caso de que surja una tecnología para la integración de circuitos que reemplace a la tecnología LSI por avances en la tecnología de semiconductores o tecnología derivada de la misma, dicha tecnología puede usarse para integrar los bloques funcionales. Por ejemplo, puede aplicarse la biotecnología.
Aplicabilidad industrial
Lista de signos de referencia
100, 102 UE
200, 202, 204, 206, 300, 302, 304, 306 Señalización
110 MSC/MGW
320 ATCF/ATGW
700, 800 Sección de recepción.
702, 802 Sección de transmisión
704, 806 Sección de negociación de códec.
706, 810 Sección de análisis de carga útil de RTP
708, 808 Sección de generación de carga útil de RTP
710 Sección de informe de códec
804 Sección de detección de códec
1100 Sección de identificación de la posición del códec

Claims (22)

REIVINDICACIONES
1. Un sistema de comunicación que comprende:
un nodo (110) de red;
un primer terminal (100) que soporta un primer códec y un segundo códec; y
un terminal (102) que soporta el primer códec y otro códec,
en el que:
el primer códec es un códec diferente de un códec heredado, el primer códec soporta un modo compatible y un modo no compatible, el modo compatible que es compatible con el segundo códec y puede utilizarse como el segundo códec y el modo no compatible que no es compatible con el segundo códec y no puede utilizarse como el segundo códec, el segundo códec que es el códec heredado,
el primer terminal y el terminal están adaptados para negociar el modo no compatible en una negociación de sesión para comunicar datos entre el primer terminal y el terminal cuando dicha comunicación comienza en una red de conmutación de paquetes, PS,
el nodo (110) de red que está adaptado para detectar si el modo no compatible negociado del primer terminal es conmutado al modo compatible o al segundo códec en la comunicación de datos entre el primer terminal y el terminal y, después de dicha detección, para transmitir una señal para que el terminal conmute el modo no compatible negociado del terminal al modo compatible mediante el uso de un formato de carga útil del primer códec; y
el terminal está adaptado para conmutar el modo no compatible negociado del terminal al modo compatible sin cambiar el primer códec, en base a la señal.
2. El sistema de comunicación de acuerdo con la reivindicación 1, en el que el formato de carga útil es común para el modo compatible y el modo no compatible.
3. El sistema de comunicación de acuerdo con la reivindicación 1, en el que el nodo de red está adaptado para detectar si el modo no compatible negociado es conmutado a un tercer códec que no sea el modo compatible y no el segundo códec, y los dos terminales están adaptados para renegociar un códec que se va a usar para la comunicación.
4. Un procedimiento de comunicación para su uso en un sistema de comunicación, que incluye al menos un nodo de red, un primer terminal y un terminal, en el que el primer terminal soporta un primer códec y un segundo códec, y el terminal soporta el primer códec y otro códec, en el que el primer códec es un códec diferente de un códec heredado, el primer códec soporta un modo compatible y un modo no compatible, siendo compatible el modo compatible con el segundo códec y puede utilizarse como el segundo códec y siendo no compatible el modo no compatible con el segundo códec y no puede utilizarse como el segundo códec, siendo el segundo códec el códec heredado, el procedimiento de comunicación que comprende:
negociar, por el primer terminal y el terminal, el modo no compatible en una negociación de sesión para comunicar datos entre el primer terminal y el terminal cuando dicha comunicación comienza en una red de conmutación de paquetes, PS;
detectar, por el nodo de la red, si el modo no compatible negociado del primer terminal es conmutado al modo compatible o al segundo códec en la comunicación de datos entre el primer terminal y el terminal, y después de dicha detección, transmitir una señal para que el terminal conmute el modo no compatible negociado del terminal al modo compatible utilizando un formato de carga útil del primer códec; y conmutar, por el terminal, el modo no compatible negociado del terminal al modo compatible sin cambiar el primer códec, en base a la señal.
5. El procedimiento de comunicación de acuerdo con la reivindicación 4, que comprende
detectar, por el nodo de la red, si el modo no compatible negociado es conmutado a un tercer códec que no sea el modo compatible y no el segundo códec, y renegociar, por los dos terminales, un códec que se va a usar para la comunicación.
6. El procedimiento de comunicación de acuerdo con la reivindicación 4,
en el que un formato de carga útil de protocolo de Transporte en Tiempo Real, RTP, común para el modo compatible y el modo no compatible, es el formato de carga útil.
7. Un terminal (102) para la comunicación, el terminal que comprende:
medios para soportar un primer códec y otro códec, donde el primer códec es un códec diferente de un códec heredado, el primer códec soporta un modo compatible y un modo no compatible, el modo compatible que es compatible con un segundo códec y puede ser utilizado como el segundo códec, y el modo no compatible que no es compatible con el segundo códec y no puede utilizarse como el segundo códec, siendo el segundo códec el códec heredado,
un negociador adaptado para negociar el modo no compatible en una negociación de sesión para comunicar datos entre un primer terminal y el terminal cuando la comunicación comienza en una red de conmutación de paquetes, PS, el primer terminal que soporta el primer códec y el segundo códec; un receptor adaptado para recibir una señal para conmutar el modo no compatible negociado del terminal al modo compatible, en el que la señal utiliza un formato de carga útil del primer códec; y
un generador adaptado para conmutar el modo no compatible negociado al modo compatible sin cambiar el primer códec, en base a la señal durante la comunicación de datos.
8. El terminal de acuerdo con la reivindicación 7,
en el que el negociador está adaptado para seleccionar un modo preferencial, que es uno del modo compatible y el modo no compatible, en base a la información descrita en un ofrecimiento de Protocolo de Descripción de Sesión, SDP, y respuestas o información incorporada previamente en el software.
9. El terminal de acuerdo con la reivindicación 7,
en el que el formato de carga útil de protocolo de Transporte en Tiempo Real, RTP, común para el modo compatible y el modo no compatible, es el formato de carga útil.
10. El terminal de acuerdo con la reivindicación 9, que comprende además:
un transmisor adaptado para transmitir datos que se codifican utilizando el modo compatible utilizando el formato de carga útil del primer códec.
11. El terminal de acuerdo con la reivindicación 7,
en el que un formato de carga útil de protocolo de Transporte en Tiempo Real, RTP, es el formato de carga útil del primer códec, y la señal está incluida en él.
12. El terminal de acuerdo con la reivindicación 7,
en el que la señal es transmitida por un Protocolo de Control de Transporte en Tiempo Real, RTCP.
13. El terminal de acuerdo con la reivindicación 7,
en el que la señal se incluye en un ofrecimiento de Protocolo de Descripción de Sesión, SDP.
14. El terminal de acuerdo con la reivindicación 7,
en el que la señal se transmite desde un nodo de red.
15. Un procedimiento de comunicación para un terminal para comunicar datos de audio/voz entre un primer terminal y el terminal, en el que el terminal soporta un primer códec y otro códec, y el primer terminal soporta el primer códec y un segundo códec, el procedimiento que comprende:
negociar un modo no compatible del primer códec en una negociación de sesión para comunicar datos entre el primer terminal y el terminal cuando la comunicación comienza en una red de conmutación de paquetes, PS, el primer códec que es un códec diferente de un códec heredado, el primer códec que soporta un modo compatible y el modo no compatible, el modo compatible que es compatible con el segundo códec y puede utilizarse como el segundo códec, y el modo no compatible que no es compatible con el segundo códec y no puede utilizarse como el segundo códec, el segundo códec que es el códec heredado;
recibir una señal para conmutar el modo no compatible negociado del terminal al modo compatible utilizando un formato de carga útil del primer códec; y
conmutar el modo no compatible negociado al modo compatible sin cambiar el primer códec, en base a la señal durante la comunicación de datos.
16. El procedimiento de comunicación de acuerdo con la reivindicación 15, que comprende, además: transmitir datos de audio/voz que se codifican utilizando el modo compatible utilizando el formato de carga útil del primer códec.
17. El procedimiento de comunicación de acuerdo con la reivindicación 15, que comprende, además: seleccionar un modo preferencial, que es uno de, el modo compatible y el modo no compatible, en base a la información descrita en un ofrecimiento de Protocolo de Descripción de Sesión, SDP, y respuestas o información incorporada previamente en el software.
18. El procedimiento de comunicación de acuerdo con la reivindicación 15, en el que un formato de carga útil de protocolo de Transporte en Tiempo Real, RTP, común para el modo compatible y el modo no compatible, es el formato de carga útil.
19. El procedimiento de comunicación de acuerdo con la reivindicación 15, en el que la señal se incluye en un formato de carga útil de protocolo de Transporte en Tiempo Real, RTP, que es el formato de carga útil del primer códec.
20. El procedimiento de comunicación de acuerdo con la reivindicación 15, en el que la señal es transmitida por un Protocolo de Control de Transporte en Tiempo Real, RTCP.
21. El procedimiento de comunicación de acuerdo con la reivindicación 15, en el que la señal se incluye en un ofrecimiento de Protocolo de Descripción de Sesión, SDP.
22. El procedimiento de comunicación de acuerdo con la reivindicación 15, en el que la señal se transmite desde un nodo de red.
ES12853666T 2011-11-30 2012-11-16 Nodo de red y procedimiento de comunicación Active ES2728678T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2011261617 2011-11-30
PCT/JP2012/007358 WO2013080471A1 (ja) 2011-11-30 2012-11-16 ネットワークノード及び通信方法

Publications (1)

Publication Number Publication Date
ES2728678T3 true ES2728678T3 (es) 2019-10-28

Family

ID=48534970

Family Applications (1)

Application Number Title Priority Date Filing Date
ES12853666T Active ES2728678T3 (es) 2011-11-30 2012-11-16 Nodo de red y procedimiento de comunicación

Country Status (7)

Country Link
US (4) US9456388B2 (es)
EP (2) EP2787765B1 (es)
JP (3) JP6012625B2 (es)
ES (1) ES2728678T3 (es)
PL (1) PL2787765T3 (es)
TR (1) TR201907782T4 (es)
WO (1) WO2013080471A1 (es)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2787765B1 (en) 2011-11-30 2019-03-06 Panasonic Intellectual Property Corporation of America Network node and communication method
WO2015129181A1 (ja) * 2014-02-28 2015-09-03 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 音声通信端末、中間ノード、処理装置、接続方法およびプログラム
WO2015169210A1 (en) * 2014-05-05 2015-11-12 Mediatek Inc. Method and apparatus for managing a call during a handover procedure in a communications system
WO2015174018A1 (ja) * 2014-05-13 2015-11-19 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ ネットワークノード及びシグナリング処理方法
BR112017002286A2 (pt) 2014-09-05 2019-09-03 Intel Corp impedimento de transcodificação durante continuidade de chamada de voz de rádio única (srvcc)
US10148703B2 (en) 2014-10-09 2018-12-04 T-Mobile Usa, Inc. Service capabilities in heterogeneous network
CN107251610B (zh) * 2015-05-20 2020-09-25 松下电器（美国）知识产权公司 通信节点、终端及通信控制方法
US10057393B2 (en) 2016-04-05 2018-08-21 T-Mobile Usa, Inc. Codec-specific radio link adaptation
US9826072B1 (en) * 2016-09-29 2017-11-21 T-Mobile Usa, Inc. Network-terminal interoperation using compatible payloads
US11799922B2 (en) 2016-12-21 2023-10-24 T-Mobile Usa, Inc. Network core facilitating terminal interoperation
WO2018170705A1 (zh) * 2017-03-20 2018-09-27 华为技术有限公司 一种业务通信方法及设备
US10771509B2 (en) 2017-03-31 2020-09-08 T-Mobile Usa, Inc. Terminal interoperation using called-terminal functional characteristics
MX2019013558A (es) * 2017-05-18 2020-01-20 Fraunhofer-Gesellschaft zur Förderung der Angewandten Forschung Ev Dispositivo de red de gestion.
KR102703720B1 (ko) * 2018-07-20 2024-09-06 삼성전자주식회사 축합환 화합물, 이를 포함한 조성물 및 이를 포함한 유기 발광 소자
US11611909B2 (en) * 2018-09-07 2023-03-21 Apple Inc. Apparatus and method for signaling ran-assisted codec adaptation capabilities in IMS multimedia telephony sessions
EP3895395A1 (en) * 2018-12-10 2021-10-20 Telefonaktiebolaget LM Ericsson (publ) Network node, entity and methods performed therein for handling a communication session in a communication network

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6751477B1 (en) * 2000-05-17 2004-06-15 Telefonaktiebolaget Lm Ericsson (Publ) Systems and methods for dynamically optimizing the fidelity of a speech signal received from a wireless telephony device and transmitted through a packet-switched network
JP3449353B2 (ja) 2000-12-13 2003-09-22 日本電気株式会社 通信方式およびトランスコーダのアライメント方法
US7149515B2 (en) * 2003-10-17 2006-12-12 Motorola, Inc. Vocoder selection method
FR2862473B1 (fr) 2003-11-18 2006-03-24 Nortel Networks Ltd Procede de controle de service de communication dans un systeme de telecommunication et commutateur associe
JP2005236388A (ja) * 2004-02-17 2005-09-02 Nippon Telegr & Teleph Corp <Ntt> リソース管理方法、リソース管理装置、リソース管理プログラム及びそのプログラムを記録した記録媒体
EP2549829A3 (en) * 2004-03-04 2014-10-15 Telefonaktiebolaget L M Ericsson (publ) Method for transmitting data in a telecommunications network and device utilising that method
US20050254440A1 (en) * 2004-05-05 2005-11-17 Sorrell John D Private multimedia network
US20090003570A1 (en) * 2007-06-26 2009-01-01 Texas Instruments Incorporated Method, system and apparatus for providing endpoint-to-endpoint transcoding free connection
CN101822093A (zh) * 2007-08-14 2010-09-01 爱立信电话股份有限公司 编解码器协商和选择中的或与之相关的改进
US8391241B2 (en) * 2007-10-04 2013-03-05 Telefonaktiebolaget L M Ericsson (Publ) Inter-system handoff using circuit switched bearers for serving general packet radio service support nodes
CN101222690B (zh) * 2008-02-01 2012-12-12 华为技术有限公司 一种编码切换方法、系统和设备
US8204022B2 (en) 2008-02-20 2012-06-19 Alcatel Lucent Method of providing transcoding during voice-over-internet protocol handoff
EP2417749A4 (en) * 2009-04-07 2017-01-11 Telefonaktiebolaget LM Ericsson (publ) Method and arrangement for session negotiation
JP5001983B2 (ja) 2009-07-21 2012-08-15 株式会社エヌ・ティ・ティ・ドコモ 通信制御システム、及び通信制御方法
US9027062B2 (en) * 2009-10-20 2015-05-05 Time Warner Cable Enterprises Llc Gateway apparatus and methods for digital content delivery in a network
JP5140696B2 (ja) * 2010-04-26 2013-02-06 株式会社エヌ・ティ・ティ・ドコモ 移動通信システム及び移動局
US9077774B2 (en) * 2010-06-04 2015-07-07 Skype Ireland Technologies Holdings Server-assisted video conversation
WO2012153165A1 (en) * 2011-05-06 2012-11-15 Nokia Corporation A pitch estimator
EP2787765B1 (en) * 2011-11-30 2019-03-06 Panasonic Intellectual Property Corporation of America Network node and communication method

Also Published As

Publication number Publication date
TR201907782T4 (tr) 2019-06-21
JPWO2013080471A1 (ja) 2015-04-27
US20190150038A1 (en) 2019-05-16
JP6012625B2 (ja) 2016-10-25
US9906990B2 (en) 2018-02-27
US20140342739A1 (en) 2014-11-20
EP3493595A1 (en) 2019-06-05
JP6434601B2 (ja) 2018-12-05
JP2018029398A (ja) 2018-02-22
US10362514B2 (en) 2019-07-23
EP2787765A4 (en) 2015-07-29
JP6246293B2 (ja) 2017-12-13
EP3493595B1 (en) 2020-05-20
WO2013080471A1 (ja) 2013-06-06
PL2787765T3 (pl) 2019-09-30
EP2787765A1 (en) 2014-10-08
US9456388B2 (en) 2016-09-27
US20180139662A1 (en) 2018-05-17
US10225767B2 (en) 2019-03-05
EP2787765B1 (en) 2019-03-06
JP2017017746A (ja) 2017-01-19
US20160360448A1 (en) 2016-12-08

Similar Documents

Publication Publication Date Title
ES2728678T3 (es) Nodo de red y procedimiento de comunicación
JP6647364B2 (ja) 通信端末装置、通信方法及び集積回路
ES2749222T3 (es) Terminal y procedimiento de selección de modo de codificación
JP6420328B2 (ja) ネットワークノード及びシグナリング処理方法
US20180041924A1 (en) Communication node, terminal, and communication control method
ES2346759T3 (es) Procedimiento de control de servicio de comunicacion en un sistema de telecomunicacion, y conmutador asociado.