ES2465218T3 - Método para transferir múltiples sesiones, dispositivo de control de llamadas y servidor de continuidad de servicio - Google Patents

Método para transferir múltiples sesiones, dispositivo de control de llamadas y servidor de continuidad de servicio Download PDF

Info

Publication number
ES2465218T3
ES2465218T3 ES10811234.3T ES10811234T ES2465218T3 ES 2465218 T3 ES2465218 T3 ES 2465218T3 ES 10811234 T ES10811234 T ES 10811234T ES 2465218 T3 ES2465218 T3 ES 2465218T3
Authority
ES
Spain
Prior art keywords
session
transfer
transferred
scc
voice
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
ES10811234.3T
Other languages
English (en)
Other versions
ES2465218T5 (es
Inventor
Qiang YI
Hui Jin
Shuiping Long
Xiaoyan Duan
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.)
Huawei Device Co Ltd
Original Assignee
Huawei Device Co Ltd
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
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=43627248&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=ES2465218(T3) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Huawei Device Co Ltd filed Critical Huawei Device Co Ltd
Application granted granted Critical
Publication of ES2465218T3 publication Critical patent/ES2465218T3/es
Publication of ES2465218T5 publication Critical patent/ES2465218T5/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • 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
    • 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
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/146—Markers for unambiguous identification of a particular session, e.g. session cookie or URL-encoding
    • 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
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/08—Upper layer protocols
    • H04W80/10—Upper layer protocols adapted for application session management, e.g. SIP [Session Initiation Protocol]

Abstract

Un método de transferencia multisesión, en el que: después de completar la transferencia de una primera sesión de un terminal desde un dominio de la red de origen a un dominio de la red de destino, el método comprende: recibir (B1), por parte de un servidor de Centro de Conmutación Móvil, MSC, que proporciona servicio al terminal en el dominio de la red de destino, información de estado de una segunda sesión del terminal desde un Servidor de Acceso, AS, de Centralización y Continuidad de servicios, SCC, en donde la segunda sesión debe ser transferida, la información de estado comprende un tipo de medio de la segunda sesión que se pretende transferir, y los tipos de medios comprenden el vídeo; y enviar (B2) al SCC AS, por parte del servidor MSC, una petición para transferir la voz de la segunda sesión que se pretende transferir si el servidor MSC determina que el dominio de la red de destino no es capaz de transmitir datos de vídeo, como consecuencia de lo cual el SCC AS convierte la segunda sesión que se pretende transferir en una sesión de voz para su transferencia.

Description

