ES2654891T3 - Método, sistema y dispositivo para conmutación de dominio - Google Patents
Método, sistema y dispositivo para conmutación de dominio Download PDFInfo
- Publication number
- ES2654891T3 ES2654891T3 ES08706487.9T ES08706487T ES2654891T3 ES 2654891 T3 ES2654891 T3 ES 2654891T3 ES 08706487 T ES08706487 T ES 08706487T ES 2654891 T3 ES2654891 T3 ES 2654891T3
- Authority
- ES
- Spain
- Prior art keywords
- transfer
- session
- identifier
- domain
- message
- 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
Links
- 238000000034 method Methods 0.000 title claims abstract description 111
- 238000012546 transfer Methods 0.000 claims abstract description 651
- 102000018059 CS domains Human genes 0.000 claims abstract description 115
- 108050007176 CS domains Proteins 0.000 claims abstract description 115
- 230000011664 signaling Effects 0.000 claims description 28
- 241000282836 Camelus dromedarius Species 0.000 claims description 25
- 238000000605 extraction Methods 0.000 claims description 11
- 230000000977 initiatory effect Effects 0.000 claims description 10
- 238000006243 chemical reaction Methods 0.000 claims description 9
- 230000004913 activation Effects 0.000 claims description 8
- 102100039901 Calcyclin-binding protein Human genes 0.000 claims 15
- 102100039510 Cancer/testis antigen 2 Human genes 0.000 claims 2
- 101000889345 Homo sapiens Cancer/testis antigen 2 Proteins 0.000 claims 2
- 230000008569 process Effects 0.000 description 71
- 238000013507 mapping Methods 0.000 description 61
- 238000010586 diagram Methods 0.000 description 9
- 230000003993 interaction Effects 0.000 description 9
- 238000001914 filtration Methods 0.000 description 8
- 238000004891 communication Methods 0.000 description 7
- 230000006978 adaptation Effects 0.000 description 3
- 230000004044 response Effects 0.000 description 3
- 238000012217 deletion Methods 0.000 description 2
- 230000037430 deletion Effects 0.000 description 2
- 238000007726 management method Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000004458 analytical method Methods 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 230000004069 differentiation Effects 0.000 description 1
- 230000009977 dual effect Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 239000000463 material Substances 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
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/10—Architectures or entities
- H04L65/1016—IP multimedia subsystem [IMS]
-
- 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/1066—Session management
- H04L65/1083—In-session procedures
-
- 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/1066—Session management
- H04L65/1083—In-session procedures
- H04L65/1095—Inter-network session transfer or sharing
-
- 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
- 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 de dominio, la transferencia se lleva a cabo entre un dominio de circuito y una red de acceso con conectividad IP para la continuidad de la llamada de voz, VCC, caracterizado por que recibe, de una función de control de dominio CS IMS, ICCF, por una función de transferencia de dominio, DTF, que es un módulo funcional de un servicio de aplicación de continuidad de la llamada de voz, VCC AS, un mensaje de invitación, en donde el mensaje de invitación contiene un número de transferencia de dominio VCC, VDN, y un identificador de transferencia, en donde el identificador de transferencia y el VDN son independientes entre sí; y determina, por la DTF, que el mensaje de invitación es una solicitud de transferencia para un tramo de sesión existente según el destino del mensaje de invitación que es el VDN de la DTF y el identificador de transferencia, y llevar a cabo, por la DTF, una transferencia de dominio de una sesión según el identificador de transferencia.
Description
Método, sistema y dispositivo para conmutación de dominio.
Campo de la tecnología
La presente invención se refiere al campo de la comunicación y, más concretamente, a un método, sistema y 5 dispositivo de transferencia de dominio.
Antecedentes
Un subsistema multimedia de Protocolo de Internet (IP, por sus siglas en inglés) (IMS, por sus siglas en inglés) es un subsistema que se superpone a un dominio de transferencia de paquetes (PS) existente, y adopta el dominio PS para controlar la señalización y un canal de portadora de transmisión de medios para la capa superior, introduce el 10 protocolo de protocolo de iniciación de sesión (SIP, por sus siglas en inglés) como un protocolo de control de servicio, para proveer abundantes servicios multimedia mediante la separación del control de servicio y el control de portadora según las características del SIP que incluyen que el SIP es simple, fácil de expandirse, y conveniente para su combinación con los medios. Las principales entidades funcionales en el IMS incluyen una función de control de sesión de llamada (CSFC, por sus siglas en inglés) para controlar el registro de usuario, la sesión y otras 15 funciones, un servidor de aplicaciones (AS, por sus siglas en inglés) para proveer varias funciones de control lógicas de servicio, un servidor de abonado doméstico (HSS, por sus siglas en inglés) para gestionar datos de abono de usuario de manera centralizada, y una pasarela de medios con función de control de pasarela de medios MGCF/IMS (IM-MGW, por sus siglas en inglés) adaptada para llevar a cabo un interfuncionamiento con la red con conmutación de circuitos. El usuario tiene acceso al IMS a través del nodo de proxy de ubicación actual P-CSCF, y la sesión y
20 control de activación de servicio y la interacción con el control de servicio del AS finalizan por un nodo de servicio de dominio doméstico S-CSCF en la ubicación de registro.
Se supone que un usuario de dominio CS llama a un usuario IMS, o la sesión se conecta al dominio CS a través del IMS, el IMS y el dominio CS deben llevar a cabo el interfuncionamiento. El interfuncionamiento del IMS y el dominio CS se lleva a cabo mediante la conversión de una señalización de parte de usuario de red digital de servicios
25 integrados (ISUP, por sus siglas en inglés) y el SIP a través del elemento de red MGCF.
Si la señalización entre el IMS y el dominio CS puede convertirse o no depende de si la señalización ISUP y la señalización SIP tienen el mensaje correspondiente o no, si las células en el mensaje pueden llevar a cabo el mapeo mutuo o no, y si la MGCF puede convertir el mapeo o no.
Cuando la red se desarrolla hacia el IMS, el dominio CS y el dominio IMS pueden coexistir durante cierto período, y
30 en consideración del funcionamiento y coste de gestión, el operador puede pretender desplegar el servicio en el dominio IMS de manera centralizada, de modo que puede accederse al servicio a través del dominio CS o del dominio IMS. Además, durante la evolución de la red, la red de acceso de red de acceso con conectividad IP (CAN, por sus siglas en inglés) que tiene una capacidad de voz sobre IP (VoIP, por sus siglas en inglés) es un proceso de despliegue escalonado. Con el fin de asegurar que el usuario pueda tener acceso a la red IMS a través de CS en la
35 red de acceso IP-CAN sin la capacidad VoIP, y pueda proveer capacidades de servicio más abundantes en la red de acceso IP-CAN con la capacidad VoIP, se define que la llamada de voz en tiempo real puede transferirse entre el dominio CS y el dominio de acceso IP-CAN. Las relaciones lógicas de red para llevar a cabo las dos demandas se describen a continuación.
Un servidor de aplicaciones de continuidad de llamada de voz (VCC AS, por sus siglas en inglés) finaliza la función 40 de gestión de transferencia del usuario entre el dominio de circuito y la IP-CAN.
Una función de control de dominio CS IMS (ICCF, por sus siglas en inglés) finaliza la adaptación entre la señalización de dominio CS y la señalización SIP de dominio IMS, y lleva a cabo el control de servicio y la interacción del usuario en el dominio IMS como un proxy de usuario. Según el despliegue, la ICCF puede también conectarse de forma serial en el trayecto de acceso del dominio de paquete.
45 El mensaje de control de sesión puede entregarse entre un equipo de usuario (EU) y la ICCF a través de ciertos canales de señalización, y se hace referencia a todos los canales de señalización como canales de control CS IMS (ICCC, por sus siglas en inglés). Según los diferentes entornos de red de acceso, pueden existir diferentes protocolos de entrega de mensajes. Por ejemplo, cuando solo se conecta el dominio CS, el mensaje puede transmitirse a través de un protocolo de datos de servicio suplementario no estructurados (USSD, por sus siglas en
50 inglés), un mensaje corto, y una multifrecuencia de tono dual (DTMF, por sus siglas en inglés), etc. Cuando el EU se conecta a la IP-CAN sin la capacidad VoIP, el mensaje puede transmitirse a través del protocolo SIP entregado a través de la IP-CAN.
Dado que la interfaz aérea del dominio CS solo puede soportar una llamada de voz, y en consideración de otras condiciones como, por ejemplo, la velocidad de transferencia, cuando el EU tiene la sesión con múltiples usuarios remotos, solo un dominio CS se establece entre la ICCCF y el EU para la portadora, y el control de servicio en las múltiples sesiones se finaliza mediante el uso del ICCC.
IMS es la descripción del proyecto de asociación de tercera generación (3GPP, por sus siglas en inglés), y un subsistema multimedia similar también existe en 3GGP2 y los servicios y protocolos convergentes de
5 telecomunicaciones e Internet para el interfuncionamiento avanzado (TISPAN, por sus siglas en inglés). En la presente invención, solo el IMS se describe en aras de la descripción, pero claramente, el método descrito también es aplicable al sistema del 3GPP2 y TISPAN.
En el proyecto de continuidad de la llamada de voz (VCC, por sus siglas en inglés) del 3GPP, el EU inicia la transferencia mediante el uso de un número de transferencia de dominio VCC / identificador de recursos uniforme de
10 transferencia de dominio VCC (URI, por su siglas en inglés) (VDN/VDI, por sus siglas en inglés). Cuando el EU transfiere de IP-CAN al dominio CS, el proceso incluye las siguientes etapas.
En la etapa 1, el EU inicia una solicitud de llamada a la función de transferencia de dominio (DTF, por sus siglas en inglés), a saber, un módulo funcional del VCC AS, y el destino es el VDN de la DTF.
En las etapas 2-5, la solicitud de llamada iniciada por el EU se encamina hacia la DTF después de entregarse al IMS 15 a través del dominio CS.
En las etapas 6-7, la DTF sabe que es una solicitud de transferencia a través del VDN, para actualizar un tramo de acceso de la sesión al tramo de acceso del dominio CS, y liberar el tramo de acceso original de la IP-CAN.
Cuando el EU transfiere del dominio CS a IP-CAN, el proceso incluye las siguientes etapas.
En la etapa 1, el EU inicia una solicitud de llamada a la DTF a través de IP-CAN, y el destino es el VDI de la DTF.
20 En la etapa 2, la llamada iniciada por el EU se encamina hacia la DTF.
En las etapas 3-4, la DTF sabe que es una solicitud de transferencia a través del VDI, para actualizar el tramo de acceso de la sesión al tramo de acceso de la IP-CAN, y liberar el tramo de acceso original del dominio CS.
Durante la invención, el inventor descubre que en el sistema de comunicación existente, el VDN y el VDI son relativamente fijos durante la transferencia VCC, y se configuran de manera fija en el EU, o se entregan al EU por el
25 aire (OTA, por sus siglas en inglés). En cada solicitud de transferencia, el EU inicia la solicitud de llamada a la DTF mediante el uso del VDN o VDI como el número al que se llama, independientemente de las sesiones. Cuando el EU tiene las sesiones con varios usuarios remotos, la DTF no puede distinguir a través del VDN/VDI qué sesión pretende transferir el EU.
NORTEL Y OTROS: "IMS-controlled: Replacing Section 6.3.7:Supplementary Services" 3GPP borrador, S2-051669
30 VCC 6_3_7 describe un método para la transferencia de dominio entre CS e IMS. El mensaje de solicitud de transferencia de dominio solo contiene VDN/VDI o el número de teléfono al que se llama.
Compendio
La presente invención se dirige a un método de transferencia de dominio, y dispositivo, según las reivindicaciones independientes anexas 1 y 10 para llevar a cabo la ubicación y transferencia de dominio en una sesión que se
35 transferirá llevados a cabo por un AS de transferencia de dominio.
El método de transferencia de dominio llevado a cabo entre un dominio de circuito y una red de acceso de conectividad IP para la continuidad de la llamada de voz, VCC, según la presente invención incluye las etapas descritas a continuación. Una función de transferencia de dominio, DTF, que es un módulo funcional de un servidor de aplicaciones de continuidad de llamada de voz, VCC AS, recibe un mensaje de invitación que contiene un 40 número de transferencia de dominio VCC, VDN, o un identificador de recursos uniforme de transferencia de dominio VCC, VDI, y un identificador de transferencia, en donde el identificador de transferencia y el VDN/VDI son independientes entre sí. La DTF determina que el mensaje de invitación es una solicitud de transferencia para un tramo de sesión existente según el destino del mensaje de invitación que es el propio VDN/VDI y el identificador de transferencia, y lleva a cabo una transferencia de dominio en una sesión correspondiente según el identificador de
45 transferencia.
La terminal de usuario según la presente invención incluye una unidad de grabación y una unidad de contención. La unidad de grabación se adapta para grabar una relación de asociación entre una sesión y un identificador de transferencia cuando se establece la sesión. La unidad de contención se adapta para adquirir el identificador de transferencia asociado a la sesión de la unidad de grabación, y contener un número de transferencia de dominio 50 VCC, VDN, o un identificador de recursos uniforme de transferencia de dominio VCC, VDI, y el identificador de transferencia en un mensaje de solicitud de transferencia de dominio enviado a una función de transferencia de
dominio, DTF, cuando se inicia una transferencia de dominio de la sesión, en donde el identificador de transferencia
y el VDN/VDI son independientes entre sí. El servidor de aplicaciones de continuidad de la llamada de voz, VCC AS, según la presente invención incluye una unidad de grabación y una unidad de función de transferencia de dominio, DTF. La unidad de grabación se adapta
5 para grabar una relación de asociación entre una sesión y un identificador de transferencia cuando se establece la sesión. La unidad DTF se adapta para adquirir un número de transferencia de dominio VCC, VDN, o un identificador de recursos uniforme de transferencia de dominio VCC, VDI, y el identificador de transferencia de un mensaje de invitación, en donde el identificador de transferencia y el VDN/VDI son independientes entre sí, determinar que el mensaje de invitación es una solicitud de transferencia para un tramo de sesión existente según el destino del
10 mensaje de invitación que es el propio VDN/VDI y el identificador de transferencia, adquirir la sesión asociada al
identificador de transferencia de la unidad de grabación, y llevar a cabo una transferencia de dominio en la sesión. En la presente invención, el AS de transferencia de dominio recibe el mensaje de solicitud de transferencia de dominio que contiene el identificador de transferencia; el AS de transferencia de dominio adquiere el identificador de transferencia del mensaje de solicitud de transferencia de dominio, y lleva a cabo la transferencia de dominio en la
15 sesión correspondiente según el identificador de transferencia, y así lleva a cabo la ubicación y transferencia de dominio en la sesión que se transferirá por el AS de transferencia de dominio. Breve descripción de los dibujos La Figura 1 es un diagrama de flujo de etapas de un método según una realización de la presente invención; la Figura 2 es una vista estructural esquemática de una terminal de usuario según una realización de la presente
20 invención; la Figura 3 es una vista estructural esquemática de un AS de transferencia de dominio según una realización de la presente invención;
la Figura 4 es un diagrama de flujo de la Realización 1 de la presente invención;
la Figura 5 es un diagrama de flujo de la Realización 2 de la presente invención;
25 la Figura 6 es un diagrama de flujo de la Realización 3 de la presente invención; la Figura 7 es un diagrama de flujo de la Realización 4 de la presente invención; la Figura 8 es un diagrama de flujo de la Realización 5 de la presente invención; la Figura 9 es un diagrama de flujo de la Realización 6 de la presente invención; la Figura 10 es un diagrama de flujo de la Realización 7 de la presente invención;
30 la Figura 11 es un diagrama de flujo de la Realización 8 de la presente invención; la Figura 12 es un diagrama de flujo de la Realización 9 de la presente invención; la Figura 13 es un diagrama de flujo de la Realización 10 de la presente invención; la Figura 14 es un diagrama de flujo de la Realización 11 de la presente invención; la Figura 15 es un diagrama de flujo de la Realización 12 de la presente invención;
35 la Figura 16 es un diagrama de flujo de la Realización 13 de la presente invención; la Figura 17 es un diagrama de flujo de la Realización 14 de la presente invención; la Figura 18 es un diagrama de flujo de la Realización 15 de la presente invención; la Figura 19 es un diagrama de flujo de la Realización 16 de la presente invención; la Figura 20 es un diagrama de flujo de la Realización 17 de la presente invención;
40 la Figura 21 es un diagrama de flujo de la Realización 18 de la presente invención; la Figura 22 es un diagrama de flujo de la Realización 19 de la presente invención; la Figura 23 es un diagrama de flujo de la Realización 20 de la presente invención; la Figura 24 es un diagrama de flujo de la Realización 21 de la presente invención;
la Figura 25 es un diagrama de flujo de la Realización 22 de la presente invención;
la Figura 26 es un diagrama de flujo de la Realización 23 de la presente invención;
la Figura 27 es un diagrama de flujo de la Realización 24 de la presente invención;
5 la Figura 28 es un diagrama de flujo de la Realización 25 de la presente invención;
la Figura 29 es un diagrama de flujo de la Realización 26 de la presente invención;
la Figura 30 es una vista esquemática de un flujo de implementación de un método para proveer una transferencia multisesión en forma de acceso múltiple según una realización de la presente invención;
las Figuras 31 a 41 son, respectivamente, vistas esquemáticas del flujo de implementación de las Realizaciones 27 a 10 37;
la Figura 42 es una vista estructural esquemática de un sistema para proveer la transferencia multisesión en forma de acceso múltiple según una realización de la presente invención;
la Figura 43 es una vista estructural esquemática de un AS de transferencia de dominio para proveer la transferencia multisesión en forma de acceso múltiple según una realización de la presente invención; y
15 la Figura 44 es una vista estructural esquemática de una terminal de usuario para proveer la transferencia multisesión en forma de acceso múltiple según una realización de la presente invención.
Descripción detallada
Con el fin de llevar a cabo la ubicación y transferencia de dominio en una sesión que se transferirá llevadas a cabo por un AS de transferencia de dominio, la presente invención provee un método de transferencia de dominio. Con 20 referencia a la Figura 1, el método incluye las siguientes etapas.
En la etapa E1, un AS de transferencia de dominio recibe un mensaje de solicitud de transferencia de dominio que contiene un identificador de transferencia.
El identificador de transferencia en la presente invención y un número VDN/VDI son independientes entre sí, o diferentes números VDN/VDI se usan en diferentes sesiones como el identificador de transferencia.
25 En la etapa E2, el AS de transferencia de dominio adquiere el identificador de transferencia del mensaje de solicitud de transferencia de dominio, y lleva a cabo una transferencia de dominio en una sesión correspondiente según el identificador de transferencia.
El identificador de transferencia se libera después de detener la correspondiente sesión.
La presente invención provee un sistema de transferencia de dominio, el cual incluye una terminal de usuario y un 30 AS de transferencia de dominio, y además incluye un elemento de red de proxy de usuario.
La terminal de usuario se adapta para enviar un mensaje de solicitud de transferencia de dominio que contiene un identificador de transferencia cuando se inicia una transferencia de dominio de una sesión.
El AS de transferencia de dominio se adapta para adquirir el identificador de transferencia del mensaje de solicitud de transferencia de dominio, y llevar a cabo la transferencia de dominio en la sesión correspondiente según el 35 identificador de transferencia.
El elemento de red de proxy de usuario puede ser uno de los siguientes elementos de red de proxy de usuario, y puede también ser cualquier combinación funcional de los elementos de red de proxy de usuario como se describe a continuación.
Uno de los elementos de red de proxy de usuario y la terminal de usuario entregan un mensaje ICCC que contiene el 40 identificador de transferencia al otro; y el elemento de red de proxy de usuario y el AS de transferencia de dominio entregan un mensaje SIP que contiene el identificador de transferencia al otro.
Otro elemento de red de proxy de usuario se adapta para aplicar un recurso de puerto de medios para la sesión que se transferirá, notificar al AS de transferencia de dominio, e indicar el AS de transferencia de dominio para renegociar la sesión que se transferirá con un usuario remoto mediante el uso del recurso de puerto de medios,
45 cuando la terminal de usuario tiene la sesión en un dominio CS y la terminal de usuario transfiere la sesión de IP-CAN al dominio CS.
Otro elemento de red de proxy de usuario se adapta para liberar el recurso de puerto de medios correspondiente a la sesión según la notificación de liberación de sesión del AS de transferencia de dominio, y notificar a la terminal de usuario que la sesión se libera, cuando la terminal de usuario transfiere la sesión del dominio CS a IP-CAN.
Otro elemento de red de proxy de usuario se ubica en un trayecto de acceso entre la terminal de usuario y el AS de
5 transferencia de dominio, y se adapta para finalizar el identificador de control de sesión y la conversión de identificador de transferencia en el mensaje, cuando la terminal de usuario y el AS de transferencia de dominio interactúan entre sí a través del mensaje.
Con referencia a la Figura 2, la realización de la presente invención provee una terminal de usuario, y la terminal de usuario incluye una unidad de grabación y una unidad de contención, y además incluye una unidad de asignación,
10 una unidad de recepción, y una unidad de extracción, y/o una unidad de recepción y una unidad de asociación.
La unidad de grabación se adapta para grabar una relación de asociación entre una sesión y un identificador de transferencia cuando se establece la sesión.
La unidad de contención se adapta para adquirir el identificador de transferencia asociado a la sesión de la unidad de grabación, y contener el identificador de transferencia en un mensaje de solicitud de transferencia de dominio 15 enviado al AS de transferencia de dominio, cuando se inicia una transferencia de dominio de la sesión. En particular, cuando se inicia la transferencia de dominio de la sesión en IP-CAN, la terminal de usuario envía el mensaje de establecimiento de sesión SIP que contiene el identificador de transferencia asociado a la sesión al AS de transferencia de dominio, para indicar que la sesión se transfiere a IP-CAN. De manera alternativa, cuando se inicia la transferencia de dominio de la sesión en el dominio CS, la terminal de usuario envía el mensaje de solicitud de
20 transferencia de dominio que contiene el identificador de transferencia asociado a la sesión al AS de transferencia de dominio, para indicar que la sesión se transfiere al dominio CS. De manera alternativa, la terminal de usuario envía el mensaje que contiene el identificador de transferencia nulo al AS de transferencia de dominio, para indicar que la sesión a la que se hace referencia es una sesión por defecto.
La unidad de asignación se adapta para distribuir el identificador de transferencia asociado a la sesión, enviar el
25 identificador de transferencia a la unidad de grabación para su grabación, y enviar el identificador de transferencia al AS de transferencia de dominio, cuando se establece la sesión. En particular, cuando la terminal de usuario establece la sesión en IP-CAN, la unidad de asignación distribuye el identificador de transferencia asociado a la sesión, y notifica al AS de transferencia de dominio mediante la contención del identificador de transferencia en el mensaje SIP. De manera alternativa, cuando la terminal de usuario establece la sesión en el dominio CS, la unidad
30 de asignación distribuye el identificador de transferencia asociado a la sesión, y notifica al AS de transferencia de dominio. De manera alternativa, según una norma por defecto, la unidad de asignación distribuye el identificador de transferencia para la sesión, de modo que la terminal de usuario y el AS de transferencia de dominio adquieren el mismo identificador de transferencia para la sesión.
La unidad de recepción se adapta para recibir un mensaje enviado desde un lado de red cuando se establece la 35 sesión.
La unidad de extracción se adapta para extraer el identificador de transferencia del mensaje recibido por la unidad de recepción, y enviar el identificador de transferencia a la unidad de grabación para su grabación. En particular, cuando la terminal de usuario establece la sesión en IP-CAN, el AS de transferencia de dominio distribuye el identificador de transferencia asociado a la sesión, y notifica a la terminal de usuario mediante la contención del
40 identificador de transferencia en el mensaje SIP. Luego, la terminal de usuario adquiere el identificador de transferencia a través de la unidad de extracción. De manera alternativa, cuando la terminal de usuario establece la sesión en el dominio CS, el AS de transferencia de dominio distribuye el identificador de transferencia asociado a la sesión, y notifica a la terminal de usuario. Luego, la terminal de usuario adquiere el identificador de transferencia a través de la unidad de extracción.
45 La unidad de asociación se adapta para extraer un identificador de control del mensaje recibido por la unidad de recepción, y asociar el identificador de control a la sesión actualmente establecida.
La realización de la presente invención provee un AS de transferencia de dominio, el cual incluye una unidad de grabación y una unidad de transferencia, y además incluye una unidad de asignación; o una unidad de recepción y una unidad de extracción; o una unidad de asignación, una unidad de recepción y una unidad de extracción. Con
50 referencia a la Figura 3, el AS de transferencia de dominio, por ejemplo, incluye una unidad de grabación, una unidad de transferencia, una unidad de asignación, una unidad de recepción, y una unidad de extracción.
La unidad de grabación se adapta para grabar una relación de asociación entre una sesión y un identificador de transferencia cuando se establece la sesión.
5
10
15
20
25
30
35
40
45
50
La unidad de transferencia se adapta para adquirir el identificador de transferencia del mensaje de solicitud de transferencia, adquirir la sesión asociada al identificador de transferencia de la unidad de grabación, y llevar a cabo una transferencia de dominio en la sesión.
La unidad de asignación se adapta para distribuir el identificador de transferencia asociado a la sesión, enviar el identificador de transferencia a la unidad de grabación para su grabación, y enviar el identificador de transferencia al AS de transferencia de dominio, cuando se establece la sesión. En particular, cuando la terminal de usuario establece la sesión en IP-CAN, la unidad de asignación distribuye el identificador de transferencia asociado a la sesión, y notifica a la terminal de usuario mediante la contención del identificador de transferencia en el mensaje SIP. De manera alternativa, cuando la terminal de usuario establece la sesión en el dominio CS, la unidad de asignación distribuye el identificador de transferencia asociado a la sesión, y notifica a la terminal de usuario. De manera alternativa, según una norma por defecto, la unidad de asignación distribuye el identificador de transferencia para la sesión, de modo que la terminal de usuario y el AS de transferencia de dominio adquieren el mismo identificador de transferencia para la sesión.
La unidad de recepción se adapta para recibir un mensaje enviado desde la terminal de usuario cuando se establece la sesión.
La unidad de extracción se adapta para extraer el identificador de transferencia del mensaje recibido por la unidad de recepción, y enviar el identificador de transferencia a la unidad de grabación para su grabación. En particular, cuando la terminal de usuario establece la sesión en IP-CAN, la terminal de usuario distribuye el identificador de transferencia asociado a la sesión, y notifica al AS de transferencia de dominio mediante la contención del identificador de transferencia en el mensaje SIP. Luego, el AS de transferencia de dominio adquiere el identificador de transferencia a través de la unidad de extracción. De manera alternativa, cuando la terminal de usuario establece la sesión en el dominio CS, la terminal de usuario distribuye el identificador de transferencia asociado a la sesión, y notifica al AS de transferencia de dominio. Luego, el AS de transferencia de dominio adquiere el identificador de transferencia a través de la unidad de extracción.
La realización de la presente invención provee un elemento de red de proxy de usuario, el cual incluye una unidad de reenvío, una unidad de generación, y una unidad de cooperación, y además incluye una unidad de aplicación y una unidad de liberación.
La unidad de reenvío se adapta para reenviar el identificador de transferencia que interactúa entre la terminal de usuario y el AS de transferencia de dominio.
La unidad de generación se adapta para generar el identificador de control asociado a la sesión cuando se establece la sesión.
La unidad de cooperación se adapta para cooperar con la terminal de usuario a través del identificador de control generado por la unidad de generación, para grabar la relación de asociación entre la sesión y el identificador de transferencia cuando se establece la sesión.
La unidad de aplicación se adapta para aplicar un recurso de puerto de medios para la sesión que se transferirá y notificar al AS de transferencia de dominio cuando la terminal de usuario tiene la sesión en el dominio CS y la terminal de usuario transfiere la sesión de IP-CAN al dominio CS.
La unidad de liberación se adapta para liberar el recurso de puerto de medios correspondiente a la sesión según la notificación de liberación de sesión del AS de transferencia de dominio, y notificar a la terminal de usuario que la sesión se libera, cuando la terminal de usuario transfiere la sesión del dominio CS a IP-CAN.
La descripción detallada se provee con 26 realizaciones de la siguiente manera.
Realización 1. El EU como un llamante establece la sesión IP-CAN. La DTF asigna el identificador de transferencia y entrega el identificador de transferencia al EU. Con referencia a la Figura 4, el proceso incluye las siguientes etapas.
En las etapas 1-3, cuando obtiene acceso a P-CAN, el EU inicia una sesión para B, y un mensaje de Invitación se encamina a la DTF según la información de abono.
En las etapas 4-5, la DTF descubre que es una nueva llamada aquí, la DTF continúa enviando la llamada a la parte llamada B, y al mismo tiempo distribuye un identificador de transferencia para la sesión.
En la etapa 6, la DTF adquiere el 183 reconocimiento de la parte llamada B.
En las etapas 7-9, la DTF añade el identificador de transferencia de la sesión al mensaje de reconocimiento devuelto al EU, y devuelve el mensaje de reconocimiento al EU.
En la etapa 10, el EU guarda el identificador de transferencia adquirido.
5
10
15
20
25
30
35
40
45
Después de establecer la sesión, si el EU pretende iniciar la transferencia de la sesión entre los dominios de acceso, el flujo de transferencia puede usar cualquiera de las Realizaciones 19-22. Las realizaciones de distribución del identificador de transferencia cuando se establece la sesión son iguales a la presente Realización y, por consiguiente, no se repiten aquí.
Notas:
El identificador de transferencia no solo es un VDI/VDN dinámico, sino que también es un identificador independiente del VDI/VDN, y puede distribuirse, contenerse y entregarse mediante el uso de la manera descrita en la presente realización. Las realizaciones subsiguientes son iguales a la presente realización y, por consiguiente, no se repiten aquí.
Si la sesión es la primera sesión entre el EU y la DTF, el identificador de transferencia de la sesión puede ser el identificador por defecto o el identificador nulo, y las realizaciones subsiguientes son similares a la presente realización.
La Figura 4 solo muestra que el identificador de transferencia se devuelve al EU a través del mensaje 183 de reconocimiento, durante la aplicación práctica, el identificador de transferencia puede devolverse al EU a través de otros mensajes de reconocimiento como, por ejemplo, un mensaje 180 y un mensaje 200 OK.
El identificador de transferencia se contiene mediante la definición reciente de un campo de encabezamiento o un parámetro del mensaje SIP (por ejemplo, definición reciente de un campo de encabezamiento DT-ID, o adición reciente de un parámetro Transferencia-ID a un campo de encabezamiento A), o se contiene mediante la extensión del campo de encabezamiento o parámetro original (por ejemplo, el campo de encabezamiento de Servidor o Usuario-Agente), o se contiene en el contenido del mensaje de protocolo de descripción de sesión (SDP, por sus siglas en inglés) del formato de texto.
La sesión no se limita a una pura sesión de voz, y puede ser una sesión multimedios. Las realizaciones subsiguientes son iguales a la presente realización y, por consiguiente, no se repiten aquí.
Realización 2. El EU como una llamada establece la sesión IP-CAN. La DTF asigna el identificador de transferencia y entrega el identificador de transferencia al EU. Con referencia a la Figura 5, el proceso incluye las siguientes etapas.
En las etapas 1-2, la DTF recibe una solicitud de sesión iniciada por un usuario remoto B al EU local.
En la etapa 3, la DTF distribuye un identificador de transferencia para la sesión.
En las etapas 4-6, la DTF añade el identificador de transferencia de la sesión al mensaje de Invitación, y envía el mensaje de Invitación al EU.
En la etapa 7, el EU guarda el identificador de transferencia adquirido.
Notas:
El identificador de transferencia se contiene mediante la definición reciente de un campo de encabezamiento o un parámetro del mensaje SIP (por ejemplo, la definición reciente de un campo de encabezamiento DT-ID, o la adición reciente de un parámetro Transferencia-ID a un campo de encabezamiento A), o se contiene mediante la extensión del campo de encabezamiento o parámetro original (por ejemplo, el campo de encabezamiento de Servidor o Usuario-Agente), o se contiene en el contenido del mensaje SDP del formato de texto.
Realización 3. El EU como un llamante establece la sesión CS, y el VCC AS distribuye y entrega el identificador de transferencia al EU a través del mensaje ICCC. Con referencia a la Figura 6, el proceso incluye las siguientes etapas.
En la etapa 1, el EU envía un mensaje USSD en el dominio CS al VCC AS para solicitar el establecimiento de una nueva sesión para el usuario remoto B.
En la etapa 2, el VCC AS distribuye un identificador de transferencia para la sesión.
En la etapa 3, el VCC AS regresa para notificar al EU el identificador de transferencia distribuido de la sesión a través del mensaje USSD.
En la etapa 4, después de recibir la notificación del identificador de transferencia distribuido de la sesión del VCC AS, el EU guarda el identificador de transferencia de la sesión.
5
10
15
20
25
30
35
40
45
En la etapa 5, una portadora se establece entre el EU y el VCC AS, y la etapa y otras etapas pueden llevarse a cabo en paralelo o en cualquier secuencia. Cuando se ha establecido la portadora CS entre el EU y el VCC AS, esta etapa es opcional.
En la etapa 6, el VCC AS continúa encaminando la solicitud de llamada hacia el siguiente salto hacia el usuario remoto B.
Notas:
En las etapas 1 y 3, además del mensaje USSD, el VCC AS y el EU pueden interactuar a través de otros mensajes de señalización de dominio de circuito, por ejemplo, un mensaje corto y una DTMF, o el mensaje SIP se entrega a través del paquete. La manera de uso y los propósitos del mensaje son iguales al canal de mensaje ICCC entre el EU y la ICCF (el mensaje del servicio IMS se controla mediante el uso de la entrega del mensaje de señalización original), así que aquí se hace referencia a las maneras de entrega entre el EU y el VCC AS mediante el uso del canal de señalización original como el ICCC. Las realizaciones subsiguientes son iguales a la presente realización.
Realización 4. El EU como una llamada establece la sesión IP-CAN y el VCC AS asigna y entrega directamente el identificador de transferencia al EU a través del mensaje ICCC. Con referencia a la Figura 7, el proceso incluye las siguientes etapas.
En la etapa 1, el VCC AS recibe una solicitud de sesión iniciada por un usuario remoto B a un EU local.
En la etapa 2, el VCC AS distribuye un identificador de transferencia para la sesión.
En la etapa 3, el VCC AS notifica mediante el mensaje USSD al EU que el usuario remoto solicita establecer una sesión, y el identificador de transferencia distribuido de la sesión que ha distribuido en la etapa 2.
En la etapa 4, después de recibir la notificación del identificador de transferencia de la sesión distribuido por el VCC AS, el EU guarda el identificador de transferencia de la sesión.
En la etapa 5, una portadora se establece entre el EU y el VCC AS, y la etapa y otras etapas pueden llevarse a cabo en paralelo o en cualquier secuencia. Cuando se ha establecido la portadora CS entre el EU y el VCC AS, esta etapa es opcional.
En la etapa 6, el EU finaliza el proceso de establecimiento de la sesión con el usuario remoto a través del dominio CS y el VCC AS.
Notas:
En la etapa 3, además del mensaje USSD, el VCC AS y el EU pueden interactuar a través de otros mensajes ICCC como, por ejemplo, un mensaje corto y una DTMF.
Realización 5. El EU como un llamante interactúa mediante el mensaje USSD y establece la sesión CS a través de CAMEL. La DTF asigna el identificador de transferencia y la ICCF entrega el identificador de transferencia a través del mensaje ICCF al EU. Con referencia a la Figura 8, el proceso incluye las siguientes etapas.
En las etapas 1-4, el EU notifica a través del canal ICCC a la ICCF que pretende establecer una nueva sesión, en la cual la ICCF distribuye un identificador de control particular para la sesión, y devuelve el identificador de control al EU en el mensaje de reconocimiento del ICCC. El EU guarda el identificador de control.
En las etapas 5-11, el EU inicia el flujo de establecimiento de la sesión para el usuario B en el dominio CS, la llamada de dominio CS se redirige a la ICCF a través de CAMEL y, aquí, la ICCF restablece el usuario B real llamado según un mensaje de punto de detección inicial (IDP, por sus siglas en inglés) activado a través de CAMEL para el protocolo de control de sesión (SCP, por sus siglas en inglés).
En las etapas 12-13, la ICCF convierte el mensaje en el mensaje de Invitación y envía la solicitud para invitar al usuario B, y el mensaje se activa para la DTF.
En las etapas 14-16, la DTF distribuye un identificador de transferencia de la sesión para la sesión, y envía la solicitud al usuario B llamado.
En las etapas 17-19, la DTF recibe el mensaje de reconocimiento del usuario B llamado, añade el identificador de transferencia al mensaje de reconocimiento, y continúa la devolución.
En las etapas 20-21, la ICCF recibe el mensaje de reconocimiento con el identificador de transferencia añadido de la DTF, y luego devuelve el identificador de control y el identificador de transferencia al EU mediante el uso del canal de mensaje ICCC.
En la etapa 22, el EU adquiere la sesión asociada correcta del identificador de transferencia llevando a cabo la asociación con el identificador de control guardado, y guarda el identificador de transferencia.
Notas:
Cuando se ha establecido la portadora de dominio CS entre el EU y la ICCF, las etapas 5-11 son opcionales.
5 La Figura 8 solo muestra que el identificador de transferencia se devuelve a la ICCF a través del mensaje 183 de reconocimiento, durante la aplicación práctica, el identificador de transferencia puede devolverse al EU a través de otros mensajes de reconocimiento como, por ejemplo, un mensaje 180 y un mensaje 200 OK.
El identificador de transferencia se contiene mediante la definición reciente de un campo de encabezamiento o un parámetro del mensaje SIP (por ejemplo, la definición reciente de un campo de encabezamiento DT-ID, o la adición
10 reciente de un parámetro Transferencia-ID a un campo de encabezamiento A), o se contiene mediante la extensión del campo de encabezamiento o parámetro original (por ejemplo, el campo de encabezamiento de Servidor o Usuario-Agente), o se contiene en el contenido del mensaje SDP del formato de texto.
El SCP y la ICCF en la Figura 8 pueden desplegarse en la misma entidad física, o pueden desplegarse de forma separada. Cuando se despliegan juntos, interactúan entre sí a través de la información mediante la interfaz interna.
15 Cuando se despliegan de forma separada, interactúan entre sí a través de la información mediante el protocolo de alerta común (CAP, por sus siglas en inglés), la parte de aplicación móvil (MAP, por sus siglas en inglés), el SIP, y otros protocolos existentes y las interfaces privadas. La relación entre el SCP y la ICCF en las restantes realizaciones es igual a la presente realización y, por consiguiente, no se repite aquí.
Cuando la ICCF no se despliega en la red, una función de adaptación CS (CSAF, por sus siglas en inglés) en el
20 VCC AS finaliza la entrega del identificador de transferencia a través del canal ICCC de la ICCF, y las realizaciones subsiguientes son iguales a la presente realización.
En la presente realización, después de que la relación de asociación entre el identificador de control y la sesión se guarda por el EU y la ICCF, posteriormente la ICCF contiene el identificador de control en la notificación ICCC, para indicar la sesión a la cual se asocia el identificador de transferencia distribuido por la DTF. En la aplicación práctica,
25 entre el EU y la ICCF, múltiples sesiones pueden distinguirse y distribuirse a través del identificador de control, y la notificación de mensaje y el control de servicio pueden llevarse a cabo en cada sesión mediante el uso del mensaje ICCC. La descripción detallada puede obtenerse con referencia a las etapas 27-31 de la Realización 25.
En las restantes realizaciones, el identificador de control distribuido tiene una función similar, de modo que no se repite en la presente memoria.
30 Realización 6. El EU como un llamante establece la sesión CS llamando a la PTS de la ICCF. La DTF asigna el identificador de transferencia y la ICCF entrega el identificador de transferencia a través del mensaje ICCF al EU. Con referencia a la Figura 9, el proceso incluye las siguientes etapas.
En las etapas 1-4, el EU inicia el flujo de establecimiento de la portadora de dominio CS para la ICCF en el dominio CS.
35 En las etapas 5-8, el EU notifica a través del canal ICCC la ICCF que pretende establecer una nueva sesión. Aquí, la ICCF distribuye un identificador de control particular para la sesión, y devuelve el identificador de control al EU en el mensaje de reconocimiento del ICCC. El EU guarda el identificador de control.
En las etapas 9-11, la ICCF adquiere el usuario B real llamado de la notificación del ICCC, convierte el mensaje en el mensaje de Invitación y envía la solicitud para invitar al usuario B, y el mensaje se activa para la DTF.
40 En las etapas 12-14, la DTF distribuye un identificador de transferencia de la sesión para la sesión, y envía la solicitud al usuario B llamado.
En las etapas 15-17, la DTF recibe el mensaje de reconocimiento del usuario B llamado, añade el identificador de transferencia al mensaje de reconocimiento, y continúa la devolución.
En las etapas 18-19, la ICCF recibe el mensaje de reconocimiento con el identificador de transferencia añadido de la
45 DTF, y luego devuelve el identificador de control y el identificador de transferencia al EU mediante el uso del canal de mensaje ICCC.
En la etapa 20, el EU adquiere la sesión asociada correcta del identificador de transferencia llevando a cabo la asociación al identificador de control guardado, y guarda el identificador de transferencia.
Notas:
5
10
15
20
25
30
35
40
45
Cuando se ha establecido la portadora de dominio CS entre el EU y la ICCF, las etapas 1-4 son opcionales.
La Figura 9 solo muestra que el identificador de transferencia se devuelve a la ICCF a través del mensaje 183 de reconocimiento, durante la aplicación práctica, el identificador de transferencia puede devolverse al EU a través de otros mensajes de reconocimiento como, por ejemplo, un mensaje 180 y un mensaje 200 OK.
El identificador de transferencia se contiene mediante la definición reciente de un campo de encabezamiento o un parámetro del mensaje SIP (por ejemplo, la definición reciente de un campo de encabezamiento DT-ID, o la adición reciente de un parámetro Transferencia-ID a un campo de encabezamiento A), o se contiene mediante la extensión del campo de encabezamiento o parámetro original (por ejemplo, el campo de encabezamiento de Servidor o Usuario-Agente), o se contiene en el contenido del mensaje SDP del formato de texto.
Realización 7. El EU como un llamante establece la sesión CS a través de CAMEL. La DTF asigna el identificador de transferencia y la ICCF entrega el identificador de transferencia a través del mensaje ICCF al EU. Con referencia a la Figura 10, el proceso incluye las siguientes etapas.
En las etapas 1-7, el EU inicia el flujo de establecimiento de la sesión para el usuario B en el dominio CS, la llamada de dominio CS se redirige a la ICCF a través de CAMEL y, aquí, la ICCF restablece el usuario B real llamado según un mensaje IDP activado a través de CAMEL para el SCP.
En las etapas 8-9, la ICCF convierte el mensaje en el mensaje de Invitación y envía la solicitud para invitar al usuario B, y el mensaje se activa para la DTF.
En las etapas 10-12, la DTF distribuye un identificador de transferencia de la sesión para la sesión, y envía la solicitud al usuario B llamado.
En las etapas 13-15, la DTF recibe el mensaje de reconocimiento del usuario B llamado, añade el identificador de transferencia al mensaje de reconocimiento, y continúa la devolución.
En las etapas 16-17, la ICCF recibe el mensaje de reconocimiento con el identificador de transferencia añadido de la DTF, y luego devuelve un identificador de control fijo especial (por ejemplo, siendo de manera fija 1) y el identificador de transferencia al EU mediante el uso del canal de mensaje ICCC.
En la etapa 18, después de adquirir el mensaje ICCF, dado que el identificador de control fijo siempre se asocia a la sesión de dominio CS que se establece, el EU adquiere y guarda la relación de asociación entre el identificador de transferencia y la sesión.
Notas:
El identificador de control de sesión especial puede ser, de forma fija, cierto valor negociado por la ICCF y el EU, y puede omitirse en el mensaje ICCC. Al mismo tiempo, con el fin de evitar cualquier confusión, cuando la sesión se establece en Interfuncionamiento, la ICCF rechazará nuevas sesiones.
La Figura 10 solo muestra que el identificador de transferencia se devuelve a la ICCF a través del mensaje 183 de reconocimiento, durante la aplicación práctica, el identificador de transferencia puede devolverse al EU a través de otros mensajes de reconocimiento como, por ejemplo, un mensaje 180 y un mensaje 200 OK.
El identificador de transferencia se contiene mediante la definición reciente de un campo de encabezamiento o un parámetro del mensaje SIP (por ejemplo, la definición reciente de un campo de encabezamiento DT-ID, o la adición reciente de un parámetro Transferencia-ID a un campo de encabezamiento A), o se contiene mediante la extensión del campo de encabezamiento o parámetro original (por ejemplo, el campo de encabezamiento de Servidor o Usuario-Agente), o se contiene en el contenido del mensaje SDP del formato de texto.
Realización 8. El EU como una llamada establece la sesión CS. La DTF asigna el identificador de transferencia y la ICCF entrega el identificador de transferencia a través del mensaje ICCF al EU. Con referencia a la Figura 11, el proceso incluye las siguientes etapas.
En las etapas 1-2, la DTF recibe una solicitud de sesión iniciada por un usuario remoto B al EU local.
En la etapa 3, la DTF distribuye un identificador de transferencia para la sesión.
En la etapa 4, la DTF añade el identificador de transferencia de la sesión al mensaje de Invitación.
En la etapa 5, el mensaje de Invitación se encamina hacia la ICCF.
En las etapas 6-7, la ICCF notifica a través del canal ICCC al EU que la nueva sesión se establecerá y contiene el identificador de control y el identificador de transferencia. En las etapas 8-9, el EU guarda el identificador de control y el identificador de transferencia.
Notas:
5 El identificador de transferencia se contiene mediante la definición reciente de un campo de encabezamiento o un parámetro del mensaje SIP (por ejemplo, la definición reciente de un campo de encabezamiento DT-ID, o la adición reciente de un parámetro Transferencia-ID a un campo de encabezamiento A), o se contiene mediante la extensión del campo de encabezamiento o parámetro original (por ejemplo, el campo de encabezamiento de Servidor o Usuario-Agente), o se contiene en el contenido del mensaje SDP del formato de texto.
10 Realización 9. El EU como un llamante establece la sesión IP-CAN. El EU asigna el identificador de transferencia y entrega el identificador de transferencia a la DTF. Con referencia a la Figura 12, el proceso incluye las siguientes etapas.
En las etapas 1-4, cuando el EU obtiene acceso a IP-CAN, el usuario necesita iniciar una sesión para B, aquí el EU distribuye un identificador de transferencia para la sesión, y envía el identificador de transferencia mediante la
15 contención del identificador de transferencia en un mensaje de Invitación.
En las etapas 5-6, la solicitud de establecimiento de sesión se encamina hacia la DTF, si la DTF descubre que es una nueva llamada, la DTF guarda el identificador de transferencia, elimina la información de identificador del mensaje de Invitación, y envía el mensaje al usuario B.
Notas:
20 El identificador de transferencia se contiene mediante la definición reciente de un campo de encabezamiento o un parámetro del mensaje SIP (por ejemplo, la definición reciente de un campo de encabezamiento DT-ID, o la adición reciente de un parámetro Transferencia-ID a un campo de encabezamiento A), o se contiene mediante la extensión del campo de encabezamiento o parámetro original (por ejemplo, el campo de encabezamiento de Servidor o Usuario-Agente), o se contiene en el contenido del mensaje SDP del formato de texto.
25 Realización 10. El EU como una llamada establece la sesión IP-CAN. El EU asigna el identificador de transferencia y entrega el identificador de transferencia a la DTF. Con referencia a la Figura 13, el proceso incluye las siguientes etapas.
En las etapas 1-5, la DTF recibe una solicitud de sesión iniciada por un usuario remoto B al EU local y encamina la solicitud hacia el EU.
30 En la etapa 6, el EU distribuye un identificador de transferencia para la sesión.
En las etapas 7-9, el EU añade el identificador de transferencia de la sesión al mensaje de reconocimiento del SIP, y envía el mensaje de reconocimiento a la DTF.
En las etapas 10-11, la DTF guarda un identificador de transferencia adquirido, elimina la información de identificador del mensaje de reconocimiento, y envía el mensaje al usuario B.
35 Notas:
La Figura 13 solo muestra que el identificador de transferencia se devuelve a la DTF a través del mensaje 183 de reconocimiento, durante la aplicación práctica, el identificador de transferencia puede devolverse a la DTF a través de otros mensajes de reconocimiento como, por ejemplo, un mensaje 180 y un mensaje 200 OK.
El identificador de transferencia no solo es un VDI/VDN dinámico, sino también un identificador independiente del
40 VDI/VDN, y puede distribuirse y entregarse mediante la contención usando la manera descrita en la presente realización. Las realizaciones subsiguientes son iguales a la presente realización y, por consiguiente, no se repiten aquí.
Realización 11. El EU como un llamante interactúa a través del mensaje USSD y establece la sesión CS. El EU asigna el identificador de transferencia y entrega directamente el identificador de transferencia al VCC AS a través
45 del mensaje ICCC. Con referencia a la Figura 14, el proceso incluye las siguientes etapas.
En la etapa 1, cuando el EU obtiene acceso a CS, el usuario necesita iniciar una sesión para B, y aquí el EU distribuye un identificador de transferencia para la sesión, y se prepara para iniciar la llamada.
En la etapa 2, el EU notifica a través del mensaje USSD al VCC AS que la nueva sesión para el extremo remoto se establecerá y notifica al VCC AS sobre el identificador de transferencia distribuido de la sesión.
En la etapa 3, después de recibir la notificación sobre el identificador de transferencia distribuido de la sesión del EU, el VCC AS guarda el identificador de transferencia de la sesión.
En la etapa 4, una portadora se establece entre el EU y el VCC AS, y la etapa y otras etapas pueden llevarse a cabo en paralelo o en cualquier secuencia. Cuando se ha establecido la portadora CS entre el EU y el VCC AS, esta 5 etapa es opcional.
En la etapa 5, el VCC AS continúa encaminando la solicitud de llamada hacia el siguiente salto hacia el usuario remoto B.
Notas:
En la etapa 2, además del mensaje USSD, el VCC AS y el EU pueden interactuar entre sí a través de otros 10 mensajes ICCC como, por ejemplo, un mensaje corto y una DTMF.
Realización 12. El EU como una llamada interactúa a través del mensaje USSD y establece la sesión CS. El EU asigna el identificador de transferencia y entrega directamente el identificador de transferencia al VCC AS a través del mensaje USSD. Con referencia a la Figura 15, el proceso incluye las siguientes etapas.
En la etapa 1, el VCC AS recibe una solicitud de sesión iniciada por un usuario remoto B a un EU local.
15 En la etapa 2, el VCC AS notifica a través del mensaje USSD al EU que el usuario remoto solicita establecer una sesión.
En la etapa 3, el EU distribuye un identificador de transferencia para la sesión.
En la etapa 4, el EU notifica a través del mensaje USSD al VCC AS que la nueva sesión para el extremo remoto se establecerá y notifica al VCC AS el identificador de transferencia de sesión distribuido correspondiente a la sesión. 20 Además del mensaje USSD, la DTF puede notificar al EU a través de otros mensajes ICCC como, por ejemplo, un mensaje corto y una DTMF.
En la etapa 5, después de recibir la notificación del identificador de transferencia de sesión distribuido del EU, el VCC AS guarda el identificador de transferencia de la sesión.
En la etapa 6, una portadora se establece entre el EU y el VCC AS, y la etapa y otras etapas pueden llevarse a cabo 25 en paralelo o en cualquier secuencia. Cuando se ha establecido la portadora CS entre el EU y el VCC AS, esta etapa es opcional.
En la etapa 7, el EU finaliza el proceso de establecimiento de la sesión con el usuario remoto a través del dominio CS y el VCC AS.
Notas:
30 En las etapas 2 y 4, además del mensaje USSD, el VCC AS y el EU pueden interactuar entre sí a través de otros mensajes ICCC como, por ejemplo, el mensaje corto y la DTMF.
Realización 13. El EU como un llamante establece la sesión CS y el EU asigna y entrega el identificador de transferencia a la DTF a través del mensaje ICCC. Con referencia a la Figura 16, el proceso incluye las siguientes etapas.
35 En las etapas 1-2, cuando el EU obtiene acceso al dominio CS, el usuario necesita iniciar una sesión para B, aquí el EU distribuye un identificador de transferencia para la sesión, y envía el identificador de transferencia mediante la contención del identificador de transferencia en la solicitud de establecimiento de llamada. Según la manera de establecimiento de la sesión, el EU puede entregar el identificador de transferencia de sesión a la ICCF de varias formas, y las realizaciones 15-18 muestran varias maneras posibles.
40 En las etapas 3-4, la ICCF en el trayecto de encaminamiento recibe la solicitud de llamada, y lleva a cabo la conversión según la demanda, para asegurar que el identificador de transferencia se envía a la DTF mediante su contención en el mensaje SIP.
En las etapas 5-6, la solicitud de establecimiento de sesión se encamina hacia la DTF, si la DTF descubre que es una nueva llamada, la DTF guarda el identificador de transferencia, elimina la información de identificador del 45 mensaje de Invitación, y envía el mensaje al usuario B.
Notas:
El EU notifica a la ICCF mediante la contención del identificador de transferencia a través de un mensaje ICCC, o a través de la información de usuario (UUI). 13
El identificador de transferencia se contiene mediante la definición reciente de un campo de encabezamiento o un parámetro del mensaje SIP (por ejemplo, la definición reciente de un campo de encabezamiento DT-ID, o la adición reciente de un parámetro Transferencia-ID a un campo de encabezamiento A), o se contiene mediante la extensión del campo de encabezamiento o parámetro original (por ejemplo, el campo de encabezamiento de Servidor o Usuario-Agente), o se contiene en el contenido del mensaje SDP del formato de texto.
Realización 14. El EU como una llamada establece la sesión CS y el EU asigna y entrega el identificador de transferencia a la DTF a través del mensaje ICCC. Con referencia a la Figura 17, el proceso incluye las siguientes etapas.
En las etapas 1-5, la DTF recibe una solicitud de sesión iniciada por un usuario remoto B al EU local y encamina la solicitud hacia el EU a través de la ICCF.
En la etapa 6, el EU distribuye un identificador de transferencia para la sesión.
En la etapa 7, el EU añade el identificador de transferencia de la sesión al mensaje de reconocimiento del ICCC, y envía el mensaje de reconocimiento a la ICCF.
En las etapas 8-11, si se requiere que una portadora de dominio CS se establezca entre la ICCF y el EU en la sesión, el EU devuelve el reconocimiento de Alerta durante el proceso de establecimiento de portadora.
En la etapa 12, después de adquirir el reconocimiento del EU, la ICCF añade el identificador de transferencia al mensaje 180, y devuelve el reconocimiento al usuario B.
En las etapas 13-15, el mensaje de reconocimiento se encamina hacia la DTF; la DTF guarda el identificador de transferencia adquirido, elimina la información de identificador del mensaje de reconocimiento, y envía el mensaje al usuario B.
Notas:
Si no es necesario establecer la portadora de dominio CS, las etapas 8-11 son opcionales, y el identificador de transferencia se devuelve directamente en el mensaje de reconocimiento ICCC.
La Figura 17 solo muestra que el identificador de transferencia se devuelve al EU a través del mensaje 180 de reconocimiento, durante la aplicación práctica, el identificador de transferencia puede devolverse al EU a través de otros mensajes de reconocimiento como, por ejemplo, un mensaje 200 OK.
El identificador de transferencia se contiene mediante la definición reciente de un campo de encabezamiento o un parámetro del mensaje SIP (por ejemplo, la definición reciente de un campo de encabezamiento DT-ID, o la adición reciente de un parámetro Transferencia-ID a un campo de encabezamiento A), o se contiene mediante la extensión del campo de encabezamiento o parámetro original (por ejemplo, el campo de encabezamiento de Servidor o Usuario-Agente), o se contiene en el contenido del mensaje de protocolo de descripción de sesión (SDP, por sus siglas en inglés) del formato de texto.
Realización 15. El EU entrega el identificador de transferencia a la ICCF en la forma de ICCC. Con referencia a la Figura 18, el proceso incluye las siguientes etapas.
En la etapa 1, el EU notifica a la ICCF mediante la contención del identificador de transferencia de la sesión a través del canal ICCC.
En las etapas 2-4, la ICCF adquiere el identificador de transferencia a través del mensaje ICCC, si el mensaje ICCC se asocia a una sesión existente, la ICCF necesita adquirir la sesión correcta del identificador de control en el mensaje ICCC, luego notifica a la DTF mediante la contención del identificador de transferencia en el mensaje SIP en la sesión.
La presente realización puede ser aplicable a la etapa 2 en la Realización 13.
Realización 16. El EU entrega el identificador de transferencia a la ICCF en la forma de activación IDP de la UUI. Con referencia a la Figura 19, el proceso incluye las siguientes etapas.
En la etapa 1, el EU contiene una célula UUI en el mensaje ESTABLECIMIENTO de iniciación de sesión, y el contenido UUI es el identificador de transferencia de la sesión.
En la etapa 2, el centro de transferencia móvil (MSC, por sus siglas en inglés) activa un servicio inteligente CAMEL, y notifica a la ICCF a través del mensaje IDP después de atravesar el SCP.
En las etapas 3-6, la ICCF notifica al MSC que se redirija a PSI de la ICCF, y luego se encamine hacia la ICCF
mediante el establecimiento del interfuncionamiento de llamada entre el dominio CS y el IMS. En las etapas 7-9, la ICCF convierte el mensaje en el mensaje SIP según el identificador de transferencia en el mensaje IDP grabado, y notifica a la DTF mediante la contención del identificador de transferencia en el mensaje
5 SIP. Notas: Si la ICCF no se despliega en la red, el SCP y la DTF interactúan directamente entre sí, y la dirección distribuida
cambiada es PSI de la DTF. La presente realización puede ser aplicable a la etapa 2 en la Realización 13.
10 La presente realización puede ser aplicable a la Realización 21, y se adapta para entregar el identificador de transferencia (en las etapas 1-7). Realización 17. El EU entrega el identificador de transferencia a la ICCF en la forma de conversión MGCF de la UUI.
Con referencia a la Figura 20, el proceso incluye las siguientes etapas. En las etapas 1-2, el EU contiene una célula UUI en el mensaje ESTABLECIMIENTO de iniciación de sesión, y el
15 contenido UUI es el identificador de transferencia de la sesión. El mensaje se reenvía a la MGCF después de atravesar el MSC. En la etapa 3, la MGCF convierte el mensaje ISUP que contiene el mensaje UUI en el mensaje SIP. En las etapas 4-6, el mensaje SIP se encamina hacia la ICCF, la ICCF determina que el contenido UUI contenido en
el mensaje SIP es el identificador de transferencia, para notificar a la DTF después de la conversión para contener el 20 identificador de transferencia en otro mensaje SIP de campo de encabezamiento, o notificar a la DTF mediante la contención del identificador de transferencia en la UUI sin conversión. Notas: Si la ICCF no se despliega en la red, el mensaje SIP convertido por la MGCF directamente alcanza la DTF. La presente realización puede ser aplicable a la etapa 2 en la Realización 13. 25 La presente realización puede ser aplicable a la Realización 21, y se adapta para entregar el identificador de
transferencia (en las etapas 1-7). Realización 18. El EU entrega el identificador de transferencia a la ICCF en la forma de conversión MGCF de la subdirección. Con referencia a la Figura 21, el proceso incluye las siguientes etapas.
En las etapas 1-2, el EU contiene la subdirección en el mensaje ESTABLECIMIENTO de iniciación de sesión, y la 30 subdirección es el identificador de transferencia de la sesión. El mensaje se reenvía a la MGCF después de atravesar el MSC. En la etapa 3, la MGCF convierte el mensaje ISUP que contiene la subdirección en el mensaje SIP. En las etapas 4-6, el mensaje SIP se encamina hacia la ICCF y se reenvía a la DTF. Notas:
35 Si la ICCF no se despliega en la red, el mensaje SIP convertido por la MGCF directamente alcanza la DTF. Además de la subdirección, las diferentes direcciones llamadas capaces de encaminarse hacia la DTF pueden directamente usarse entre el EU y la DTF, para identificar las diferentes transferencias llevadas a cabo en la sesión diferente, y el proceso de conversión es similar, por consiguiente, no se repite aquí.
La presente realización puede ser aplicable a la etapa 2 en la Realización 13.
40 La presente realización puede ser aplicable a la Realización 21, y se adapta para entregar el identificador de transferencia (en las etapas 1-7). Realización 19. El EU inicia una transferencia multisesión de IP-CAN al dominio CS y entrega el identificador de
transferencia a la ICCF a través de la ICCF. El EU establece la sesión a través de VDN y CAMEL. Con referencia a la Figura 22, el proceso incluye las siguientes etapas.
5
10
15
20
25
30
35
40
45
En las etapas 1-4, el EU notifica a través del canal ICCC a la ICCF que una nueva sesión se establecerá y contiene el identificador de transferencia de la sesión. Aquí, la ICCF distribuye un identificador de control particular para la sesión, y devuelve el identificador de control al EU mediante la contención del identificador de control en el mensaje de reconocimiento del ICCC. El EU guarda el identificador de control.
En las etapas 5-11, el EU inicia un flujo de establecimiento de sesión para el VDN de la DTF en el dominio CS, la llamada de dominio CS se redirige a la ICCF a través de CAMEL y, aquí, la ICCF restablece la parte real llamada según un mensaje IDP activado para el SCP a través de CAMEL.
En las etapas 12-13, la ICCF convierte el mensaje en el mensaje de Invitación, envía la solicitud a la DTF, y contiene el identificador de transferencia enviado desde el EU.
En la etapa 14, la DTF determina que la solicitud de transferencia es una solicitud de transferencia para un tramo de sesión existente según el destino del mensaje de Invitación que es el propio VDN y el identificador de transferencia contenido.
En la etapa 15, aquí, la DTF actualiza la información de tramo de acceso, e inicia una negociación de medios con el usuario remoto.
En la etapa 16, la DTF libera el antiguo tramo de acceso IP-CAN.
Notas:
Cuando se ha establecido la portadora de dominio CS entre el EU y la ICCF, las etapas 5-11 son opcionales.
El identificador de transferencia puede entregarse junto con cierto mensaje de establecimiento inicial de sesión específico como un mensaje (por ejemplo, el mensaje de Invitación del SIP o el mensaje de establecimiento de sesión similar en el ICCC), y puede también entregarse en el mensaje de proceso de establecimiento de sesión (por ejemplo, el mensaje 180 SIP o el mensaje similar en el ICCC), o se entrega como un mensaje independiente (por ejemplo, la Información SIP o el mensaje similar en el ICCC). Las realizaciones subsiguientes son iguales a la presente realización y, por consiguiente, no se repiten aquí.
El identificador de transferencia se contiene mediante la definición reciente de un campo de encabezamiento o un parámetro del mensaje SIP (por ejemplo, la definición reciente de un campo de encabezamiento DT-ID, o la adición reciente de un parámetro Transferencia-ID a un campo de encabezamiento A), o se contiene mediante la extensión del campo de encabezamiento o parámetro original (por ejemplo, el campo de encabezamiento Reemplazar), o se contiene en el contenido del mensaje SDP del formato de texto.
Realización 20. El EU inicia una transferencia multisesión de la IP-CAN al dominio CS y entrega el identificador de transferencia y VDN a la ICCF. El EU establece la sesión a través de VDN y CAMEL. Con referencia a la Figura 23, el proceso incluye las siguientes etapas.
En las etapas 1-4, el EU inicia el flujo de establecimiento de la portadora de dominio CS para la ICCF en el dominio CS.
En las etapas 5-8, el EU notifica a través del canal ICCC a la ICCF que una sesión para el VDN de la DTF se establecerá. Aquí, la ICCF distribuye un identificador de control particular para la sesión, y devuelve el identificador de control al EU mediante la contención del identificador de control en el mensaje de reconocimiento del ICCC. El EU guarda el identificador de control.
En las etapas 9-11, la ICCF adquiere el VDN real llamado de la notificación del ICCC, convierte el mensaje en el mensaje de Invitación y envía el identificador de transferencia a la DTF mediante la contención del identificador de transferencia en el mensaje de Invitación.
En la etapa 12, la DTF determina que la solicitud de transferencia es una solicitud de transferencia para un tramo de sesión existente según el destino del mensaje de Invitación que es el propio VDN y el identificador de transferencia contenido.
En la etapa 13, aquí, la DTF actualiza la información de tramo de acceso, e inicia una negociación de medios con el usuario remoto.
En la etapa 14, la DTF libera el antiguo tramo de acceso IP-CAN.
Notas:
Cuando se ha establecido la portadora de dominio CS entre el EU y la ICCF, las etapas 1-4 son opcionales.
El identificador de transferencia se contiene mediante la definición reciente de un campo de encabezamiento o un parámetro del mensaje SIP (por ejemplo, la definición reciente de un campo de encabezamiento DT-ID, o la adición reciente de un parámetro Transferencia-ID a un campo de encabezamiento A), o se contiene mediante la extensión del campo de encabezamiento o parámetro original (por ejemplo, el campo de encabezamiento Reemplazar), o se contiene en el contenido del mensaje SDP del formato de texto.
Realización 21. El EU inicia una transferencia multisesión de IP-CAN al dominio CS y entrega el identificador de transferencia y VDN a la ICCF a través de la UUI y CAMEL. El EU establece la sesión a través de VDN y CAMEL. Con referencia a la Figura 24, el proceso incluye las siguientes etapas.
En la etapa 1, el EU inicia la llamada al VDN de la DTF en el dominio CS, y contiene el identificador de transferencia a través de la célula UUI del mensaje Establecimiento.
En las etapas 2-7, la llamada se activa a través de CAMEL en el MSC, y la llamada de dominio CS se redirige a la ICCF, aquí, la ICCF restablece el VDN llamado real y el identificador de transferencia contenido en la UUI según un mensaje IDP activado a través de CAMEL al SCP.
En las etapas 8-9, la ICCF convierte el mensaje en el mensaje de Invitación y envía el identificador de transferencia a la DTF mediante la contención del identificador de transferencia en el mensaje de Invitación.
En la etapa 10, la DTF determina que la solicitud de transferencia es una solicitud de transferencia para un tramo de sesión existente según el destino del mensaje de Invitación que es el propio VDN y el identificador de transferencia contenido.
En la etapa 11, aquí, la DTF actualiza la información de tramo de acceso, e inicia una negociación de medios con el usuario remoto.
En la etapa 12, la DTF libera el antiguo tramo de acceso IP-CAN.
Notas:
El identificador de transferencia se contiene mediante la definición reciente de un campo de encabezamiento o un parámetro del mensaje SIP (por ejemplo, la definición reciente de un campo de encabezamiento DT-ID, o la adición reciente de un parámetro Transferencia-ID a un campo de encabezamiento A), o se contiene mediante la extensión del campo de encabezamiento o parámetro original (por ejemplo, el campo de encabezamiento Reemplazar), o se contiene en el contenido del mensaje SDP del formato de texto.
La presente realización solo muestra que el identificador de transferencia se contiene en la UUI y se activa para la ICCF a través del IDP, durante la aplicación práctica, cualquiera de las maneras de realización en las Realizaciones 16-18 pueden usarse.
Realización 22. El EU inicia una transferencia multisesión del dominio CS a IP-CAN y entrega el identificador de transferencia a la DTF a través de SIP. Con referencia a la Figura 25, el proceso incluye las siguientes etapas.
En las etapas 1-3, el EU inicia la llamada al VDI de la DTF en el dominio IP-CAN, y contiene el identificador de transferencia. El mensaje de Invitación se encamina hacia la DTF según la información de abono.
En la etapa 4, la DTF determina que la solicitud de transferencia es una solicitud de transferencia para un tramo de sesión existente según el destino del mensaje de Invitación que es el propio VDN y el identificador de transferencia contenido.
En la etapa 5, aquí, la DTF actualiza la información de tramo de acceso, e inicia una negociación de medios con el usuario remoto.
En la etapa 6, la DTF libera el antiguo tramo de acceso IP-CAN u otros tramos de acceso IP-CAN originales.
Notas:
El identificador de transferencia se contiene mediante la definición reciente de un campo de encabezamiento o un parámetro del mensaje SIP (por ejemplo, la definición reciente de un campo de encabezamiento DT-ID, o la adición reciente de un parámetro Transferencia-ID a un campo de encabezamiento A), o se contiene mediante la extensión del campo de encabezamiento o parámetro original (por ejemplo, el campo de encabezamiento Reemplazar), o se contiene en el contenido del mensaje SDP del formato de texto.
La sesión no solo se transfiere entre el dominio de circuito y el dominio de paquete, sino que también se transfiere entre diferentes IP-CAN. La transferencia entre diferentes dominios de acceso por paquetes diferentes también se llama transferencia de dominio en la presente invención. Otras realizaciones son iguales a la presente realización y, por consiguiente, no se repiten aquí.
Realización 23. El identificador de transferencia por defecto se adapta para transferir una sesión. Con referencia a la Figura 26, el proceso incluye las siguientes etapas.
5 Configurándose con antelación o a través de otros medios, si el VCC AS no asigna el identificador de transferencia de sesión para la sesión y notifica al EU, el EU usa el valor nulo (u otros valores por defecto) al igual que la configuración en el VCC AS como el identificador de transferencia por defecto de la sesión.
En la etapa 1, el VCC AS recibe una solicitud de sesión iniciada por un usuario remoto B al EU-A local.
En la etapa 2, según la determinación de que aquí el EU-A no tiene la sesión u otro resultado de determinación, el
10 VCC AS no asigna un identificador de transferencia distinto para la sesión, sino que usa el valor nulo por defecto como el identificador de transferencia de la sesión. El identificador de transferencia por defecto no se entrega al EU.
En la etapa 3, según el resultado de selección de dominio, el VCC AS entrega la solicitud de llamada al EU a través del dominio CS. La solicitud de llamada puede entregarse en forma de Interfuncionamiento o en forma de interacción USSD. La solicitud de establecimiento de llamada no incluye el identificador de transferencia por defecto de la
15 sesión (el mensaje puede no contener el parámetro que identifica el identificador de transferencia, o puede contener el parámetro pero el valor del parámetro es nulo).
En la etapa 4, el EU recibe una nueva solicitud de establecimiento de sesión, y aquí el VCC AS no distribuye el identificador de transferencia para la sesión, de modo que el EU usa, de forma similar, el valor nulo por defecto como el identificador de transferencia de la sesión.
20 En la etapa 5, el EU-A finaliza el establecimiento de la portadora y la sesión con el Usuario Remoto B a través del dominio CS y el VCC AS, etc.
Aquí, una sesión se establece entre el EU-A y el Usuario Remoto-B en el dominio CS.
En la etapa 6, el VCC AS recibe una solicitud de sesión iniciada por otro usuario remoto, Usuario Remoto C, al EU local.
25 En la etapa 7, el VCC AS distribuye un identificador de transferencia S1 para la sesión.
En la etapa 8, el VCC AS notifica a través del mensaje USSD al EU-A que una sesión se establecerá y el identificador de transferencia de sesión S1 correspondiente a la sesión.
En la etapa 9, después de recibir la notificación del identificador de transferencia de sesión distribuido del VCC AS, el EU guarda el identificador de transferencia de sesión S1.
30 En la etapa 10, el EU-A finaliza el establecimiento de la portadora y sesión con el Usuario Remoto C remoto a través del dominio CS y el VCC AS, etc.
Aquí, dos sesiones se establecen entre el EU-A y el Usuario Remoto-B y entre el EU-A y el Usuario Remoto-C en el dominio CS al mismo tiempo.
En la etapa 11, se cambia el entorno de acceso subsiguiente y el EU-A inicia la solicitud de transferencia de dominio
35 en el dominio PS. El EU-A determina iniciar la transferencia de la sesión entre el EU-A y el Usuario Remoto-B al dominio PS, y la sesión usa el identificador de transferencia nulo por defecto, de modo que el EU-A no contiene el identificador de transferencia en la solicitud de transferencia (el mensaje no contiene el parámetro que identifica el identificador de transferencia, o contiene el parámetro pero el valor del parámetro es nulo).
En la etapa 12, después de que la solicitud alcanza el VCC AS, el VCC AS restablece la sesión correcta según el
40 identificador de control guardado y el identificador de transferencia. Aquí, la solicitud de transferencia no contiene el identificador de transferencia, de modo que el VCC AS logra que la solicitud de transferencia solicite transferir la sesión entre el EU-A y el Usuario Remoto-B a través de la concordancia mediante el uso del identificador de transferencia nulo por defecto.
En la etapa 13, el VCC AS coordina finalizar el establecimiento del nuevo tramo de sesión, la actualización del 45 puerto de medios, y la liberación del antiguo tramo de sesión, etc.
Aquí, la sesión entre el EU-A y el Usuario Remoto-B en el dominio CS se transfiere al dominio PS.
En la etapa 14, el EU-A inicia la transferencia de sesión entre el EU-A y el Usuario Remoto-C al dominio PS. El EU-A contiene el identificador de transferencia S1 correspondiente a la sesión en la solicitud de transferencia.
En la etapa 15, después de que la solicitud alcanza el VCC AS, el VCC AS restablece la sesión correcta según el identificador de control guardado y el identificador de transferencia. Aquí, la solicitud de transferencia contiene el identificador de transferencia S1, de modo que el VCC AS logra que la solicitud de transferencia solicite transferir la sesión entre el EU-A y el Usuario Remoto-C a mediante la concordancia.
5 En la etapa 16, el VCC AS coordina finalizar el establecimiento del nuevo tramo de sesión, la actualización del puerto de medios, y la liberación del antiguo tramo de sesión, etc.
Aquí, las dos sesiones del EU-A se transfieren al dominio PS.
Notas:
Además del mensaje USSD, el VCC AS y el EU pueden interactuar entre sí a través de otros mensajes ICCC como, 10 por ejemplo, un mensaje corto y una DTMF.
El establecimiento de sesión de las dos sesiones puede llevarse a cabo en paralelo o en cualquier secuencia. La transferencia de sesión de las dos sesiones puede también llevarse a cabo en paralelo o en cualquier secuencia.
La situación del EU que distribuye el identificador de transferencia de sesión o que transfiere la sesión del dominio PS al CS es similar a la de más arriba y, por consiguiente, no se repite aquí.
15 Realización 24. La ICCF lleva a cabo una adaptación de conversión de identificador de comunicación (CID, por sus siglas en inglés)/identificador tipo silo (STID, por sus siglas en inglés) con el fin de transferir la sesión. Con referencia a la Figura 27, el proceso incluye las siguientes etapas.
En la etapa 1, la DTF recibe una solicitud de sesión iniciada por un usuario remoto B al EU local.
En la etapa 2, la DTF distribuye un identificador de transferencia para la sesión.
20 En la etapa 3, la DTF entrega el identificador de transferencia distribuido de la sesión a la dirección de EU mediante la contención del identificador de transferencia en el mensaje SIP.
En la etapa 4, después de entregar el mensaje a la ICCF, la ICCF genera un identificador de control de sesión correspondiente al identificador de transferencia de sesión, y guarda una relación correspondiente entre el identificador de transferencia y el identificador de control.
25 En la etapa 5, el identificador de control se entrega y la sesión CS se establece entre la ICCF y el EU.
En la etapa 6, el EU guarda el identificador de control correspondiente a la sesión.
En la etapa 7, se cambia el entorno de acceso subsiguiente y el EU inicia la solicitud de transferencia de dominio mediante la contención del identificador de control de la sesión en el dominio PS.
En la etapa 8, después de que la solicitud alcanza la ICCF, la ICCF restablece el identificador de transferencia de la 30 sesión según la correspondiente relación guardada entre el identificador de control y el identificador de transferencia.
En la etapa 9, la ICCF envía el identificador de transferencia de la sesión a la DTF mediante la contención del identificador de transferencia en el mensaje SIP.
En la etapa 10, después de recibir la solicitud de transferencia, la DTF compara el identificador de transferencia de la sesión, identifica la sesión que se transferirá, y finaliza el establecimiento y la actualización del nuevo tramo de 35 sesión, etc.
Notas:
La presente realización solo muestra la situación en la que la sesión se establece en el dominio CS y se transfiere al dominio PS, y la situación en la que la sesión se establece en el dominio PS y se transfiere al dominio CS es igual a la descrita más arriba.
40 La presente realización solo muestra la situación en la que la DTF distribuye el identificador de transferencia, y la situación en la que el EU distribuye el identificador de transferencia es igual a la descrita más arriba.
Realización 25. La multisesión transferida de IP-CAN al dominio CS, y el proceso en el puerto de medios llevado a cabo por la ICCF se describen.
Cuando el EU transfiere múltiples sesiones de IP-CAN al dominio CS, una portadora de dominio CS se establece 45 entre el EU y la ICCF, entonces es necesario resolver el problema de la conexión de medios entre la portadora de dominio CS y los múltiples usuarios remotos. La presente realización describe principalmente el proceso de
procesamiento de medios llevado a cabo por la ICCF y el flujo de iniciación de transferencia puede ser cualquiera de las realizaciones de más arriba.
El EU-A establece dos sesiones con el EU-B y el EU-C en el dominio IP-CAN, la sesión A-B se encuentra en un estado activado y la sesión A-C se encuentra en un estado de espera. Con referencia a la Figura 28, el proceso 5 incluye las siguientes etapas.
En las etapas 1-4, el EU inicia una primera solicitud de transferencia de sesión en el dominio CS y contiene el identificador de transferencia de la sesión A-B, dado que la portadora de dominio CS no existe, el EU inicia el establecimiento de la portadora de dominio CS al mismo tiempo, y la solicitud de transferencia se encamina primero hacia la ICCF.
10 En la etapa 5, la ICCF contiene la información de medios MGW y el identificador de transferencia durante el proceso de establecimiento de la portadora de dominio CS, y envía a la DTF el mensaje de Invitación.
En las etapas 6-13, la DTF identifica que el tramo de sesión de la sesión A-B se transferirá según el identificador de transferencia, para iniciar la negociación con el usuario B, y el tramo de sesión de IP-CAN se libera después de establecer el tramo de acceso del dominio CS.
15 Aquí, los medios de la sesión A-B establecen la conexión a través de la portadora de dominio CS y se encuentran en el estado activado, y los medios de la sesión A-C se conectan a través de IP-CAN y se encuentran en el estado de espera.
En la etapa 14, el EU inicia una segunda solicitud de transferencia en el dominio CS, contiene el identificador de transferencia de la sesión A-C e indica que la sesión se encuentra en el estado de ESPERA.
20 En las etapas 15-17, después de que la ICCF recibe la solicitud de transferencia de sesión, una sesión ha existido en el dominio CS, de modo que el puerto MGW no puede adaptarse directamente para establecer la conexión de medios con el EU-C, entonces aquí la ICCF necesita aplicar el puerto para cada parte de la sesión en un servidor de recursos de medios (MRS, por sus siglas en inglés).
En la etapa 18, la ICCF contiene la información de porción de medios distribuida para el EU-C y asigna el atributo de 25 medio a Inactivo, y al identificador de transferencia, y los envía a la DTF a través del mensaje de Invitación.
En las etapas 19-26, la DTF identifica que el tramo de sesión de la sesión A-C se transferirá según el identificador de transferencia, para iniciar la negociación con el usuario C, y el tramo de sesión de IP-CAN se libera después de establecer el tramo de acceso del dominio CS.
Aquí, los medios de la sesión A-B establecen la conexión a través de la portadora de dominio CS y se encuentran en
30 el estado activado, y en los medios de la sesión A-C, el EU-C se conecta al MRS y se encuentra en el estado de espera.
En las etapas 27-31, posteriormente, el EU necesita llamar al usuario C y mantener la llamada con el usuario B, para iniciar una solicitud de control de servicio suplementario de sesión de ESPERA a la ICCF a través del ICCC. Después de que la ICCF recibe el mensaje, los medios MGW se redirigen hacia el MRS, el tren de medios del EU-B
35 se redirige hacia el MRS y se modifica al estado no activado, los medios del EU-C al MRS se activan, y los puertos conectados a MGW y al EU-C en el MRS se conectan.
Aquí, los medios de la sesión A-C establecen la conexión a través de la portadora de dominio CS y el MRS y se encuentran en el estado activado, y en los medios de la sesión A-B, el EU-B se conecta al MRS y se encuentra en el estado de espera.
40 Notas:
El usuario inicia la solicitud de transferencia en el dominio CS a través no solo de la manera en el dibujo sino también de cualquiera de las maneras de establecimiento de las realizaciones de más arriba.
Las etapas 15-17 pueden llevarse a cabo en paralelo en cualquier secuencia.
El MRS en la Figura 28 puede ser un procesador de función de recursos multimedia (MRFP, por sus siglas en
45 inglés) controlado por un controlador de función de recursos multimedia (MRFC, por sus siglas en inglés), o puede ser la MGW controlada por la MGCF. Cuando el MRS en el dibujo es la MGW, la conexión entre la MGW y el MRS en el flujo de más arriba es una conexión interna, y la presente etapa es opcional.
En la Figura 28, el puerto aplicado en el MRS puede ser el puerto independiente o el puerto conectado al mismo recurso de mezcla de audio. Cuando es el puerto conectado al mismo recurso de mezcla de audio, el proceso de
50 conexión de los puertos P-C y P-M es opcional.
5
10
15
20
25
30
35
40
45
50
La presente realización describe el proceso en el puerto de medios llevado a cabo por la ICCF cuando múltiples sesiones se transfieren de IP-CAN a CS. También es aplicable a la situación en la que una sesión existe en el dominio CS, y una sesión subsiguiente se transfiere de IP-CAN a CS.
Realización 26. La multisesión transferida del dominio CS a IP-CAN, y el proceso en el puerto de medios llevado a cabo por la ICCF se describen.
El EU-A establece las dos sesiones con el EU-B y el EU-C en el dominio CS, la sesión A-B se encuentra en un estado activado y la sesión A-C se encuentra en un estado de espera. Con referencia a la Figura 29, el proceso incluye las siguientes etapas.
En la etapa 1, el EU inicia una primera solicitud de transferencia de sesión en IP-CAN, y contiene el identificador de transferencia de la sesión A-B.
En las etapas 2-6, la DTF identifica que el tramo de sesión de la sesión A-B se transferirá según el identificador de transferencia, para iniciar la negociación con el usuario B, y después de establecer el tramo de acceso de IP-CAN, el mensaje Adiós se envía para liberar el tramo de sesión del dominio CS.
En las etapas 7-8, aquí, después de recibir el mensaje Adiós, la ICCF libera el puerto P-B del usuario B al MRS en la sesión original A-B en el dominio CS, y notifica al EU-A a través del canal ICCC que la sesión A-B se libera.
Aquí, los medios de la sesión A-B establecen la conexión de extremo a extremo a través de la portadora IP-CAN y se encuentran en el estado activado, y los medios de la sesión A-C se conectan a través de IP-CAN y MRS y se encuentran en el estado de espera.
En la etapa 9, el EU inicia una segunda solicitud de transferencia en IP-CAN, contiene el identificador de transferencia de la sesión A-C e indica que la sesión se encuentra en el estado de ESPERA en los medios provistos por el EU.
En las etapas 10-14, la DTF identifica que el tramo de sesión de la sesión A-C se transferirá según el identificador de transferencia, para iniciar la negociación de medios con el usuario C, y después de establecer el tramo de acceso de IP-CAN, el mensaje Adiós se envía para liberar el tramo de sesión del dominio CS.
En las etapas 15-19, después de recibir el mensaje Adiós, la ICCF libera el puerto P-C del usuario C para el MRS en la sesión original A-C en el dominio CS, después determina que el dominio CS no tiene la sesión, la ICCF libera el puerto P-M conectado a MGW en el MRS, y envía el mensaje Adiós a la MGCF. Después de recibir el mensaje Adiós, la MGCF inicia la eliminación de los medios, convierte el mensaje en el mensaje ISUP, e inicia la eliminación de sesión para el dominio de circuito del EU-A.
Aquí, los medios de la sesión A-B establecen la conexión de extremo a extremo a través de IP-CAN y se encuentran en el estado activado, y los medios de la sesión A-C establecen la conexión de extremo a extremo a través de IP-CAN y se encuentran en el estado no activado, y los recursos de portadora del dominio CS se liberan.
En resumen, en las realizaciones de la presente invención, el AS de transferencia de dominio recibe el mensaje de solicitud de transferencia de dominio que contiene el identificador de transferencia. El AS de transferencia de dominio adquiere el identificador de transferencia del mensaje de solicitud de transferencia de dominio, y lleva a cabo la transferencia de dominio en la sesión correspondiente según el identificador de transferencia. Por lo tanto, la ubicación y transferencia de dominio en la sesión que se transferirá llevadas a cabo por el AS de transferencia de dominio se llevan a cabo.
Además, en las realizaciones de la presente invención, se describen, en varias situaciones, los flujos detallados de la distribución del identificador de transferencia, la entrega del identificador de transferencia, la grabación de la relación de asociación entre la sesión y el identificador de transferencia llevada a cabo por la terminal de usuario, la ubicación de la sesión llevada a cabo por la DTF cuando se inicia la transferencia, y la transferencia de dominio llevada a cabo en la sesión ubicada por la DTF.
Asimismo, se provee además la solución de diferenciación de múltiples sesiones entre la ICCF y el EU cuando el EU tiene múltiples sesiones.
Se provee además cómo aplicar el puerto de recursos de medios cuando las múltiples sesiones que comparten una portadora de dominio CS se transfieren al dominio CS, para resolver el problema de cómo conectar el puerto MGW con múltiples puertos de medios remotos.
Durante la implementación de la presente invención, el primer identificador se adapta para identificar la sesión en la terminal de usuario, el segundo identificador se adapta para identificar la sesión en el AS de transferencia de dominio, y se establece una relación de mapeo entre el primer identificador y el segundo identificador. Cuando la terminal de usuario inicia la transferencia de sesión, el primer identificador se contiene en la solicitud de transferencia de sesión, el AS de transferencia de dominio determina el segundo identificador correspondiente al primer identificador según la relación de mapeo. El AS de transferencia de dominio lleva a cabo la transferencia después de determinar la sesión según el segundo identificador. La sesión se refiere principalmente a la sesión IMS y/o a la sesión CS.
5 El identificador de sesión usado durante la implementación lleva a cabo el identificador mediante el uso de una cantidad de secuencia de establecimiento de sesión de un usuario, pero la cantidad de secuencia no es en general única sino que solamente es del usuario, entonces durante el uso, el identificador de usuario se añade para llevar a cabo el identificador. Además, cuando el usuario tiene múltiples terminales, es necesario añadir un identificador de terminal, para finalmente determinar una única sesión. La cantidad de secuencia de establecimiento de sesión de un
10 usuario se define según la secuencia de generación de sesión en una terminal en la sesión del dominio IMS, y la cantidad de secuencia de la sesión en el dominio CS puede indicarse mediante 0 o la sesión CS se indica directamente por el identificador de usuario.
Es decir, durante la implementación, primero se requiere la cantidad de secuencia en el identificador de sesión, luego se requiere el identificador de usuario y finalmente se requiere el identificador de terminal. Durante la 15 implementación, el identificador de material positivo (PMI, por sus siglas en inglés) se usa como el identificador de terminal, para asegurar que la sesión puede llevar a cabo el identificador único en cada capa y cada condición de aplicación. Según el mismo objetivo, de manera diferente, durante la implementación, puede usarse un identificador de terminal general, por ejemplo, una sesión se identifica mediante el uso de un instancia-id y cantidad de secuencia de establecimiento de sesión, o la sesión se identifica mediante el uso de una identidad internacional de equipo
20 móvil (IMEI, por sus siglas en inglés), número de serie electrónico (ESN, por su siglas en inglés), u otros identificadores únicos generales.
Durante la implementación, la cantidad de secuencia puede generarse, respectivamente, por los dos extremos sin la interacción (por ejemplo, el establecimiento de la sesión en el dominio CS), o puede generarse por un extremo, y enviarse al usuario remoto (por ejemplo, el establecimiento de la sesión en el dominio IMS).
25 El identificador de usuario puede ser IMPU en el dominio IMS, puede ser una estación móvil de red digital de servicios integrados internacionales (MSISDN, por sus siglas en inglés) o un directorio móvil (MDN) (en la red de acceso múltiple por división de código (CDMA, por sus siglas en inglés)) en el dominio CS para llevar a cabo el identificador.
Cuando se describe la implementación detallada de la presente invención, en primer lugar, se describe el flujo de la
30 implementación, luego se describe la implementación de cada etapa y finalmente se describen además las realizaciones detalladas.
Con referencia a la Figura 30, se muestra una vista esquemática de un flujo de implementación de un método para proveer una transferencia multisesión en forma de acceso múltiple, y el método incluye las siguientes etapas.
En la etapa 401, antes de que el EU transfiera la sesión, la sesión en la terminal de usuario se identifica por el primer
35 identificador, la sesión en el AS de transferencia de dominio se identifica por el segundo identificador, y se establece la relación de mapeo entre el primer identificador y el segundo identificador.
En esta etapa, el EU y la DTF determinan el identificador de sesión para cada sesión establecida, y establecen la relación de mapeo. Aquí, la relación de mapeo se comprende y lleva a cabo fácilmente. En la implementación, la relación de mapeo más fácil, en la cual el primer identificador es igual al segundo identificador, se usa para la 40 descripción. Es decir, los identificadores de cada IMS o sesión CS en el EU y los identificadores de las sesiones en el EU anclado en la DTF son idénticos y únicos, y el objeto único es permitir al EU y a la DTF identificar diferentes sesiones. En la implementación, el EU y la DTF solo necesitan enviar el identificador determinado por sí mismo a la otra parte, las dos partes pueden establecer la relación de mapeo. Además, en una implementación preferida, el identificador determinado por la otra parte puede usarse directamente como el identificador de sí mismo, para
45 simplemente establecer la relación de mapeo. De manera diferente, cuando se establece la relación de mapeo, la forma de enviar a la otra parte puede no usarse, y también está disponible generar, respectivamente, el identificador según la misma norma, por ejemplo, cuando se establece la sesión en el dominio CS, el identificador se genera de esta manera. Por lo tanto, la descripción se provee de la siguiente manera con la forma de implementación de establecimiento de la relación de mapeo mediante el envío del identificador a la otra parte.
50 1. Cuando la sesión es la sesión IMS, las situaciones son las siguientes.
1). Cuando la parte que llama es del IMS, el identificador de sesión IMS o la cantidad de secuencia de establecimiento de sesión se genera en el EU o la DTF, y durante el proceso de establecimiento de sesión, el identificador de sesión IMS generado o la cantidad de secuencia de establecimiento de sesión pueden contenerse mediante el uso del campo de encabezamiento o parámetro original, añadiendo el campo de encabezamiento o
55 parámetro, o extendiendo el campo de encabezamiento o parámetro en el protocolo SIP.
La sesión IMS se identifica mediante el uso del identificador de terminal general (por ejemplo, instancia-id), la cantidad de secuencia de establecimiento de sesión o el identificador de usuario, y la cantidad de secuencia de establecimiento de sesión; o la sesión IMS se identifica por el identificador de terminal (por ejemplo, el PMI local), el identificador de usuario y la cantidad de secuencia de establecimiento de sesión. Cuando varios EU comparten la
5 IMPU, un identificador se adapta para identificar una terminal de usuario, y el PMI se usa como un método para identificar la terminal de usuario. De manera diferente, cuando la parte llamada es del IMS, el PMI también puede adaptarse para identificar la siguiente terminal de usuario de los varios EU que comparten la IMPU.
Cuando el identificador de sesión IMS o la cantidad de secuencia de establecimiento de sesión se genera en el EU, durante el proceso de establecimiento de sesión, la cantidad de secuencia de establecimiento de sesión se contiene 10 en el campo de encabezamiento de Usuario-Agente. En particular, cuando la parte que llama es del IMS, la cantidad de secuencia de establecimiento de sesión se contiene en el campo de encabezamiento de Usuario-Agente, cuando la solicitud de establecimiento de sesión alcanza la DTF, la DTF guarda la cantidad de secuencia de establecimiento de la sesión IMS. Durante o después del proceso de establecimiento de sesión, según la información contenida cuando se establece la sesión, el identificador de sesión IMS se combina según la definición del identificador de
15 sesión IMS en la DTF.
De manera alternativa, después de establecer la sesión, se notifica a la DTF el identificador de sesión IMS o la cantidad de secuencia de establecimiento de sesión mediante la contención del identificador de sesión IMS usando el método SIP: INFO. El objetivo del método INFO es permitir entregar la información de control relevante para la sesión, y la información de control se genera en la sesión. El objetivo del mensaje INFO es contener un mensaje de
20 capa de aplicación a lo largo del trayecto de señalización SIP. El método INFO no se adapta para cambiar el estado de la llamada SIP, o el parámetro de estado inicializado del SIP de la sesión. El método INFO solo se adapta para enviar la información opcional de la capa de aplicación relevante para la sesión. La información en la sesión puede llevar a cabo la comunicación en el encabezamiento de información INFO o servir como una parte del cuerpo del mensaje.
25 Cuando el identificador de sesión IMS o la cantidad de secuencia de establecimiento de sesión se genera en la DTF, durante la implementación, la cantidad de secuencia de establecimiento de sesión puede contenerse en el campo de encabezamiento de Servidor. En particular, la parte que llama es del IMS, cuando la solicitud de establecimiento de sesión alcanza la DTF, la DTF genera la cantidad de secuencia de establecimiento de la sesión IMS según la solicitud de establecimiento de sesión, y la cantidad de secuencia de establecimiento de sesión se contiene en el
30 campo de encabezamiento de Servidor en un mensaje de respuesta durante el proceso de establecimiento de la sesión. Durante el proceso de establecimiento de la sesión, cuando el mensaje de respuesta alcanza el EU, el EU guarda la cantidad de secuencia de establecimiento de la sesión IMS. Durante o después del proceso de establecimiento de sesión, según la información contenida cuando se establece la sesión, el identificador de sesión IMS se combina según la definición del identificador de sesión IMS en la DTF.
35 De manera alternativa, después de establecer la sesión, se notifica al EU el identificador de sesión IMS o la cantidad de secuencia de establecimiento de sesión mediante el uso del método SIP: INFO.
2). Cuando la parte llamada es del IMS, el identificador de sesión IMS o la cantidad de secuencia de establecimiento de sesión se genera en el EU o la DTF, y durante el proceso de establecimiento de sesión, el identificador de sesión IMS generado o la cantidad de secuencia de establecimiento de sesión pueden contenerse usando el campo de
40 encabezamiento o parámetro original, añadiendo el campo de encabezamiento o el parámetro, o extendiendo el campo de encabezamiento o el parámetro en el protocolo SIP.
La sesión IMS se identifica mediante el uso de PMI+IMPU (SIP URI o TEL URI) y la cantidad de secuencia de establecimiento de sesión, o IMPU y la cantidad de secuencia de establecimiento de sesión.
Cuando el identificador de sesión o la cantidad de secuencia de establecimiento de sesión se genera en el EU,
45 durante el proceso de establecimiento de la sesión, la cantidad de secuencia de establecimiento de sesión se contiene en el campo de encabezamiento de Servidor, cuando la señalización alcanza la DTF durante el proceso de establecimiento de sesión, la DTF guarda la cantidad de secuencia de establecimiento de la sesión IMS. Durante o después del proceso de establecimiento de sesión, según la información contenida cuando se establece la sesión, el identificador de sesión IMS se combina según la definición del identificador de sesión IMS en la DTF.
50 De manera alternativa, después de establecer la sesión, se notifica a la DTF el identificador de sesión IMS o la cantidad de secuencia de establecimiento de sesión mediante el uso del método SIP: INFO.
Cuando el identificador de sesión IMS o la cantidad de secuencia de establecimiento de sesión se generan en la DTF, durante la implementación, cuando la señalización alcanza la DTF, según la información que se solicita se contenga cuando se establece la sesión, el identificador de sesión IMS o la cantidad de secuencia de 55 establecimiento de sesión se generan según la norma de definición del identificador de sesión IMS en la DTF. Durante el proceso de establecimiento de sesión, la cantidad de secuencia de establecimiento de sesión se contiene mediante el uso del campo de encabezamiento de Usuario-Agente, y durante el proceso de establecimiento de
sesión, cuando la señalización alcanza el EU, el EU guarda la cantidad de secuencia de establecimiento de sesión IMS. Durante o después del proceso de establecimiento de sesión, según la información contenida cuando se establece la sesión, el identificador de sesión IMS se combina según la norma de definición del identificador de sesión IMS en la DTF. De manera alternativa, después de establecer la sesión, se notifica al EU el identificador de
5 sesión IMS o la cantidad de secuencia de establecimiento de sesión mediante el uso del método SIP: INFO.
2. Cuando la sesión es la sesión CS, las situaciones son las siguientes.
1). La parte que llama es de CS.
Solo una sesión se activa en el dominio CS, la cantidad de secuencia de establecimiento de sesión en el dominio CS no puede asignarse, o una cantidad de secuencia especial, por ejemplo, 0, puede asignarse para indicar la cantidad
10 de secuencia de establecimiento de la sesión. Según el flujo VCC normal, la sesión CS se identifica según la MSISDN o la MSISDN+0 en el EU y la DTF. Durante la implementación en la aplicación CDMA, la sesión puede identificarse mediante el uso del MDN o MDN+0.
2). La parte llamada es de CS.
Solo una sesión se activa en el dominio CS, la cantidad de secuencia de establecimiento de la sesión en el dominio
15 CS no puede asignarse, o una cantidad de secuencia especial, por ejemplo, 0, puede asignarse para indicar la cantidad de secuencia de establecimiento de la sesión. Según el flujo VCC normal, la sesión CS se identifica según la MSISDN o la MSISDN+0 en el EU y la DTF.
En la etapa 402, cuando se transfiere la sesión, el primer identificador se contiene en la solicitud de transferencia de sesión, el AS de transferencia de dominio determina el segundo identificador correspondiente al primer identificador
20 según la relación de mapeo. El AS de transferencia de dominio lleva a cabo la transferencia después de determinar la sesión según el segundo identificador.
1. La solicitud de transferencia de sesión se inicia del dominio IMS al dominio IMS.
En la solicitud de transferencia de sesión IMS, el identificador de sesión IMS original se contiene mediante el uso del campo de encabezamiento o parámetro original, añadiendo el campo de encabezamiento o el parámetro, o 25 extendiendo el campo de encabezamiento o parámetro en el protocolo SIP en el método INVITACIÓN. En particular, durante la implementación, el identificador de sesión IMS original puede contenerse mediante el uso del campo de encabezamiento Reemplazar, el campo de encabezamiento Desde, o el campo de encabezamiento Usuario-Agente.
El método INVITACIÓN es una función principal SIP, cuando una entidad pretende iniciar la comunicación con otra entidad, y puede finalizarse mediante el envío de una INVITACIÓN. Cada INVITACIÓN incluye una dirección SIP (o
30 el localizador de recursos uniforme (URL, por sus siglas en inglés)), para servir como el destino de envío de INVITACIÓN. El URL es el principal trayecto de encaminamiento del mensaje. Durante el proceso de creación de la sesión de comunicación, la dirección SIP identifica, de forma única, al usuario.
2. La solicitud de transferencia de sesión se inicia del dominio CS al dominio IMS.
En la solicitud de transferencia de sesión IMS, el identificador de sesión CS original se contiene mediante el uso del
35 campo de encabezamiento o parámetro original, añadiendo el campo de encabezamiento o parámetro, o extendiendo el campo de encabezamiento o parámetro en el protocolo SIP en el método INVITACIÓN. En particular, durante la implementación, el identificador de sesión IMS original puede contenerse mediante el uso del campo de encabezamiento Reemplazar, el campo de encabezamiento Desde, o el campo de encabezamiento Usuario-Agente.
3. La solicitud de transferencia de sesión se inicia del dominio IMS al dominio CS.
40 El identificador de sesión IMS original se contiene en la UUI o el VDN. Durante la implementación, cuando un centro de conmutación móvil visitado (VMSC, por sus siglas en inglés) activa, de manera inteligente, la solicitud a FE-C en el trayecto de señalización de transferencia CS, la información contenida en la señalización de activación inteligente incluye [llamar], [VDN], y [UUI]. Aquí, la información del identificador de sesión IMS original se puede contener en la UUI o el VDN. FE-C guarda la información de transferencia de sesión mediante la interacción con la CSAF. Cuando
45 la llamada se encamina hacia la red IMS doméstica de usuario VCC a través de un encaminamiento multimedia IP (IMRN), la información de transferencia de sesión puede adquirirse en la CSAF según el IMRN, y se genera el identificador de sesión IMS original, de modo que el identificador de sesión IMS original se contiene mediante el uso del campo de encabezamiento o parámetro original, añadiendo el campo de encabezamiento o parámetro, o extendiendo el campo de encabezamiento o parámetro en el protocolo SIP en la solicitud INVITACIÓN. Otro método
50 en paralelo con la manera de activación inteligente es que la información de identificador de sesión IMS original en el mensaje IAM se convierte directamente en el parámetro correspondiente en la solicitud de INVITACIÓN a través de la MGCF, y se contiene para finalmente alcanzar la DTF. La manera de contención puede ser igual a la manera de implementación de transferencia del IMS en la realización de más arriba.
El primer identificador se contiene mediante el uso del campo de encabezamiento Reemplazar, en el campo de encabezamiento Desde, o en el campo de encabezamiento Usuario-Agente.
Las etapas de la implementación se describen a continuación.
1). El identificador de sesión IMS original o la cantidad de secuencia de establecimiento de parte de sesión en el
5 identificador de sesión IMS original se contiene en el elemento de información UUI en la señalización de activación inteligente InicialDP, o la cantidad de secuencia de establecimiento de parte de sesión en el identificador de sesión IMS original se contiene en el VDN.
2). El encaminamiento se redirige a IMS y alcanza la CSAF, la CSAF adquiere la cantidad de secuencia de establecimiento de la sesión IMS mediante el análisis desde la UUI o el VDN, para generar el identificador de sesión
10 IMS original.
3). El identificador de sesión IMS original se contiene mediante el uso del campo de encabezamiento añadido en la solicitud INVITACIÓN recientemente generada, extendiendo el campo de encabezamiento existente, o añadiendo el campo de encabezamiento. Por ejemplo, el primer identificador se contiene mediante el uso del campo de encabezamiento Reemplazar, en el campo de encabezamiento Desde, o en el campo de encabezamiento Usuario
15 Agente.
4). La solicitud se activa para la DTF a través de la S-CSCF, el segundo identificador de sesión se obtiene mediante la asociación con el primer identificador de sesión, se determina el tramo de acceso de sesión IMS original y el tramo de acceso de sesión IMS original se transfiere al nuevo tramo de acceso de sesión CS.
La manera de implementación de la presente invención se describe además con las realizaciones detalladas como 20 se establece a continuación.
Realización 27
Con referencia a la Figura 31, se muestra un diagrama de flujo esquemático de la Realización 27. La parte que llama es del IMS, el EU genera la cantidad de secuencia de establecimiento de sesión, y los identificadores de sesión en la DTF y el EU son iguales. La implementación incluye las siguientes etapas.
25 En las etapas 501-503, el EU inicia una sesión IMS según la indicación del usuario. La cantidad de secuencia de establecimiento de la sesión IMS se genera en el EU, y la cantidad de secuencia de establecimiento de la sesión IMS se contiene en el campo de encabezamiento Usuario-Agente de la solicitud de sesión INVITACIÓN. Con el fin de identificar el EU particular, el identificador de dispositivo del EU como, por ejemplo, el PMI, se contiene en la solicitud de sesión. Cuando el flujo de llamada IMS alcanza la DTF según la estructura VCC, la DTF determina que
30 la sesión es la llamada de dominio IMS, y guarda la cantidad de secuencia de establecimiento de la sesión IMS contenida en la solicitud de sesión.
En las etapas 504-505, la DTF inicia la llamada al usuario remoto como un agente de usuario adosado (B2BUA, por sus siglas en inglés).
En las etapas 506-510, la sesión se establece con éxito según el flujo de establecimiento de la sesión de llamada
35 IMS. Durante o después del proceso de establecimiento de la sesión, según la cantidad de secuencia de establecimiento de la sesión, el EU y la DTF generan el identificador de sesión IMS según la manera de composición del identificador de sesión IMS.
Durante la implementación, el identificador de sesión IMS es [PMI+]IMPU (SIP URI o TEL URI) y la cantidad de secuencia de establecimiento de sesión, y se genera por el EU, en el cual [PMI+] indica que el PMI es opcional. En
40 aras de la descripción, en todas las realizaciones, el contenido en el identificador "[ ]" adoptado en la descripción del identificador de sesión indica que es opcional.
Definitivamente, si el identificador de sesión no se entrega en el mensaje de interacción de establecimiento de sesión, después de establecer la sesión, el EU notifica a la DTF a través del mensaje INFO de solicitud en la sesión, de modo que los identificadores de sesión en el EU y la DTF son iguales.
45 Realización 28
Con referencia a la Figura 32, se muestra un diagrama de flujo esquemático de la Realización 28. La parte que llama es del IMS, la cantidad de secuencia de establecimiento de la sesión IMS se genera en la DTF, y los identificadores de sesión en la DTF y el EU son iguales. La implementación incluye las siguientes etapas.
En las etapas 601-603, el EU inicia una sesión IMS según la indicación del usuario. Con el fin de permitir a la red
50 identificar qué EU inicia la sesión, el identificador de dispositivo del EU, por ejemplo, el PMI, se contiene en el mensaje de sesión. Cuando el flujo de llamada IMS alcanza la DTF según la estructura VCC, la DTF determina que la sesión es la llamada de dominio IMS, y genera y guarda la cantidad de secuencia de establecimiento de la sesión IMS.
En las etapas 604-605, la DTF inicia la llamada al usuario remoto como el B2BUA.
En las etapas 606-610, la sesión se establece con éxito según el flujo de establecimiento de la sesión de llamada
5 IMS. La DTF contiene la cantidad de secuencia de establecimiento de la sesión para el EU mediante el uso del campo de encabezamiento de Servidor en el mensaje de respuesta. Durante o después del proceso de establecimiento de la sesión, según la cantidad de secuencia de establecimiento de la sesión, el EU y la DTF generan el identificador de sesión IMS según la manera de composición del identificador de sesión IMS.
Durante la implementación, el identificador de sesión IMS es [PMI+]IMPU (SIP URI o TEL URI) y la cantidad de 10 secuencia de establecimiento de la sesión, y se genera por la DTF.
Después de establecer la sesión, la DTF notifica al EU a través del mensaje INFO de solicitud en la sesión, de modo que los identificadores de sesión en el EU y la DTF son iguales.
Realización 29
Con referencia a la Figura 33, se muestra un diagrama de flujo esquemático de la Realización 29. La parte que llama
15 es del IMS, el EU genera la cantidad de secuencia de establecimiento de la sesión IMS, y los identificadores de sesión en el EU y la DTF son iguales. La implementación incluye las siguientes etapas.
En las etapas 701-702, el usuario es la parte llamada, la solicitud de Invitación alcanza la S-CSCF local del EU, y se activa para la DTF según una norma de filtrado inicial, y la sesión se ancla en la DTF.
En el IMS, la S-CSCF necesita detectar cada norma de filtrado inicial en secuencia en el IMS, pero en ciertas 20 situaciones, no es necesario o imposible detectar las normas de filtrado inicial.
En las etapas 703-707, la DTF activa la solicitud de INVITACIÓN para la S-CSCF, y la solicitud de INVITACIÓN se activa para DSF según la norma de filtrado, DSF lleva a cabo una decisión de selección de dominio, y continúa llevando a cabo la conexión de sesión en el dominio IMS, luego el dominio de interacción de DSF y DTF se selecciona como el resultado de conexión de dominio IMS.
25 En las etapas 708-714, el EU recibe la solicitud de sesión, genera y guarda la cantidad de secuencia de establecimiento de la sesión IMS. Durante el proceso subsiguiente de establecimiento de la sesión, el EU entrega la cantidad de secuencia de establecimiento de la sesión IMS a la DTF a lo largo del trayecto de señalización mediante el uso del campo de encabezamiento de Servidor. Con el fin de permitir a la red identificar qué EU genera el identificador de sesión, el EU entrega el identificador de dispositivo, por ejemplo, el PMI, a la DTF. Durante o
30 después del proceso de establecimiento de sesión, según la cantidad de secuencia de establecimiento de la sesión, el EU y la DTF generan el identificador de sesión IMS según la manera de composición del identificador de sesión IMS.
Durante la implementación, el identificador de sesión IMS es [PMI+]IMPU (SIP URI o TEL URI) y la cantidad de secuencia de establecimiento de la sesión, y se genera por el EU.
35 Después de establecer la sesión, el EU notifica a la DTF a través del mensaje INFO, de modo que los identificadores de sesión en el EU y la DTF son iguales.
Realización 30
Con referencia a la Figura 34, se muestra un diagrama de flujo esquemático de la Realización 30. La parte llamada es del IMS, la cantidad de secuencia de establecimiento de la sesión IMS se genera en la DTF, y los identificadores
40 de sesión en la DTF y el EU son iguales. La implementación incluye las siguientes etapas.
En las etapas 801-802, el usuario es la parte llamada, la solicitud de Invitación alcanza la S-CSCF local del EU, y se activa para la DTF según la norma de filtrado inicial, y la sesión se ancla en la DTF.
En las etapas 803-807, la DTF activa la solicitud de INVITACIÓN para la S-CSCF, y la solicitud de INVITACIÓN se activa para DSF según la norma de filtrado, DSF lleva a cabo la decisión de selección de dominio, y continúa
45 llevando a cabo la conexión de sesión en el dominio IMS, luego el dominio de interacción de DSF y DTF se selecciona como el resultado de conexión de dominio IMS.
En las etapas 808-814, la DTF genera y guarda la cantidad de secuencia de establecimiento de la sesión IMS, según el resultado de sesión de conexión adquirido en el dominio IMS. Durante el proceso subsiguiente de establecimiento de la sesión, la DTF entrega la cantidad de secuencia de establecimiento de la sesión IMS al EU a 50 lo largo del trayecto de señalización mediante el uso del campo de encabezamiento de Usuario-Agente. Con el fin de
permitir a la red identificar en qué terminal se detiene la sesión, el EU contiene el identificador de dispositivo de aquel, por ejemplo, el PMI, en el mensaje de respuesta de sesión. Durante o después del proceso de establecimiento de la sesión, según la cantidad de secuencia de establecimiento de la sesión, el EU y la DTF generan el identificador de sesión IMS según la manera de composición del identificador de sesión IMS.
5 Durante la implementación, el identificador de sesión IMS es [PMI+]IMPU (SIP URI o TEL URI) y la cantidad de secuencia de establecimiento de la sesión, y se genera por la DTF.
Después de establecer la sesión, la DTF notifica al EU a través del mensaje INFO, de modo que los identificadores de sesión en el EU y la DTF son iguales.
Realización 31
10 Con referencia a la Figura 35, se muestra un diagrama de flujo esquemático de la Realización 31. La parte que llama es de CS, y los identificadores de sesión en la DTF y el EU son iguales. La implementación incluye las siguientes etapas.
En las etapas 901-902, el EU inicia la llamada en el dominio CS y establece el identificador de sesión (MSISDN[+0]) de la llamada CS, después de que la llamada alcanza el VMSC, este se activa de forma inteligente para las
15 aplicaciones personalizadas para redes móviles de lógica mejorada CAMEL (Aplicación CAMEL), el mensaje de activación inteligente IDP contiene el número que llama y el número al que se llama. La Aplicación CAMEL interactúa con la CSAF y adquiere un IMRN de redireccionamiento de encaminamiento, y el IMRN se entrega al VMSC como la información contenida en la respuesta InicialDP.
En las etapas 903-904, el MSC envía IAM a la MGCF mediante el uso del IMRN como el número llamado, e IAM
20 alcanza la CSAF después de atravesar la MGCF y la I-CSCF. La información CS de la sesión se adquiere en la CSAF según el IMRN.
En las etapas 905-908, la CSAF genera la solicitud de Invitación según la información CS, en la cual el Tel URI de la parte llamada sirve como el número llamado. La CSAF puede contener el identificador de sesión CS o la cantidad de secuencia de establecimiento de la sesión (0) en la solicitud de Invitación según el método para establecer la sesión
25 IMS. La sesión se activa para la DTF a través de la S-CSCF, y la sesión CS se ancla en la DTF, la DTF determina que la parte que llama es del CS, y guarda el identificador de sesión CS (MSISDN [+0]). Luego, la solicitud de sesión se establece para el usuario remoto que llama a lo largo del trayecto de señalización.
Durante la distribución de la Aplicación CAMEL, durante el proceso de llamado, la CSAF adquiere la información de sesión CS interactuando con la Aplicación CAMEL. Cuando la solicitud de establecimiento de sesión alcanza la
30 CSAF a través del IMRN, la CSAF genera la solicitud de Invitación de continuar conectando la sesión según la información de sesión CS adquirida.
Realización 32
Con referencia a la Figura 36, se muestra un diagrama de flujo esquemático de la Realización 32. El EU es la parte llamada y, en un proceso de sesión CS, los identificadores de sesión en la DTF y el EU son iguales. La
35 implementación incluye las siguientes etapas.
En las etapas 1001-1002, el usuario es la parte llamada, la solicitud de INVITACIÓN alcanza la S-CSCF local del EU, y se activa para la DTF según una norma de filtrado inicial, y la sesión se ancla en la DTF.
En las etapas 1003-1007, la DTF activa la solicitud de Invitación para la S-CSCF, y la solicitud de INVITACIÓN se activa para DSF según la norma de filtrado, DSF lleva a cabo la decisión de selección de dominio, y continúa
40 llevando a cabo la conexión de sesión en el dominio CS, luego el dominio de interacción de DSF y DTF se selecciona como el resultado de conexión de dominio CS. La DTF genera el identificador de sesión del dominio CS (MSISDN[+0]).
En las etapas 1008-1010, según el proceso de establecimiento de la sesión en el dominio CS, el EU recibe la solicitud de sesión, y determina el identificador de sesión CS (MSISDN[+0]). Luego, la sesión se establece según el
45 proceso de conexión de sesión de dominio CS.
Realización 33
Con referencia a la Figura 37, se muestra un diagrama de flujo esquemático de la Realización 33, el EU transfiere una sesión IMS actual a la sesión IMS bajo otra red de acceso, y el identificador de sesión de tramo de acceso IMS original se contiene mediante el uso del campo de encabezamiento Reemplazar. La implementación incluye las
50 siguientes etapas.
En las etapas 1101-1103, la sesión IMS se identifica usando [PMI+]IMPU (SIP URI o TEL URI) y la cantidad de secuencia de establecimiento de la sesión. El EU determina transferir la sesión IMS actual a la sesión IMS bajo otra red de acceso, el identificador de sesión de tramo de acceso IMS original se contiene usando el campo de encabezamiento Reemplazar, y se entrega a la DTF a lo largo del trayecto de señalización.
5 En las etapas 1104-1113, la DTF recibe la solicitud de transferencia de sesión. Se detecta que la transferencia se lleva a cabo en la sesión, el identificador de sesión de tramo de acceso IMS original se encuentra a partir de la solicitud de transferencia, entonces, el tramo de acceso IMS original se determina desde la sesión anclada, el tramo de acceso IMS original se transfiere al nuevo tramo de acceso IMS, el usuario remoto que llama se actualiza, y el tramo de acceso IMS original se libera. El nuevo identificador de sesión de tramo de acceso IMS se genera según la
10 norma de establecimiento de sesión IMS.
Durante la implementación, la cantidad de secuencia de establecimiento de la sesión en el identificador de sesión de tramo de acceso IMS original puede contenerse usando el campo de encabezamiento Reemplazar, y la IMPU y el PMI se completan respectivamente según el mecanismo de sesión IMS original. Según la información contenida en la solicitud de transferencia de sesión, el identificador de sesión de tramo de acceso IMS original se genera según la 15 norma de determinación del identificador de sesión IMS en la DTF. Luego, el tramo de acceso IMS original se determina en la sesión anclada, el identificador de sesión de tramo de acceso IMS se guarda, el tramo de acceso IMS original se transfiere al nuevo tramo de acceso IMS, el usuario remoto que llama se actualiza, y el tramo de acceso IMS original se libera. El identificador de sesión de tramo de acceso IMS original o la cantidad de secuencia de establecimiento de la sesión en el identificador de sesión puede contenerse usando el campo de encabezamiento
20 Desde en la solicitud de transferencia, y cuando la solicitud de transferencia alcanza la DTF, la transferencia de sesión se lleva a cabo según el identificador de sesión de tramo de acceso IMS original.
Realización 34
Con referencia a la Figura 38, se muestra un diagrama de flujo esquemático de la Realización 34, el EU transfiere una sesión IMS actual a la sesión IMS bajo otra red de acceso, y el identificador de sesión de tramo de acceso IMS
25 original se contiene mediante el uso del campo de encabezamiento Reemplazar. La implementación incluye las siguientes etapas.
En las etapas 1201-1203, se establece la sesión CS, y el mismo identificador de sesión CS (MSISDN+[0]) capaz de determinar la sesión se guarda en el EU y la DTF. El EU determina transferir la sesión CS actual a la sesión IMS. Se indica que la sesión original es la sesión CS mediante la contención del identificador de sesión CS original usando el 30 campo de encabezamiento Reemplazar en la solicitud de transferencia o mediante la no contención del campo de encabezamiento Reemplazar en la solicitud de transferencia. La solicitud de transferencia se entrega a la DTF a lo largo del trayecto de señalización. La DTF determina el tramo de acceso CS original según el identificador de sesión CS original en la solicitud de transferencia o identifica la sesión CS para encontrar el trama de acceso CS original ya que el campo de encabezamiento Reemplazar no se contiene en la solicitud de transferencia. Luego, el tramo de
35 acceso original se transfiere al nuevo tramo de acceso.
En las etapas 1204-1214, se actualiza el usuario remoto que llama y se libera el tramo de acceso IMS original. El nuevo identificador de sesión de tramo de acceso IMS se genera según la norma de establecimiento de la sesión IMS.
Durante la implementación, la cantidad de secuencia de establecimiento de la sesión en el identificador de sesión de
40 tramo de acceso IMS original puede contenerse usando el campo de encabezamiento Reemplazar. Según la información contenida en la solicitud de transferencia de sesión, el identificador de sesión de tramo de acceso IMS original se genera según la norma de determinación del identificador de sesión CS en la DTF. Luego, el tramo de acceso IMS original se determina en la sesión anclada, el identificador de sesión de tramo de acceso IMS se guarda, el tramo de acceso IMS original se transfiere al nuevo tramo de acceso IMS, el usuario remoto que llama se
45 actualiza, y el tramo de acceso IMS original se libera. El identificador de sesión de tramo de acceso IMS original o la cantidad de secuencia (0) de establecimiento de la sesión en el identificador de sesión pueden contenerse usando el campo de encabezamiento Desde en la solicitud de transferencia, y cuando la solicitud de transferencia alcanza la DTF, la transferencia de sesión se lleva a cabo según el identificador de sesión de tramo de acceso CS original.
Realización 35
50 Con referencia a la Figura 39, se muestra un diagrama de flujo esquemático de la Realización 35, y el EU transfiere un IMS actual a una sesión CS, en la cual la implementación de iniciación de la transferencia incluye las siguientes etapas.
En la etapa 1301, la sesión IMS original se identifica usando [PMI+]IMPU (SIP URI o TEL URI) y la cantidad de secuencia de establecimiento de la sesión, la sesión IMS se establece con éxito, y el mismo identificador de sesión
55 único para la sesión IMS existe en el EU y la DTF.
En las etapas 1302-1304, el EU determina transferir la sesión IMS actual a la sesión CS, genera la solicitud de transferencia, e inicia la transferencia, en la cual la cantidad de secuencia de sesión en el identificador de sesión IMS original se contiene en la solicitud de transferencia. En la presente realización, la cantidad de secuencia de sesión se contiene añadiendo un prefijo/sufijo al VDN llamado, y puede contenerse en la información UUI. El EU 5 puede generar y grabar el identificador de sesión CS (MSISDN+[0]). Después de que la sesión alcanza el VMSC, la sesión se activa para la Aplicación CAMEL a través del mensaje IDP, el VDN o el parámetro UUI con el prefijo/sufijo se contiene en el IDP (dependiendo de la manera de contención de la cantidad de secuencia de sesión cuando la terminal de usuario inicia la transferencia). Después de recibir el mensaje IDP, la Aplicación CAMEL analiza el número llamado, adquiere el VDN y la cantidad de secuencia de establecimiento de la sesión en el identificador de
10 sesión de tramo de acceso IMS original, determina que es la solicitud de transferencia de sesión, mantiene la información contenida en la solicitud de transferencia junto con la CSAF, distribuye el IMRN, y entrega el IMRN al VMSC mediante la contención del IMRN en la respuesta IDP.
En las etapas 1305-1308, según el IMRN, el VMSC redirige el encaminamiento al dominio IMS, cuando el encaminamiento alcanza la CSAF, la CSAF analiza la cantidad de secuencia de establecimiento de la sesión IMS 15 desde el VDN, o según la cantidad de secuencia adquirida y guardada en la etapa 1303 o la cantidad de secuencia adquirida interrogando desde la CSAF, el identificador de sesión de tramo de acceso IMS original se genera y completa en el campo de encabezamiento de Reemplazar en la solicitud de INVITACIÓN recientemente generada para su contención. La CSAF contiene el identificador de sesión CS o la cantidad de secuencia de establecimiento de la sesión (0) en la solicitud de Invitación según el método para establecer la sesión CS. La solicitud se activa para
20 la DTF a través de la S-CSCF, la DTF determina que es la solicitud de transferencia de sesión CS, el tramo de acceso IMS original se determina según el identificador de sesión de tramo de acceso IMS original, y el tramo de acceso IMS original se transfiere al nuevo tramo de acceso CS. La DTF puede además generar el identificador de sesión CS (MSISDN+[0]), que se dispone para la siguiente transferencia.
En las etapas 1309-1310, la solicitud de Reinvitación se envía para actualizar el usuario remoto que llama, luego se 25 libera el tramo de acceso IMS original, y se finaliza la transferencia de sesión.
En la solicitud de transferencia de INVITACIÓN generada por la CSAF, la cantidad de secuencia de establecimiento de la sesión en el identificador de sesión de tramo de acceso IMS original puede contenerse usando el campo de encabezamiento Reemplazar. La DTF genera el identificador de sesión CS (MSISDN+[0]) según la solicitud de transferencia de sesión CS, y genera el identificador de sesión de tramo de acceso IMS original en la DTF. Luego, el 30 tramo de acceso IMS original se determina a partir de la sesión anclada, el nuevo identificador de sesión de tramo de acceso CS se guarda, el tramo de acceso IMS original se transfiere al nuevo tramo de acceso CS, el usuario remoto se actualiza, y el tramo de acceso IMS original se libera. El identificador de sesión de tramo de acceso IMS original o la cantidad de secuencia de establecimiento de la sesión en el identificador de sesión pueden contenerse mediante el uso del campo de encabezamiento Desde en la solicitud de transferencia de INVITACIÓN generada por
35 la CSAF. Cuando la solicitud de transferencia alcanza la DTF, la transferencia de sesión se lleva a cabo según el identificador de sesión de tramo de acceso IMS original.
Realización 36
Con referencia a la Figura 40, se muestra un diagrama de flujo esquemático de la Realización 36, en la transferencia de sesión de EU cruzado, el EU1 transfiere una sesión IMS actual en el EU2 a la sesión IMS en el EU1, y la
40 implementación de iniciación de la transferencia incluye las siguientes etapas.
En las etapas 1401-1403, la sesión IMS se establece en el EU2, y el EU1 interactúa con el EU2 a través de interfaces inalámbricas, la técnica infrarroja, u otras maneras, y así adquiere la información de sesión en el EU2. La sesión IMS se identifica usando [PMI+]IMPU (SIP URI o TEL URI) y la cantidad de secuencia de establecimiento de la sesión. El EU1 determina transferir la sesión IMS en el EU2 a la sesión IMS en el EU1, y el identificador de sesión
45 de tramo de acceso IMS original se contiene mediante el uso del campo de encabezamiento Reemplazar, y se entrega a la DTF a lo largo del trayecto de señalización.
En las etapas 1404-1413, la DTF recibe la solicitud de transferencia de sesión. Se detecta que la transferencia se lleva a cabo en la sesión, el identificador de sesión de tramo de acceso IMS original se encuentra a partir de la solicitud de transferencia, entonces, el tramo de acceso IMS original se determina desde la sesión anclada, el tramo
50 de acceso IMS original se transfiere al nuevo tramo de acceso IMS, el usuario remoto se actualiza, y el tramo de acceso IMS original se libera. El nuevo identificador de sesión de tramo de acceso IMS se genera según la norma de establecimiento de sesión IMS.
La cantidad de secuencia de establecimiento de la sesión en el identificador de sesión de tramo de acceso IMS original puede contenerse usando el campo de encabezamiento Reemplazar. Según la información contenida en la 55 solicitud de transferencia de sesión, el identificador de sesión de tramo de acceso IMS original se genera según la norma de determinación del identificador de sesión IMS en la DTF. Luego, el tramo de acceso IMS original se determina en la sesión anclada, el identificador de sesión de tramo de acceso IMS se guarda, el tramo de acceso
IMS original se transfiere al nuevo tramo de acceso IMS, el usuario remoto que llama se actualiza, y el tramo de acceso IMS original se libera. El identificador de sesión de tramo de acceso IMS original o la cantidad de secuencia de establecimiento de la sesión en el identificador de sesión puede contenerse mediante el uso del campo de encabezamiento Desde en la solicitud de transferencia, y cuando la solicitud de transferencia alcanza la DTF, la
5 transferencia de sesión se lleva a cabo según el identificador de sesión de tramo de acceso IMS original.
De manera distinta, la transferencia puede volver a implementarse cuando la sesión CS se transfiere a la sesión IMS
o la sesión IMS se transfiere a la sesión CS, y la manera de transferencia puede llevarse a cabo según las Realizaciones 8, 9 y 11.
Realización 37
10 Con referencia a la Figura 41, se muestra un diagrama de flujo esquemático de la Realización 37, cuando la solicitud de transferencia no atraviesa la Aplicación CAMEL, la sesión IMS actual se transfiere a la sesión CS, y la implementación de iniciación de la transferencia incluye las siguientes etapas.
En la etapa 1501, la sesión IMS original se identifica mediante el uso de [PMI+]IMPU (SIP URI o TEL URI) y la cantidad de secuencia de establecimiento de la sesión, la sesión IMS se establece con éxito, y el mismo identificador
15 de sesión único para la sesión IMS existe en el EU y la DTF.
En las etapas 1502-1505, el EU determina transferir la sesión IMS actual a la sesión CS, genera la solicitud de transferencia, y contiene la cantidad de secuencia de establecimiento de la sesión IMS original añadiendo un sufijo al VDN en la solicitud de transferencia. El EU también puede generar el identificador de sesión CS (MSISDN+[0]). Durante el proceso de transferencia, el VMSC encamina la solicitud de transferencia hacia la MGCF según el VDN,
20 la MGCF genera la solicitud de INVITACIÓN para la DTF según el VDN recibido con la cantidad de secuencia de la sesión y envía la solicitud de INVITACIÓN a la DTF, en la solicitud de INVITACIÓN, el identificador de sesión IMS original o la cantidad de secuencia de la sesión en el identificador de sesión también se completa en el campo de encabezamiento Reemplazar o el campo de encabezamiento Desde.
En las etapas 1506-1507, la DTF determina que es la solicitud de transferencia de sesión CS, el tramo de acceso
25 IMS original se determina según el identificador de sesión de tramo de acceso IMS original, y el tramo de acceso IMS original se transfiere al nuevo tramo de acceso CS. La solicitud de Reinvitación se envía para actualizar el usuario remoto que llama, luego se libera el tramo de acceso IMS original, y se finaliza la transferencia de sesión. La DTF además genera el identificador de sesión CS (MSISDN+[0]), que se dispone para la siguiente transferencia.
La cantidad de secuencia de establecimiento de la sesión en el identificador de sesión de tramo de acceso IMS
30 original puede contenerse mediante el uso de la UUI del elemento de información en el mensaje IAM enviado a la MGCF desde el VMSC.
La presente invención además provee un sistema para proveer la transferencia multisesión en forma de acceso múltiple, y la implementación del sistema se describe más abajo con los dibujos anexos.
Con referencia a la Figura 42, se muestra una vista estructural esquemática del sistema para proveer la
35 transferencia multisesión en forma de acceso múltiple, en la cual el sistema incluye una terminal de usuario, un AS de transferencia de dominio, adaptado para transferir la sesión. El sistema incluye un primer módulo de identificador, un segundo módulo de identificador, un módulo de mapeo, un módulo de envío de solicitud, un módulo de determinación de identificador, y un módulo de determinación de sesión.
El primer módulo de identificador se adapta para identificar la sesión en la terminal de usuario mediante el uso de un 40 primer identificador.
El segundo módulo de identificador se adapta para identificar la sesión en el AS de transferencia de dominio mediante el uso de un segundo identificador.
El módulo de mapeo se adapta para establecer una relación de mapeo entre el primer identificador y el segundo identificador.
45 El módulo de envío de solicitud se adapta para contener el primer identificador en la solicitud de transferencia como el identificador de transferencia, y enviar la solicitud de transferencia al AS de transferencia de dominio durante la transferencia de la sesión.
El módulo de determinación de identificador se adapta para determinar el segundo identificador correspondiente al primer identificador según la relación de mapeo.
50 El módulo de determinación de sesión se adapta para determinar la sesión según el segundo identificador.
El AS de transferencia de dominio lleva a cabo la transferencia en la sesión determinada por el módulo de determinación de sesión.
El módulo de mapeo incluye una primera unidad de envío, una segunda unidad de envío, una primera unidad de establecimiento de mapeo, y una segunda unidad de establecimiento de mapeo.
5 Cuando la sesión es la sesión IMS, durante el proceso de establecimiento de la sesión, la primera unidad de envío envía el primer identificador a la primera unidad de mapeo mediante la contención del primer identificador usando el parámetro existente, extendiendo el parámetro existente o añadiendo el parámetro, o envía el primer identificador a la primera unidad de mapeo mediante la contención del primer identificador a través de SIP: INFO del SIP después de establecer la sesión. La primera unidad de establecimiento de mapeo establece la relación de mapeo entre el
10 primer identificador y el segundo identificador según el primer identificador enviado.
Durante el proceso de establecimiento de la sesión, la segunda unidad de envío envía el segundo identificador a la segunda unidad de mapeo mediante la contención del segundo identificador usando el parámetro existente, extendiendo el parámetro existente o añadiendo el parámetro, o envía el segundo identificador a la segunda unidad de mapeo mediante la contención del segundo identificador a través de SIP: INFO del SIP después de establecer la
15 sesión. La segunda unidad de establecimiento de mapeo establece la relación de mapeo entre el primer identificador y el segundo identificador según el segundo identificador enviado.
El identificador contenido por la primera unidad de envío y la segunda unidad de envío mediante la adición del parámetro existente, extensión del parámetro existente o adición del parámetro incluye la IMPU del identificador de usuario público y la cantidad de secuencia de establecimiento de la sesión.
20 Después de establecer la sesión, la primera unidad de envío y la segunda unidad de envío envían el identificador entre sí después de contener el identificador en SIP: INFO en el protocolo SIP.
Cuando la sesión es la sesión CS, la primera unidad de envío usa el identificador de usuario de dominio CS o el identificador de usuario de dominio CS +0 como el primer identificador, y envía el primer identificador a la primera unidad de mapeo. La primera unidad de establecimiento de mapeo establece la relación de mapeo entre el primer
25 identificador y el segundo identificador según el primer identificador enviado.
De manera alternativa, la segunda unidad de envío usa el identificador de usuario de dominio CS o el identificador de usuario de dominio CS +0 como el segundo identificador, y envía el segundo identificador a la segunda unidad de mapeo. La segunda unidad de establecimiento de mapeo establece la relación de mapeo entre el primer identificador y el segundo identificador según el segundo identificador enviado.
30 Cuando se transfiere la solicitud al IMS, el módulo de envío de solicitud se adapta para contener el primer identificador usando el campo de encabezamiento existente, extendiendo el campo de encabezamiento existente, o añadiendo el campo de encabezamiento en la solicitud de transferencia de sesión. El primer identificador se contiene usando el campo de encabezamiento existente, extendiendo el campo de encabezamiento existente, o añadiendo el campo de encabezamiento en la solicitud de transferencia de sesión. Durante la implementación, el
35 primer identificador puede contenerse mediante el uso del campo de encabezamiento Reemplazar, el campo de encabezamiento Desde, o el campo de encabezamiento Usuario-Agente.
Cuando la solicitud se transfiere al CS, el módulo de envío de solicitud se adapta para contener el primer identificador usando la UUI, el VDN en la solicitud de transferencia de sesión, y el primer identificador se completa en el campo de encabezamiento existente, el campo de encabezamiento extendido, y el campo de encabezamiento
40 recientemente añadido en el mensaje de INVITACIÓN a través de la entidad de interfuncionamiento CS-IMS.
La entidad de interfuncionamiento CS-IMS puede ser la entidad MGCF o la entidad CSAF.
La presente invención además provee un AS de transferencia de dominio para proveer la transferencia multisesión en forma de acceso múltiple, y la implementación del AS de transferencia de dominio se describe más abajo con los dibujos anexos.
45 Con referencia a la Figura 43, se muestra una vista estructural esquemática del AS de transferencia de dominio para proveer la transferencia multisesión en la forma de acceso múltiple, el AS de transferencia de dominio incluye un segundo módulo de identificador, adaptado para identificar la sesión en el AS de transferencia de dominio mediante el uso de un segundo identificador; un módulo de mapeo, adaptado para establecer una relación de mapeo entre el primer identificador y el segundo identificador; un módulo de determinación de identificador, adaptado para
50 determinar el segundo identificador correspondiente al primer identificador según la relación de mapeo; y un módulo de determinación de sesión, adaptado para determinar la sesión según el segundo identificador; en el cual el AS de transferencia de dominio lleva a cabo la transferencia en la sesión determinada por el módulo de determinación de sesión.
Cuando la sesión es la sesión IMS, el módulo de mapeo incluye una primera unidad de envío, una segunda unidad de envío, una primera unidad de establecimiento de mapeo, y una segunda unidad de establecimiento de mapeo.
La primera unidad de envío se adapta para enviar el primer identificador a la primera unidad de mapeo mediante la contención del primer identificador durante el proceso de establecimiento de la sesión, o enviar el primer 5 identificador a la primera unidad de mapeo mediante la contención del primer identificador a través del SIP después de establecer la sesión.
La primera unidad de establecimiento de mapeo se adapta para establecer la relación de mapeo entre el primer identificador y el segundo identificador según el primer identificador enviado.
La segunda unidad de envío se adapta para enviar el segundo identificador a la segunda unidad de mapeo mediante
10 la contención del segundo identificador durante el proceso de establecimiento de la sesión, o enviar el segundo identificador a la segunda unidad de mapeo mediante la contención del segundo identificador a través del SIP después de establecer la sesión.
La segunda unidad de establecimiento de mapeo se adapta para establecer la relación de mapeo entre el primer identificador y el segundo identificador según el segundo identificador enviado.
15 La primera unidad de envío puede enviar el primer identificador a la primera unidad de mapeo mediante la contención del primer identificador usando el parámetro existente, extendiendo el parámetro existente o añadiendo el parámetro durante el proceso de establecimiento de la sesión, o enviar el primer identificador a la primera unidad de mapeo mediante la contención del primer identificador a través de SIP: INFO del SIP después de establecer la sesión.
20 La segunda unidad de envío puede enviar el segundo identificador a la segunda unidad de mapeo mediante la contención del segundo identificador usando el parámetro existente, extendiendo el parámetro existente o añadiendo el parámetro durante el proceso de establecimiento de la sesión, o enviar el segundo identificador a la segunda unidad de mapeo mediante la contención del segundo identificador a través de SIP: INFO del SIP después de establecer la sesión.
25 Cuando la sesión es la sesión CS, el módulo de mapeo incluye una primera unidad de envío, una segunda unidad de envío, una primera unidad de establecimiento de mapeo, y una segunda unidad de establecimiento de mapeo.
La primera unidad de envío usa el identificador de usuario de dominio CS o el identificador de usuario de dominio CS +0 como el primer identificador, y envía el primer identificador a la primera unidad de mapeo.
La primera unidad de establecimiento de mapeo establece la relación de mapeo entre el primer identificador y el 30 segundo identificador según el primer identificador enviado.
De manera alternativa, la segunda unidad de envío usa el identificador de usuario de dominio CS o el identificador de usuario de dominio CS +0 como el segundo identificador, y envía el segundo identificador a la segunda unidad de mapeo.
La segunda unidad de establecimiento de mapeo establece la relación de mapeo entre el primer identificador y el 35 segundo identificador según el segundo identificador enviado.
La presente invención además provee una terminal de usuario para proveer la transferencia multisesión en forma de acceso múltiple, y la implementación de la terminal de usuario se describe más abajo con los dibujos anexos como se establece a continuación.
Con referencia a la Figura 44, se muestra una vista estructural esquemática de la terminal de usuario para proveer la
40 transferencia multisesión en forma de acceso múltiple, y la terminal de usuario incluye un primer módulo de identificador, adaptado para identificar la sesión en la terminal de usuario mediante el uso de un primer identificador; y un módulo de envío de solicitud, adaptado para contener el primer identificador en la solicitud de transferencia, y enviar la solicitud de transferencia al AS de transferencia de dominio durante la transferencia de la sesión.
Cuando se transfiere la solicitud al IMS, el módulo de envío de solicitud se adapta para contener el primer
45 identificador usando el campo de encabezamiento existente, extendiendo el campo de encabezamiento existente, o añadiendo el campo de encabezamiento en la solicitud de transferencia de sesión.
El primer identificador se contiene usando el campo de encabezamiento existente, extendiendo el campo de encabezamiento existente, o añadiendo el campo de encabezamiento en la solicitud de transferencia de sesión. Durante la implementación, el primer identificador puede contenerse mediante el uso del campo de encabezamiento
50 Reemplazar, el campo de encabezamiento Desde, o el campo de encabezamiento Usuario-Agente.
Cuando la solicitud se transfiere al CS, el módulo de envío de solicitud se adapta para contener el primer identificador usando la UUI, el VDN en la solicitud de transferencia de sesión, y el primer identificador se completa en el campo de encabezamiento existente, el campo de encabezamiento extendido, y el campo de encabezamiento recientemente añadido en el mensaje de INVITACIÓN a través de la entidad de interfuncionamiento CS-IMS.
5 La entidad de interfuncionamiento CS-IMS puede ser la entidad MGCF o la entidad CSAF.
En la presente invención, durante la implementación, se usa la estructura técnica del VCC, en la estructura técnica del VCC, cuando el dominio de circuito y el dominio IMS tienen solo una sesión, la sesión en un dominio se transfiere a la sesión en el otro dominio entre los dos dominios, y se extiende de forma tal que cuando varias sesiones IMS existen en el dominio IMS, la transferencia entre las dos sesiones aún se admite. Bajo la condición de
10 que múltiples redes de acceso existan en el dominio IMS, la sesión IMS bajo un acceso se transfiere a la sesión IMS bajo otra red de acceso, y así se resuelve el problema en la técnica VCC en el sistema de comunicación existente en el que solo la única sesión se admite en el dominio IMS, y se mejora la practicabilidad de la técnica VCC, y se mejora la competitividad del operador en el servicio móvil de red.
Será aparente para las personas con experiencia en la técnica que se pueden llevar a cabo varias modificaciones y
15 variaciones a la presente invención sin apartarse del alcance de la invención. En vista de lo antedicho, se pretende que la presente invención cubra las modificaciones y variaciones de la presente invención siempre que caigan dentro del alcance de las siguientes reivindicaciones y sus equivalentes.
Claims (8)
-
imagen1 REIVINDICACIONES1. Un método de transferencia de dominio, la transferencia se lleva a cabo entre un dominio de circuito y una red de acceso con conectividad IP para la continuidad de la llamada de voz, VCC, caracterizado por querecibe, de una función de control de dominio CS IMS, ICCF, por una función de transferencia de dominio, DTF, que5 es un módulo funcional de un servicio de aplicación de continuidad de la llamada de voz, VCC AS, un mensaje de invitación, en donde el mensaje de invitación contiene un número de transferencia de dominio VCC, VDN, y un identificador de transferencia, en donde el identificador de transferencia y el VDN son independientes entre sí; ydetermina, por la DTF, que el mensaje de invitación es una solicitud de transferencia para un tramo de sesión existente según el destino del mensaje de invitación que es el VDN de la DTF y el identificador de transferencia, y10 llevar a cabo, por la DTF, una transferencia de dominio de una sesión según el identificador de transferencia. -
- 2.
- El método según la reivindicación 1, en donde diferentes VDN se usan en diferentes sesiones como el identificador de transferencia.
-
- 3.
- El método según la reivindicación 1, en donde cuando la sesión establecida en una red de acceso con conectividad de protocolo de Internet, IP-CAN, el AS de transferencia de dominio asigna el identificador de
15 transferencia asociado a la sesión, y notifica a una terminal de usuario mediante la contención del identificador de transferencia en un mensaje de protocolo de iniciación de sesión, SIP; ocuando la sesión establecida en un dominio de sesión de llamada, CS, el AS de transferencia de dominio asigna el identificador de transferencia asociado a la sesión, y notifica a una terminal de usuario. - 4. El método según la reivindicación 1, en donde cuando la sesión establecida en una IP-CAN, una terminal de20 usuario que inicia una solicitud de transferencia de dominio asigna el identificador de transferencia asociado a la sesión, y entrega el AS de transferencia de dominio mediante la contención del identificador de transferencia en un mensaje SIP; ocuando la sesión establecida en un dominio CS, una terminal de usuario que inicia una solicitud de transferencia de dominio asigna el identificador de transferencia asociado a la sesión, y notifica al AS de transferencia de dominio.25 5. El método según la reivindicación 1, en donde antes de llevar a cabo la transferencia de dominio, según una norma por defecto, una terminal de usuario que inicia una solicitud de transferencia de dominio y el AS de transferencia de dominio respectivamente asignan el mismo identificador de transferencia para la sesión, y la terminal de usuario y el AS de transferencia de dominio respectivamente graban el identificador de transferencia asignado para la sesión; o30 en donde uno de una terminal de usuario que inicia la solicitud de transferencia de dominio y el AS de transferencia de dominio envía un mensaje que contiene un identificador de transferencia nulo al otro para indicar que la sesión a la que se hace referencia es una sesión por defecto.
- 6. El método según la reivindicación 1, en donde cuando la solicitud de transferencia de dominio es una solicitud de transferencia de dominio iniciada en una IP-CAN, una terminal de usuario que inicia la solicitud de transferencia de35 dominio en la IP-CAN envía al AS de transferencia de dominio un mensaje de establecimiento de sesión SIP que contiene el identificador de transferencia asociado a la sesión para indicar que la sesión se transfiere a la IP-CAN; ola solicitud de transferencia de dominio es una solicitud de transferencia de dominio iniciada en un dominio CS, una terminal de usuario que inicia la solicitud de transferencia de dominio en el dominio CS envía al AS de transferencia de dominio el mensaje de solicitud de transferencia de dominio que contiene el identificador de transferencia40 asociado a la sesión para indicar que la sesión se transfiere al dominio CS.
- 7. El método según la reivindicación 3, en donde el AS de transferencia de dominio entrega el identificador de transferencia a la terminal de usuario mediante la contención del identificador de transferencia en un dominio de circuito en una de las siguientes maneras:en la manera 1.1, el AS de transferencia de dominio entrega el identificador de transferencia a la terminal de usuario45 mediante la contención del identificador de transferencia en un mensaje de canal de control de subsistema multimedia IP CS, ICCC;en la manera 1.2, la terminal de usuario y un elemento de red de proxy de usuario entregan el identificador de transferencia entre sí mediante la contención del identificador de transferencia en el mensaje ICCC, y el elemento de red de proxy de usuario y el AS de transferencia de dominio entregan el identificador de transferencia entre sí50 mediante la contención del identificador de transferencia en un mensaje SIP; y34
imagen2 en la manera 1.3, el AS de transferencia de dominio entrega el identificador de transferencia a la terminal de usuario mediante la contención del identificador de transferencia en una señalización SIP y mediante la conversión del identificador de transferencia a un mensaje de información de usuario a usuario, UUI, a través de una función de control de pasarela de medios, MGCF.5 8. El método según la reivindicación 4 o 6, en donde la terminal de usuario notifica al AS de transferencia de dominio mediante la contención del identificador de transferencia en una de las siguientes maneras:en la manera 2.1, cuando se inicia una llamada, la terminal de usuario notifica al AS de transferencia de dominio a través de una entidad de punto de control de servicio, SCP, en una manera de activación de CAMEL mediante la contención del identificador de transferencia en una célula UUI en un mensaje de dominio de circuito;10 en la manera 2.2., cuando se inicia una llamada, la terminal de usuario notifica a un elemento de red de proxy de usuario a través de la entidad SCP en la manera de activación de CAMEL mediante la contención del identificador de transferencia en la célula UUI en el mensaje de dominio de circuito; y el elemento de red de proxy de usuario notifica al AS de transferencia de dominio mediante un mensaje SIP;en la manera 2.3, cuando se inicia la llamada, la terminal de usuario notifica al AS de transferencia de dominio15 mediante la contención del identificador de transferencia en la célula UUI en el mensaje de dominio de circuito y la conversión del mensaje de dominio de circuito que comprende la UUI en el mensaje SIP a través de una MGCF;en la manera 2.4, cuando se inicia la llamada, la terminal de usuario notifica al AS de transferencia de dominio mediante la contención del identificador de transferencia en una subdirección de una parte llamada de la llamada y la conversión de una señalización de dominio de circuito en el mensaje SIP a través de la MGCF;20 en la manera 2.5, cuando se inicia la llamada, la terminal de usuario notifica al AS de transferencia de dominio mediante la indicación del identificador de transferencia de la sesión usando un identificador llamado de la llamada, después de que la MGCF convierte la señalización de dominio de circuito en el mensaje SIP; yen la manera 2.6, cuando se inicia la llamada, la terminal de usuario entrega el identificador de transferencia al AS de transferencia de dominio mediante la contención del identificador de transferencia en un mensaje ICCC.25 9. El método según la reivindicación 1, en donde el identificador de transferencia se contiene en un mensaje SIP en una de las maneras que se describen a continuación:contener el identificador de transferencia en un DT-ID de campo de encabezamiento SIP recientemente definido o un parámetro de encabezamiento SIP recientemente definido Transferencia-ID a un campo de encabezamiento A;contener el identificador de transferencia en el contenido SDP del mensaje SIP; y30 contener el identificador de transferencia en el uso de extensión del campo de encabezamiento Reemplazar SIP original o parámetro de encabezamiento SIP. - 10. Un servidor de aplicaciones de continuidad de llamada de voz, VCC AS, llevar a cabo la transferencia entre un dominio de circuito y una red de acceso con conectividad IP para VCC, que comprende:una unidad de grabación, adaptada para grabar una relación de asociación entre una sesión y un identificador de 35 transferencia cuando se establece la sesión; yuna unidad de función de transferencia de dominio, DTF, adaptada para recibir, de una función de control de dominio CS IMS, ICCF, un mensaje de invitación, en donde el mensaje de invitación contiene el identificador de transferencia y un número de transferencia de dominio VCC, VDN, en donde el identificador de transferencia y el VDN son independientes entre sí, determinar que el mensaje de invitación es una solicitud de transferencia para un tramo de40 sesión existente según el destino del mensaje de invitación que es el VDN de la DTF y el identificador de transferencia, adquirir la sesión asociada al identificador de transferencia de la unidad de grabación, y llevar a cabo una transferencia de dominio en la sesión.
- 11. El AS de transferencia de dominio según la reivindicación 10, que además comprende:una unidad de asignación, adaptada para asignar el identificador de transferencia asociado a la sesión, enviar el45 identificador de transferencia a la unidad de grabación para su grabación, y enviar el identificador de transferencia a la terminal de usuario, cuando se establece la sesión; ouna unidad de recepción, adaptada para recibir un mensaje enviado desde la terminal de usuario cuando se establece la sesión; y35
imagen3 una unidad de extracción, adaptada para extraer el identificador de transferencia del mensaje recibido por la unidad de recepción, y enviar el identificador de transferencia a la unidad de grabación para su grabación.36
Applications Claiming Priority (7)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN200710079849 | 2007-02-15 | ||
| CN2007100798492A CN101247637B (zh) | 2007-02-15 | 2007-02-15 | 一种在多接入方式下提供会话切换的方法及系统 |
| CN200710100497 | 2007-04-17 | ||
| CN200710100497 | 2007-04-17 | ||
| CN200710129687A CN100586234C (zh) | 2007-04-17 | 2007-08-17 | 一种域切换的方法、系统及装置 |
| CN200710129687 | 2007-08-17 | ||
| PCT/CN2008/000309 WO2008101402A1 (fr) | 2007-02-15 | 2008-02-04 | Procédé, système et dispositif pour la commutation de domaine |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2654891T3 true ES2654891T3 (es) | 2018-02-15 |
Family
ID=40886592
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES08706487.9T Active ES2654891T3 (es) | 2007-02-15 | 2008-02-04 | Método, sistema y dispositivo para conmutación de dominio |
Country Status (3)
| Country | Link |
|---|---|
| EP (2) | EP3322219A1 (es) |
| ES (1) | ES2654891T3 (es) |
| WO (1) | WO2008101402A1 (es) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102170672A (zh) * | 2010-02-26 | 2011-08-31 | 中兴通讯股份有限公司 | Ipsplit网络中移动切换的实现方法、系统和装置 |
| CN102209011A (zh) * | 2010-03-29 | 2011-10-05 | 中兴通讯股份有限公司 | 多穴终端建立连接的方法和系统 |
| US20140181203A1 (en) * | 2011-06-15 | 2014-06-26 | Telefonaktiebolaget L M Ericsson (Publ) | Methods and arrangement for dispatching requests |
| CN103036758B (zh) * | 2011-10-10 | 2017-02-15 | 中兴通讯股份有限公司 | 一种标识网与传统网络互联互通的方法、asr及isr |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1297124C (zh) * | 2004-09-30 | 2007-01-24 | 华为技术有限公司 | Ip多媒体子系统中利用电路交换承载业务的系统及方法 |
| CN1801998A (zh) * | 2004-12-31 | 2006-07-12 | 华为技术有限公司 | 从多媒体子系统域到电路子系统域的会话切换方法 |
| CN100505899C (zh) * | 2005-08-04 | 2009-06-24 | 华为技术有限公司 | 第三代移动通信系统的跨域路由控制方法 |
-
2008
- 2008-02-04 EP EP17190806.4A patent/EP3322219A1/en active Pending
- 2008-02-04 EP EP08706487.9A patent/EP2094026B1/en active Active
- 2008-02-04 ES ES08706487.9T patent/ES2654891T3/es active Active
- 2008-02-04 WO PCT/CN2008/000309 patent/WO2008101402A1/zh active Application Filing
Also Published As
| Publication number | Publication date |
|---|---|
| WO2008101402A1 (fr) | 2008-08-28 |
| EP3322219A1 (en) | 2018-05-16 |
| EP2094026A4 (en) | 2009-12-09 |
| EP2094026A1 (en) | 2009-08-26 |
| EP2094026B1 (en) | 2017-11-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8594013B2 (en) | System, method and apparatus for implementing multimedia call continuity | |
| EP1959622B1 (en) | A method, device or network system for selecting the called junction network | |
| US8155084B2 (en) | User equipment, call continuity application server, and network handover method | |
| KR100886548B1 (ko) | 인터넷 프로토콜 멀티미디어 서브시스템 네트워크에서단말의 성능 정보를 전달하기 위한 방법 및 시스템 | |
| EP2543226B1 (en) | Method and apparatus for policy control within network comprising a mobile network and a fixed line network | |
| CN100583843C (zh) | 一种会话路由路径控制方法和系统 | |
| US20100106846A1 (en) | Method and apparatuses for making use of virtual ims subscriptions coupled with the identity of a non sip compliant terminal for non-registered subscribers | |
| ES2442781T3 (es) | Método y aparatos para modificar el estado de dominio de paquetes conmutados | |
| EP2081337A1 (en) | System, method and devices for achieving the multimedia session continuity | |
| JP2010517411A (ja) | 異種無線通信ネットワークにおけるハンドオーバー装置及び方法 | |
| WO2007036147A1 (fr) | Procede et systeme d'etablissement d'un appel initial dans le service de la continuite de service vocal | |
| CN101018400A (zh) | 一种基于话音业务连续性的实现呼叫业务的系统和方法 | |
| KR20130077866A (ko) | 사용자 엔티티들의 세트를 향한 통신들을 관리하기 위한 애플리케이션 서버 | |
| EP2089995B1 (en) | Heterogeneous communication system and method for processing call in the same system | |
| KR101264199B1 (ko) | 음성 호 연속 서비스를 위한 도메인 전환 방법 및 시스템 | |
| KR20060113284A (ko) | 이종망간에 음성 서비스를 지원하는 아이엠에스 시스템 및그에 따른 호 설정 방법 | |
| ES2654891T3 (es) | Método, sistema y dispositivo para conmutación de dominio | |
| CN100586234C (zh) | 一种域切换的方法、系统及装置 | |
| WO2010133185A1 (zh) | 一种单模业务连续性实现方法及单模业务连续性系统 | |
| WO2008040171A1 (fr) | Procédé, système de domaine de commutation de circuits apercevant des informations de sessions multimédia du domaine ims | |
| CN101146367A (zh) | 一种基于话音业务连续性的实现呼叫业务的系统和方法 | |
| CN1913504B (zh) | 一种路由路径控制方法、系统和装置 | |
| EP2040508A1 (en) | Method, apparatuses and program product for controlling IMS services when user is roaming in CS domain | |
| US8644298B1 (en) | Adding a service control channel after session establishment | |
| WO2008125018A1 (fr) | Procédé, système et dispositif pour distinguer une session |