Método para transferir múltiples sesiones, dispositivo de control de llamadas y servidor de continuidad de servicio
Campo de la invención
La presente invención está relacionada con el campo de las tecnologías de comunicación y, en particular, un método de transferencia multisesión, un dispositivo de control de llamadas y un Servidor de Aplicación de Continuidad de Servicio.
Antecedentes de la invención
La Continuidad de Sesión (SC) del Subsistema Multimedia IP (IMS) es una tecnología para evitar la interrupción de una sesión IMS en curso cuando un Equipo de Usuario (UE) del IMS se desplaza entre diferentes redes de acceso y para asegurar una experiencia de usuario favorable. La esencia de la SC es un Servidor de Aplicación de Continuidad y Centralización de Servicios (SCC AS), el cual controla la transferencia de sesión de un UE entre múltiples redes.
Un UE del Servicio Centralizado IMS (ICS) es un UE del IMS con capacidades de ICS mejoradas. Las capacidades de ICS se refieren, en general, al soporte de una interfaz Gm o una interfaz I1; y un UE no ICS se refiere a un UE que no soporta ni la interfaz Gm ni la interfaz I1, o se refiere a un UE que soporta la interfaz Gm o la interfaz I1 pero no utiliza dichas interfaces para transferir señalización en el proceso de comunicación.
Cuando un UE no ICS transfiere una sesión de voz normal desde un dominio de Conmutación de Paquetes (PS) a un dominio de Conmutación de Circuitos (CS), el UE no ICS envía como petición de transferencia una señalización del dominio CS (por ejemplo, un mensaje de configuración) en el dominio CS, donde la petición incluye un Número de Transferencia de Sesión (STN) como número llamado; después de recibir la petición, el SCC AS identifica la petición como una petición de transferencia de acuerdo con el valor del STN, y correlaciona la sesión en el dominio PS asociada, actualiza al otro extremo, y para terminar el proceso de transferencia libera la sesión correspondiente en el dominio PS.
La transferencia multisesión del UE no ICS desde el dominio PS al dominio CS soporta únicamente transferencia de dos sesiones. Antes de enviar una petición de transferencia, el UE libera otras sesiones que no sean las dos sesiones a transferir. Si el UE no consigue liberar las otras sesiones, el SCC AS tiene que correlacionar la petición de transferencia con las sesiones a transferir después de recibir la petición de transferencia. Si en ese momento existen más de dos sesiones, el SCC AS también puede iniciar la liberación de las sesiones. La solución detallada es: primero se transfiere la sesión activa (si no existe ninguna sesión activa, únicamente es necesario transferir la última sesión mantenida); después de completar la transferencia, el SCC AS envía a un servidor de Centro de Conmutación Móvil (MSC) información sobre una sesión activa la cual se activa antes de la última sesión activada, o información sobre la última sesión mantenida, y el servidor MSC inicia la transferencia de una segunda sesión en lugar del UE.
El documento “Transfer for media modifications (transferencia para modificaciones de medios), S2-090934-23838030”, XP050333376, divulga una transferencia de acceso de medios de una sesión IMS desde PS a CS para transferencias de acceso dentro de las redes de acceso 3GPP. El SCC AS proporciona mecanismos basados en IMS para habilitar la continuidad del servicio de la sesión multimedia. El SCC AS analiza la información necesaria para la transferencia de acceso tal como se describe en la sección de procedimiento y decide qué escenario de transferencia de acceso se debería ejecutar, y correlaciona la petición de transferencia de acceso con la sesión de referencia, utilizando la información proporcionada en el mensaje SIP INVITE (invitación SIP) entrante, ejecuta la transferencia de la sesión IMS entre diferentes redes de acceso.
El documento US 2008049725 divulga un servicio multimedia CS con cambio y recuperación de servicios. El cambio de servicios dentro de SCUDIF se refiere a la capacidad de un usuario de cambiar desde, por ejemplo, una video llamada, o más en general una llamada multimedia que incluya contenido enriquecido como, por ejemplo, contenido visual o acústico que no sea voz, a una llamada de voz y viceversa durante una llamada en curso. Sin embargo, dicho cambio de servicio no funciona con la Parte de Usuario, ISUP, de la red digital de servicios integrados, RDSI, o con sistemas de señalización menos desarrollados. Además, un problema con SCUDIF es que necesita el soporte BICC en toda la red troncal.
El documento “Digital celular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); LTE; IP Multimedia System (IMS) centralized services; Stage 2 (Sistema de telecomunicaciones móviles digitales (Fase 2+); Sistema de Telecomunicaciones Móviles Universal (UMTS); LTE; servicios centralizados del Sistema Multimedia IP (IMS); Etapa 2)” XP01404453 divulga una transferencia de acceso PS-CS de múltiples sesiones multimedia que tiene posibles configuraciones en las que se soportan capacidades ICS así como configuraciones en las que no se soportan capacidades ICS. Cuando se utiliza un UE que no tiene capacidades ICS,
o que no es capaz de utilizarlas, se debe proporcionar la transferencia de acceso desde una sesión activa y cero o
más sesiones inactivas de solo voz cuando se transfiere la portadora de voz entre un acceso CS y uno PS.
En el proceso de investigación y uso de la técnica anterior, el inventor de la presente invención encuentra que: cuando el UE se desplaza desde una red PS a una red CS y el UE incluye múltiples sesiones, si la segunda sesión que se transfiere es una sesión multimedia, la técnica anterior no tiene en cuenta la anomalía de que la segunda sesión puede no ser trasferible debido a que la Red de Acceso Radio (RAN) del UE no soporta la transmisión del vídeo o que los recursos de red actuales no son suficientes para soportar la transmisión del vídeo.
Resumen de la invención
Los modos de realización de la presente invención proporcionan un método de transferencia multisesión, un dispositivo de control de llamadas, y un SCC AS para superar el problema de que la red actual no soporta el procesamiento del vídeo en un proceso de transferencia multisesión.
En un modo de realización de la presente invención se proporciona un método de transferencia multisesión. Después de terminar la transferencia de una primera sesión de un terminal desde un dominio de la red de origen a un dominio de la red de destino, el método incluye:
recibir, por parte de un servidor MSC que da servicio al terminal en el dominio de la red de destino, información de estado de una segunda sesión del terminal desde un SCC AS, donde la segunda sesión necesita ser transferida, la información de estado incluye un tipo de medio de la segunda sesión que se pretende transferir, y los tipos de medios incluyen el vídeo; y
enviar al SCC AS, por parte del servidor MSC, una petición para transferir la voz de la segunda sesión que se pretende transferir si el servidor MSC determina que el dominio de la red de destino no es capaz de transmitir datos de vídeo, como consecuencia de lo cual el SCC AS convierte la segunda sesión que se pretende transferir en una sesión de voz para su transferencia.
Un dispositivo de control de llamadas proporcionado en un modo de realización de la presente invención incluye:
una unidad de recepción, configurada para recibir desde un SCC AS información de estado de una segunda sesión del UE, donde la segunda sesión necesita ser transferida, la información de estado incluye el tipo de medio de la segunda sesión que se pretende transferir, y los tipos de medios incluyen el vídeo; y
una unidad de control de transferencia de sesión, configurada para: comprobar si un dominio de la red de destino de la transferencia de sesión es capaz de transmitir datos de vídeo; si el dominio de la red de destino de la transferencia de sesión no es capaz de transmitir datos de vídeo, enviar al SCC AS una petición para transferir la voz de la segunda sesión que se pretende transferir, como consecuencia de lo cual el SCC AS convierte la segunda sesión que se pretende transferir en una sesión de voz para su transferencia.
Un SCC AS proporcionado en un modo de realización de la presente invención incluye:
una unidad de envío, configurada para enviar a un servidor MSC que da servicio al terminal la información de estado de una segunda sesión del UE, donde la segunda sesión necesita ser transferida, la información de estado incluye un tipo de medio de la segunda sesión que se pretende transferir, y los tipos de medios incluyen el vídeo; y
una unidad de procesamiento de sesiones, configurada para recibir desde el servidor MSC una petición para transferir la voz de una segunda sesión que se pretende transferir, y convertir la segunda sesión en una sesión de voz para su transferencia.
En los modos de realización de la presente invención, en un proceso de transferencia multisesión entre redes, si la segunda sesión que se pretende transferir incluye vídeo, el servidor MSC comprueba las capacidades de la red actual. Si la red actual no es capaz de transmitir vídeo, el servidor MSC envía una petición para transferir la voz de la segunda sesión que se pretende transferir. El SCC AS recibe la petición de transferencia, y convierte la segunda sesión que se pretende transferir en una sesión de voz para su transferencia o libera la segunda sesión que se pretende transferir y, de este modo, se evita el problema de la técnica anterior de la incapacidad de transferir la sesión, y se mejora la transferencia de servicios multisesión entre redes.
Breve descripción de los dibujos
La FIG. 1 es un diagrama de flujo de un método de transferencia multisesión de acuerdo con el Modo de realización 1 de la presente invención;
la FIG. 2 es un diagrama de flujo de un método de transferencia multisesión de acuerdo con el Modo de realización 2 de la presente invención;
la FIG. 3 es un diagrama de flujo de la conversión de una segunda sesión que se pretende transferir en una sesión
de voz para su transferencia de acuerdo con un modo de realización de la presente invención;
la FIG. 4 es un diagrama de flujo de la señalización de un primer ejemplo de aplicación de acuerdo con un modo de realización de la presente invención;
la FIG. 5 es un diagrama de flujo de la señalización de un segundo ejemplo de aplicación de acuerdo con un modo de realización de la presente invención;
la FIG. 6 es un diagrama de flujo de la señalización de un tercer ejemplo de aplicación de acuerdo con un modo de realización de la presente invención;
la FIG. 7 es un diagrama esquemático de la estructura de un dispositivo de control de llamadas de acuerdo con el Modo de realización 3 de la presente invención;
la FIG. 8 es un diagrama esquemático de la estructura de un dispositivo de control de llamadas de acuerdo con el Modo de realización 4 de la presente invención;
la FIG. 9 es un diagrama esquemático de la estructura de un SCC AS de acuerdo con el Modo de realización 5 de la presente invención; y
la FIG. 10 es un diagrama esquemático de la estructura de un SCC AS de acuerdo con el Modo de realización 6 de la presente invención.
Descripción detallada de los modos de realización
Se proporciona a continuación la descripción detallada junto con los dibujos adjuntos para proporcionar una comprensión completa de la presente invención. Evidentemente, los dibujos y la descripción detallada representan únicamente modos de realización particulares de la presente invención en lugar de todos los modos de realización. Todos los demás modos de realización, los cuales se pueden derivar por parte de aquellos experimentados en la técnica a partir de los modos de realización proporcionados en la presente solicitud sin ningún esfuerzo creativo, se encontrarán dentro del alcance de la presente invención.
Se divulgan un método de transferencia multisesión, un dispositivo de control de llamadas y un SCC AS tal como se detalla más abajo.
Modo de realización 1
En este modo de realización se proporciona un método de transferencia multisesión. Tal como se muestra en la FIG. 1, después de completar la transferencia de una primera sesión de un terminal desde un dominio de la red de origen a un dominio de la red de destino, el método incluye:
B1. Un servidor MSC que da servicio al terminal en el dominio de la red de destino recibe desde un SCC AS información de estado de una segunda sesión del terminal, donde es necesario transferir la segunda sesión, la información de estado incluye un tipo de medio de la segunda sesión que se pretende transferir y los tipos de medios incluyen el vídeo.
En este modo de realización, el terminal es un UE no ICS o un UE de funciones parecidas, el dominio de la red de origen es un dominio de la red PS, y el dominio de la red de destino es un dominio CS.
B2. El servidor MSC envía al SCC AS una petición para transferir la voz de la segunda sesión que se pretende transferir si el servidor MSC determina que el dominio de la red de destino no es capaz de transmitir datos de vídeo, como consecuencia de lo cual el SCC AS convierte la segunda sesión que se pretende transferir en una sesión de voz para su transferencia o libera la segunda sesión que se pretende transferir después de recibir la petición.
En este modo de realización, después de que el SCC AS libere la segunda sesión que se pretende transferir, el método puede incluir, además, el siguiente paso:
El servidor MSC recibe un mensaje de respuesta de fallo enviado por el SCC AS como respuesta a la petición de transferencia, y elimina la información de estado de la sesión de la segunda sesión que se pretende transferir.
La red de destino puede ser incapaz de transmitir datos de vídeo por muchas razones. Por ejemplo, porque la transferencia de datos de vídeo no sea soportada por la red de acceso o por el ancho de banda de la red, o porque los recursos de la red no sean suficientes (el servicio de vídeo hace uso de más recursos que el servicio de voz).
En este modo de realización, la petición para transferir la voz de la segunda sesión al SCC AS se puede enviar del siguiente modo:
Específicamente, un dispositivo de la red troncal envía al SCC AS únicamente una petición de transferencia de voz 4
de la sesión, esto es asigna el valor 0 al número de puerto de transmisión del vídeo en la información de la fila de medios en la petición, y solicita únicamente la transferencia de la voz. De este modo, después de recibir la petición, el SCC AS convierte la segunda sesión que se pretende transferir en una sesión de voz para su transferencia, o libera la segunda sesión que se pretende transferir. El servidor MSC puede solicitar al SCC AS que convierta la sesión de vídeo en una sesión de voz de muchos modos, y el modo de conversión no se debe entender como una limitación de la presente invención.
En el Modo de realización 1, en un proceso de transferencia multisesión entre redes, si la segunda sesión que se pretende transferir incluye vídeo, el servidor MSC comprueba las capacidades de la red actual. Si la red actual es incapaz de transmitir vídeo, el servidor MSC envía una petición para transferir la voz de la segunda sesión que se pretende transferir. El SCC AS recibe la petición de transferencia, y convierte la segunda sesión que se pretende transferir en una sesión de voz para su transferencia o libera la segunda sesión que se pretende transferir y, de este modo, se evita el problema de la técnica anterior de la incapacidad de transferir la sesión, y se mejora la transferencia de servicios multisesión entre redes.
Modo de realización 2
En este modo de realización se proporciona un método de transferencia multisesión. Tal como se muestra en la FIG. 2, después de completar la transferencia de una primera sesión de un terminal desde un dominio de la red de origen a un dominio de la red de destino, el método incluye los siguientes pasos:
C1. Un SCC AS envía información de estado de una segunda sesión del terminal a un servidor MSC que da servicio al terminal en el dominio de la red de destino, donde la segunda sesión tiene que ser transferida, la información de estado incluye un tipo de medio de la segunda sesión que se pretende transferir y los tipos de medios incluyen el vídeo.
C2. El SCC AS convierte la segunda sesión que se pretende transferir en una sesión de voz para su transferencia o libera la segunda sesión que se pretende transferir, si el SCC AS recibe una indicación enviada por el servidor MSC debido a que el dominio de la red de destino es incapaz de transmitir datos de vídeo, donde la indicación indica un fallo de transferencia de la segunda sesión que se pretende transferir.
En este modo de realización, el paso de la liberación de la segunda sesión que se pretende transferir incluye: liberar la segunda sesión que se pretende transferir en el dominio de la red de origen, e interactuar con el otro extremo de la comunicación del terminal para actualizar el extremo de acceso del otro extremo de la comunicación. La sesión se puede liberar de otros modos, y el modo de liberación no se debe entender como una limitación de la presente invención.
En el Modo de realización 2, cuando la red actual no soporta la sesión de vídeo, el SCC AS convierte la segunda sesión que se pretende transferir en una sesión de voz o libera la segunda sesión que se pretende transferir y, de este modo, se evita la incapacidad de transferir la sesión de la técnica anterior, y se mejora la transferencia de servicios multisesión entre redes.
En el Modo de realización 2, el SCC AS recibe la indicación de fallo de transferencia de la segunda sesión que se pretende transferir enviada por el servidor MSC como consecuencia de que el dominio de la red de destino es incapaz de transmitir datos de vídeo, lo cual se puede implementar de los siguientes modos:
Modo 1: el SCC AS recibe del servidor MSC una indicación de fallo de transferencia de la segunda sesión. La indicación incluye un parámetro de la causa de fallo de transferencia, y el parámetro de la causa de fallo de transferencia indica que el dominio de la red de destino es incapaz de transmitir datos de vídeo. La indicación de fallo de transferencia de la segunda sesión que se pretende transferir se puede incluir en el mensaje de petición de transferencia de información (mensaje INFO) basándose en un Protocolo de Inicio de Sesión (SIP), o se puede incluir en un mensaje instantáneo.
Modo 2: antes de que el SCC AS reciba la indicación del fallo de transferencia de la segunda sesión que se pretende transferir enviada por el servidor MSC como consecuencia de que el dominio de la red de destino es incapaz de transmitir datos de vídeo, el método incluye:
El SCC AS envía al servidor MSC un mensaje de petición Subscribe (Suscripción).
El SCC AS puede recibir la indicación de fallo de transferencia de la segunda sesión que se pretende transferir enviada por el servidor MSC como consecuencia de que el dominio de la red de destino es incapaz de transmitir datos de vídeo mediante:
la recepción de un mensaje Notify (Notificación) de la petición de suscripción devuelta por el dispositivo de la red troncal, donde el mensaje Notify incluye una indicación del fallo de la transferencia de la segunda sesión que se pretende transferir.
Tal como se muestra en la FIG. 3, el paso de la conversión de la segunda sesión que se pretende transferir en una sesión de voz para su transferencia en el Modo de realización 2 incluye los siguientes pasos:
D1. Liberar el vídeo de la sesión que se pretende transferir en el dominio de la red de origen;
D2. Notificarle al servidor MSC que vuelva a enviar una petición de transferencia de sesión del tipo voz para configurar un extremo de acceso de la segunda sesión que se pretende transferir en el dominio de la red de destino. Los detalles de la notificación al servidor MSC para que vuelva a enviar una petición de transferencia de sesión del tipo voz puede ser: devolver un mensaje INFO al servidor MSC, o devolver un OK 200 como respuesta al mensaje Notify, o devolver un Message (mensaje); y
D3. Interactuar con el otro extremo de la comunicación del terminal para actualizar el extremo de acceso del otro extremo de la comunicación.
El extremo de acceso del otro extremo de la comunicación se puede actualizar mediante el siguiente procedimiento:
El SCC AS asocia el extremo de la llamada de la segunda sesión que se pretende transferir en el dominio de la red de destino al extremo de la llamada del otro extremo de la comunicación.
Cuando los dos extremos de acceso se encuentran asociados, el SCC AS es equivalente a un Agente de Usuario en Cadena (B2BUA) para implementar la comunicación entre ambas partes.
El SCC AS interactúa con el otro extremo de la comunicación del terminal para convertir en audio el vídeo de la segunda sesión que se pretende transferir. Debido a que la segunda sesión entre el terminal y el otro extremo de la comunicación en la red de origen es una sesión de vídeo, el SCC AS tiene que llevar a cabo una negociación de medios con el otro extremo de la comunicación y actualizar la información del codificador/decodificador apropiado con el fin de convertir la sesión de vídeo a una sesión de voz. La negociación de medios se puede implementar mediante la información del Protocolo de Descripción de Sesión (SDP).
Después de completar una transferencia de sesión, la segunda sesión del terminal en la red de origen es redundante, y el SCC AS libera el extremo de la llamada del terminal en el dominio de la red de origen.
A continuación se proporcionan ejemplos de aplicación basados en el Modo de realización 1 y el Modo de realización 2 de la presente invención y la aplicación de protocolos de comunicación específicos. En los ejemplos de aplicación siguientes, el dominio de la red de origen es un dominio PS, y el dominio de la red de destino es un dominio CS.
Ejemplo de aplicación 1:
Después de recibir la información de estado de la sesión multimedia de la segunda sesión que se pretende transferir, el servidor MSC no es capaz de transferir la sesión multimedia por diversas razones. Por lo tanto, el servidor MSC envía una petición para transferir la voz. Las razones pueden ser: la RAN actual del UE no soporta la transmisión de vídeo, o los recursos de la red no son suficientes. La FIG. 4 es el diagrama de flujo:
F1-F4. Son iguales que los pasos A1-A4 de la FIG. 1 de la técnica anterior.
F5. El SCC AS comprueba si el servidor MSC que proporciona servicio al UE soporta vídeo. Si el servidor MSC soporta vídeo, el SCC AS envía información de estado de la sesión multimedia, donde la información de estado indica que los tipos de medios incluyen el vídeo.
Si el servidor MSC no soporta la transmisión de vídeo, en los pasos posteriores el SCC AS libera el vídeo de la sesión en el dominio PS de origen, y envía la información de estado de la sesión de voz. La información de estado de la sesión especifica el tipo de medio audio y asigna el valor 0 al número de puerto de la fila de medios del vídeo.
F6. El SCC AS añade la información de estado de sesión seleccionada a un mensaje OK 200, y envía el mensaje OK 200 a una Función de Control de Sesión de Llamada Servidora (S-CSCF) o una Función de Control de Sesión de Llamada Interrogadora (I-CSCF) como respuesta a la petición INVITE. La siguiente descripción toma la S-CSCF como un ejemplo, y el procesamiento con respecto a la I-CSCF es el mismo.
F7. La S-CSCF envía al servidor MSC un mensaje OK 200.
F8. El servidor MSC recibe la información de estado de la segunda sesión (una sesión multimedia), y comprueba si se soporta la transmisión de vídeo en función de la RAN actual del UE y los recursos disponibles.
F9a. Si la red actual soporta la transmisión de vídeo, el servidor MSC envía una petición para transferir la sesión multimedia de acuerdo con la técnica anterior, y a continuación se actualiza el otro extremo, y se transfiere la sesión.
F9b. Si la red actual no soporta la transmisión de vídeo, únicamente es necesario transmitir la voz de la sesión. El servidor MSC envía una petición para transferir una sesión de voz y, específicamente, asigna el valor 0 al número de puerto del vídeo en la información SDP en la petición Invite enviada.
F10. La S-CSCF transmite al SCC AS la petición Invite.
F11b-F12b. El SCC AS determina que la sesión correspondiente a la petición de transferencia es una sesión multimedia que incluye vídeo, y selecciona convertir la sesión multimedia en una sesión de voz y libera el vídeo en el dominio PS de origen. Específicamente, el SCC AS genera una petición re-INVITE de acuerdo con la información SDP almacenada, y asigna el valor 0 al número de puerto correspondiente a la fila de medios del vídeo en la información SDP. A través de la S-CSCF se transmite al UE local la petición para liberar el medio.
Alternativamente, en este modo de realización, después de recibir la petición Invite, el SCC AS detecta que la sesión correspondiente incluye vídeo y, de acuerdo con la política, rechaza convertir la sesión multimedia en una sesión de voz. Por lo tanto, el SCC AS devuelve una respuesta 4** (por ejemplo, prohibido 403), libera la sesión multimedia y, a continuación, actualiza al otro extremo antes de proceder con el paso F22. En este modo de realización, la política puede estar preconfigurada en el SCC AS. Después de recibir el mensaje 4**, el servidor MSC borra la información de estado de sesión de la sesión.
F13b-F14b. El UE borra el vídeo y envía un mensaje de respuesta OK 200 en la respuesta a la petición re-INVITE. El mensaje de respuesta OK 200 se transmite al SCC AS a través de la S-CSCF.
F15b-F16b. El SCC AS envía un mensaje de confirmación (ACK) como respuesta al mensaje de respuesta, y el mensaje ACK se transmite al UE a través de la S-CSCF.
F17b. El SCC AS actualiza al otro extremo utilizando la información SDP en la petición Invite enviada por el servidor MSC.
F18b-F19b. El SCC AS devuelve una respuesta OK 200 como respuesta a la petición Invite. La S-CSCF transmite al servidor MSC la respuesta OK 200.
F20b-F21b. El servidor MSC envía al SCC AS un mensaje ACK, el cual se transmite a través de la S-CSCF. De este modo, queda configurado en el dominio CS el extremo de la llamada (extremo de acceso) de la segunda sesión.
F22. El SCC AS libera la sesión del UE en el dominio PS de origen.
En este modo de realización, cuando el servidor MSC determina que el dominio CS no soporta la transmisión de vídeo, el servidor MSC inicia un proceso de transferencia de la voz de la sesión multimedia, lo cual provoca que el SCC AS libere el vídeo en el dominio de la red de origen. De este modo, cuando las condiciones de red no permiten la transferencia de la sesión multimedia, ésta se transfiere mediante la transmisión de la sesión de voz.
Ejemplo de aplicación 2:
Cuando el servidor MSC no es capaz de transferir una sesión de vídeo debido a la red CS, se puede enviar un mensaje INFO al SCC AS utilizando un canal de señalización establecido en una primera sesión. El mensaje INFO indica un fallo al transferir la segunda sesión y las causas del fallo. Después de recibir el mensaje INFO, el SCC AS libera el vídeo en el dominio PS, y envía otro mensaje INFO que ordena al servidor MSC transferir la voz. Tal como se muestra en la FIG. 5, el procedimiento incluye los siguientes pasos:
G1-G9a. Son los mismos pasos F1-F9a que en el ejemplo de aplicación 1.
G9b. Si la red actual no soporta la transmisión de vídeo, el servidor MSC envía un mensaje INFO. El mensaje INFO se transmite en el canal establecido en la primera sesión, e incluye una indicación del fallo de la transmisión de la segunda sesión. La indicación del fallo de transferencia se puede incluir en una cabecera del mensaje o en un cuerpo del mensaje, tal como se detalla a continuación:
(i)
La indicación se incluye en una cabecera del mensaje. Por ejemplo, una cabecera “subject (asunto)” de destino del mensaje INFO incluye la indicación del fallo de la transferencia. El cometido original de la cabecera “subject” es indicar una conversación. En este modo de realización, la cabecera “subject” se amplía para indicar un fallo de transferencia de la sesión e incluir la causa del fallo.
(ii)
La indicación se incluye en un cuerpo del mensaje: el cuerpo del mensaje del mensaje INFO incluye la indicación del fallo de transferencia y la causa del fallo. La causa del fallo es “Video_not_supported (vídeo no soportado)” o “lack_resource (falta de recursos)”. El cuerpo del mensaje se puede encontrar en un formato de Lenguaje de Etiquetas Extensible (XML), tal como se detalla más abajo:
<?xml version=”1.0”?>
<ati xmlns=”urn:3gpp:ns:imscont:ati”>
<aes i=”callIdOfSessionY” lt=”UEATag” rt=”SCCASTag” lUri=”tel:+1-237-555-1111” rUri=”sip:UE3@operator.net” s=”fail” cause=”Video_not_supported/lack_resource”/>
</ati>
En los atributos que aparecen más arriba, “aes” es la información sobre la segunda sesión; “i” es el identificador de llamada (Call-Id) de la segunda sesión en el dominio PS; “lt” es una etiqueta del UE local (que se corresponde con el servidor MSC); “rt” es una etiqueta del UE otro extremo; “lUri" es un identificador del UE local; “rUri” es un identificador del UE otro extremo; “s” indica que los estados de transferencia opcionales son “success (éxito)”, “fail (fallo)”, y “retry (reintentar)”; si el estado de transferencia es “fail”, “cause (causa)” se refiere a la causa del fallo, y las causas posibles incluyen “Video_not_supported” y “lack_resource”.
A la cabecera de aceptación y a la cabecera Content-Type (tipo de contenido) del mensaje INFO se les asigna el “application/vnd.3gpp.ati+xml”.
G10b-G11b. El mensaje INFO se transmite al SCC AS a través de la S-CSCF.
G12b-G13b. El SCC AS recibe el mensaje INFO y devuelve una respuesta OK 200. La respuesta OK 200 se transmite al servidor MSC a través de la S-CSCF.
G14b. El SCC AS analiza el campo “s” y el campo “cause” en el cuerpo del mensaje del mensaje INFO, y detecta que la transferencia de la sesión multimedia ha fallado por las razones anteriores. En consecuencia, el SCC AS convierte la sesión multimedia en una sesión de voz para su transferencia, libera el vídeo de la sesión multimedia y actualiza al otro extremo. El procedimiento de liberación es el mismo que los pasos F11b-F15b en el ejemplo de aplicación 1. Alternativamente, el SCC AS libera la sesión en lugar de transferirla. Si el SCC AS libera la sesión, el SCC AS lleva a cabo el paso G20b directamente. Si el servidor MSC no recibe un mensaje INFO dentro de cierto período, el servidor MSC no envía una petición de transferencia, sino que borra la información de estado de la segunda sesión que se pretende transferir.
Si el vídeo se libera de forma satisfactoria, el SCC AS genera un mensaje INFO indicando que el vídeo se ha liberado de forma satisfactoria y que el servidor MSC tiene que volver a enviar una petición para transferir la voz de la sesión. Específicamente, en un cuerpo del mensaje XML o en una cabecera “subject” del mensaje del mensaje INFO se incluye una indicación para volver a enviar la petición de transferencia. Si la indicación se incluye en la cabecera “subject” del mensaje, en la cabecera del mensaje se escribe “transfer_voice (transferir voz)”; si la indicación se incluye en el cuerpo del mensaje, el cuerpo del mensaje es como sigue:
<?xml version=”1.0”?>
<ati xmlns=”urn:3gpp:ns:imscont:ati”>
<aes i=”callIdOfSessionY” lt=”UEATag” rt=”SCCASTag” lUri=”tel:+1-237-555-1111” rUri=”sip:UE3@operator.net” s=”retry” cause=”transfer_voice”/>
</ati>
G15b-G16b. El mensaje INFO se transmite al servidor MSC a través de la S-CSCF.
G17b-G18b. El servidor MSC recibe el mensaje INFO y devuelve una respuesta OK 200. La respuesta OK 200 se transmite al SCC AS a través de la S-CSCF.
G19b. El servidor MSC recibe el mensaje INFO, analiza el campo “s” y el campo “cause”, y vuelve a enviar una petición Invite para transferir la sesión de acuerdo con la información de la sesión.
G20b. El SCC AS recibe la petición de transferencia desde el servidor MSC en el dominio CS, y actualiza al otro extremo.
G21. El SCC AS libera la sesión del UE en el dominio PS de origen.
En este modo de realización, el modo equivalente de un mensaje SIP puede reemplazar al mensaje INFO para llevar a cabo las operaciones anteriores. El procedimiento de operación es el mismo. Si el SCC AS no libera el vídeo de forma satisfactoria, no es necesario enviar un mensaje INFO al servidor MSC, y la segunda sesión se libera en la red PS de origen. Si el servidor MSC no recibe un mensaje INFO dentro de cierto período de tiempo, el servidor MSC no envía una petición de transferencia, sino que borra la información de estado de la segunda sesión que se pretende transferir.
En este modo de realización, se utiliza un mensaje INFO de SIP (o un modo equivalente de un mensaje instantáneo) para indicar el fallo de la transferencia. De este modo, cuando la red no soporta la transmisión de vídeo o los recursos de red no son suficientes, el SCC AS convierte la sesión multimedia en una sesión de voz, y se lo notifica al servidor MSC a través de un mensaje INFO o de un mensaje instantáneo; y el servidor MSC vuelve a enviar una petición para transferir la sesión de voz. El mensaje INFO y el mensaje instantáneo del modo equivalente se transmiten en el canal de la primera sesión existente. Se asume que la primera sesión no se libera mientras el servidor MSC comprueba las condiciones de la red e intercambia información con el SCC AS.
Ejemplo de aplicación 3:
En este ejemplo de aplicación, el servidor MSC se suscribe al estado de transferencia de la segunda sesión, y comprueba si la sesión se ha transferido con éxito. Si la transferencia falla debido a que la red de destino no es capaz de transmitir vídeo, el SCC AS libera el vídeo y se lo notifica al servidor MSC para que inicie la transferencia de la voz de la segunda sesión que se pretende transferir. Debido a que la petición de suscripción es independiente de la sesión, la suscripción se puede realizar en el canal de la primera sesión que ya existe, o en un nuevo canal de sesión. Tal como se muestra en la FIG. 6, el procedimiento incluye los siguientes pasos:
H1-H7. Son los mismos que los pasos F1-F7 en el ejemplo de aplicación 1.
H8. El SCC AS envía una petición Subscribe (Suscribir) para suscribirse a los eventos relacionados con el UE. El request-URI (URI de petición) es el identificador del UE. Una cabecera “event (evento)” o un cuerpo de mensaje de la petición Subscribe indica el evento de suscripción. El evento de suscripción aquí indica si se ha transferido con éxito la segunda sesión que se pretende transferir. A la cabecera “event” se le asigna el valor “second transfer (segunda transferencia)”.
La cabecera “accept (aceptar)” de la petición indica el formato del cuerpo del mensaje del mensaje Notify. El formato aquí es XML, por ejemplo, “application/vnd.3gpp.ati+xml”. El SCC AS puede enviar la petición Subscribe únicamente cuando la segunda sesión que se pretende transferir es una sesión multimedia. Aquí se omite el mensaje de respuesta devuelto después de que la suscripción se haya realizado con éxito.
H9. La petición Subscribe se transmite al servidor MSC a través de la S-CSCF.
H10. El servidor MSC recibe la información de estado de la segunda sesión (sesión multimedia) que se pretende transferir, y comprueba si se soporta una transmisión de vídeo en función de las condiciones de la red actual del UE.
H11a. Si la red actual (condiciones de la red o recursos de la red) soporta la transmisión de vídeo, el servidor MSC envía una petición para transferir la sesión multimedia de acuerdo con la técnica anterior.
H12a. La segunda sesión (sesión multimedia) que se pretende transferir se transfiere con éxito, el servidor MSC envía un mensaje Notify al SCC AS. El contenido del mensaje Notify se incorpora en el cuerpo del mensaje con formato XML del Notify. El formato específico del cuerpo del mensaje es “application/vnd.3gpp.ati+xml”. Ver también el ejemplo de aplicación 2. En los atributos, a “s” se le asigna el valor “success (éxito)”; y a “Cause” se le asigna el valor null (nulo).
H13a. El mensaje Notify se transmite al SCC AS a través de la S-CSCF.
H14a. Se configura con éxito un extremo de acceso entre el servidor MSC y el SCC AS en el dominio CS, y el SCC AS actualiza al otro extremo.
H11b. El servidor MSC determina que la red actual es incapaz de transmitir vídeo, y genera un mensaje Notify que indica un fallo de transferencia utilizando el formato “application/vnd.3gpp.ati+xml”. En los atributos del mensaje, a “s” se le asigna el valor “fail (fallo)”; y la causa del fallo de transferencia de la segunda sesión se indica en “cause”, donde la causa es “Video_not_supported” o “lack_resource”. Los significados de los atributos se describen más arriba en el ejemplo de aplicación 2.
<?xml version=”1.0”?>
<ati xmlns=”urn:3gpp:ns:imscont:ati”>
<aes i=”callIdOfSessionY” lt=”UEATag” rt=”SCCASTag” lUri=”tel:+1-237-555-1111” rUri=”sip:UE3@operator.net” s=”fail” cause=”Video_not_supported/lack_resource”/>
</ati>
El cuerpo del mensaje del formato “application/vnd.3gpp.ati+xml” incluye, además, la información asociada a la sesión que se pretende transferir. Aquí, el mensaje Notify de respuesta puede incluir dicha información de sesión (incluyendo los elementos excepto el atributo “s” y el atributo “cause”) de modo que el SCC AS puede realizar la
comprobación y llevar a cabo la operación de liberación. Alternativamente, el mensaje Notify incluye únicamente el atributo “s” y el atributo “cause” en lugar de la información de la sesión, y el SCC AS detecta el evento de suscripción y recibe la información de la sesión de la segunda sesión que se pretende transferir de acuerdo con la información almacenada de la sesión.
H12b. El mensaje Notify se transmite a la S-CSCF.
H13b. El mensaje Notify se transmite al SCC AS a través de la S-CSCF.
H14b. El SCC AS recibe el mensaje Notify, y analiza el campo “s” y el campo “cause” del mensaje, y detecta que la transferencia de la sesión multimedia ha fallado por las razones anteriores. En consecuencia, el SCC AS convierte la sesión multimedia en una sesión de voz para su transferencia, libera el vídeo de la sesión multimedia en el domino PS de acuerdo con los pasos F11b-F15b del ejemplo de aplicación 1, y actualiza al otro extremo. Alternativamente, el SCC AS libera la sesión en lugar de transferirla. Si el SCC AS libera la sesión, el SCC AS devuelve un mensaje OK 200 como respuesta al mensaje Notify, y actualiza al otro extremo antes de llevar a cabo el paso H21. Si el servidor MSC no recibe una indicación para volver a enviar una petición dentro de cierto período de tiempo, el servidor MSC no envía más peticiones de transferencia, sino que borra la información de estado de la segunda sesión que se pretende transferir.
H15b. El SCC AS envía un mensaje de respuesta OK 200 como respuesta al mensaje Notify. Si el SCC AS libera el vídeo con éxito, el cuerpo del mensaje de la respuesta OK 200 ordena al servidor MSC que vuelva a enviar una petición para transferir la voz de la sesión. El cuerpo del mensaje es el mismo que el del ejemplo de aplicación 2:
<?xml version=”1.0”?>
<ati xmlns=”urn:3gpp:ns:imscont:ati”>
<aes i=”callIdOfSessionY” lt=”UEATag” rt=”SCCASTag” lUri=”tel:+1-237-555-1111” rUri=”sip:UE3@operator.net” s=”retry” cause=”transfer_voice”/>
</ati>
Si el SCC AS falla al liberar el vídeo, el SCC AS intenta liberar la segunda sesión sin enviar ninguna indicación al servidor MSC. Si el servidor MSC no recibe ninguna indicación para volver a enviar una petición dentro de cierto período de tiempo, el servidor MSC no envía más peticiones de transferencia, sino que borra la información de estado de la segunda sesión que se pretende transferir.
H16b. La respuesta OK 200 se transmite al servidor MSC a través de la S-CSCF.
H17b. El servidor MSC recibe la respuesta, y analiza el cuerpo del mensaje de la respuesta para conocer la necesidad de enviar una petición para transferir la voz.
H18b-H19b. Si el servidor MSC transfiere la voz con éxito, el servidor MSC envía un mensaje Notify al SCC AS. El contenido del mensaje se describe en el paso H12a.
H20b. El otro extremo es actualizado, y se configura la conexión de la sesión entre el UE y el otro extremo de la comunicación.
H21. Se libera la sesión de la red PS de origen.
Después de cierto tiempo, el SCC AS puede cancelar la relación de suscripción con el servidor MSC.
En este modo de realización, el SCC AS se suscribe al estado de transferencia de la segunda sesión, y recibe el mensaje Notify desde el servidor MSC. Si la red no es capaz de transferir la sesión multimedia, el SCC AS recibe la orden de liberar el vídeo y convertir la sesión multimedia en una sesión de voz para su transferencia, y el servidor MSC transfiere la voz de la sesión o el SCC AS libera la segunda sesión que se pretende transferir en lugar de llevar a cabo la transferencia.
Las personas con un conocimiento normal en la técnica deben entender que todos o parte de los pasos del método en los modos de realización de la presente invención se pueden implementar mediante un programa que controle el hardware apropiado. El programa se puede almacenar en un medio de almacenamiento legible por un ordenador. El medio de almacenamiento puede ser una Memoria de Solo Lectura (ROM), una Memoria de Acceso Aleatorio (RAM), un disco magnético, o un CD-ROM.
Modo de realización 3
Tal como se muestra en al FIG. 7, un dispositivo de control de llamadas incluye:
una unidad 810 de recepción, configurada para recibir desde un SCC AS información de estado de una segunda sesión de un terminal, donde es necesario transferir la segunda sesión, y la información de estado indica que el tipo de medios de la segunda sesión que se pretende transferir es vídeo; y
una unidad 820 de control de transferencia de sesión, configurada para: comprobar si un dominio de la red de destino de la transferencia de sesión es capaz de transmitir datos de vídeo; si el dominio de la red de destino de la transferencia de sesión no es capaz de transmitir vídeo, enviar al SCC AS una petición para transferir la voz de la segunda sesión que se pretende transferir, como consecuencia de lo cual el SCC AS convierte la segunda sesión que se pretende transferir en una sesión de voz para su transferencia o libera la segunda sesión que se pretende transferir después de recibir la petición.
Mediante el dispositivo de control de llamadas de este modo de realización, en el momento de transferir la segunda sesión del UE que se pretende transferir, si se comprueba que el dominio de la red de destino no es capaz de transmitir datos de vídeo, se envía directamente al SCC AS una petición para transferir la voz de la segunda sesión que se pretende transferir, por ejemplo, se le asigna el valor 0 al número de puerto de transmisión del vídeo en la información de la fila de medios de la petición, y únicamente es necesario transferir la voz. Después de recibir la petición, el SCC AS convierte la segunda sesión que se pretende transferir en una sesión de voz para su transferencia o libera la segunda sesión que se pretende transferir. De este modo, se evita el fallo en la transferencia de la sesión de la técnica anterior, y se mejora el servicio de transferencia multisesión entre redes.
Modo de realización 4
Tal como se muestra en la FIG. 8, un dispositivo de control de llamadas incluye:
una unidad 910 de recepción, configurada para recibir desde un SCC AS información de estado de una segunda sesión de un terminal, donde es necesario transferir la segunda sesión, la información de estado incluye un tipo de medios de la segunda sesión que se pretende transferir, y los tipos de medios incluye vídeo; y
una unidad 920 de control de transferencia de sesión, configurada para: comprobar si un dominio de la red de destino de la transferencia de sesión es capaz de transmitir datos de vídeo; si el dominio de la red de destino de la transferencia de sesión no es capaz de transmitir datos de vídeo, enviar al SCC AS una indicación de fallo en la transferencia de la segunda sesión que se pretende transferir, como consecuencia de lo cual el SCC AS convierte la segunda sesión que se pretende transferir en una sesión de voz para su transferencia o libera la segunda sesión que se pretende transferir después de recibir la indicación.
Mediante el dispositivo de control de llamadas de este modo de realización, en el momento de transferir la segunda sesión del UE que se pretende transferir, si se comprueba que el dominio de la red de destino no es capaz de transmitir datos de vídeo, se envía al SCC AS una indicación de fallo en la transferencia de la segunda sesión que se pretende transferir, de modo que el SCC AS lleva a cabo las operaciones posteriores después de recibir la indicación del fallo. De este modo, se evita el fallo en la transferencia de la sesión de la técnica anterior, y se mejora el servicio de transferencia multisesión entre redes.
Los dispositivos de control de llamadas del tercer modo de realización y del cuarto modo de realización pueden ser entidades de red capaces de controlar llamadas en la red CS, por ejemplo, un servidor MSC o un dispositivo similar.
Modo de realización 5
Tal como se muestra en la FIG. 9, un SCC AS incluye:
una unidad 1010 de envío, configurada para enviar información de estado de una segunda sesión de un terminal a un servidor MSC que da servicio al terminal, donde es necesario transferir la segunda sesión, la información de estado incluye un tipo de medios de la segunda sesión que se pretende transferir, y los tipos de medios incluyen el vídeo; y
una unidad 1020 de procesamiento de sesión, configurada para recibir desde el servidor MSC una petición para transferir voz de la segunda sesión que se pretende transferir, y convertir la segunda sesión que se pretende transferir en una sesión de voz para su transferencia o liberar la segunda sesión que se pretende transferir. Para los métodos de funcionamiento del dispositivo de control de llamadas y del SCC AS, ver los modos de realización de los métodos descritos más arriba.
Modo de realización 6
Tal como se muestra en la FIG. 10, un SCC AS incluye:
una unidad 1110 de envío, configurada para enviar información de estado de una segunda sesión de un terminal a un servidor MSC que proporciona servicio al UE, donde es necesario transferir la segunda sesión, y la información de estado indica que el tipo de medio de la segunda sesión que se pretende transferir es vídeo; y
una unidad 1120 de procesamiento de sesión, configurada para: recibir una indicación enviada por el servidor MSC como consecuencia de que el dominio de la red de destino no es capaz de transmitir datos de vídeo, donde la indicación indica un fallo de transferencia de la segunda sesión que se pretende transferir; y convertir la segunda sesión que se pretende transferir en una sesión de voz para su transferencia, o liberar la segunda sesión que se
5 pretende transferir.
Más arriba se han divulgado un método de transferencia multisesión, un dispositivo de control de llamadas y un SCC AS. El principio e implementación de la presente invención se describen en la presente solicitud mediante ejemplos específicos. La descripción sobre los modos de realización de la presente invención se proporciona únicamente para facilitar la comprensión del método y las ideas centrales de la presente invención. Las personas con un conocimiento
10 normal de la técnica pueden realizar variaciones y modificaciones a la presente invención en cuanto a lo específico.

Claims (8)

  1. REIVINDICACIONES
    1. Un método de transferencia multisesión, en el que: después de completar la transferencia de una primera sesión de un terminal desde un dominio de la red de origen a un dominio de la red de destino, el método comprende:
    recibir (B1), por parte de un servidor de Centro de Conmutación Móvil, MSC, que proporciona servicio al terminal en el dominio de la red de destino, información de estado de una segunda sesión del terminal desde un Servidor de Acceso, AS, de Centralización y Continuidad de servicios, SCC, en donde la segunda sesión debe ser transferida, la información de estado comprende un tipo de medio de la segunda sesión que se pretende transferir, y los tipos de medios comprenden el vídeo; y
    enviar (B2) al SCC AS, por parte del servidor MSC, una petición para transferir la voz de la segunda sesión que se pretende transferir si el servidor MSC determina que el dominio de la red de destino no es capaz de transmitir datos de vídeo, como consecuencia de lo cual el SCC AS convierte la segunda sesión que se pretende transferir en una sesión de voz para su transferencia.
  2. 2. El método de acuerdo con la reivindicación 1, en el que:
    el dominio de la red de origen es un dominio de Conmutación de Paquetes, PS, y el dominio de la red de destino es un dominio de Conmutación de Circuitos, CS.
  3. 3.
    El método de acuerdo con la reivindicación 1 o la reivindicación 2, en el que: después de que el SCC AS haya liberado la segunda sesión que se pretende transferir, el método comprende:
    recibir, por parte del servidor MSC, un mensaje de respuesta de fallo enviado por el SCC AS como respuesta a la petición de transferencia, y borrar la información de estado de la sesión de la segunda sesión que se pretende transferir.
  4. 4.
    El método de acuerdo con una cualquiera de las reivindicaciones 1-3, en el que el envío al SCC AS, por parte del servidor MSC, de una petición para transferir la voz de la segunda sesión que se pretende transferir comprende, además: asignar el valor 0 a un número de puerto de transmisión del vídeo en una información de la fila de medios en la petición, y solicitar únicamente la transferencia de la voz.
  5. 5. Un dispositivo de control de llamadas, que comprende:
    una unidad (810) de recepción, configurada para recibir información de estado de una segunda sesión de un terminal desde un Servidor de Acceso, AS, de Centralización y Continuidad de Servicios, SCC, en donde la segunda sesión debe ser transferida, la información de estado comprende un tipo de medio de la segunda sesión que se pretende transferir, y los tipos de medios comprenden el vídeo; y
    una unidad (820) de control de transferencia de sesión, configurada para: comprobar si un dominio de la red de destino de la transferencia de sesión es capaz de transmitir datos de vídeo; si el dominio de la red de destino de transferencia de la sesión no es capaz de transmitir datos de vídeo, enviar al SCC AS una petición para transferir la voz de la segunda sesión que se pretende transferir, como consecuencia de lo cual el SCC AS convierte la segunda sesión que se pretende transferir en una sesión de voz para su transferencia.
  6. 6. El dispositivo de control de llamadas de acuerdo con la reivindicación 5, en el que la unidad de control de transferencia de sesión envía al SCC AS una petición para transferir la voz de la segunda sesión que se pretende transferir configurada además para asignar el valor 0 a un número de puerto de transmisión del vídeo en una información de fila de medios en la petición, y solicitar únicamente la transferencia de la voz.
  7. 7. Un Servidor de Aplicación de Continuidad y Continuidad del Servicio, que comprende:
    una unidad (1010) de envío, configurada para enviar información de estado de una segunda sesión de un terminal a un servidor de Centro de Conmutación Móvil, MSC, que proporciona servicio al terminal, en donde la segunda sesión debe ser transferida, la información de estado comprende un tipo de medio de la segunda sesión que se pretende transferir, y los tipos de medios comprenden el vídeo; y
    una unidad (1020) de procesamiento de sesión, configurada para recibir desde el servidor MSC una petición para transferir la voz de la segunda sesión que se pretende transferir, y convertir la segunda sesión en una sesión de voz para su transferencia.
  8. 8. El Servidor de Aplicación de Continuidad y Continuidad del Servicio de acuerdo con la reivindicación 7, en donde la petición para transferir la voz de la segunda sesión que se pretende transferir recibida desde el servidor MSC comprende la asignación del valor 0 a un número de puerto de transmisión de vídeo en la información de una fila de medios.
ES10811234.3T 2009-08-31 2010-08-19 Método para transferir múltiples sesiones, dispositivo de control de llamadas y servidor de continuidad de servicio Active ES2465218T5 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
CN200910171816XA CN102006645B (zh) 2009-08-31 2009-08-31 多会话转移方法及呼叫控制设备和业务连续性服务器
CN200910171816 2009-08-31
PCT/CN2010/076132 WO2011023074A1 (zh) 2009-08-31 2010-08-19 多会话转移方法及呼叫控制设备和业务连续性服务器

Publications (2)

Publication Number Publication Date
ES2465218T3 true ES2465218T3 (es) 2014-06-05
ES2465218T5 ES2465218T5 (es) 2017-08-16

Family

ID=43627248

Family Applications (1)

Application Number Title Priority Date Filing Date
ES10811234.3T Active ES2465218T5 (es) 2009-08-31 2010-08-19 Método para transferir múltiples sesiones, dispositivo de control de llamadas y servidor de continuidad de servicio

Country Status (5)

Country Link
US (1) US10021602B2 (es)
EP (1) EP2464166B2 (es)
CN (1) CN102006645B (es)
ES (1) ES2465218T5 (es)
WO (1) WO2011023074A1 (es)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101127766B (zh) * 2007-09-24 2010-06-09 中兴通讯股份有限公司 基于sip协议的消息处理方法、装置及ip通信系统
CN102006645B (zh) 2009-08-31 2012-01-04 华为终端有限公司 多会话转移方法及呼叫控制设备和业务连续性服务器
CN103118238B (zh) * 2011-11-17 2016-03-16 中国电信股份有限公司 视频会议的控制方法和视频会议系统
GB201320776D0 (en) 2013-11-25 2014-01-08 Microsoft Corp Communication system architecture
GB201320778D0 (en) 2013-11-25 2014-01-08 Microsoft Corp Communication system architecture
GB201320770D0 (en) 2013-11-25 2014-01-08 Microsoft Corp Communication system architecture
GB201320774D0 (en) 2013-11-25 2014-01-08 Microsoft Corp Communication system architecture
NO2707687T3 (es) 2014-03-20 2018-08-25
US9591124B2 (en) 2014-04-30 2017-03-07 Motorola Solutions, Inc. Method and system for transferring an audio signal between devices of a single user
US9544253B2 (en) * 2014-07-09 2017-01-10 Genband Us Llc Multimedia conversation transfer
CN107371140B (zh) * 2016-05-11 2021-01-12 中国移动通信有限公司研究院 一种呼叫前转的处理方法及设备
WO2018066799A1 (ko) * 2016-10-07 2018-04-12 엘지전자(주) 무선 통신 시스템에서 세션 및 서비스 연속성 모드 선택 방법 및 이를 위한 장치
CN109842643B (zh) 2017-11-27 2021-11-09 华为技术有限公司 一种会话处理的方法、装置及系统
WO2023241294A1 (en) * 2022-06-14 2023-12-21 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for application context relocation

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE60307221T2 (de) * 2003-01-16 2007-07-12 Sony Ericsson Mobile Communications Ab Weiterreichen einer Videotelefoniesitzung mit verminderter Qualität
US20040180689A1 (en) * 2003-03-14 2004-09-16 Logicacmg Wireless Networks, Inc. Systems and methods for establishing communication between a first wireless terminal and a second wireless terminal differing in respect to at least one feature
US20070100981A1 (en) * 2005-04-08 2007-05-03 Maria Adamczyk Application services infrastructure for next generation networks including one or more IP multimedia subsystem elements and methods of providing the same
ATE514272T1 (de) * 2006-08-03 2011-07-15 Accuris Technologies Ltd Roaming-gateway
WO2008026094A1 (en) * 2006-08-28 2008-03-06 Nokia Corporation Method, system and terminal for multimedia session establishment
KR101250589B1 (ko) * 2006-10-02 2013-04-03 삼성전자주식회사 멀티미디어 통화 서비스를 수행하기 위한 멀티미디어ＰｏＣ 세션 개설 및 관리 시스템과 그 방법 및 단말장치
GB0707387D0 (en) 2007-04-17 2007-05-23 Lucent Technologies Inc Single radio VCC:LTE-VMSC anchor solution
CN101325732B (zh) * 2007-06-15 2011-07-20 华为技术有限公司 呼叫控制的方法和ims的电路交换控制装置及终端设备
CN101110946B (zh) * 2007-08-17 2011-01-05 中兴通讯股份有限公司 对会话初始化协议终端的音频和视频通信进行切换的方法
CA2750660C (en) * 2008-08-18 2017-06-06 Telefonaktiebolaget L M Ericsson (Publ) Technique for emergency session handling in a communication network
CN102484850B (zh) * 2009-06-29 2015-08-19 黑莓有限公司 用于演进的分组系统中的语音服务的系统和方法
CN102006645B (zh) 2009-08-31 2012-01-04 华为终端有限公司 多会话转移方法及呼叫控制设备和业务连续性服务器

Also Published As

Publication number Publication date
US10021602B2 (en) 2018-07-10
WO2011023074A1 (zh) 2011-03-03
EP2464166B1 (en) 2014-03-05
EP2464166A1 (en) 2012-06-13
US20120155457A1 (en) 2012-06-21
EP2464166B2 (en) 2016-12-21
EP2464166A4 (en) 2012-06-13
ES2465218T5 (es) 2017-08-16
CN102006645A (zh) 2011-04-06
CN102006645B (zh) 2012-01-04

Similar Documents

Publication Publication Date Title
ES2465218T3 (es) Método para transferir múltiples sesiones, dispositivo de control de llamadas y servidor de continuidad de servicio
EP3240257B1 (en) A domain transferring method for single radio voice call continuity
JP5859535B2 (ja) アプリケーションサーバによるユーザ装置ケイパビリティの検索
RU2617438C2 (ru) Синхронизация состояний вызова сетевого компонента и мобильное устройство при переносе сеанса
CN101646256B (zh) 跨无线接入技术的语音切换方法、设备及网络系统
KR101263741B1 (ko) 멀티미디어 세션 전달을 위한 방법, 사용자 디바이스 및 서버
WO2010025602A1 (zh) 紧急业务切换方法
KR20120102771A (ko) 서비스 집중화 및 지속성 애플리케이션 서버(ｓｃｃ ａｓ)에 의해 개시되는 사용자 장치간 이전(ｉｕｔ), 액세스 이전 및 대체를 위한 방법 및 장치
WO2009012665A1 (fr) Procédé pour assurer une continuité d&#39;appel multimédia, équipement et système associés
TW201220886A (en) Single radio voice call continuity for emergency callback or click-to-dial sessions
JP2012533199A (ja) セッションの継続性を改善するための方法及びデバイス
EP2487958B1 (en) Method and system for realizing session handover
EP2485530B1 (en) System and method for switching ringing state session with customized alerting tone
EP2421218B1 (en) Session transfer method, apparatus and system thereof
ES2398057T3 (es) Una método, un dispositivo y un sistema de comunicaciones móviles para realizar una transferencia explícita de comunicaciones
US20120081505A1 (en) Session transfer method and user equipment
US20110106958A1 (en) Method and system for providing wireless services
EP2564634B1 (en) Improvements to handover
KR101501964B1 (ko) 터널 방향전환 방법 및 상호연동 기능 엔티티
WO2018072202A1 (zh) 一种终端的呼叫业务切换方法及装置
WO2011023054A1 (zh) 一种ip多媒体子系统中多会话能力同步方法及系统
EP3073799A1 (en) Method and apparatus for notifying/triggering call forwarding/deflection service
CN108259327A (zh) VoLTE业务恢复方法、系统及装置
US20120295620A1 (en) Advanced legacy mobile station domain (almsd) intersystem handoff without anchor network bearer support
KR102206887B1 (ko) HSS(Home Subscriber Server) 및 그 제어방법과 그 제어방법을 실행시키기 위한 기록매체