ES2959653T3 - Sistema y método para implementar medios y transferencia de medios entre dispositivos - Google Patents

Abstract

Un método de control de transferencia, que comprende obtener una etiqueta de característica multimedia enviada a una red por un terminal en una solicitud de REGISTRO, SIP o Protocolo de inicio de sesión. La etiqueta de característica de medios contiene información que indica una tecnología de red de acceso que el terminal utilizó para registrar. El método comprende además enviar, a través de una red de acceso seleccionada según la tecnología de red de acceso indicada, una solicitud SIP para una transferencia de control de una sesión entre terminales. La solicitud SIP incluye un campo de encabezado Aceptar-Contacto que contiene una etiqueta de característica de medios configurada con la información de la etiqueta de característica de medios que el terminal incluyó en la solicitud de REGISTRO SIP. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN

Sistema y método para implementar medios y transferencia de medios entre dispositivos

Antecedentes

La presente descripción se refiere en general a la gestión de medios y/o de funciones de control para sesiones en sistemas de comunicación móviles y más específicamente a un sistema y un método para implementar transferencia de medios y/o de funciones de control entre dispositivos.

Tal como se utiliza en el presente documento, el término "dispositivo" puede referirse a los términos "estación móvil" (MS), "agente de usuario" o "equipo de usuario" (UE), que pueden incluir dispositivos electrónicos tales como teléfonos fijos y móviles, asistentes digitales personales, ordenadores de mano o portátiles, teléfonos inteligentes, impresoras, máquinas de fax, televisores, decodificadores y otros dispositivos de visualización de video, equipos de audio para el hogar y otros sistemas de entretenimiento para el hogar, sistemas de control y monitorización del hogar (por ejemplo, monitorización del hogar, sistemas de alarma y sistemas de control climático), electrodomésticos mejorados, tales como refrigeradores informatizados y dispositivos similares que tienen capacidades de comunicación en red. En algunas configuraciones, UE puede referirse a un dispositivo móvil inalámbrico. Dichos UE que son dispositivos inalámbricos móviles pueden incluir o no un módulo de memoria que es interno al dispositivo o que se puede quitar, siendo ejemplos, entre otros: un módulo de identidad de abonado (SIM) o una tarjeta UICC que posiblemente incluya una aplicación ISIM, Compact Flash, MicroSD, R-UIM, etc. La funcionalidad SIM/UICC también puede proporcionarse mediante software de seguridad SIM/UICC descargable. Los términos también pueden referirse a dispositivos que tienen capacidades similares pero que no son fácilmente transportables, como ordenadores de escritorio, decodificadores, TV, IPTV o nodos de red. El término dispositivo también cubre el término agente de usuario (UA) SIP que puede ser fijo o móvil. Cuando un UA es un nodo de red, el nodo de red podría actuar en nombre de otra función tal como un UA o un dispositivo de línea fija y simular o emular el UA o dispositivo de línea fija. Por ejemplo, para algunos UA, el cliente SIP IMS que normalmente residiría en el dispositivo en realidad reside en la red y transmite información de mensajes SIP al dispositivo utilizando protocolos optimizados. En otras palabras, algunas funciones que tradicionalmente realizaba un UA se pueden distribuir en forma de un UA remoto, donde el UA remoto representa el UA en la red. El término "UA" también puede referirse a cualquier componente de hardware o software que pueda finalizar una sesión de comunicación que podría incluir, entre otras, una sesión SIP. Además, los términos "agente de usuario", "UA", "equipo de usuario, "UE" y "nodo" podrían usarse como sinónimos en el presente documento. Los expertos en la materia apreciarán que estos términos se pueden usar indistintamente dentro de la aplicación.

Un UE puede operar en una red de comunicación inalámbrica que proporcione comunicaciones de datos de alta velocidad. Por ejemplo, el UE puede operar según las tecnologías del sistema global para comunicaciones móviles (GSM) y del servicio general de radio por paquetes (GPRS). Hoy en día, dicho UE puede funcionar además según velocidades de datos mejoradas para evolución de GSM (EDGE), o GPRS mejorado (EGPRS) o GPRS mejorado fase 2 (EGPRS2). Otras redes inalámbricas que los UE pueden operar incluyen, entre otras, CDMA, UMT<s>, E-UTRAN, WiMax y WLAN (por ejemplo, 802.11). Los UE también pueden operar en entornos de redes fijas como xDSL, redes de cable DOCSIS, ethernet u redes ópticas. Algunos UE pueden ser capaces de operación multimodo, donde pueden operar en más de una tecnología de red de acceso, ya sea en una única red de acceso a la vez o en algunos dispositivos que utilizan múltiples tecnologías de acceso simultáneamente.

EDGElEGPRS/EGPRS2 son ejemplos de tecnología de comunicaciones móviles digitales que permiten una mayor velocidad de transmisión de datos y una mayor fiabilidad de transmisión de datos. La red a menudo se clasifica como una tecnología de red de 2,75G. EDGE se ha introducido en las redes GSM de todo el mundo aproximadamente desde 2003, inicialmente en América del Norte. EDGE/EGPRS/EGPRS2 se puede utilizar en cualquier aplicación de conmutación de paquetes, como aquellas que implican una conexión a internet. Las aplicaciones de datos de alta velocidad, como vídeo y otros servicios multimedia, se benefician de la mayor capacidad de datos de EGPRS. Un UE también puede operar en otras tecnologías inalámbricas como, entre otras, Wimax, Wifi, etc.

A medida que la red de comunicaciones se vuelve cada vez más compleja, la infraestructura de la red se está alejando del concepto basado en telefonía de una identidad única, como un número de teléfono, que se mapea de manera única a una única línea telefónica, teléfono celular u otro UE. Por ejemplo, el protocolo de inicio de sesión (SIP) y otras tecnologías de comunicación basadas en internet relacionadas soportan el registro de múltiples dispositivos en una red, compartiendo cada dispositivo la misma identidad de usuario (por ejemplo, un SIP o un identificador uniforme de recursos (URI) Tel), o un grupo de identidades superpuestas o idénticas. Este grupo de identidades se denomina conjunto de registro implícito (IRS). Según la evolución de las redes de comunicación, SIP también es capaz de soportar varios tipos de medios, incluidos, entre otros, texto, datos para aplicaciones, audio y vídeo, etc., dentro de la misma sesión establecida entre una red y un UE. Los expertos en la materia apreciarán que los dispositivos/SIP UA pueden tener diferentes capacidades, como una pantalla pequeña que soporte vídeo o un IPTV que soporte HDTV. Por lo tanto, sería ventajoso si una sesión entre 2 o más dispositivos/SIP UA iniciada en una pantalla pequeña que tuviera un componente de video y voz pudiera mover su componente de video a la HDTV cuando el usuario estuviera cerca de esta. Esta capacidad se denomina transferencia entre UE (IUT) y se define en 3GPP TS 23.237 y 3GPP TS 24.292.

Para proporcionar un funcionamiento eficaz de la red y los dispositivos asociados en IUT, PNM u otros servicios como BlackBerry Unite, algunas redes incluyen UE administradores o controladores que tienen la capacidad de gestionar los dispositivos o sesiones que se pueden entregar dentro de un grupo de UE objetivo que están, cada uno, correlacionados con un servidor de red. En ese caso, el UE administrador o controlador puede configurarse para gestionar el funcionamiento de diversas características/parámetros disponibles a través de uno o más UE. En algunos casos, la función de controlador puede transferirse desde un UE controlador a otro UE que tenga la capacidad de proporcionar funcionalidad de controlador. En algunos casos, varios UE pueden actuar como controladores. En algunos casos, un UE controlador puede implementar funcionalidad de controlador de gestión de red personal (PNM). En algunos casos, un UE tiene múltiples agentes de usuario, uno por red de acceso. De manera similar, un UA administrador o controlador puede configurarse para gestionar el funcionamiento de diversas funciones o parámetros disponibles a través de uno o más UA. Un UA administrador o controlador también puede ser un UE administrador o controlador. A continuación, los términos UE y UA se utilizan a menudo indistintamente, a menos que quede claro por el contexto.

SIP permite configurar un UE de manera que pueda ser notificado dependiendo de las identidades de los remitentes para el filtrado de comunicaciones y el desvío de servicios en función del UE al que se dirige una comunicación. Por ejemplo, un usuario puede configurar un servicio de reenvío de llamadas/comunicaciones para permitir que se proporcione una identidad de usuario pública particular (como un número de teléfono residencial o una dirección de correo electrónico) a miembros de la familia para comunicarse con un usuario directamente en el teléfono móvil del usuario y los amigos o familiares pueden ser reenviados al correo de voz personal, mientras que los compañeros de trabajo son reenviados a un teléfono de la oficina que, en última instancia, lo reenvía al correo de voz corporativo.

Como tal, SIP permite que un usuario tenga identidades consistentes en múltiples UE, donde los UE pueden incluir teléfonos residenciales, teléfonos móviles personales, teléfonos de trabajo, teléfonos móviles corporativos, teléfonos de casas de vacaciones, clientes de voz sobre IP (VoIP) de ordenadores portátiles, faxes, etc. Las identidades de usuario públicas consistentes también permiten que un usuario sea accesible en cualquier UE que el usuario esté usando actualmente. Esta flexibilidad minimiza la necesidad de mantener una gran lista de contactos orientados a dispositivos para identificar a cada usuario en una libreta de direcciones y tener que decidir qué dispositivo es mejor al intentar establecer una comunicación: cada usuario (y todos sus teléfonos celulares, residenciales y móviles asociados, ordenadores, etc.) pueden ser identificados mediante una única identificación. Así, es posible comunicarse con alguien usando solo una identificación única con la red y/o el usuario de terminación determinando el UE más apropiado para contactar con el individuo.

En redes que implementan SIP y tienen UE administradores o controladores, es deseable garantizar que se establezcan nuevas sesiones con los UE que tengan la mejor capacidad para manejar el contenido, que puede incluir varios tipos de medios. No sería lo más apropiado, por ejemplo, aceptar medios que incluyan contenido de vídeo en un teléfono de oficina convencional que no tenga medios para mostrar el contenido de vídeo o que tenga una pantalla de vídeo muy pequeña cuando hay una televisión o una pantalla/monitor de ordenador disponible para su uso por el usuario. Además, cuando un UE ya está involucrado en una sesión que utiliza uno o más tipos de medios y el UE recibe una invitación para añadir o modificar uno o más tipos de medios a la sesión, se debe identificar un UE controlador para que el usuario pueda solicitar transferir el nuevo tipo de medio a un UE diferente que pueda soportar y procesar o representar el nuevo tipo de medio. Por ejemplo, si un usuario está participando en una sesión de audio en el teléfono móvil del usuario y el usuario desea aceptar medios de transmisión de video añadidos en otro dispositivo, el UE controlador proporciona al usuario la capacidad de seleccionar otro dispositivo, tal como un PC portátil, para recibir y mostrar los medios de transmisión de video añadidos, según la capacidad del dispositivo y las preferencias del usuario.

Adicionalmente, el usuario puede utilizar diferentes dispositivos como controladores de la sesión durante el tiempo de la sesión. Por ejemplo, un usuario puede aceptar la sesión o uno o más componentes de medios de la sesión en su teléfono móvil fuera en el jardín, pero luego moverse dentro de la casa y transferir tanto los componentes de audio como de video a su ordenador de escritorio y ya que el usuario desea a continuación controlar la sesión desde su ordenador de sobremesa también transfiere el control de la sesión desde su teléfono móvil a su ordenador de sobremesa. Finalmente, la funcionalidad de estado del controlador solo deberá transferirse entre ciertos UE miembros capaces de ser dispositivos controladores (por ejemplo, es poco probable que las televisores básicos tengan la capacidad de interactuar con el usuario para realizar la funcionalidad de controlador) y autorizados para recibir la función de controlador por la red. Por consiguiente, es importante dar a conocer un mecanismo seguro para distribuir y procesar solicitudes de transferencia para la sesión, los medios y la funcionalidad de controlador entre un conjunto de UE que potencialmente pueden ser utilizados por diferentes abonados (por ejemplo, dispositivos compartidos como teléfonos residenciales y televisores).

El documento "Transfer for Media modifications", 3GPP DRAFT, F-06921, da a conocer la continuidad del servicio y soluciones para la movilidad de flujos de medios y control del servicio de una sesión entre diferentes dispositivos bajo la misma suscripción.

El documento "3rd Generation Partnership Project; Technical Specification Group Core NetWork and Termináis; IP multimedia cali control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SOP); Stage 3 (Release 8)", TS 24.229, da a conocer un protocolo de control de llamadas para uso en el subsistema de red central multimedia IP.

El documento "3rd Generation Partnership Project; Technical Specification Group Services and Architecture; IP Multimedia Subsystem (IMS) Service Continuity; Stage 2 (Release 9)", TS 23. 237, describe los requisitos arquitectónicos y los procedimientos para la prestación de la continuidad del servicio IMS.

Compendio

La invención está definida por las reivindicaciones adjuntas.

Breve descripción de los dibujos

Para una comprensión más completa de esta descripción, a continuación se hace referencia a la siguiente breve descripción, tomada en relación con los dibujos adjuntos y la descripción detallada, en donde los numerales de referencia similares representan partes similares.

La figura 1 ilustra a continuación un ejemplo para transferir medios y función de controlador IUT entre UE asociados con una red;

la figura 2 ilustra una red de comunicaciones a modo de ejemplo para implementar el presente sistema para realizar transferencia de función de controlador y/o medios IUT entre UE conectados a la red;

la figura 3 ilustra un flujo de ejemplo para registrar un UE con una red IMS que provoca el registro con un SCC AS; la figura 4 ilustra un objeto de gestión de lista de IUT permitido a modo de ejemplo para identificar uno o más UE con capacidad de IUT que incluyen UE controlado o tanto UE controlador como UE controlado;

Las figuras 5a y 5b ilustran los parámetros y DDF del MO de lista de IUT permitido a modo de ejemplo mostrado en la figura 4;

la figura 6 ilustra un flujo de ejemplo para proporcionar la función de controlador IUT a un UE donde sólo se requiere autorización de un único UE controlador;

la figura 7 ilustra un flujo de ejemplo para proporcionar la función de controlador IUT a un UE donde sólo se requiere autorización de más de un UE controlador;

la figura 8 ilustra un flujo de ejemplo para transferir el medio A y la función de controlador a un UE según lo solicitado por un UE controlador IUT;

la figura 9 ilustra un flujo de ejemplo para transferir el medio A y la función de controlador desde el UE-1 al UE-2, la solicitud de sesión entrante incluye un identificador de función de controlador y se entrega a través del punto de referencia Gm y el medio A se transmite a través de una red de conmutación de circuitos;

la figura 10 ilustra un flujo de ejemplo para transferir el medio A y la función de controlador desde el UE-1 al UE-2, donde la solicitud de sesión entrante incluye un identificador de función de controlador y se entrega a través del punto de referencia I1 y el medio A se transmite a través de una red de CS;

la figura 11 ilustra múltiples UE asociados con un usuario, se establecen sesiones colaborativas entre un subconjunto de los UE;

Las figuras 12a y 12b ilustran flujos de ejemplo para un establecimiento de sesión colaborativa de terminación al recibir una solicitud de invitación de sesión;

la figura 13 ilustra un flujo de ejemplo para transferir la funcionalidad de controlador IUT desde un primer PS UE a un segundo PS UE, donde el primer y el segundo UE pueden usar la misma portadora o portadoras diferentes;

la figura 14 es una ilustración de un flujo de mensajes alternativo para transferencia de funcionalidad de medios/controlador a otro UE dentro de una sesión colaborativa utilizando el punto de referencia Gm;

la figura 15 es una ilustración de un flujo de mensajes alternativo para la transferencia de funcionalidad de medios/controlador a otro UE dentro de la sesión colaborativa utilizando el punto de referencia I1;

la figura 16 es una ilustración de un flujo de mensajes alternativo para la transferencia de información de sesión en curso iniciada por controlador;

la figura 17 ilustra un sistema de comunicaciones inalámbricas que incluye una realización del agente de usuario; la figura 18 muestra un diagrama de bloques del agente de usuario que incluye un procesador de señales digitales (DSP) y una memoria;

la figura 19 ilustra un entorno de software que puede implementarse mediante un procesador de un agente de usuario;

la figura 20 ilustra un ejemplo de un sistema que incluye un componente de procesamiento adecuado para implementar un método para proporcionar continuidad a sesiones en transición entre redes;

la figura 21 es una ilustración de una estructura a modo de ejemplo para almacenar información dentro de una red que describe UE controladores y controlados asociados;

la figura 22 es una ilustración de información a modo de ejemplo almacenada en la red, tal como dentro de un HSS; y

la figura 23 es una ilustración de indicadores de ejemplo con posición de valor de bit de referencia.

Descripción detallada

La presente descripción supera los inconvenientes antes mencionados al proporcionar un sistema y un método para la gestión de medios y/o de funciones de control en sistemas de comunicaciones móviles y más específicamente un sistema y un método para implementar la transferencia de medios y/o la transferencia de funciones de control entre dispositivos.

En un ejemplo, el método para transferir la función de controlador desde un primer equipo de usuario (UE) a un segundo UE que posiblemente pertenece a la misma parte incluye establecer una sesión para comunicar contenido de medios entre el primer UE y un tercer UE. Al primer UE se le asigna inicialmente la función de controlador para la sesión. El método incluye recibir una solicitud del primer UE para transferir al menos un subconjunto de función de controlador para la sesión al segundo UE, y determinar la capacidad del segundo UE para implementar una función de controlador. Cuando el segundo UE tiene la capacidad de operar como controlador, el método incluye asignar el al menos un subconjunto de función de controlador para la sesión al segundo UE, y responder a la solicitud para transferir al menos un subconjunto de función de controlador para la sesión para notificar al primer UE que libere la sesión.

En otro ejemplo, el método para transferir la función de controlador desde un primer equipo de usuario (UE) a un segundo UE incluye establecer una sesión para comunicar contenido de medios entre el primer UE y un tercer UE. Al primer UE se le asigna inicialmente la función de controlador para la sesión y el primer UE incluye una interfaz. El método incluye recibir una solicitud a través de la primera interfaz de UE para transferir la función de controlador para la sesión al segundo UE, transmitir una solicitud de transferencia de función de controlador de sesión a un servidor de aplicaciones y recibir una respuesta de transferencia desde el servidor de aplicaciones. Cuando la respuesta de transferencia indica que el primer UE debe liberar la función de controlador de sesión, el método incluye liberar la función de controlador de sesión.

En otro ejemplo, un método para transferir una sesión para comunicar contenido de medios entre un primer equipo de usuario (UE) y un tercer UE incluye asignar la función de controlador del primer UE para la sesión, recibir una solicitud del primer UE para transferir la sesión para comunicar contenido de medios a un segundo UE, y determinar la capacidad del segundo UE para recibir la sesión para comunicar contenido de medios. Cuando el segundo UE tiene la capacidad de recibir la sesión para comunicar contenido de medios, el método incluye transferir la sesión para comunicar contenido de medios al segundo UE, y responder a la solicitud para transferir la sesión para comunicar contenido de medios al segundo UE para notificar al primer UE que libere la sesión.

Los diversos aspectos de la descripción se describen a continuación haciendo referencia a los dibujos adjuntos, en la totalidad de los cuales los numerales iguales se refieren a elementos iguales o correspondientes. Debe entenderse, sin embargo, que los dibujos y la descripción detallada relacionada con los mismos no pretenden limitar el objeto reivindicado a la forma particular dada a conocer. Más bien, la intención es cubrir todas las modificaciones, equivalentes y alternativas que entren dentro del espíritu y alcance del objeto reivindicado.

Tal como se utilizan en el presente documento, los términos "componente", "sistema" y similares pretenden referirse a una entidad relacionada con ordenador, ya sea hardware, una combinación de hardware y software, software o software en ejecución. Por ejemplo, un componente puede ser, entre otros, un proceso que se ejecuta en un procesador, un procesador, un objeto, un ejecutable, un hilo de ejecución, un programa y/o un ordenador. A modo de ilustración, tanto una aplicación que se ejecuta en un ordenador como el ordenador pueden ser un componente. Uno o más componentes pueden residir dentro de un proceso y/o hilo de ejecución y un componente puede estar localizado en un ordenador y/o distribuido entre dos o más ordenadores.

La expresión "a modo de ejemplo" se utiliza en el presente documento con el significado de servir como ejemplo, instancia o ilustración. Cualquier aspecto o diseño descrito en el presente documento como "a modo de ejemplo" no necesariamente debe interpretarse como preferido o ventajoso sobre otros aspectos o diseños.

Además, la materia dada a conocer puede implementarse como un sistema, método, aparato o artículo de fabricación usando programación estándar y/o técnicas de ingeniería para producir software, software inalterable, hardware o cualquier combinación de los mismos para controlar un ordenador o dispositivo basado en procesador para implementar los aspectos detallados en el presente documento. El término "artículo de fabricación" (o alternativamente, "producto de programa informático") tal como se utiliza en el presente documento pretende abarcar un programa informático accesible desde cualquier dispositivo, soporte o medio legible por ordenador. Por ejemplo, los medios legibles por ordenador pueden incluir, entre otros, dispositivos de almacenamiento magnético (por ejemplo, disco duro, disquete, tiras magnéticas y similares), discos ópticos (por ejemplo, disco compacto (CD), disco versátil digital (DVD) y similares), tarjetas inteligentes y dispositivos de memoria flash (por ejemplo, tarjetas, memorias USB y similares). Además, se debe apreciar que se puede emplear una onda portadora para transportar datos electrónicos legibles por ordenador tales como los utilizados para transmitir y recibir correo electrónico o para acceder a una red tal como internet o una red de área local (LAN). Por supuesto, los expertos en la materia reconocerán que se pueden realizar muchas modificaciones a esta configuración sin apartarse del alcance o espíritu del objeto reivindicado.

El presente sistema proporciona gestión de medios y/o de funciones de control para implementar transferencia de medios o transferencia de funciones de control entre dispositivos asociados con una red de comunicaciones. En una implementación, el sistema realiza transferencia entre UE (IUT) según 3GPP TS 23.237 para transferir uno o más componentes de medios de una sesión o algunos o todos los flujos de medios y/o función de controlador (controlador IUT) desde uno o más UA o UE SIP controladores a uno o más UA o UE SIP controlados. El sistema puede implementarse en varias redes de comunicación en las que los UE están configurados para que se les asigne una única identificación compartida (por ejemplo, Tel URI, SIP URI, MSISDN, C-MSISDN, GRUU (URI de agente de usuario enrutable globalmente), etc.), o tener información de identificación que se superpone con otros UE asociados con la red. Dentro de la red, cada UE puede iniciar varias sesiones de comunicación, implicando cada sesión la comunicación de datos que pueden incluir múltiples tipos de medios tales como, entre otros, datos para aplicaciones (aplicación de tipo de medios), voz, texto, video (incluidos varios esquemas de codificación) y audio.

En una configuración, el sistema se implementa a través de una red que soporta SIP y tiene varios UA o UE SIP administradores o controladores además de UA o UE SIP no controladores o controlados. La función de controlador puede trasladarse de un primer UE controlador a otro UE dependiendo, entre otras cosas, de reglas de la red, políticas del operador, preferencias del usuario u otros requisitos del sistema. En algunos casos, los UE que tienen función de controlador o controlado pueden proporcionarse a través de una red en la que los UE controlados están configurados de manera similar a los UE controladores que tienen capacidades funcionales y diseños de sistema similares. Cuando un UE entre los UE se registra por primera vez en una red, el primer UE que soporta la funcionalidad de controlador registrado con el servidor inalámbrico puede designarse automáticamente como UE administrador o controlador. En algunos casos, cuando una red recibe una solicitud de transferencia inicial para sesiones colaborativas enviada por un UE que soporta la funcionalidad de controlador, el UE puede ser designado automáticamente como UE administrador o controlador. Sin embargo, se pueden emplear otros algoritmos para determinar el UE controlador preliminar entre una colección de UE. Después de conectarse a la red, un usuario puede opcionalmente cambiar la designación del controlador del primer UE registrado a uno de los otros UE registrados bajo el control del usuario o de otros usuarios asociados.

Utilizando el presente sistema, una red que presta servicio a un usuario con múltiples UE, cada uno de los cuales comparte una identificación común, puede recibir una invitación para participar en una sesión que incluye varios tipos de medios. Después de recibir la invitación, la red transfiere, reenvía o envía la invitación de sesión (por ejemplo, SIP INVITE o SIP Re-INVITE) al UE del usuario según los tipos de medios descritos en la invitación, el UE preferido especificado por el usuario, u otra información disponible para el UE controlador o la red. Si el usuario ya está involucrado en una sesión usando varios tipos de medios y se recibe una oferta (por ejemplo, un protocolo de descripción de sesión (SDP OFERTA) para la misma sesión que añade, elimina o modifica uno o más tipos de medios, se puede identificar un UE controlador para transferir los nuevos tipos de medios y funciones de control de sesión a un UE diferente.

En una implementación, cuando el UE (por ejemplo, un ICS UE) recibe una solicitud SIP INVITE que contiene SDP para establecer una sesión usando una portadora IP, el ICS UE establece la sesión según 3GPP TS 24.229, pero con las siguientes aclaraciones. En primer lugar, si la solicitud SIP INVITE contiene una cabecera diálogo objetivo que contiene parámetros de diálogo que corresponden a un diálogo existente (o un diálogo en el proceso de establecimiento) entre el ICS UE y el servidor de aplicaciones de coherencia y continuidad del servicio (SCC AS), el ICS UE trata la solicitud SIP INVITE como otro diálogo que forma parte de la misma sesión que el diálogo identificado por los parámetros de diálogo contenidos en la cabecera diálogo objetivo. En segundo lugar, si la solicitud SIP INVITE no contiene una cabecera diálogo objetivo pero hay un diálogo existente (o un diálogo en proceso de establecimiento) entre el ICS UE y el SCC AS, el SCC AS puede verificar si los parámetros de diálogo para esta solicitud corresponden a los parámetros de diálogo recibidos en una cabecera diálogo objetivo recibido en un diálogo existente (o un diálogo en proceso de establecimiento) entre el ICS UE y el SCC AS y, de ser así, el ICS UE puede tratar la solicitud SIP INVITE como otro diálogo que forma parte de la misma sesión que el diálogo en el que se recibió la cabecera diálogo objetivo. Esta segunda aclaración puede cubrir la posibilidad de que las solicitudes lleguen fuera del orden en que fueron enviadas.

Un UE controlador configurado para implementar IUT según el presente sistema puede configurarse para realizar uno o más de uno de los siguientes: añadir uno o más flujos de medios a una sesión creando un nuevo tramo de acceso en un UE diferente, añadir uno o más flujos de medios a una sesión en un tramo de acceso existente en un UE diferente, eliminar uno o más flujos de medios de una sesión en un tramo de acceso en un UE diferente, proporcionar control del servicio MMTel con medios en un UE diferente (ver, por ejemplo, 3GPP TS 22.173), y proporcionar una actualización de características de los medios en diferentes UE. Por consiguiente, cada UE controlador puede configurarse para establecer y/o liberar sesiones colaborativas que proporcionan una o más sesiones ancladas con una entidad o nodo de red particular tal como un SCC AS. Mientras mantiene una sesión colaborativa en curso, cada UE controlador puede transferir flujos de medios de la sesión colaborativa a un UE objetivo. Además, cada UE controlador puede configurarse para transferir todos o algunos de los uno o más flujos de medios disponibles a un UE objetivo con o sin establecer una sesión colaborativa. Si se transfieren todos los flujos de medios a un UE objetivo, se puede liberar la sesión existente en el UE controlador.

En una implementación de sistema de ejemplo, para implementar transferencia entre UE (IUT), el SCC AS utiliza el punto de referencia ISC hacia el S-CSCF para la ejecución de la transferencia entre UE. Por ejemplo, para habilitación y ejecución de IUT, el SCC AS puede analizar primero la información requerida para transferencia entre UE, tal como se describe a continuación, y decidir qué redes de acceso deben ejecutarse según la política del operador y las preferencias del usuario. El SCC AS puede entonces rechazar la solicitud de transferencia entre UE si no está alineada con la política del operador. El SCC AS puede recuperar del servidor de abonado local (HSS) después del registro el C MSISDN vinculado a la identidad de usuario privada del IMS almacenada en el perfil de usuario en el HSS, y recuperar del HSS después del registro de un tercero la funcionalidad de controlador para transferencia entre UE vinculada a la identidad de usuario privada del IMS almacenada en el perfil de usuario en el HSS. El SCC AS también puede determinar si se permite a un UE, y es capaz de realizar funcionalidad de controlador para la transferencia entre UE, correlacionar la solicitud de transferencia entre UE con la sesión anclada, utilizando la información proporcionada en el SIP INVITE entrante o en la solicitud de transferencia entre UE entrante, y ejecutar la transferencia entre UE de IMS entre diferentes UE que pertenecen a la misma suscripción de IMS conectados a través de las mismas o diferentes redes de acceso. El SCC AS también puede proporcionar datos de cobro específicos de la transferencia IUT, proporciona a un UE controlador información de los UE transferibles y decidir, basándose en el análisis de los diversos factores de entrada relacionados con la continuidad del servicio, si se debe actualizar la política del operador proporcionada para transferencia entre UE. El SCC AS también puede generar y actualizar la política del operador para transferencia entre UE enviando la política del operador al UE a través de OMA DM, incluyendo la prioridad entre la política del operador y las preferencias del usuario, que podría usarse también para iniciar el procedimiento de transferencia entre UE para sesiones en curso y determinar si enviar a un UE controlador una invitación de sesión entrante recibida desde una parte remota para que el UE controlador de terminación pueda iniciar la transferencia entre UE.

Generalmente, el SCC AS proporciona funcionalidad para combinar y/o dividir flujos de medios sobre una o más redes de acceso según sea necesario para transferencias de sesión, terminación de sesión, o tras solicitud del UE para añadir flujos de medios sobre una red de acceso adicional durante la configuración de una sesión, o tras solicitud del UE para añadir y/o eliminar flujos de medios a través de una o más redes de acceso a sesiones existentes.

Al manejar flujos de medios de una sesión IMS, el SCC AS puede tener en cuenta los servicios asociados con la sesión.

Para enrutar MÉTODOS SIP (como SIP INVITE) a través de un tramo de acceso particular, es necesario identificar el flujo de registro particular que corresponde a ese tramo de acceso.

Draft-ietf-sip-outbound describe cómo un UA o UE SIP puede registrarse en múltiples flujos de registro mediante los cuales las solicitudes pueden llegar al UA o UE. Como es soportado con 3GPP IMS, el UE utiliza el mecanismo definido en Draft-ieff-sip-outbound para registrarse utilizando diferentes flujos a través de diferentes redes de acceso. Cada flujo a través de las diferentes redes de acceso puede, como se define en Draft-ieff-sip-outbound, contener un parámetro de cabecera de contacto "reg-id" diferente en la cabecera de contacto de la solicitud SIP REGISTER. Al registrarse, el UE incluye una cabecera P-Access-Network-Info en la solicitud SIP REGISTER como se describe en 3GPP TS 24.229: en la tabla 1 se muestra un ejemplo de sintaxis del campo de cabecera P-Access-Network-Info extendido según 3GPP TS 24.229.

Tabla 1

Como puede verse en la sintaxis de P-Access-Network-Info, el tipo de acceso indica la tecnología de red de acceso utilizada por la red a través de la cual se enruta la solicitud SIP REGISTER. Sin embargo, aunque el parámetro "reg id" identifica de forma única el flujo de registro, no existe ningún mecanismo actual que permita a la red ordenar que un SIP METHOD como SIP INVITE se dirija a través de un flujo de registro particular. Para habilitar esto, es posible definir e incluir en la cabecera de contacto de la solicitud SIP REGISTER una etiqueta de característica de medios que identifique el flujo de registro (el parámetro "reg-id" no es una etiqueta de característica de medios). A continuación se muestran ejemplos de dos posibles realizaciones de dicha etiqueta de característica de medios. Los expertos en la materia apreciarán que se puede utilizar cualquier construcción de caracteres alfanuméricos apropiados para transmitir el mismo significado desde el SIP UA IUE.

En el primer ejemplo mostrado en la tabla 2, se define la etiqueta de característica g.3gpp.icsflow, que permite incluir una cadena en la etiqueta de característica de medios que identifica el flujo. Esta cadena podría contener el mismo valor de identificador que en el parámetro "reg-id" (por ejemplo, g.3gpp.icsflow=[regid]) o podría contener alguna otra cadena; sin embargo, en una implementación la cadena debe ser diferente para cada flujo de registro. El UE podría permitir al usuario definir marcadores comprensibles para los humanos para la cadena utilizada en la etiqueta de característica de medios, ya que el usuario puede necesitar usar estos marcadores para indicar a qué tramo de acceso desea transferir un tipo de medio cuando realiza una transferencia de medios (por ejemplo, "internet", "TV por cable", "celular", "WLAN").

Tabla 2

En otro ejemplo mostrado en la tabla 3, la etiqueta de característica de medios g.3gpp.ics existente se mejora para indicar también si el registro se realiza directamente desde el teléfono móvil o desde un nodo de red y también indica qué flujo de registro se está utilizando.

Tabla 3

El UE, al registrarse, incluye la cabecera P-Access-Network-Info que contiene la identificación de la tecnología de acceso utilizada en ese tramo de acceso en la solicitud SIP REGISTER junto con una etiqueta de característica de medios que contiene un identificador único para el flujo, tal como se describió anteriormente en la cabecera de contacto de la solicitud SIP REGISTER.

El SCC AS u otro nodo de red puede obtener la etiqueta de característica de medios suscribiéndose al paquete de eventos de registro según RFC 3860 o a los procedimientos mejorados de registro de terceros (por ejemplo, solicitud SIP REGISTER entrante incluida en el cuerpo de la solicitud de SIP REGISTER de terceros). El SCC AS también puede obtener la cabecera P-Access-Network-Info a partir de la solicitud de SIP REGISTER de terceros.

El SCC AS también puede obtener información sobre el estado de registro que necesita para implementar requisitos específicos de los servicios centralizados (ICS) de IMS a partir de cualquier solicitud REGISTER de terceros recibida (por ejemplo, incluida la información contenida en el cuerpo de la solicitud REGISTER de terceros), tal como se especifica en 3GPP. TS 24.229, cualquier paquete de eventos de reg recibido, tal como se especifica en 3GPP TS 24.229, o la interfaz Sh, tal como se especifica en 3GPP TS 29.328 y 3GPP TS 29.329, por ejemplo. Usando estos mecanismos, el SCC AS puede obtener el tipo de acceso y, si están presentes, los valores de clase de acceso de la cabecera P-Access-Network-Info y el valor de la etiqueta de característica de medios g.3gpp.icsflow y asociar el tipo de acceso y, si están presentes, valores de clase de acceso con el valor de la etiqueta de característica de medios g.3gpp.icsflow para que una solicitud pueda enrutarse a través de un flujo específico que corresponda a una IP-CAN específica.

El SCC AS, u otro nodo de red, almacena la información de tipo de acceso y/o clase de acceso (posiblemente incluyendo la información de ubicación asociada) obtenida de la cabecera P-Access-Network-Info en asociación con el identificador de tramo/flujo de acceso obtenido de la etiqueta de característica de medios. Se debe observar que el P-CSCF también puede incluir tipos de acceso adicionales o valores de clase de acceso en la cabecera P-Access-Network-Info que contiene la clase de acceso y el tipo de acceso verificados por la red e indicados como tales mediante la inclusión del parámetro "np" (red proporcionada). Según la disponibilidad y la política del operador, el tipo de acceso y/o la clase de acceso a partir de la cabecera P-Access-Network-Info proporcionada por el UE o la cabecera P-Access-Network-Info proporcionada por la red o ambas, pueden almacenarse en asociación con el identificador de tramo/flujo de acceso obtenido de la etiqueta de característica de medios.

Cuando el SCC AS (u otro nodo de red) basándose en una política de operador o preferencias del usuario o configuración de usuario determina que una solicitud que contiene ciertos tipos de medios ofrecidos debe enrutarse a través de un determinado tramo de acceso, el SCC AS (u otro nodo de red) obtiene el identificador de tramo/flujo de acceso obtenido previamente de la etiqueta de característica de medios que se almacena en asociación con el tipo de acceso y/o la clase de acceso de cabecera P-Access-Network-Info. A continuación, el SCC AS (u otro nodo de red) incluye en la solicitud una cabecera de aceptar-contacto que contiene la etiqueta de característica de medios (por ejemplo, g.3gpp.icsflow) con el valor establecido en el identificador de tramo/flujo de acceso que se asoció con el tipo de acceso y/o la clase de acceso para el tramo de acceso por el que se va a enrutar la solicitud. Los parámetros "requerir" y "explícito" también pueden incluirse opcionalmente en la cabecera de aceptar-contacto asociada con la etiqueta de característica de medios que contiene el identificador de tramo/flujo de acceso. Como resultado, la solicitud se enruta al UE utilizando el tramo de acceso deseado utilizando el mecanismo descrito en RFC 3841 y, correspondientemente, si se acepta la solicitud, los medios también se establecen utilizando ese tramo de acceso.

En algunas implementaciones, la política del operador de red la proporciona el operador en la red y puede comunicarse al UE durante el provisionamiento inicial o mediante gestión de dispositivos OMA, por ejemplo. La política del operador puede comunicarse al UE, a través de gestión de dispositivos OMA, siempre que el operador actualice la política.

La política del operador puede indicar, para cada tipo de medio o grupo de medios soportado, una lista de redes de acceso que están restringidas para originar sesiones y la transferencia de sesión, una lista de redes de acceso preferidas (en orden de prioridad) para ser utilizadas por el UE con capacidades SC para originar sesiones y transferencia de sesión, cuando esas redes de acceso estén disponibles y la transferencia de sesión sea posible, y si el UE con capacidades SC "deberáVdeberíaVpuede" comenzar a transferir uno o varios flujos de medios a redes de acceso objetivo con prioridades más altas que la red de acceso actual, cuando las redes de acceso de destino estén disponibles y la transferencia de sesión sea posible. Al indicar "deberá", el operador obliga al UE a iniciar la transferencia de sesión según la lista de redes de acceso preferidas del operador local lo antes posible. Al indicar "debería", el operador recomienda al UE que inicie la transferencia de sesión según la lista de redes de acceso preferidas del operador local, si la transferencia de sesión es posible y deseable después de haber tenido en cuenta la información del entorno operativo local. Al indicar "puede", el operador deja al UE libre para decidir si iniciar o no la transferencia de sesión según las preferencias del usuario (cuando estén configuradas), si la transferencia de sesión es posible y deseable después de haber tenido en cuenta la información del entorno operativo local. Siempre que las preferencias del usuario no estén configuradas, el UE puede tener en cuenta la lista de redes de acceso preferidas del operador local. La política del operador también puede indicar si se deben mantener o eliminar uno o varios flujos de medios no transferibles en el caso de una transferencia de sesión parcial. Generalmente, la política del operador para transferencia sesión es consistente con la política del operador para T-ADS.

Las preferencias del usuario pueden indicar, por ejemplo, acceso preferido. La información del entorno operativo local puede ser específica por implementación y puede comprender elementos tales como información del entorno de radio, calidad de la conexión IP (fluctuación, retraso y pérdida de paquetes), requisitos específicos por aplicación, consideraciones de memoria, consideraciones de potencia, etc. El UE puede tener en cuenta la política del operador de la cuenta, las preferencias del usuario y la información del entorno operativo local al decidir qué acceso usar para las sesiones salientes o antes de considerar iniciar la transferencia de sesión. Generalmente, las preferencias del usuario para transferencia de acceso no se transfieren a la red.

Para IUT, el UE puede indicar las siguientes preferencias del usuario al SCC AS a través de la interfaz Ut y el SCC AS puede tener en cuenta la política del operador y las preferencias del usuario al decidir si el UE tiene permiso y es capaz de actuar como controlador, y para determinar qué red de acceso utilizar para las sesiones entrantes, qué tipo de medio transmitir en cierto UE y si enviar una invitación de sesión entrante del UE controlador desde una parte remota: UE preferido para actuar como UE controlador; tipo de red de acceso preferido para sesiones entrantes; tipo de medio preferido a recibir en un UE particular del usuario; y preferencia para recibir una invitación de sesión entrante desde una parte remota en un UE controlador.

Además, para IUT, el UE generalmente está configurado para soportar una funcionalidad de controlador o controlado de IUT. En el caso de un UE de terminación, el UE puede configurarse para convertirse en un UE controlador con el fin de aplicar IUT para la sesión en curso cuando un extremo remoto envía una invitación de sesión.

Si el usuario desea indicar que se establezca una sesión de medios para uno o más tipos de medios a través de un tramo de acceso particular al realizar una transferencia de medios, el usuario puede indicarlo seleccionando en su UE controlador el tramo de acceso que desea usar para el tipo de medio particular. El UE podría haber permitido previamente al usuario definir marcadores comprensibles para los humanos para la cadena utilizada en la etiqueta de característica de medios, de modo que el usuario pueda usar estos marcadores para indicar a qué tramo de acceso desea transferir un tipo de medio al realizar una transferencia de medios (por ejemplo, " internet", "TV por cable", "celular" o "WLAN"). Alternativamente, el dispositivo, cuando se registra sobre un tipo de acceso, proporciona un mapeo entre los tipos de acceso legibles por humanos que el usuario puede leer y los tipos de acceso que soporta el dispositivo. A continuación, se muestran realizaciones de ejemplo, pero los expertos en la materia apreciarán que el mapeo podría estar más o menos restringido cuando la idea es que una cadena alfanumérica legible por humanos se mapee contra un número de posibles valores de tipo de acceso a la cabecera P-Access-Network-Info.

Por ejemplo, WLAN = "IEEE-802.11" I "IEEE-802.11 a" / "IEEE-802.11 b" / "IEEE-802.11 gVIEEE-802.11 n" DSL = "ADSL" / "ADSL2" / "ADSL2+" / "RADSL" / "SDSL" / "HDSL" / "HDSL2" / "G.SHDSL" / "VDSL" / "IDSL' Celular = "3GPP-GERAN" / "3GPP-UTRAN-FDD" / "3GPP-UTRAN-TDD" / "3GPP-E-UTRAN-FDD" I "3GPP-E-UTRAN-TDD"

Televisión por cable = "DOCSIS"

Por ejemplo, si el usuario tiene un teléfono móvil con capacidad multimodo que soporta acceso WLAN y celular (por ejemplo, EDGEIUMTSILTE) simultáneamente, el usuario puede desear que el tipo de medio de vídeo se reciba a través del acceso WLAN por razones de eficiencia del ancho de banda, rentabilidad o mejor calidad de imagen, mientras usa la conexión celular para tipos de medios de voz y audio. Para hacer esto, el UE incluye en la solicitud utilizada para solicitar la transferencia de medios (por ejemplo, una solicitud SIP REFER) una cabecera de aceptarcontacto que contiene la etiqueta de característica de medios (por ejemplo, g.3gpp.icsflow) con el valor establecido en el identificador de tramo/flujo de acceso para el tramo de acceso por el que el usuario seleccionó para enrutar el tipo de medio transferido. Los parámetros "requerir" y "explícito" también pueden incluirse opcionalmente en la cabecera de aceptar-contacto asociada con la etiqueta de característica de medios que contiene el identificador de tramo/flujo de acceso. En el caso de una solicitud SIP REFER, la cabecera de aceptar-contacto junto con sus valores podría incrustarse dentro de cabecera Refer-To. Cuando el SCC AS (u otro nodo de red) recibe la solicitud de transferencia de medios, incluye la cabecera de aceptar-contacto junto con sus valores de la solicitud de transferencia de medios en la solicitud enviada al UE al que se van a transferir los medios. Esto hace que la solicitud se enrute al UE utilizando el tramo de acceso deseado utilizando el mecanismo descrito en RFC 3841 y, correspondientemente, si se acepta la solicitud, también que los medios se establezcan utilizando ese tramo de acceso. Se debe observar que el UE al que se van a transferir los medios podría, en algunos casos (como el ejemplo anterior), ser el mismo UE que actúa como el UE controlador que envía la solicitud de transferencia de medios.

La figura 1 ilustra un flujo de comunicación de ejemplo que puede ser implementado por el presente sistema para transferir medios y/o función de controlador IUT entre UA o UE SIP asociados con una red. El flujo permite transferir el control del servicio de una sesión que contiene dos componentes de medios desde un primer UE controlador (UE-1) a un segundo UE controlado (UE-2). Tanto el primer como el segundo UE pueden compartir la misma identidad de usuario público, por ejemplo, compartiendo el mismo SIP URI o Tel URI, o teniendo identidades de usuario públicas superpuestas o idénticas definidas por un conjunto de registro implícito (IRS). Sin embargo, tendrán identidades privadas únicas tales como, entre otras, identidad privada IMS, IMSI, MIN, etc. En este ejemplo, el UE-1 tiene una sesión multimedia establecida con un UE remoto, cuya sesión está anclada en un SCC AS. El UE-1 inicialmente facilita el control de sesión colaborativa.

Como se muestra en la figura 1, la sesión multimedia incluye dos componentes de medios (medios-A y medios-B) y el UE-1 quiere transferir el control de sesión colaborativa y uno de los componentes de medios (medios-A) al UE-2 a través de un IUT. Como se ilustra, en la etapa 101, el UE-1 inicia el proceso de transferencia del control de sesión colaborativa y el tipo de medio (medio-A) al UE-2 comunicando o enviando una solicitud de transferencia al SCC AS. La solicitud de transferencia indica que el control de sesión colaborativa y el tipo de medio (medio-A) se transferirán al UE-2. La solicitud de transferencia puede contener SDP (posiblemente incrustado en la cabecera Refer-To de una solicitud SIP REFER) que contiene el tipo de medio que se transferirá. Alternativamente, el tipo de medio puede indicarse señalizando las etiquetas de característica apropiadas, etc. en la solicitud de transferencia. El UE-2 puede identificarse, entre otros, por GRUU, SIP URI, Tel URI, etc. En la etapa 102, el SCC AS identifica la solicitud y realiza un proceso de verificación. El proceso de verificación puede incluir la verificación de que el UE-1 tiene permiso para realizar IUT y la identificación del UE-2; en esta realización, el GRUU de UE-2 se almacena en el SCC AS (existe un REGISTRO válido) y se almacena contra ese GRUU que son etiquetas de característica de medios que coinciden con las que se han recibido en la solicitud de UE-1. Si el GRUU de UE-2 no existe o las etiquetas de característica no coinciden, entonces la solicitud puede ser rechazada. Alternativamente, el proceso de verificación puede incluir que el SCC AS recupere un Tel URI, SIP URI de un UE autorizado. Si el Tel URI recuperado, SIP URI coincide con un UE-1 que podría usar, entonces el SCC AS puede identificar otro UE objetivo que coincida con el Tel URI recuperado, SIP URI. A continuación, el SCC AS se aseguraría de que las etiquetas de característica en la cabecera de aceptar-contacto y los parámetros explícitos y requeridos estén configurados para elegir un contacto alternativo al que realiza la solicitud.

Si al UE-1 se le permite solicitar la transferencia del control de sesión colaborativa y los medios-A al UE-2, el SCC AS puede comunicarse con, o enviar una solicitud al UE-2 indicando que el control de sesión colaborativa y los medios-A serán transferidos a UE-2. Por ejemplo, el SIP METHOD (por ejemplo, SIP INVITE) puede incluir como objetivo el GRUU de UE-2 junto con una etiqueta de característica de medios que indica el control de sesión colaborativa (función de controlador IUT). El SIP METHOD puede incluir en la cabecera de aceptar-contacto las etiquetas de característica de medios requeridas con "Explícito" y "Requerido". Alternativamente, se incluye SDP que contiene el tipo de medio a transferir. En la etapa 103, el sistema establece un control de sesión colaborativa entre el UE-2 y el SCC AS. En este punto, el UE-2 se convierte en el UE controlador (en base a la recepción de la etiqueta de característica de medios que indica la función de controlador IUT) para las sesiones colaborativas. Sin embargo, en otras implementaciones, el UE-1 puede enviar una solicitud de transferencia que incluya los medios a transferir, manteniendo al mismo tiempo el control de sesión colaborativa en el UE-1. En este caso, la solicitud de transferencia no incluye la indicación, identificador, testigo, indicador, o etiqueta de característica de medios del control de sesión colaborativa (función de controlador IUT).

En una implementación, la sesión colaborativa incluye un conjunto lógico de una o más sesiones de subsistema multimedia IP (IMS), posiblemente en dos o más UE que comparten la misma suscripción IMS, ancladas en el AS SCC que se presentan en el tramo remoto como una sola sesión IMS. El tramo remoto puede ser el tramo de control de llamada entre el SCC AS y la parte remota visto desde la perspectiva del abonado (para un ejemplo adicional, ver 3GPP TS 23.292 para la definición de tramo remoto para sesiones IMS que utilizan medios de conmutación de circuitos).

En la etapa 104, se establece una sesión que transporta el medio A entre el UE-2 y el SCC AS. En este punto, el sistema puede actualizar opcionalmente el tramo remoto entre el SCC AS y la parte remota según el establecimiento de la nueva sesión con UE-2. Por ejemplo, el tramo remoto puede actualizarse para implementar un ajuste o cambio de códec de vídeo (por ejemplo, porque un dispositivo IPTV requiere un cambio o para renegociar de otro modo los medios). Después del establecimiento exitoso del control de sesión colaborativa y la transferencia del medio A al UE-2, el SCC AS envía una respuesta de transferencia de regreso al UE-1 en la etapa 105 (por ejemplo, una solicitud SIP NOTIFY para una respuesta final según RFC 3515). Después de recibir la respuesta de transferencia, la sesión anterior que transporta el medio A en el UE-1 puede liberarse y el control de sesión colaborativa se libera en la etapa 106. Después de la transferencia exitosa del control de sesión colaborativa, el UE-1 se convierte en un UE controlado (un UE que recibe y/o transmite flujo de medios (medios-B) como parte de la sesión colaborativa, mientras está subordinado al UE controlador para el control de la sesión) y el UE-2 asume el papel de UE controlador. El tipo de medio (medio-A) se comunica entre el UE-2 y la parte remota y el tipo de medio (medio-B) continúa comunicándose entre el UE-1 y la parte remota. Si la transferencia no fue exitosa, el SCC AS enviará un mensaje de regreso al UE-1 indicando el fracaso de la transferencia. El mensaje puede incluir, entre otros, una respuesta SIP 488 (no aceptable en este caso). Se puede incluir una advertencia en la respuesta indicando el motivo del error. El mensaje al UE-1 que indica el fallo de la transferencia puede estar contenido en una solicitud SIP NOTIFY que contiene en el cuerpo un SIPfrag de la respuesta del UE-2 (por ejemplo, una respuesta SIP 488 (no aceptable en este caso))).

El flujo de comunicación ilustrado en la figura 1 permite la transferencia de medios y el control de sesión colaborativa entre UE. Además de la transferencia de control de sesión colaborativa y de medios, el flujo anterior también puede transferir la función de controlador entre UE después de que uno o más UE controladores autoricen otorgar la función de controlador al UE objetivo.

En una implementación, para facilitar la transferencia de sesión (por ejemplo, para la continuidad del servicio IMS), el UE puede configurarse para almacenar y aplicar una política de operador (por ejemplo, tal como se ha descrito anteriormente) para la transferencia de sesión. El UE también puede iniciar procedimientos de transferencia de sesión basándose en criterios de activación que incluyen la política actual del operador, las preferencias del usuario y la información del entorno operativo local, proporcionando los detalles necesarios para llevar a cabo una operación de transferencia de sesión al SCC AS. El UE también puede proporcionar su capacidad para soportar la funcionalidad de controlador o controlado para IUT e iniciar el procedimiento de IUT basándose en la política actual del operador y las preferencias del usuario, proporcionando los detalles necesarios para llevar a cabo una operación de IUT al SCC AS.

Un UE puede tener múltiples contextos de registro posiblemente utilizando diferentes redes de acceso. Un UE, dependiendo de la política de IUT y la implementación en la red o servidor de aplicaciones (AS), puede configurarse para usar diferentes redes de acceso para algunas o todas las transmisiones de medios. Por ejemplo, un UE puede utilizar una radio de red de área local inalámbrica (WLAN) o alguna otra red de acceso para transmisión de medios de tipo vídeo, que tenga propiedades apropiadas según algunas preferencias del usuario predefinidas o una política de la red/del operador.

Un indicador que indica propiedades o un UE objetivo o un UE objetivo específico también puede ser capaz de identificar una tecnología de acceso (por ejemplo, soportada por el mismo dispositivo). Las solicitudes se pueden enrutar a través de un tramo de acceso particular que utiliza una tecnología de acceso particular usando el procedimiento descrito anteriormente.

En otras implementaciones del sistema, la funcionalidad de UE controlador también puede alojarse en una caja física tal como un decodificador o software ejecutable alojado en un ordenador personal, servidor de medios, nodo B local u otro dispositivo que no sea manejado físicamente por un usuario. En un ejemplo, un usuario está rodeado de receptores de medios o UE controlados. Los receptores de medios pueden permitir la interacción con, o complementar el UE controlador u otro dispositivo controlador de medios. Por ejemplo, un control remoto de TV puede ofrecer detener y rebobinar u otras funciones que son interceptadas por el receptor de medios o TV y reenviadas a un dispositivo o UE configurado para manejar varias funciones. En algunas implementaciones, una sola caja puede soportar múltiples UA SIP para diferentes dispositivos físicos externos. Por ejemplo, un servidor doméstico o un decodificador puede implementar múltiples UA SIP para otros dispositivos conectados sin capacidad SIP, como televisores básicos, teléfonos de línea fija heredados y sistemas de entretenimiento doméstico no habilitados para SIP.

Haciendo referencia a continuación a la figura 2, se ilustra una red de comunicaciones a modo de ejemplo para implementar el presente sistema para realizar IUT. La red 212 es una red de comunicaciones e incluye varios componentes tales como una estación base, SCC AS, función de control de sesión de llamada (CSCF) tal como P(intermediaria)-CSCF, S(de servicio)-CSCF e I(de interrogación)-CSCF servidor del centro de conmutación móvil (MSC), MSC mejorado para el servicio centralizado (ICS) de IMS y/o varios sistemas de almacenamiento de datos para almacenar capacidad del dispositivo, preferencias del usuario, listas de UE controladores y UE controlados para IUT, información de mapeo de tramos de sesión por dispositivo, y otras reglas o restricciones utilizadas en la implementación del presente sistema. Al comunicarse con la red 212, los UE pueden asociarse (por ejemplo, REGISTRARSE) con la red y comunicarse a través de la red 212 con otros UE asociados u otros dispositivos configurados para comunicarse a través de la red 212. El usuario 214 tiene varios UE 216, 218 y 220. Los UE 216, 218 y 220 comparten una única identidad 230 que puede definirse mediante un Tel URI o SIP URI, por ejemplo, en el conjunto A del IRS. El usuario 222 tiene UE 224 y 226 que también están conectados a la red 212. Los UE 224 y 226 también comparten una identidad, por un IRS B, por ejemplo.

En la figura 2, los UE del usuario 214 incluyen varios dispositivos diferentes. El UE 216 es un teléfono celular que no tiene capacidad de vídeo, el UE 218 es un portátil que tiene capacidades de voz sobre IP (VoIP) y videoconferencia, y el UE 220 es una televisión configurada para comunicarse con la red 212, pero que tiene una capacidad de entrada de usuario mínima. En el presente ejemplo, la televisión 220 está conectada mediante una conexión por cable al intermediario 221 para comunicarse con la red 212. El intermediario 221 puede incluir una puerta de enlace local, un decodificador de cable, un decodificador u otro sistema para comunicarse con la red 212. El intermediario 221 puede comunicarse con la red 212 de forma inalámbrica o mediante una conexión por cable. Sin embargo, los expertos en la materia apreciarán que parte o todo el intermediario 221 puede estar incorporado en la televisión 220. A medida que cada uno de los UE 216, 218 y 220 establece una conexión con la red 212, la función de controlador IUT puede asignarse a uno o más de los UE asociados con el usuario 214. La función de controlador IUT puede asignarse basándose en reglas que evalúan cualquier combinación de las capacidades funcionales del UE, preferencias del usuario, requisitos de red u otros datos disponibles a través del usuario 214, la red 212 o cualquier otra entidad en la red de comunicación 212. En el presente ejemplo, al UE 216 (un teléfono celular) se le asigna inicialmente la función de controlador IUT. Como tal, el UE 216 puede enviar una solicitud de transferencia de ciertos medios en sesiones en curso a cualquiera de los UE 218 y 220. Como parte del proceso de transferencia, el UE 216 también puede emitir una solicitud a la red 212 para transferir la función de controlador IUT a cualquiera de los UE 218 y 220. En algunos casos, dependiendo de las reglas definidas por la red y definidas por el usuario, algunos o todos los medios y la función de controlador IUT pueden transferirse a los UE 224 y 226 que pertenecen al usuario 222.

Haciendo referencia a la figura 2, el usuario 214 puede iniciar una llamada telefónica utilizando el teléfono celular 216 al UE 232 que pertenece al usuario 230. Debido a que el teléfono celular 216 no soporta video, la sesión establecida incluye solo voz sin video. Sin embargo, si el UE 232 del usuario 230 soporta video y el usuario 230 desea añadir video a la sesión, el usuario 230 puede emitir una solicitud o invitación al usuario 214 para añadir video a la sesión. Debido a que el teléfono celular 216 no puede manejar video, no se puede añadir video a la sesión a menos que el usuario 214 indique al UE 216 que se redirija a un UE que pueda manejar video. En este ejemplo, al recibir una solicitud para añadir video a la sesión en curso, el usuario 214 puede indicar al UE 216 que redirija la solicitud con tipo de video al portátil 218 que tiene capacidades de videoconferencia. Para redirigir la solicitud con video al portátil 218, el teléfono celular 216 genera un mensaje como una respuesta no final SIP 3xx para poder redirigir la solicitud con tipo de video a la red 212 (si se usó una respuesta SIP final como una SIP 3xx respuesta, se podría redirigir toda la sesión). Dependiendo de la implementación del sistema, al recibir la solicitud para añadir un nuevo tipo de medio desde una parte remota, una red (por ejemplo, SCC AS) puede iniciar automáticamente una invitación al UE objetivo basándose en la capacidad del dispositivo, las preferencias del usuario o las reglas de la red, por ejemplo. Alternativamente, una interfaz de usuario proporcionada por el teléfono celular 218 puede permitir al usuario 214 ordenar al teléfono celular 218 que redirija el mensaje al portátil 218. Después de que la red 212 (por ejemplo, SCC AS) reciba la solicitud para redirigir la solicitud, la red 212 (por ejemplo, SCC AS)) verifica que el portátil 218 pueda soportar medios de tipo video. Esto consiste en que el SCC AS 212 observe las etiquetas de característica de medios que se pasaron al SCC AS 212 como parte del SIP REGISTER del portátil 218 y se almacenaron en el SCC AS 212 contra las etiquetas de característica de medios GRUU del portátil 218 de REGISTRO.

El SCC AS 212 verifica que el teléfono celular 216 tenga la capacidad de solicitar la redirección y esté autorizado para realizar dicha solicitud. Si se cumplen estos requisitos, el SCC AS 212 puede verificar si la etiqueta de característica contenida en el SIP METHOD (por ejemplo, SIP INVITE) del controlador está almacenada en el contacto SIP al que se redirigen los medios. Si la etiqueta de característica de medios está presente, el SCC AS redirige la solicitud al portátil 218 enviando una solicitud de invitación (por ejemplo, una SIP INVITE) con un SDP que contiene el tipo de medio. El SCC AS también establece "Explícito" y "Requerido" según RFC 3841 para garantizar que se elija el objetivo correcto en el S-CSCF. Tras la redirección exitosa y un establecimiento de sesión colaborativa, el teléfono celular 216 también puede solicitar una transferencia de la función de controlador IUT al portátil 218.

En el presente ejemplo, la funcionalidad de controlador IUT se transfiere al portátil 218. Como tal, el portátil 218 tiene la opción de volver a tener la sesión de videoconferencia con otros UE accesible al usuario 214. Por ejemplo, para facilitar la visualización de la videoconferencia en curso por un grupo más grande de personas, el usuario 214 puede desear duplicar algunos o todos los medios de la videoconferencia en una televisión 220 mientras mantiene la videoconferencia en el portátil 218 que está configurado para comunicarse a través de la red 212. En este ejemplo, la televisión 220 no incluye micrófono. Como tal, el usuario 214, usando el portátil 218 (que tiene estado de controlador IUT), ordena a la red 212 que duplique solo la parte de video de la sesión de videoconferencia en curso a la televisión 220. En una implementación, donde el SCC AS libera el tipo de medio del transferido tramo después de la transferencia, es necesario señalizar que se solicita duplicación. La duplicación se puede señalizar utilizando una nueva etiqueta de característica de medios, una variable SDP, un parámetro y/o una cabecera SIP. En otra implementación, donde el UE transferente libera el tipo de medio del tramo transferido después de la transferencia, no se requiere ninguna señalización de la duplicación que se solicita. Tras la autorización de la duplicación, el SCC AS 212 envía un mensaje tal como una invitación de sesión (SIP INVITE) con tipo de medio de vídeo a la televisión 220 para facilitar la visualización. Sin embargo, la parte de voz de la sesión permanece en el portátil 218 para que el usuario 214 pueda continuar comunicándose con el usuario 230. En este ejemplo, la televisión 220 tampoco tiene una interfaz de usuario para recibir una entrada del usuario para iniciar transferencias de medios adicionales. Por consiguiente, el estado del controlador IUT permanece en el portátil 218 para que el usuario 214 pueda transferir la parte de vídeo de la videoconferencia desde la televisión 220 a otro dispositivo. Si el estado del controlador IUT fuera transferido a la televisión heredada 220, es posible que no haya ningún mecanismo mediante el cual transferir la sesión a otro dispositivo porque la televisión heredada 220 no puede proporcionar la interfaz de usuario adecuada para iniciar dicha transferencia: la parte de vídeo de la sesión se quedaría a la fuerza con la televisión heredada 220.

Dependiendo de la implementación del sistema, se pueden aplicar varias políticas o restricciones al número y combinación de UE que se pueden establecer para cada usuario. Por ejemplo, una red puede implementar restricciones que establezcan que solo un UE con capacidad de controlador IUT puede convertirse en un controlador IUT, o múltiples UE con capacidad de controlador IUT pueden convertirse en controladores IUT para cualquier sesión colaborativa, múltiples UE con capacidad de controlador IUT pueden convertirse en controladores IUT con múltiples UE para todas las sesiones colaborativas, pero con solo un UE controlador IUT por la misma sesión colaborativa. Además, una portadora preferida (conmutación de circuitos o conmutación de paquetes, por ejemplo) puede especificarse mediante reglas de red, preferencias del usuario o una combinación de las mismas. Por ejemplo, la configuración de la portadora preferida puede depender del tipo de medio y de la capacidad del dispositivo, por ejemplo conmutación de circuitos para sesiones de tipo de medio de voz y conmutación de paquetes para sesiones de tipo vídeo.

La red (por ejemplo, SCC AS) también puede utilizar las siguientes indicaciones para fines de cobro: una indicación de qué UE es un controlador IUT, identidad de UE que realiza una función de controlador IUT, indicación de conjunto de suscripción para IUT que indica que un conjunto de UE pertenecen a la misma suscripción y una indicación de portadora (puede haber diferentes cargos según la portadora que se utilice).

En el presente sistema, cada UE puede configurarse para comunicarse con la red (por ejemplo, a través del SCC AS u otro componente de la red de comunicaciones) para instruir a la red, en este caso el SCC AS, sobre si el UE tiene la capacidad para soportar la funcionalidad de controlador IUT. En una implementación, el UE transmite sus capacidades al SCC AS, por ejemplo, usando un mensaje SIP que incluye un SIP METHOD como SIP REGISTER, SIP PUBLISH, SIP SUBSCRIBE, SIP NOTIFY, SIP INVITE, SIP Re-INVITE, SIP UPDATE, SIP OPTIONES y SIP REFER o una respuesta SIP o lenguaje de marcado extensible: protocolo de acceso de configuración (XCAP) o basado en servicios web, por ejemplo utilizando SOAP o HTTP. Una forma para que un UE transmita sus capacidades al SCC AS es utilizar una etiqueta de característica de medios, por ejemplo g.3gpp.iut en una cabecera de contacto. Por ejemplo, los MÉTODOS SIP como SIP REGISTER, SIP SUBSCRIBE, SIP NOTIFY, SIP INVITE, SIP Re-INVITE, SIP UPDATE, SIP OPTIONS, SIP PUBLISH y SIP REFER que incluyen una cabecera de contacto pueden configurarse para incluir una etiqueta de característica de medios de controlador IUT para indicar el soporte de un UE particular para la funcionalidad de controlador IUT. Alternativamente, las respuestas SIP, tales como SIP 200 OK, también pueden incluir una cabecera de contacto que puede configurarse para indicar las capacidades del controlador de un UE.

Cuando se implementa usando cabeceras de contacto, la etiqueta de característica del controlador IUT puede incluir, por ejemplo, tres valores posibles (solo se describen valores a modo de ejemplo ya que el sistema puede usar otros valores que tienen varios nombres y atributos). En primer lugar, un valor "Activo" puede indicar que el UE con la dirección de contacto asociada con la etiqueta de característica del controlador IUT está actuando actualmente como el controlador IUT para la sesión. En segundo lugar, un valor "Inactivo" puede indicar que el UE con la dirección de contacto asociada con la etiqueta de característica del controlador IUT está actuando actualmente como un controlado en IUT (es decir, no como controlador IUT activo) para la sesión, pero se le puede asignar el rol de controlador IUT. En tercer lugar, un valor "Pasivo" puede indicar que el UE con la dirección de contacto asociada con la etiqueta de característica del controlador IUT está actuando actualmente como un controlado en IUT para la sesión y es incapaz de, o no está dispuesto a aceptar el rol de controlador IUT. Pasivo también podría significar que el dispositivo puede actuar como controlado, pero no tiene funcionalidad de controlador.

En algunas implementaciones, la indicación del controlador IUT puede incluir dos valores posibles tales como (activo, inactivo) o (activo, pasivo) en cualquier UE particular. Las definiciones de valores de ejemplo pueden incluir: g.3gpp.iutcontroller="active" o g.3gpp.iutcontroller="passive". En algunos casos, el valor del controlador IUT tiene como prefijo un indicador de versión. Por ejemplo, el valor del controlador IUT puede ser "activeX" donde X puede ser un valor de 0 o 1 a Y que indica la versión de IUT soportada por el UE. Otro ejemplo es g.3gpp.iut=[capacidad] donde capacidad indica la capacidad del dispositivo IUT, como ser un "controlador" o un "controlado". El controlador podría ampliarse para ser "controlador activo" o "controlador de paso". Controlador activo significa que SIP UA/UE está realizando actividades de controlador para la sesión y controlador de paso significa que SIP UA/UE tiene capacidades de controlador, pero no actúa como controlador. A continuación, en la siguiente tabla 4 se proporciona una definición de ejemplo de la etiqueta de característica; sin embargo, los expertos en la materia apreciarán que se puede utilizar cualquier construcción de caracteres alfanuméricos apropiados para transmitir el mismo significado desde SIP UA/UE.

Tabla 4

En otras implementaciones, un usuario puede configurar un UE que soporta la función de controlador IUT, para activar o desactivar la configuración del controlador IUT basándose en una preferencia del usuario usando SIP, XCAP, etc. La configuración de activación o desactivación de un UE controlador o UE controlado IUT puede colocarse en el cuerpo XML MIME de un mensaje SIP o XCAP, por ejemplo. Si se activa una configuración de controlador IUT en un UE, entonces el UE actúa como un UE controlador IUT. Si una configuración de controlador IUT se desactiva en un UE, entonces el UE actúa como un UE controlado en IUT. El siguiente es un ejemplo de configuración de la funcionalidad de controlador IUT para un UE particular en XML:

<?xml version="1.0" encoding="UTF-8"?>

<iutcont-settings xmlns="urn:3gpp:params:xml:ns :ims:iutcont-settings" xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xsi:schemaLocation="urn:3gpp:params:xml:ns:ims:iutcont-settings ">

<entity id="do39s8zksn2d98x">

<iutcont-settings>

<intenuetransfer-controller active="true" />

</iutcont-settings>

Además de notificar a la red si un UE particular tiene la capacidad de, y es preferido para actuar como un UE controlador, el presente sistema permite que los UE que soportan múltiples portadoras se configuren para indicar a la red una portadora preferida por un usuario, que almacena información como las capacidades del UE y las preferencias del usuario. Dependiendo del UE, el UE puede tener la capacidad de comunicarse con una red utilizando protocolos de comunicación de conmutación de circuitos, de conmutación de paquetes o ambos, por ejemplo. Para los UE que soportan múltiples portadoras, la portadora preferida puede especificarse mediante preferencias de usuario mediante SIP, XCAP u otros esquemas de codificación. En una implementación, una portadora preferida se especifica según un tipo de medio y/o capacidad del dispositivo particular. Por ejemplo, se puede especificar una portadora particular para tipos de medios particulares en dispositivos que tienen capacidades particulares. Alternativamente, se puede especificar una preferencia de portadora general para todos los UE, independientemente del tipo de medio y/o la capacidad del dispositivo. Las preferencias de la portadora se pueden especificar en el cuerpo XML MIME de un mensaje SIP o XCAP, por ejemplo. A continuación se muestra un ejemplo de codificación en XML:

<?xml version="1.0" encoding="UTF-8"?>

<iutcont-settings xmlns="urn:3gpp:params:xml:ns:ims:iutcont-settings"

xmlns: xsi=http://www.w3.org/2001/XMLSchema-instance

xsi: schema Location="u m:3gpp:params:xmi: ns: ims: bearer-settings ">

<entity id="do39s8zksn2d98x">

<bearer-settings>

<preferred-bearer>PS</preferred-bearer>

</bear-settings>

Al recibir un mensaje que indica la capacidad de un UE y, opcionalmente, las preferencias del usuario relacionadas con una portadora preferida para el UE, uno o más componentes de red tales como una función de control de sesión de llamada como P-CSCF, S-CSCF, I-CSCF, servidor de centro de conmutación móvil (MSC), MSC mejorado para ICS o el SCC AS pueden verificar que el UE tiene permiso y es capaz de actuar como controlador si el mensaje incluye que la función de controlador IUT es compatible con el UE, y una preferencia para usar el UE como controlador. En una realización, el SCC AS también puede verificar que el UE soporta, y se ha registrado para una portadora particular, si el mensaje recibido contiene el tipo de portadora soportado y/o una preferencia para usar un tipo de portadora particular.

Durante la verificación, el SCC AS determina qué UE serán un controlador, por ejemplo, inspeccionando la etiqueta de característica de medios del controlador IUT en la cabecera de contacto de una solicitud SIP REGISTER. En una implementación, el SCC AS obtiene las etiquetas de característica de medios usando el paquete de eventos de registro de suscripción o los procedimientos mejorados de registro de terceros (solicitud SIP REGISTER entrante incluida en el cuerpo de la solicitud de SIP REGISTER de terceros). El SCC AS también puede determinar una portadora que puede usarse para el UE que se está registrando. Si un valor de portadora preferida/soportado en la política de la red es diferente del del mensaje recibido, el valor de portadora preferida/soportado definido por la política de red puede tener prioridad. Las solicitudes se pueden enrutar a través de un tramo de acceso particular o una portadora preferida que utiliza una tecnología de acceso particular usando el procedimiento descrito anteriormente.

Para verificar que el UE cumple ciertos requisitos para la asignación de la función de controlador y/o una asignación de portadora particular, la red mantiene una base de datos que almacena identidades de usuario públicas de un usuario, por ejemplo, Tel URI, SIP URI, etc., identidades de usuario privadas de un usuario, por ejemplo identidad de usuario privada IMS, IMSI, etc., qué UE (por ejemplo, ID de instancia, IMEI, MIN o GRUU) pertenecen al mismo conjunto de suscripción, qué UE pertenecen a la misma IUT, qué UE son capaces de realizar la función de controlador IUT, identidad del dispositivo como, tales como ID de instancia, IMEI, MIN, URI UA enrutable globalmente (GRUU), mapeo de apodos de dispositivo a cada dispositivo, información de mapeo de tramos de sesión conectada con cada dispositivo, portadora soportado y preferido o tecnología de acceso de radio (RAT) en cada UE, direcciones que identifican cada UA por RAT para UE o intermediarios que soportan múltiples tecnologías de acceso PS o múltiples suscripciones o servicios entre pares (P2P) y tienen al menos una UA por RAT o suscripción o servicio P2P, reglas de autorización para permitir que otro UE obtenga la función de controlador, y otra información que describe, o está asociada con el UE. Esta base de datos puede almacenarse en el HSS y ser accesible para el SCC AS usando la interfaz Sh o la información puede recibirse desde S-CSCF como resultado de un registro. La base de datos podría ser almacenada en otras entidades dentro de la red. Quizás interna en el SCC AS o como una combinación de ambos. En una implementación, para realizar actividades de registro, la red puede verificar el IRS del UE en la base de datos para ver que el UE que solicita el registro tiene el mismo IRS configurado que el de un UE autorizado. Si el UE que se está registrando utiliza el mismo conjunto de IRS que el de un UE autorizado almacenado en la base de datos, el conjunto de IRS puede indicar capacidades particulares descritas por la ID privada de IMS, y si el UE puede ser un controlador o un sujeto controlado. Además, el conjunto IRS puede indicar si el UE sólo puede ser controlado y si el UE puede suscribirse dentro y fuera del servicio.

Durante el funcionamiento del presente sistema, un nodo de red distribuye una lista de URI o identidades de UE IUT (es decir, un conjunto de URI o identidades de UE que pueden solicitar transferencia de IUT o ser transferidos, o un conjunto de URI de UE controlador y controlado que pertenecen al mismo conjunto de IUT) a los UE controladores o a un conjunto de UE IUT que permiten la identificación de qué UE son controladores o controlados, qué UE soportan la función de controlador IUT y a qué UE se puede transferir una función de controlador IUT. La lista de URI o identidades de UE IUT puede incluir información tal como apodo del dispositivo, tipos de medios soportados por URI o identidad de cada UE IUT.

Cuando un UE se registra en la red, el UE incluirá la etiqueta de característica descrita anteriormente. El GRUU de la UE se almacena como parte del proceso de registro. Este GRUU se comunica a continuación como un URI a todos los UE controladores potenciales. La información enviada también puede incluir calificaciones si el UE identificado por el GRUU es un controlador IUT, controlador (rol pasivo) y controlado, con capacidad de control o con capacidad heredada. Los tipos de medios soportados, RAT registradas, etc., también pueden comunicarse para ayudar al UE si el UE actúa como controlador. Si el dispositivo realiza un nuevo registro y las etiquetas de medios (incluidas, por ejemplo, las RAT registradas) han cambiado, esto puede provocar una actualización de la información que se envía a los UE con capacidad de controlador IUT.

Como se ilustra en la figura 3, el UE se registra en la red IMS en la etapa 301, lo que provoca el registro en el SCC AS. El SCC AS necesita determinar si el dispositivo que se ha registrado es parte del conjunto IUT. Esto puede determinarse porque el SCC AS es consciente de que ya hay entre 1 y muchos UE que son capaces de IUT en el mismo IRS. Si el SCC AS puede hacer esta determinación en Y en la etapa 302, entonces el SCC AS se comunicará con el servidor OMA DM en la etapa 303. El SCC AS puede incluir identidades necesarias al servidor OMA DM para que este pueda comunicar la información a los dispositivos necesarios, u otros dispositivos que necesiten la información en la etapa 304. Puede incluir una lista de ID de Instancia, identificaciones de equipo. Estos se habrían obtenido en el proceso de registro. En algunos casos, si el ICS UE tiene un IMEI, antes de realizar el registro, el ICS UE genera una ID de instancia basada en su IMEI, tal como se define en 3GPP TS 23.003.

En otra implementación, puede haber alguna forma de identificador de grupo de IUT (ver el ejemplo en la Tabla 5) enviado cuando un UE se registra; este identificador identifica el grupo de IUT permitiendo que abonados de diferentes IRS estén en el mismo grupo de IUT. En ese caso, el SCC AS verificaría cuando un UE se registra si el UE es parte del conjunto de IUT. Una posible realización del identificador de grupo IUT podría ser una nueva etiqueta de característica de medios o una extensión de la definida anteriormente. Por ejemplo, 3.gpp.iutgroup=[variable].

Tabla 5

En una implementación, al distribuir la lista de URI o identidades de UE IUT, la dirección del SCC AS de servicio también puede incluirse y proporcionarse a través de gestión de dispositivo de Open Mobile Alliance (OMA DM), provisionamiento de clientes u otros protocolos de administración y provisionamiento de dispositivos. Para distribuir la lista de URI o identidades de UE IUT, la red puede utilizar mecanismos de transporte aéreo tales como, entre otros, datos de servicio suplementarios no estructurados (USSD), servicio de mensajes cortos (SMS), servicio de multidifusión de difusión multimedia (MBMS), difusión de celda, conductos IP que funcionan sobre GPRS en GERAN, UTRAN, LTE, WLAN, WiMax o CDMA2000. Los URI de identificación pueden ser URI de TEL (números E.164), SIP URI que contienen una identidad de usuario pública o un URI de agente de usuario enrutable globalmente (GRUU). La lista también se puede provisionar en un módulo de memoria extraíble que podría ser, entre otros: USIM, SIM, R-UIM, UICC o Compact flash. Alternativamente, se podrían utilizar otros mecanismos de gestión de configuración, como SIP CONFIG FRAMEWORK como se describe en draft-ietf-sipping-configframework.

La lista de URI o identidades de UE IUT puede actualizarse periódicamente o no periódicamente retransmitiendo, enviando o comunicando la lista, difundiendo actualizaciones sólo a medida que la lista cambia y se actualiza, o cuando cada UE controlador solicita una lista actualizada. Alternativamente, la lista puede actualizarse comunicando información actualizada directamente a cada UE, por ejemplo, a través de una interfaz de usuario, o proporcionando a los UE medios físicos que contienen la lista actualizada. La lista de URI en el UE se actualiza cuando los otros UE que pertenecen al mismo grupo de IUT que pueden utilizar el IRS se configuran, registran o cancelan su registro. Actualizar la lista de URI o identidades de UE IUT puede ser importante ya que los UE pueden añadirse (o registrarse) o eliminarse (o darse de baja) constantemente a/de las entidades de red de servicio tales como HSS, S-CSCF, SCC AS en la red de servicio como S-CSCF, HSS o SCC AS. Las actualizaciones pueden incluir la eliminación, adición o modificación de entradas, como se describe anteriormente. El nodo de red, como SCC AS, servidor DM, proporciona la lista de URI o identidades de UE IUT.

La figura 4 ilustra un objeto de gestión de lista de IUT permitido, a modo de ejemplo, para identificar uno o más UE IUT. El MO 440 incluye un nodo raíz 442 que puede actuar como marcador de posición para cuentas cero o uno para un nodo fijo. El nodo interior AllowedIUTEntries 444 puede usarse para proporcionar una referencia a una lista de ID de conjuntos de suscripción y puede incluir un nodo 446 de tiempo de ejecución como marcador de posición para uno o más ID de conjuntos de suscripción. El nodo de tiempo de ejecución 446 puede incluir una referencia a una lista de URI o identidades para uno o más UE IUT, apodos de dispositivo y/o testigos de medios. El nodo de tiempo de ejecución adicional 450 puede usarse como marcador de posición para IUT_URI (es decir, URI o identidad de cada UE IUT), apodo de dispositivo y conjuntos de datos de testigo de medios. El nodo de tiempo de ejecución 450 puede incluir hojas 452, 454 y 456 para almacenar IUT_URI, apodos de dispositivo, testigos de medios u otros datos.

Si sólo hay un conjunto de suscripción para el UE, entonces el nodo ilustrado puede no existir en el MO. El nodo ilustrado se puede añadir con fines de escalabilidad, por ejemplo, en caso de que un usuario tenga múltiples conjuntos de suscripción para UE IUT. Puede haber varios nodos incluidos dentro del MO (no todos son obligatorios), tales como, entre otros, nodos IUT URI (es decir, URI o identidades de UE IUT) o nodos de apodo de dispositivo correspondientes al IUT URI o ambos en el MO. También se puede incluir en el MO un nodo de testigo de medios para el dispositivo. Las figuras 5a y 5b ilustran detalles de los parámetros y DDF del MO de lista de IUT permitido mostrado en la figura 4. También se pueden usar archivos elementales para distribuir una lista de URI o identidades de UE IUT. A continuación, se proporcionan archivos elementales (EF) de ejemplo que se pueden utilizar para proporcionar definiciones de listas de IUT permitidas (EFAIUTL), apodo de dispositivo IUT (EFIUTDN), testigo de medios IUT (EFIUMT) e indicación de controlador IUT (EFIUTCONTI). Cuando se utiliza un EF de esta manera, el EF puede incluirse en cualquiera de un USIM, SIM, R-UIM, UICC o Compact flash, por ejemplo.

Un primer EF a modo de ejemplo incluye el EF<aiutl>(listas de IUT permitidas) y se ilustra en la tabla 6. El EF puede contener la codificación para los URI de IUT de UE, es decir, URI o identidades de UE IUT (o apodo de dispositivo) que pertenecen a las listas de IUT permitidas. Además, para cada URI de IUT (o apodo de dispositivo) de la lista, se puede proporcionar un enlace al apodo de dispositivo (o URI de IUT) correspondiente, al testigo de medios y a la indicación del controlador IUT. El objeto TLV de listas de IUT permitidas puede incluir uno o varios TLV de lista de IUT, donde cada TLV de lista de IUT está asociado con uno o más de uno entre TEL URI, SIP URI, GRUU, ID de instancia, IMEI, etc. La información de listas de IUT permitidas a modo de ejemplo se muestra a continuación en la tabla 7.

Tabla 6

En la tabla 7, el contenido de la etiqueta de lista de IUT '80' puede incluir la lista de IUT permitida por conjunto de suscripción de IUT que es aplicable a uno o más de uno entre TEL URI, SIP URI, GRUU, ID de instancia, IMEI, etc. se proporciona en el campo de valor de este TLV.

En la tabla 8 se muestra un ejemplo de codificación para la etiqueta de lista IUT '80'. En este ejemplo, los bytes no utilizados se pueden establecer en un valor de 'FF'.

Tabla 8

Otro EF a modo de ejemplo incluye el EF<iutdn>(apodo del dispositivo IUT) mostrado en la tabla 9. El EF puede configurarse para contener el apodo del dispositivo IUT. En este ejemplo, la asociación entre un URI de IUT y el apodo del dispositivo correspondiente se proporciona en EF<aiutl>. Generalmente, en este ejemplo, la codificación se puede realizar utilizando una de las opciones de código UCS2, según se define en TS 31.101.

Tabla 9

Otro EF a modo de ejemplo incluye el EF<iutmt>(testigo de medios IUT) mostrado en la tabla 10. El EF contiene el testigo de medios IUT. En este ejemplo, la asociación entre un URl de dispositivo IUT y el testigo de medios correspondiente se proporciona en EF<aiutl>.

Tabla 10

Para este EF, en la tabla 11 se muestra un ejemplo de etiqueta de testigo de medios IUT.

Tabla 11

Para este EF, en la tabla 12 se muestra información de ejemplo del testigo de medios IUT.

Tabla 12

En este ejemplo mostrado en la tabla 12, la etiqueta de testigo de medios IUT '80' puede tener contenidos de testigo de medios IUT, por ejemplo texto, vídeo, audio, etc., realizándose la codificación utilizando una de las opciones de código UCS2, tal como se define en TS 31.101, por ejemplo.

Otro ejemplo de EF incluye el EF<iutconti>(indicación del controlador IUT) mostrado en la tabla 13. El EF puede contener las indicaciones del controlador IUT. La asociación entre un URI de IUT y la indicación correspondiente del controlador IUT se proporciona en EF<aiutl>. La indicación del controlador IUT puede proporcionarse en formato de texto o en icono.

Tabla 13

En este EF, el estado del indicador para cada tipo de indicador puede tener una longitud de 1 bit y puede codificarse o configurarse de la siguiente manera. Si el valor del bit es igual a 1, establecer la indicación. Sin embargo, si el valor del bit es igual a 0, establecer la indicación en inactiva. Por ejemplo, la figura 23 es una ilustración de indicadores de ejemplo con posición de valor de bit de referencia.

Habiendo definido y puesto a disposición una lista de URI o identidades de UE IUT sin información útil adicional distinta de los URI o identidades de UE IUT, un UE IUT puede recopilar información sobre los otros UE identificados o actuar unilateralmente para modificar la lista comunicándose con el SCC AS u otros componentes de la red. En un ejemplo, un UE controlador IUT envía SIP OPTIONS a los UE identificados en la lista para determinar las capacidades de los otros UE IUT (por ejemplo, utilizando la etiqueta de característica del controlador IUT recibida en la respuesta 200 OK) y para descubrir cuáles están actualmente disponibles, son compatibles con IUT y a cuáles se puede transferir la función de controlador IUT. Los UE controlados por IUT pueden obtener las capacidades de los otros UE, incluida la etiqueta de característica de medios que indica soporte para la funcionalidad de controlador/controlado IUT a través de un mensaje tal como la respuesta 200 (OK) devuelta en respuesta a un mensaje tal como una solicitud de SIP OPTIONS.

Habiendo determinado una lista de URI o identidades de UE IUT y, opcionalmente, teniendo actualizaciones de esa lista, una base de datos en la red, por ejemplo almacenada en el SCC AS, HSS, etc. puede almacenar información que identifica los UE controladores y los UE controlados. La información puede almacenarse en cualquier medio adecuado, como una base de datos informática u otros medios de almacenamiento electrónico. La base de datos puede incluir cualquier estructura de tabla apropiada según los requisitos del sistema. La figura 21 es una ilustración de una estructura a modo de ejemplo para almacenar información dentro de la red, que describe los UE controladores y controlados asociados (por ejemplo, dentro de un servidor de abonado local (HSS)). En la figura 21, un usuario A tiene tres dispositivos que pertenecen al conjunto IUT y el dispositivo I es un controlador IUT. Los dispositivos restantes funcionan como controlados de IUT.

La figura 22 es una ilustración de información a modo de ejemplo almacenada en la red, tal como dentro de un HSS. La figura 22 muestra datos de tres usuarios, cada uno bajo el mismo conjunto de miembros de suscripción. El usuario A y el usuario B tienen una función de controlador IUT y pueden configurar reglas de autorización de IUT mientras que el usuario C actúa como controlado en IUT en la siguiente tabla.

Dentro de las tablas, el conjunto de suscripción es un conjunto de UE del mismo usuario para fines de IUT basado en la misma suscripción o en una suscripción diferente que está sujeta a un acuerdo de itinerancia. El conjunto de miembros de suscripción es un conjunto de UE entre miembros a quienes se permite realizar transferencias entre UE y pueden pertenecer a la suscripción del mismo operador o a la suscripción de un operador diferente sujeto a un acuerdo de itinerancia. Dentro de las tablas, para el conjunto de UE IUT, cada UE se distingue como un UE controlador IUT o un UE controlado en IUT. Cada UE tiene un ID de dispositivo, como GRUU, ID de instancia o IMEI, que puede mapearse con un apodo (por ejemplo, "TV del dormitorio", "Mi móvil", etc.). Además, para cada UE, las tablas definen una capacidad para soportar ciertos tipos y formatos de medios para ese UE.

Dependiendo de la implementación del sistema, la información que describe los UE controlador y controlado puede almacenarse en varios componentes de la red, por ejemplo reglas de autorización se pueden almacenar en XDMS y el enlace del documento a las reglas de autorización almacenadas en XDMS se puede almacenar en la base de datos de suscripción. En un ejemplo, el enlace de un testigo de medios para cada dispositivo o varias reglas de autorización para el control de IUT se almacenan en la base de datos u otra entidad de red.

La red puede realizar la vinculación de conjuntos de suscripción para implementar IUT. El conjunto de suscripción puede ser del mismo operador o entre diferentes operadores dependiendo del acuerdo entre operadores (intercambio de información de abonado y de información de dispositivo de abonado entre las redes). El sistema puede soportar IUT para el mismo conjunto de suscripción. El mismo conjunto de suscripción debe indicarse como "Indicación de conjunto de suscripción" para IUT en la red y la indicación puede proporcionarse a los UE en la memoria (por ejemplo, ME, USIM o ISIM) del mismo conjunto de suscripción.

La red también debería tener la capacidad de almacenar la "última configuración preferida". Por ejemplo, en una llamada inicial, si el usuario ha dividido una sesión de videollamada entre dos UE (voz en el dispositivo que tiene ID I y video en el dispositivo que tiene ID II), la red se puede configurar para que persista esta configuración para la videollamada posterior, con el resultado de una terminación de la llamada en múltiples UE.

La red también debería tener la capacidad de almacenar el "último UE que actuó como controlador". Por ejemplo, en una comunicación inicial, un UE-1 ha actuado como función de controlador IUT y un UE-2 ha actuado como UE controlado en IUT para sesiones colaborativas. Después de la terminación de la comunicación inicial y el establecimiento de nuevas sesiones colaborativas, el UE-1 que previamente actuó como un UE controlador se convierte en un UE controlador en función de la información en la red configurada para mantener esta última configuración del UE controlador para la nueva comunicación posterior después de la terminación de la comunicación anterior.

Cuando un UE se registra en la red, el UE transmitirá información a la red que identifica al UE. La información de registro puede incluir una solicitud para que al UE se le asigne la función de controlador dentro de la red. En un ejemplo, el UE proporciona una identidad privada de IMS, una identidad de usuario público de IMS y el ID de instancia del UE a la red con fines de identificación y etiquetas de característica como se identificó anteriormente a que el UE tenga capacidad de controlador IUT. La información de registro puede proporcionarse al SCC AS, que, a continuación, puede examinar la información de registro. El SCC AS puede entonces consultar la base de datos que almacena la información del UE y su abonado para determinar si la combinación de abonado y/o UE puede ser un controlador. La base de datos puede ser local o externa. Un ejemplo de base de datos externa incluye un HSS y uno interno en el SCC AS. La información de registro se puede transmitir utilizando la interfaz Sh o el campo Serviceinfo a través de la interfaz Cx.

Al verificar la combinación de información de identidad enumerada anteriormente, el SCC AS puede determinar si el UE está autorizado para ser un controlador o no. Por consiguiente, el SCC AS puede verificar la ID privada; en este caso, todos los dispositivos pueden ser controladores el SCC AS puede verificar la ID privada y el o los IMEI; en este caso, solo los dispositivos que se utilizan con esta ID privada pueden ser controladores. O el SCC AS puede verificar la ID privada, el o los IMEI y la o las ID públicas; en este caso, la ID privada en combinación del dispositivo (IMEI) y la ID de usuario público que se está registrando pueden ser el controlador.

En algunas implementaciones, después de registrar el UE, el SCC AS proporciona al UE un testigo, un indicador o una indicación para usar en métodos SIP posteriores para identificar que el UE ha sido autorizado como controlador. El testigo o indicación puede incluirse en una etiqueta de característica, una nueva cabecera P o un cuerpo XML. Alternativamente, el SCC AS puede marcar la grabación del registro para el UE en el SCC AS como que puede ser un UE controlador. Por lo tanto, cuando el UE envía una INVITE u otro SIP METHOD, el SCC AS puede verificar sus vinculaciones para determinar si el UE es capaz de realizar la funcionalidad de controlador.

El sistema también puede realizar una verificación adicional para determinar si un dispositivo en el sistema ya está actuando como controlador y, cuando otro dispositivo solicita la funcionalidad de controlador, el sistema puede rechazar la solicitud y proporcionar una indicación al dispositivo (la indicación puede incluir una salida del mecanismo de señalización de banda), o aceptar la solicitud según las reglas descritas anteriormente.

La función de controlador para un UE particular puede limitarse a controlar otros UE que son todos manejados por el mismo usuario asociado con el UE controlador. Sin embargo, en algunas implementaciones del presente sistema, un UE controlador particular de un usuario puede tener función de controlador sobre otros UE que pertenecen a otros usuarios, donde el UE controlador particular y los otros UE están bajo la misma membresía de suscripción. En ese caso, un UE particular puede proporcionar un mecanismo para permitir a un usuario establecer reglas de autorización para permitir que una función de controlador pueda ser realizada por el UE objetivo que ha solicitado realizar la función de controlador y la red, tal como el SCC AS, o XDMS puede procesar las reglas de autorización y determinar si se permite que el UE objetivo realice la función de controlador. Además, para realizar la función de controlador, puede ser necesario que el UE obtenga el consentimiento del UE controlador existente, o el consentimiento de uno o más UE objetivo que el UE controlador ha designado. En algunos casos, cualquier UE objetivo en el servidor inalámbrico puede estar autorizado para realizar la función de controlador. Un UE puede realizar la función de controlador basándose en una limitación temporal, una limitación funcional (por ejemplo, permitir solo la transferencia de tipos de medios particulares) o puede ser permanente. Se puede asignar cualquier UE controlador para establecer las reglas de permiso temporales, funcionales o de otro tipo para transferir la función de controlador a los UE manejados por otros usuarios.

La figura 6 ilustra un flujo de ejemplo para proporcionar función de controlador IUT a un UE, donde sólo se requiere autorización de un único UE controlador. En la etapa 601, un UE controlado envía un mensaje de solicitud a la red para recibir la función de controlador IUT. En la etapa 602, el servidor (por ejemplo, usando un S-CSCF o SCC AS) busca las reglas de autorización almacenadas en el propio servidor o en otra entidad de red como XDMS establecida por el UE controlador, y descubre que no hay reglas temporales, funcionales u otras limitaciones que apliquen a la asignación de la función de controlador IUT y que la autorización para la asignación de controlador IUT solo necesita ser autorizada por el UE controlador. En la etapa 603, la red envía un mensaje de solicitud al UE controlador para autorizar o dar su consentimiento para que el UE controlado objetivo reciba la función de controlador. En la etapa 604, el UE controlador envía una respuesta OK si el usuario del UE controlador acepta la solicitud. En esta etapa, el usuario del UE controlador puede establecer un permiso temporal/permanente. En algunos casos, estas restricciones de permiso temporal/permanente están predefinidas dentro de la red. En la etapa 605, el servidor envía una respuesta OK para proporcionar la función de controlador al UE controlado. La respuesta OK en la etapa 604 puede ser diferente de la de la etapa 605. El servidor puede incluir en esta respuesta a) una contraseña temporal o permanente, y b) un testigo, identificador o certificado que permite al UE controlado objetivo obtener la función de controlador. Si el UE objetivo recibe solo permiso temporal para actuar como controlador IUT, al liberar o abandonar la sesión actual, o al salir del programa que proporciona una interfaz de usuario para cambiar algunas configuraciones o parámetros en los UE controlados, la contraseña temporal puede dejar de ser válida y, por lo tanto, el UE objetivo no conservará la función de controlador IUT.

La figura 7 ilustra un flujo de ejemplo para proporcionar la función de controlador IUT a un UE donde sólo se requiere autorización o consentimiento de más de un UE controlador. En la etapa 701, un UE controlado envía al servidor un mensaje de solicitud para recibir la función de controlador IUT. En la etapa 102, el servidor identifica los UE que tienen la función de controlador IUT existente, busca las reglas de autorización establecidas por el o los controladores identificados y descubre que el servidor necesita la autorización o el consentimiento de uno o más usuarios (o el UE del usuario) que tienen función de controlador IUT. El usuario puede designarse a sí mismo y/o a otros usuarios que tengan una función de controlador. En la etapa 703, la red envía un mensaje de solicitud a los UE controladores para autorizar al UE controlado objetivo a recibir la función de controlador IUT. En la etapa 704, el UE del usuario designado envía una respuesta OK si el usuario designado acepta la solicitud. Los UE controladores designados pueden establecer varios permisos o restricciones al autorizar la provisión de la función de controlador IUT. Alternativamente, un usuario con un UE controlador puede definir varias restricciones de permiso temporales, funcionales o permanentes y transmitirlas dentro de la red. En la etapa 705, el servidor envía una respuesta OK si todos los usuarios designados autorizan proporcionar la función de controlador. La respuesta OK en la etapa 704 puede ser diferente de la de la etapa 705. Si los UE controladores han establecido permisos u otras restricciones sobre la provisión de la función de controlador IUT, la red incluye esas restricciones al emitir la autorización al UE controlador objetivo. Si el UE objetivo recibe solo permiso temporal para actuar como controlador IUT, al liberar o abandonar la sesión actual o al salir del programa que proporciona una interfaz de usuario para cambiar algunas configuraciones o parámetros en los UE controlados, la contraseña temporal puede dejar de ser válida y, por lo tanto, el UE objetivo no conserva la función de controlador IUT.

Dependiendo de la implementación del sistema, el UE controlador IUT puede determinarse antes del establecimiento de sesión, durante un proceso de establecimiento de sesión o después de que se haya establecido una sesión particular. En algunos casos, el UE que tiene la capacidad de soportar funcionalidad de controlador IUT y envía una solicitud de transferencia inicial se asigna inicialmente como un UE controlador IUT. Si el UE controlador IUT se determina antes del establecimiento de sesión, un UE puede solicitar la asignación de la función de controlador IUT basándose en la capacidad del UE para operar como un UE controlador IUT y las preferencias del usuario asociadas. El UE puede permitir que un usuario asigne solo un UE como controlador IUT activo de la lista de URI o identidades disponibles para UE IUT. Se podrían establecer diferentes configuraciones del controlador IUT para diferentes UE para el mismo usuario. Si el controlador IUT se asigna en el establecimiento de sesión, un UE puede enviar una solicitud de configuración de sesión, por ejemplo SIP INVITE, una SIP Re-INVITE o una solicitud SIP REFER con una etiqueta de característica de controlador IUT configurada en "Activo", tal como se ha descrito anteriormente.

En algunos casos, el SCC AS puede garantizar que todas las invitaciones de terminación a una sesión se enruten a un UE que sea un controlador IUT al incluir una etiqueta de característica de medios que indique el controlador IUT en una cabecera de aceptar-contacto según RFC 3841.

En algunos casos, puede ser deseable asignar un único UE controlador IUT para cualquier sesión en curso. Por consiguiente, para garantizar que el sistema solo asigna un único UE controlador IUT, después de recibir una solicitud de que a un UE en particular se le asigne la función de controlador IUT, la red puede verificar que el UE solicitante es capaz de controlar IUT, por ejemplo, una etiqueta de característica de medios que indica la capacidad del controlador IUT está presente en la cabecera de contacto, que el UE solicitante está autorizado para ser un controlador IUT (la autorización se puede conseguir verificando la id de usuario privado de IMS asociada con el registro de este UE para ver si la funcionalidad de controlador está permitida como se describe anteriormente), que existe una política de un nodo de red, por ejemplo SCC AS o base de datos de políticas que solo un UE debe convertirse en controlador IUT para cualquier sesión en curso y que no existe ningún otro UE controlador IUT asignado para el mismo usuario. Si se cumplen todas estas condiciones, la red envía una respuesta positiva de que el UE solicitante será un controlador IUT. La red puede enviar una indicación a los otros UE IUT especificando a qué UE (por ejemplo, usando GRUU) se le ha asignado la función de controlador IUT. Esto se puede haber conseguido mediante la suscripción del UE a una notificación y cuando se ha asignado un controlador, se envía una notificación al UE que contiene el GRUU del controlador. Si no se cumplen una o más de las condiciones anteriores, la red puede rechazar la solicitud. Al rechazar la solicitud, la red puede incluir un código de motivo que explique el motivo del rechazo de la solicitud.

Al registrar un UE en particular como controlador, puede ser importante proporcionar un mecanismo de autenticación o autorización para garantizar que solo a los usuarios autorizados y/o UE autorizados se les asigne la función de controlador. En un ejemplo, la suscripción IUT es una suscripción del hogar además de una suscripción de usuario. El abono del hogar podrá incluir un abono del padre, la madre y los hijos. En este ejemplo, se puede usar una función de autorización en la red para validar que un UE particular entre la suscripción del hogar pueda ser un UE controlador. Un ejemplo de implementación de red proporciona dos niveles separados de autorización.

Primero, la red determina si el dispositivo que se suscribe puede pertenecer al mismo miembro de suscripción. Esto podría ser el resultado de criterios de filtrado, pero nuevamente el AS SCC es el que hace esto, por lo que otros criterios de filtrado pueden enviar el método SIP al AS. Puede haber algo en el campo información de servicio del HSS que vaya de forma transparente al SCC AS, que indique si este es apto para IUT como resultado de que el UE realice un SIP REGISTER. Por ejemplo, en algunos casos, puede haber información en el SCC AS que determina si el dispositivo que se está suscribiendo es capaz de realizar la función de controlador. Alternativamente, la información puede proporcionarse a través de una IMSI o una identidad privada. Por ejemplo, todos los miembros de la familia pertenecen a la misma red personal, pero solo el padre tiene la capacidad de configurar un dispositivo como controlador sobre los demás dispositivos de la madre y los hijos.

En segundo lugar, el SCC AS determina si al UE que se está registrando se le permite convertirse en un controlador IUT. Esto se puede hacer verificando la información GRUU del UE que se está registrando. Esta información nuevamente puede almacenarse dentro del HSS o SCC AS, mediante lo cual el abonado indica qué dispositivo puede ser un controlador. Alternativamente, puede ser posible vincular toda la información al mensaje de registro, en el sentido de que cuando un UE se registre habrá una ID privada. La ID privada puede usarse para determinar si el UE tiene la capacidad de usar IUT o no. Puede haber capacidades como la ID privada de IMSI que puede ser: "asignar controlador" o "ser controlado". Por lo tanto, cualquier UE que provenga de una ID de usuario privada con "asignar controlador" puede configurar ese UE como controlador.

Las ID de IMS que pueden acceder a un IRS pueden tener ciertos perfiles; por ejemplo, una suscripción del hogar puede contener 4 ID privadas de IMS, papá, mamá y 2 hijos. Papá es el único que puede asignar un controlador. Todos estos son el mismo miembro de suscripción, que puede denominarse conjunto de miembros de suscripción.

Suponiendo que 2 ID privadas de IMS pueden asignar controlador para el grupo, uno ha de tener autoridad de anulación o, si se te permite ser el controlador, se te notificará si otro UE se convierte en el controlador. Si actualmente eres el controlador, puedes negar el cambio o permitir el cambio. Esto requiere suscribirse a una notificación de estado dentro de la red y, al recibir una notificación de que la red tiene una política particular, preguntar al otro controlador si se pueden cambiar las capacidades de control.

El UE controlador IUT puede determinarse antes del establecimiento de sesión, durante el establecimiento de sesión o cuando se solicita una función de transferencia del controlador IUT a otro UE. Al determinar el UE controlador IUT antes del establecimiento de sesión, un UE envía una solicitud para tener función de controlador IUT en función de la capacidad del UE y las preferencias del usuario. El UE puede permitir que un usuario haga de más de un UE un controlador IUT activo a partir de la lista de URI o identidades para UE IUT. Cuando se determina el UE controlador IUT durante el establecimiento de sesión y cuando se solicita una transferencia de función de controlador IUT a otro UE por cualquier UE con capacidad de controlador IUT, un UE envía una solicitud tal como una solicitud SIP INVITE, una SIP Re-INVITE o una SIP REFER con una etiqueta de característica de medios que indica la función de controlador IUT. La etiqueta de característica de medios podría ser un valor de identificador de servicio de comunicación IMS (ICSI) o un valor de identificador de referencia de aplicación IMS (IARI) que identifica la función de controlador IUT que se va a transferir. Cuando la red recibe la solicitud, la red verifica que el UE solicitante sea capaz de ser un controlador IUT, que el UE solicitante esté autorizado para ser un controlador IUT (la autorización se consigue, por ejemplo, verificando la id de usuario privado de IMS asociada con el registro de este UE para ver si se permite la funcionalidad de controlador), y que existe una política (por ejemplo, de la base de datos de políticas) de que múltiples UE deben convertirse en controladores IUT para cualesquiera sesiones en curso o para la misma sesión colaborativa.

Si se cumplen todas estas condiciones anteriores, la red envía una respuesta positiva de que el UE solicitante será un controlador IUT. La red puede enviar a los otros UE IUT una indicación de qué UE (por ejemplo, utilizando información GRUU) es un controlador IUT. Si no se cumple una o más de las condiciones anteriores, la red puede rechazar la solicitud y, opcionalmente, proporcionar un código de motivo para explicar el motivo por el que se rechazó la solicitud.

Habiendo sido establecido como un UE controlador IUT, el UE controlador puede emitir solicitudes a la red para transferir tipos de medios a ciertos UE controlados, o para transferir la función de controlador IUT a otros UE. Para que el UE controlador IUT transfiera medios y/o función de controlador a un UE controlado, el UE controlador IUT envía un mensaje tal como una solicitud SIP REFER a la red, por ejemplo SCC AS. La solicitud SIP REFER puede contener incrustado dentro del URI en la cabecera REFER-TO otro mensaje tal como al menos algunos de las cabeceras SIP y/o contenidos SDP de la solicitud SIP INVITE o solicitud SIP Re-INVITE que el SCC AS debe enviar al UE controlado identificado por el URI en la cabecera Refer-To. La solicitud SIP INVITE o la solicitud SIP RE-INVITE que se envía al UE controlado puede contener datos que identifican los tipos de medios que se transferirán al UE controlado. Para permitir que el UE controlado determine que se le está transfiriendo el control, la solicitud SIP INVITE también incluye un identificador que identifica la función de controlador IUT. Este identificador puede incluir a) un URI que identifica la función de controlador IUT en un campo de cabecera SIP, b) un nuevo parámetro SIP URI (es decir, parámetro URI del controlador IUT) en el URI de solicitud o en el URI en la cabecera TO, c) una etiqueta de característica de medios que indica que el controlador IUT se incluirá en una cabecera de aceptar-contacto (según RFC 3841), d) un valor de identificador de servicio de comunicación IMS (ICSI) o un valor de identificador de referencia de aplicación IMS (IARI) que identifica la función de controlador IUT, debe transferirse como la etiqueta de característica "g.3gpp.app_ref", que se incluirá en una cabecera de aceptar-contacto (SE DEBE OBSERVAR que el UE habrá registrado previamente en el registro la etiqueta de característica de medios en la cabecera de contacto de la solicitud SIP REGISTER según RFC 3840), o e) un nuevo campo de cabecera SIP (por ejemplo, una cabecera P según RFC 3427) que indica que se transfiere la función de controlador IUT. En otra implementación, la etiqueta de característica 3.gpp.iut se puede ampliar con opciones adicionales para identificar que la función de controlador se está transfiriendo. Una realización de ejemplo se incluye a continuación en la tabla 14.

Tabla 14

Otras realizaciones también podrían incluir que cuando el UE realiza la solicitud para transferir la funcionalidad de controlador, el UE establece la etiqueta de característica de medios en controlada. Cuando el SCC AS recibe la solicitud, el SCC AS comprobará el estado del UE del que se ha recibido el mensaje. Si el estado del UE está asignado como controlador, el UE sabrá que se desea que el UE pase la funcionalidad de controlador al dispositivo objetivo identificado en el mensaje. Cuando el SCC AS envía el mensaje al dispositivo objetivo, el mensaje puede incluir un testigo o identificador que identifica que la funcionalidad de controlador se está asignando al UE.

Los siguientes ejemplos en la figura 8 ilustran flujos para transferir función de controlador IUT y/o tipos de medios desde un primer controlador a otro UE según lo solicitado por un UE controlador IUT. En los ejemplos, el UE-1 tiene una sesión multimedia establecida con una parte remota, que está anclada en un SCC AS. La sesión multimedia contiene dos componentes de medios (medios-A y medios-B) y el UE-1 desea transferir el control de sesión colaborativa y uno de los tipos de medios (medios-A) a otro UE-2. En los ejemplos, el UE-1 y el UE-2 pueden haberse registrado utilizando la misma portadora de red de acceso o una portadora de acceso de red diferente. El UE-1 y el UE-2 pueden utilizar diferente protocolo de internet - conexión entre redes (IP-CAN), por ejemplo IP-CAN 3GPP en el UE-1 e IP-CAN no 3GPP en el UE-2. El SCC AS anclado u otra entidad de red puede determinar qué portadora usar para cada UE. Se supone que el UE-1 y el UE-2 pertenecen al mismo abonado.

Siempre que el UE adquiere conectividad IP a través de una CAN IP, el UE puede registrarse en el IMS, tal como se define en TS 23.228. En ese caso, el perfil de usuario contiene un MSISDN C que está vinculado a la identidad de usuario privada de IMS. La S-CSCF puede seguir los procedimientos definidos en TS 23.218 para realizar el registro de terceros ante el SCC AS. Cuando se utiliza acceso CS para medios, el UE puede registrarse en IMS, tal como se especifica en TS 23.292. Al registrarse en el IMS, tal como se define en TS 23.228, el UE puede indicar su capacidad para soportar la funcionalidad de controlador o controlado para IUT. A continuación, en la tabla 15, se muestra un ejemplo de solicitud SIP REGISTER para que el S-CSCF realice un registro de terceros hacia el SCC AS.

Tabla 15

P-Visited-Network-ID: "Número de red visitada 1

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"

De: <sip:234150999999999@ics.mnc015.mcc234.3gppnetwork.org>;tag=2hiue

Para: <sip:234150999999999@ics.mnc015.mcc234.3gppnetwork.org>

Contacto: <sip:[5555::aaa:bbb:ccc:eee];comp=sigcomp>;reg-id=2; sip.instance="< urn:gsma:imei:90420156-025763-0>;+g.3gpp.icsi-ref="urn%3Aurn-7%3gppservice.ims.icsi.mmtel";+g.3gpp.ics="principal";+g.3gpp.icsflow="WLAN";expires=600000

ID de llamada: apb03a0s09dkjdfglkj49111

Autorización: Digest username ="user1_private@home1.net", kingdom="register.home1.net", nonce=base64(RAND AUTN server spacific data), algorithm=AKAv1-MD5, uri="sip:register.home1.net", respuesta="6629fae49393a05397450978507c4ef1"

CSeq: 3 REGISTER

Compatible: ruta, salida, g:r.u.u

Longitud de contenido: 0

--boundary1

Tipo de contenido: menssage/sip

SIP/2.0200 OK

Ruta: SIP/2.0/UDP icscf1_p.home1.net;branch-=z9hG4bK351g45.1, SIP/2.0/UDP pcscf1.visited 1.net;branch=z9hG4bK240f34.1, SIP/2.0/UDP [5555::aaa:bbb: ccc:eee]:1357;comp=sigcomp;branch=z9hG4bKnashds7

Ruta: <sip:term@pcscf1.visited 1.net;lr;ob>

Ruta de servicio: <sip:orig@scscf1.home1.net;lr>

De: <sip:234150999999999@ics.mnc015.mcc234.3gppnetwork.org>;tag=2hiue

Para: <sip:234150999999999@ics.mnc015.mcc234.3gppnetwork.org>

ID de llamada: apb03a0s09dkjdfglkj49111

Contacto: <sip:[5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp>; pubgruu="sip:user1_public1@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"

;temp-gruu=sip:tgruu.7hs==jd7vnzga5w7fajsc7-ajd6fabz0f8g5@example.com;gr" ;+sip.instance="<urn:gsma:imei:90420156-025763-0>";+g.3gpp.icsi

La f¡gura 8 ¡lustra un flujo para transfer¡r la func¡ón de controlador IUT a un UE según lo sol¡c¡tado por un UE controlador IUT. En la etapa 801, el UE-1 dec¡de transfer¡r el control de ses¡ón colaborat¡va y el t¡po de med¡o (med¡o-A) al UE-2. El UE-1 envía una sol¡c¡tud al SCC AS, ¡nd¡cando que el control de ses¡ón colaborat¡va actual y el t¡po de med¡o (med¡o-A) se transfer¡rán al UE-2. En la etapa 802, el SCC AS (o cualqu¡er otro componente de la red) ¡dent¡f¡ca la sol¡c¡tud de transferenc¡a, ver¡f¡ca que el UE-2 t¡ene perm¡so y es capaz de actuar como controlador, ver¡f¡ca que el UE-2 ha reg¡strado capac¡dades aprop¡adas, por ejemplo, et¡quetas de característ¡ca según RFC 3840, determ¡na qué portadora usar para UE-2 en func¡ón de la capac¡dad del d¡spos¡t¡vo, la preferenc¡a del usuar¡o y/o la política en la red, y determ¡na s¡ la portadora selecc¡onada ha s¡do reg¡strada por UE-2. En la etapa 803, el SCC AS genera y envía al UE-2 un mensaje de sol¡c¡tud de establec¡m¡ento de ses¡ón ut¡l¡zando el punto de referenc¡a Gm o I1, u otros métodos de transferenc¡a de datos que ¡nd¡can que el control de ses¡ón colaborat¡va y el t¡po de med¡o (med¡o-A) se van a transfer¡r. En la etapa 804 se establece un control de ses¡ón colaborat¡va entre el UE-2 y el SCC AS. El UE-2 se conv¡erte en el UE controlador para la ses¡ón colaborat¡va estableada. En la etapa 805 se establece una ses¡ón para comun¡car el t¡po de medo (med¡o-A) entre el UE-2 y la parte remota. En este momento, el tramo remoto se actual¡za en consecuenc¡a. Después del establec¡m¡ento ex¡toso del control de ses¡ón colaborat¡va y el t¡po de med¡o (med¡o-A) en el UE-2, el SCC AS envía al UE-1 un mensaje de respuesta al mensaje de sol¡c¡tud de transferenc¡a u otro mensaje que not¡f¡que al UE-1 del resultado del mensaje de sol¡c¡tud de transferenc¡a en la etapa 806 (por ejemplo, una sol¡c¡tud SIP NOTIFY que se envía para una respuesta f¡nal rec¡b¡da como resultado de una sol¡c¡tud SIP REFER según RFC 3515). F¡nalmente, en la etapa 807 se puede l¡berar la ses¡ón del t¡po de med¡o anter¡or (med¡o-A) en el UE-1 y se l¡bera el control de ses¡ón colaborat¡va. En este momento el UE-1 se conv¡erte en un UE controlado.

La f¡gura 9 ¡lustra un flujo para transfer¡r la func¡onal¡dad de controlador IUT del UE-1 al UE-2, donde la sol¡c¡tud de ses¡ón entrante se entrega a través del punto de referenc¡a Gm y los med¡os se transmuten a través de una red de conmutac¡ón de c¡rcu¡tos. Un ICS mejorado con serv¡dor MSC podría ser una ent¡dad a modo de ejemplo de una ent¡dad de ¡nterfunc¡onam¡ento para ¡mplementar el flujo ¡lustrado. Alternat¡vamente, las ent¡dades de ¡nterfunc¡onam¡ento pueden cons¡st¡r en un serv¡dor MSC heredado y MGCF. Cuando las ent¡dades de ¡nterfunc¡onam¡ento corresponden al serv¡dor MSC y MGCF, los proced¡m¡entos de conf¡gurac¡ón de portadora CS s¡guen las etapas 11-17 de la f¡gura 7.4.2.2.2-2 de t S 23.292.

Hac¡endo referenc¡a a la f¡gura 9, en las etapas 901 y 902, el UE-1 dec¡de transfer¡r el control de ses¡ón colaborat¡va y los med¡os A al UE-2. Por cons¡gu¡ente, el UE-1 envía una sol¡c¡tud al SCC AS a través de ent¡dades IMS, ¡nd¡cando que el control de ses¡ón colaborat¡va actual y el med¡o-A se transfer¡rán al UE-2. En este ejemplo, un UE controlador IUT puede ¡n¡c¡ar una sol¡c¡tud de transferenc¡a tal como a través de SIP REFER transm¡t¡endo una sol¡c¡tud que t¡ene la s¡gu¡ente ¡nformac¡ón: 1) UE de or¡gen (puede ¡nclu¡rse dentro del campo de cabecera De, un campo de cabecera Ident¡dad-declarada-P o campo de cabecera Usuar¡o-serv¡do-P), 2) UE objet¡vo (puede ¡nclu¡rse dentro del campo de cabecera Refer-To), 3) ¡nd¡cac¡ón de transferenc¡a del controlador IUT (puede ¡nclu¡rse dentro del campo de cabecera de aceptar-contacto, por ejemplo, ¡ncrustado en la sol¡c¡tud INVITE o ¡ncrustado en el campo de cabecera Refer-To), 4) ID-d¡álogo-objet¡vo (puede ¡nclu¡rse dentro del campo de cabecera d¡álogo objet¡vo que cont¡ene un ¡dent¡f¡cador de d¡álogo ex¡stente s¡ el UE objet¡vo ya es parte de la ses¡ón colaborat¡va, y no I D-díálogoobjetivo cuando se trata de una nueva sesión para el UE objetivo), y 5) tipo de medio (por ejemplo, audio, vídeo, archivo, etc. (por ejemplo, incluido en el campo de cabecera de referencia).

En la etapa 905, el SCC AS identifica la solicitud (por ejemplo, la solicitud SIP REFER), verifica que el UE-2 tiene permiso y es capaz de actuar como controlador, verifica que el UE-2 ha registrado capacidades apropiadas, por ejemplo etiquetas de característica según RFC 3840, qué portadora usar para el UE-2 según la capacidad del dispositivo, la preferencia del usuario y/o la política en la red, y si la portadora seleccionada ha sido registrada por el UE-2. Si al UE-2 no se le permite actuar como controlador, el SCC AS puede rechazar la solicitud. Si el UE-2 rechaza la transferencia de control de sesión colaborativa, se envía una respuesta adecuada que indica el rechazo. La respuesta puede indicar el motivo del rechazo de la transferencia. Dicha respuesta puede ser una respuesta SIP 488 (no aceptable en este caso) cuando los tipos de medios o códecs ofrecidos no son aceptables. Se puede incluir una advertencia en la respuesta indicando el motivo del error. El mensaje al UE-1 que indica el fallo de la transferencia puede estar contenido en una solicitud SIP NOTIFY que contiene en el cuerpo un SIPfrag de la respuesta del UE-2 (por ejemplo, una respuesta SIP 488 (no aceptable en este caso)).

En las etapas 906 y 907, si el mensaje recibido en la etapa 905 contiene una transferencia de medios para audio o vídeo, entonces el SCC AS genera y envía al UE-2 un mensaje de solicitud de establecimiento de sesión. El mensaje de solicitud de establecimiento de sesión, tal como la solicitud SIP INVITE o SIP Re-INVITE enviado después de recibir una SIP REFER, incluye la siguiente información: 1) UE de origen (puede incluirse en el campo de cabecera referido por y el campo de cabecera Identidad-declarada-P, el campo de cabecera P-Preferred-Identity o el campo de cabecera usuario servido P), 2) UE objetivo (puede incluirse en el campo de cabecera To y en el campo URI de solicitud), 3) indicación de transferencia del controlador IUT (puede incluirse en el campo de cabecera de aceptar-contacto), 4) diálogo objetivo (puede incluirse en el campo de cabecera diálogo objetivo que contiene un diálogo existente si el UE objetivo ya es parte de la sesión colaborativa y ningún diálogo objetivo cuando se trata de una nueva sesión para el UE objetivo), y 5) tipo de medio (por ejemplo, audio, vídeo, archivo) (puede incluirse en el SDP integrado en la solicitud INVITE). La solicitud también puede incluir un DN de PSI que se utilizará para el conjunto de llamadas CS que identifica esta sesión. Si el SDP contiene una línea M que permite configurar la portadora a través de CS, entonces, en la etapa 910, el UE-2 envía un mensaje de establecimiento de llamada CS a las entidades de interfuncionamiento utilizando el DN PSI como número B. En la etapa 911, las entidades de interfuncionamiento tales como un servidor MSC mejorado para ICS responden con un mensaje de llamada en curso y comienzan a configurar la ruta de señalización de control de portadora CS. En las etapas 912 y 913, las entidades de interfuncionamiento envían una SIP INVITE hacia el AS SCC a través de entidades IMS. Cuando el SCC AS recibe INVITE en la etapa 913, el SCC AS puede usar el PSI DN para recuperar la información de la sesión y en la etapa 916, cuando las entidades de interfuncionamiento reciben un SIP 200 OK del SCC AS a través de entidades IMS, las entidades de interfuncionamiento mapean la respuesta SIP 200 OK recibida a un mensaje CONEXIÓN y la envía a UE-2. En la etapa 917, al recibir el mensaje CONEXIÓN, el UE-2 envía un mensaje CONEXIÓN ACK a las entidades de interfuncionamiento. En la etapa 920, el UE-2, las entidades de interfuncionamiento y el SCC AS completan la configuración de la ruta de señalización de control de portadora CS. Se establece un control de sesión colaborativa entre el UE-2 y el SCC AS. El UE-2 se convierte en el UE controlador para la sesión colaborativa establecida. En la etapa 921 se establece el intercambio de comunicación del tipo de medio (medio-A) entre el UE-2 y la parte remota. En este momento, el tramo remoto se actualiza en consecuencia si es necesario cambiar la información del SDP. En las etapas 922 y 923, después del establecimiento exitoso del control de sesión colaborativa y el tipo de medio (medio-A) en el UE-2, el SCC AS envía al UE-1 un mensaje de respuesta al mensaje de solicitud de transferencia o un mensaje que notifica el resultado del mensaje de solicitud de transferencia mediante SIP NOTIFY. Finalmente, en la etapa 926 se puede liberar la sesión del tipo de medio anterior (medio-A) en el UE-1 y se libera el control de sesión colaborativa. El UE-1 se convierte en un UE controlado. Se debe observar que en el ejemplo anterior no se describen las etapas que implican la comunicación de mensajes convencionales de acuse de recibo. Si se transfieren todos los flujos de medios del UE-1 al UE-2, se puede liberar la sesión existente en el UE-1.

La figura 10 ilustra un flujo para transferir funcionalidad y medios del controlador IUT del UE-1 al UE-2, donde la sesión entrante se entrega a través del punto de referencia I1 y los medios se transmiten a través de una red CS. En una implementación, un ICS mejorado con servidor MSC podría ser una entidad a modo de ejemplo de la entidad de interfuncionamiento. Alternativamente, las entidades de interfuncionamiento pueden consistir en un servidor MSC heredado y MGCF. Cuando las entidades de interfuncionamiento corresponden al servidor MSC y MGCF, los procedimientos de configuración de la portadora CS siguen las etapas 1011-1017 en la figura 7.4.2.2.2-2 del TS 23.292.

En las etapas 1001 y 1002, el UE-1 decide transferir el control de sesión colaborativa y los medios A al UE-2. Por consiguiente, el UE-1 envía una solicitud al SCC AS a través de entidades IMS, indicando que el control de sesión colaborativa actual y el medio-A se transferirán al UE-2. En una implementación, el UE-1 envía una solicitud de transferencia, por ejemplo a través del método SIP REFER, con la siguiente información: 1) UE de origen (puede incluirse en el campo de cabecera De, un campo de cabecera Identidad-declarada-P o el campo de cabecera usuario servido P), 2) UE objetivo (puede incluirse dentro del campo de cabecera Refer-To), 3) indicación de transferencia del controlador IUT (puede incluirse dentro del campo de cabecera de aceptar-contacto, por ejemplo, incrustado en la solicitud INVITE o incrustado en el campo de cabecera Refer-To), 4) diálogo objetivo (puede incluirse dentro del campo de cabecera diálogo objetivo que contiene un identificador de diálogo existente si el UE objetivo ya es parte de la sesión colaborativa y ningún diálogo objetivo cuando se trata de una nueva sesión para el UE objetivo) y 5) tipo de medio (por ejemplo, audio, vídeo, archivo, etc.) (puede incluirse en el campo de cabecera referencia).

En la etapa 1005, el SCC AS identifica la solicitud (por ejemplo, la solicitud SIP REFER). Si el UE-2 está registrado en SIP en el SCC AS, el SCC AS verifica que el UE-2 esté autorizado y sea capaz de actuar como controlador, verifica que el UE-2 haya registrado las capacidades apropiadas, por ejemplo etiquetas de característica según RFC 3840, determina qué portadora usar para el UE-2 en función de la capacidad del dispositivo, la preferencia del usuario y/o la política en la red, y determina si la portadora seleccionada ha sido registrada por el UE-2. Si al UE-2 no se le permite actuar como controlador, el SCC AS puede rechazar la solicitud. Si el UE-2 rechaza la transferencia de control de sesión colaborativa, se envía una respuesta adecuada que indica el rechazo y opcionalmente el motivo del rechazo.

En la etapa 1006, el SCC AS ha determinado que el UE-2 no es alcanzable por el punto de referencia Gm. Esto puede deberse, por ejemplo, a que el UE no tiene un registro SIP activo; en otro ejemplo, el UE-2 puede estar registrado en SIP pero el SCC AS ha sido informado a través del protocolo I1 de que el punto de referencia Gm no está disponible. Si el mensaje recibido en la etapa 1002 contiene una línea SDP para audio o vídeo, entonces el SCC AS genera y envía al UE-2 un mensaje de solicitud de llamada entrante a través del punto de referencia I1 que incluye una indicación de la funcionalidad de controlador IUT y una indicación para activar el UE-2 para establecer la configuración de la portadora, si el UE-2 aún no ha establecido la portadora seleccionada, utilizando mecanismos de transporte tales como, entre otros: USSD, SMS, MBMS, CellBroadcast, conducto IP que corre sobre GPRS en GERAN, UTRAN, LTE, WLAN, WiMax o CDMA2000.

En la etapa 1007, el UE-2 envía un mensaje de establecimiento de llamada CS a las entidades de interfuncionamiento y en la etapa 1008 las entidades de interfuncionamiento responden con un mensaje de llamada en curso y comienzan a configurar la ruta de señalización de control de portadora CS. En las etapas 1009 y 1010, las entidades de interfuncionamiento envían una SIP INVITE hacia el AS SCC a través de entidades IMS. En la etapa 1013, cuando las entidades de interfuncionamiento reciben un SIP 200 OK desde el SCC AS a través de entidades IMS, las entidades de interfuncionamiento mapean la respuesta SIP 200 OK recibida a un mensaje CONEXIÓN y lo envían al UE-2.

En la etapa 1014, al recibir el mensaje CONEXIÓN, el UE-2 envía un mensaje CONEXIÓN ACK a las entidades de interfuncionamiento y en la etapa 1017 el UE-2, las entidades de interfuncionamiento y el SCC AS completan la configuración de la ruta de señalización de control de portadora CS. En este punto, se establece el control de sesión colaborativa entre el UE-2 y el SCC AS. El UE-2 se convierte en el UE controlador para la sesión colaborativa establecida.

En la etapa 1018 se establece el tipo de medio (medio-A) entre el UE-2 y la parte remota. En este momento, el tramo remoto se actualiza en consecuencia. En las etapas 1019 y 1020, después del establecimiento exitoso del control de sesión colaborativa y el tipo de medio (medio-A) en el UE-2, el SCC AS envía al UE-1 un mensaje de respuesta al mensaje de solicitud de transferencia o un mensaje que indica el resultado del mensaje de solicitud de transferencia utilizando un mensaje SIP NOTIFY. En la etapa 1023 se puede liberar el medio A anterior en el UE-1 y se libera el control de sesión colaborativa. En este momento el UE-1 se convierte en un UE controlado. Se debe observar que en el ejemplo anterior no se describen las etapas que implican la comunicación de mensajes convencionales de acuse de recibo. Si se transfieren todos los flujos de medios del UE-1 al UE-2, se puede liberar la sesión existente en el UE-1.

Los ejemplos anteriores describen flujos que tienen como resultado una transferencia exitosa de la función o los medios de controlador IUT a un UE elegible con capacidad de controlador. Sin embargo, si la transferencia no tiene éxito, el sistema puede enviar varios códigos de motivo de respuesta de mensaje o indicaciones al UE solicitante que proporcionen una explicación de por qué falló la transferencia. Los códigos o indicaciones de motivo de respuesta de ejemplo incluyen: no hay capacidad de controlador IUT (por lo que ese UE no puede realizar una solicitud legítima de estado de controlador), ya existe un UE controlador IUT para la sesión (en los casos en los que solo un UE puede ser un controlador IUT, por ejemplo), el UE no tiene la misma suscripción, límite máximo de controladores IUT, no disponible (no registrado, sin batería, etc.), no autorizado para ser un controlador IUT, tipo de medio no soportado, formato de medio no soportado, no se permite establecer una nueva sesión porque ya se ha alcanzado el número máximo de sesiones simultáneas, ocupado, etc. Los códigos o indicaciones de motivo de respuesta pueden estar contenidos en una cabecera de advertencia SIP incluida en la respuesta. En algunos casos, la respuesta de rechazo y los códigos o indicaciones de motivo asociados pueden incluirse en el cuerpo de una solicitud SIP NOTIFY, como dentro de una SIPfrag que contiene parte del mensaje de respuesta recibido en el SCC AS u otro nodo de red.

Durante el funcionamiento del presente sistema, un UE controlador IUT puede suscribirse para recibir notificaciones que describen las sesiones en curso en un UE particular o en todos los UE asociados con el usuario. Las notificaciones pueden identificar varias sesiones en curso y sus UE controlados y/o controladores asociados. En un ejemplo, un usuario A ha iniciado dos sesiones; una con el usuario C y el usuario D, y otra con el usuario B. Haciendo referencia a la sesión con los usuarios C y D, el usuario A tiene tres sesiones para su conjunto de UE controladores IUT (es decir, los dispositivos 1, 2 y 3). Para la conversación con el usuario B, el usuario A tiene dos sesiones en su conjunto UE IUT (es decir, los dispositivos 2 y 3). En este ejemplo, el usuario A puede desear conocer información que describa las sesiones actualmente en curso asociadas con los UE IUT del usuario. En ese caso, el usuario A puede enviar una solicitud (por ejemplo, SIP SUBSCRIBE) y obtener una respuesta (por ejemplo, SIP NOTIFY) con la siguiente información configurada por diálogo objetivo utilizando el paquete de eventos de diálogo como se describe en RFC 4235:

- Diálogo de destino

- ID del usuario participante (SIP URI, TEL URI o apodo)

- ID/apodo del dispositivo IUT

- ID/apodo del dispositivo controlador IUT

- Tipo de medio o archivo por sesión (es decir, una notificación de que hay tres sesiones diferentes en los dispositivos del usuario A para una sesión colaborativa particular)

Como se ilustra en el ejemplo mostrado en la figura 11, pueden existir múltiples UE para el usuario A para todas las sesiones en curso. El dispositivo 60 del usuario A ha emitido una solicitud de transferencia al dispositivo 64 del usuario A para la sesión colaborativa X que implica comunicación con los dispositivos 68 o 70 del usuario C y el dispositivo 62 del usuario A ha enviado una solicitud de transferencia al dispositivo 64 del usuario A para la sesión colaborativa Y que implica comunicación con el dispositivo 66 del usuario B. Cuando se recibe una nueva invitación para un nuevo tipo de medio en el dispositivo 62 del usuario A, es posible enviar una solicitud de transferencia de medios o una solicitud de redirección utilizando el dispositivo 60 del usuario A para transferir la nueva invitación al dispositivo 64 del usuario A. Si la solicitud de transferencia de medios o la solicitud de redirección se ha aceptado con éxito, la notificación de éxito se transfiere a los UE controladores para la sesión o a todos los UE controladores IUT que son los dispositivos 60 y 62 del usuario A. Dependiendo de la preferencia del usuario y la capacidad del dispositivo, un usuario puede configurar recibir notificaciones en todos los UE controladores o asignar qué UE controlador recibe notificaciones entre múltiples UE controladores en lugar de recibir notificaciones para todos los UE controladores. Como se muestra en la figura 11, aunque existen múltiples UE para el usuario A, sólo existe un UE controlador IUT para cada sesión colaborativa. Como tal, sólo el UE controlador para la sesión colaborativa particular recibe una notificación cuando el estado de la sesión ha cambiado en esa sesión colaborativa particular. En algunas implementaciones puede haber una cantidad sustancial de tráfico de notificación elegible para transmitirse a cualesquiera uno o varios UE controladores. Se pueden implementar mecanismos de filtrado dentro del mecanismo de notificación en la red y/o en cada UE individual para optimizar el volumen de tráfico de notificación que se transmite a los UE de control.

Para sesiones de terminación, en una implementación del presente sistema, al UE que primero reciba la solicitud para el establecimiento de sesión y sea capaz de aceptar la solicitud de establecimiento de sesión se puede asignar la función de controlador (de lo contrario, el UE que haya aceptado la sesión quedará bloqueado en la sesión y no tendrá la capacidad de enviar una solicitud de transferencia a otro UE del usuario). Al recibir una solicitud de establecimiento de sesión inicial (por ejemplo, una SIP INVITE, un SIP Re-INVITE o una SIP UPDATE) de la parte remota, es posible que la red necesite asegurarse de que la solicitud se enrute a un UE que sea un controlador o soporte la función de controlador. Una vez se ha establecido una sesión, es posible que el usuario de terminación desee transferir el control de sesión colaborativa a otro UE del mismo usuario. Si el UE objetivo no tiene capacidad de controlador IUT y no es un UE controlador IUT, entonces el UE objetivo no puede realizar una solicitud de transferencia a otro UE. Sin embargo, en algunos casos la transferencia aún puede realizarse. Por ejemplo, un UE puede permitir a un usuario proporcionar una configuración de redireccionamiento en la red, es decir, para redirigir la solicitud a un UE particular, tal como un UE controlador asignado por un usuario, cuando llega una solicitud de invitación al lado de terminación. Además, un UE puede permitir a un usuario configurar una preferencia de usuario para indicar qué portadora usar para establecimiento de sesión, posiblemente como una combinación de tipo de medio y capacidad del dispositivo. Por ejemplo, un usuario que tiene dos UE puede configurar una preferencia de usuario para usar una portadora de conmutación de paquetes para sesiones de tipo voz en el UE-1 y para usar una portadora de conmutación de circuitos para sesiones de tipo video en el UE-2.

Alternativamente, si no hay una configuración de redireccionamiento, cuando la red de terminación recibe una solicitud de invitación, la red envía una solicitud para preguntar al usuario si acepta la invitación en el UE o redirige a otro UE (es decir, un UE controlador). Si el usuario decide redirigir a otro UE (que es un UE controlador), entonces la red envía una respuesta que contiene la identidad del UE transferida a la red de terminación y la red de terminación envía la solicitud de invitación al UE asignado por el usuario.

Alternativamente, si no hay una configuración de redireccionamiento, cuando el UE de terminación recibe una solicitud de invitación, el UE pregunta al usuario si acepta la invitación o redirige a otro UE. Si el usuario decide redirigir a otro UE (es decir, un UE controlador), entonces la red envía una solicitud de redireccionamiento a la red de terminación. En ese caso, la red de terminación envía la solicitud de invitación al UE asignado por el usuario. Cuando la red de terminación recibe (por ejemplo, a través del SCC AS) un mensaje de invitación (por ejemplo, una SIP INVITE, un SIP Re-INVITE o una SIP UPDATE) la red de terminación determina qué UE de terminación se convertirá en un controlador IUT basándose en la capacidad del dispositivo, la preferencia y/o la política del usuario, y qué portadora usar para el UE de terminación. La red comprueba que el UE de terminación se haya registrado para la portadora identificado. De lo contrario, la red puede enviar una indicación al UE de terminación para iniciar el registro de la portadora. Después del registro exitoso de la portadora, la red (por ejemplo, a través del SCC AS) envía un mensaje de solicitud de invitación (por ejemplo, SIP INVITE) que indica que el control de sesión y ciertos tipos de medios se presentan al UE de terminación. Al recibir un mensaje de respuesta Ack u OK, el SCC AS puede enviar una indicación a la parte remota de que el flujo de medios ha sido redirigido a un UE diferente.

Las figuras 12a y 12b ilustran un flujo para establecimiento de sesión colaborativa de terminación cuando una parte remota envía una solicitud de invitación de sesión. En una implementación, un ICS mejorado con servidor MSC podría ser una entidad a modo de ejemplo de la entidad de interfuncionamiento. Alternativamente, las entidades de interfuncionamiento pueden consistir en un servidor MSC heredado y MGCF. El flujo de ejemplo supone que el UE-1 ha configurado una capacidad del dispositivo/preferencias del usuario para ser un controlador IUT y utilizar una portadora PS para el establecimiento de sesión con tipo de vídeo. El UE-2 ha configurado una capacidad del dispositivo/preferencias del usuario para usar una portadora CS para el establecimiento de sesión con un tipo de medio de voz. La figura 12a muestra un flujo de alto nivel, como sigue. En la etapa 1101, la red de terminación (por ejemplo, SCC AS) recibe un mensaje de invitación (por ejemplo, un SIP INVITE o un SIP Re-INVITE). En la etapa 1102, el SCC AS determina qué UE de terminación se convertirá en un controlador IUT en función de la capacidad del dispositivo, la preferencia del usuario y/o la política, y qué portadora usar para el UE de terminación en función de la capacidad del dispositivo, la preferencia del usuario y/o la política. En el ejemplo, el SCC AS determina que el UE-1 actúa como un controlador IUT y utiliza una portadora PS con un tipo de medio de vídeo mientras que el UE-2 utiliza una portadora CS con un tipo de medio de voz. En las etapas 1103 y 1104, el SCC AS envía el mensaje de solicitud de invitación (por ejemplo, SIP INVITE) a las entidades de interfuncionamiento a través de entidades IMS para establecer una sesión colaborativa hacia el UE-2. En la etapa 1105, las entidades de interfuncionamiento envían un mensaje de establecimiento de llamada CS al UE-2. En la etapa 1106, el UE-2, las entidades de interfuncionamiento y el SCC AS completan la configuración de la ruta de señalización de control de portadora CS y el SCC AS y la parte remota completan el establecimiento del tramo remoto. Se establece la sesión colaborativa con tipo de medio de voz entre el UE-2 y el SCC AS y se establece el tramo remoto entre el SCC AS y la parte remota.

En las etapas 1107 y 1108, el SCC AS envía un mensaje de solicitud de invitación (por ejemplo, SIP INVITE) al UE-1 a través de entidades IMS. En la etapa 1109, se establece la sesión colaborativa con el tipo de medio de vídeo entre el UE-1 y el SCC AS y se actualiza el tramo remoto entre el SCC AS y la parte remota. El UE-1 obtiene un control de sesión colaborativa que permite aplicar la solicitud de transferencia IUT.

En las etapas ilustradas en la figura 12a, en una implementación se supone que el UE-1 y el UE-2 pertenecen al mismo abonado (es decir, el mismo conjunto de suscripción) y el SCC AS determina establecer sesiones colaborativas sobre la red CS en el UE-2 y a través de la red PS en el UE-1 que mantiene el control de sesión colaborativa. En algunos casos, cuando las entidades de interfuncionamiento corresponden al servidor MSC y MGCF, los procedimientos de configuración de la portadora CS siguen las etapas 11-17 en la figura 7.4.2.2.2-2 del TS 23.292.

La figura 12b ilustra un flujo más detallado que en la figura 12a como sigue: en la etapa 1201, la red de terminación (por ejemplo, SCC AS) recibe un mensaje de invitación (por ejemplo, un SIP INVITE o un SIP Re-INVITE). En la etapa 1202, el SCC AS determina qué UE de terminación se convertirá en un controlador IUT en función de la capacidad del dispositivo, la preferencia del usuario y/o la política, y qué portadora usar para el UE de terminación en función de la capacidad del dispositivo, la preferencia del usuario y/o la política. En el ejemplo, el SCC AS determina que el UE-1 actúa como un controlador IUT y utiliza una portadora PS con un tipo de medio de vídeo mientras que el UE-2 utiliza una portadora CS con un tipo de medio de voz. En las etapas 1203 y 1204, el SCC AS envía el mensaje de solicitud de invitación (por ejemplo, SIP INVITE) a las entidades de interfuncionamiento a través de entidades IMS para establecer una sesión colaborativa hacia el UE-2. En las etapas 1205 y 1206, las entidades de interfuncionamiento envían un mensaje de establecimiento de llamada CS al UE-2 y reciben un mensaje de conexión de llamada CS. En las etapas 1207 a 1209, se envía un mensaje de respuesta SIP 200 OK a la parte remota a través de entidades IMS y SCC AS. La parte remota envía SIP ACK hacia las entidades de interfuncionamiento en las etapas 1210 a 1212 y las entidades de interfuncionamiento envían un mensaje de respuesta CONEXIÓN al UE-2. En la etapa 1214 se establece una sesión con un tipo de medio de voz entre el UE-2 y la parte remota.

En las etapas 1215 a 1217, el SCC AS envía el mensaje de solicitud de invitación (por ejemplo, SIP INVITE) al UE-1 de terminación para establecer una sesión con un tipo de medio de vídeo. En este punto, se establece el control de sesión colaborativa con el SCC AS y el UE-1 de terminación se convierte en un controlador IUT. Al recibir una respuesta SIP 200 OK del UE-2 a través de las entidades de interfuncionamiento y las entidades IMS como se muestra en las etapas 1218 a 1220, el SCC AS envía una SIP UPDATE a la parte remota para actualizar el tramo remoto en la etapa 1221. Después de respuestas SIP exitosas en las etapas 1222 a 1225, en la etapa 1226 se establece una sesión colaborativa con el tipo de medio de vídeo entre el UE-1 y el SCC AS y se actualiza el tramo remoto entre el SCC AS y la parte remota. Se debe observar que en el ejemplo anterior las etapas que implican la comunicación de mensajes convencionales de acuse de recibo no se describen completamente.

La figura 13 ilustra un flujo para transferir la funcionalidad de controlador IUT desde el UE-1 PS al UE-2 PS. El UE-1 y el UE-2 pueden utilizar la misma portadora o portadoras diferentes. Incluso si se utiliza una portadora de conmutación de paquetes en el UE-1 y UE-2, es posible utilizar IP-CAN 3GPP en el UE-1 e IP-CAN no 3GPP en el UE-2. En las etapas 1301 y 1302, el UE 1 decide transferir el control de sesión colaborativa y el medio A al UE 2. Por consiguiente, el UE-1 envía una solicitud al SCC AS a través de entidades IMS, indicando que el control de servicio actual y el tipo de medio (medio -A) se transferirá al UE 2. En la etapa 1305, el SCC AS identifica la solicitud, por ejemplo, la solicitud SIP REFER, verifica que el UE-2 está autorizado y es capaz de actuar como controlador y determina la portadora PS utilizada para el UE-2 según la capacidad del dispositivo, la preferencia del usuario y/o la política en la red.

En las etapas 1306 y 1307, el SCC AS genera y envía un mensaje de solicitud de establecimiento de sesión tal como una solicitud SIP INVITE (o SIP Re-INVITE) que indica el control de sesión colaborativa y el tipo de medio (medio-A). La solicitud de establecimiento de sesión se puede enrutar a través del tramo de acceso deseado (portadora) usando la etiqueta de característica de medios de identificador de flujo en la cabecera de aceptarcontacto descrita anteriormente. En la etapa 1312, se establece el control de sesión colaborativa entre el UE 2 y el SCC AS. El UE 2 se convierte en el UE controlador para la sesión colaborativa establecida. En la etapa 1313, se establece la comunicación del tipo de medio (medio-A) entre el UE 2 y la parte remota. El tramo remoto se actualiza en consecuencia. En las etapas 1314 y 1315, después del establecimiento exitoso del control de sesión colaborativa y el tipo de medio (medio-A) en el UE 2, el SCC AS envía al UE 1 un mensaje de respuesta al mensaje de solicitud de transferencia o un mensaje que notifica el resultado del mensaje de solicitud de transferencia, tal como un mensaje SIP NOTIFY. En la etapa 1318, se puede liberar el tipo de medio anterior (medio-A) en el UE 1 y el control de sesión colaborativa. El UE 1 se convierte en un UE controlado. Se debe observar que en el ejemplo anterior no se describen las etapas que implican la comunicación de mensajes convencionales de acuse de recibo.

Los presentes sistema y método pueden usarse para proporcionar una aplicación de transferencia de controlador IUT. Un método de ejemplo implementado por el presente sistema indica al menos una de la capacidad para realizar la función de controlador IUT y la incapacidad para realizar la función de controlador IUT. El método incluye proporcionar en un mensaje de protocolo de inicio de sesión (SIP) una indicación de la capacidad de soportar la función de IUT:controlador, y proporcionar en un mensaje de protocolo de inicio de sesión (SIP) una indicación de la incapacidad de soportar la función de IUT:controlador. La indicación de al menos una de la capacidad para realizar la función de controlador IUT y la incapacidad para soportar la función de IUT :controlador puede indicarse utilizando una etiqueta de característica de medios. La etiqueta de característica de medios puede indicar al menos uno de los valores "Activo", que indica la capacidad de actuar como controlador IUT y que actualmente actúa como controlador IUT para una sesión colaborativa, "Inactivo", que indica la capacidad de actuar como controlador IUT, pero actualmente no actúa como controlador IUT para una sesión colaborativa y "Pasivo" indica la incapacidad de actuar como controlador IUT para una sesión colaborativa.

Dependiendo de la implementación, la etiqueta de característica de medios puede estar contenida dentro de una cabecera de contacto. El mensaje del protocolo de inicio de sesión (SIP) puede incluir uno de una solicitud SIP REGISTER, una solicitud SIP INVITE, una solicitud SIP Re-INVITE, una solicitud SIP UPDATE, una solicitud SIP PRACK, una solicitud SIP REFER, una solicitud SIP PUBLISH, una solicitud de SIP MESSAGE, solicitud de SUBSCRIBE SIP, solicitud de SIP NOTIFY, solicitud de SIP OPTIONS y respuesta SIP.

Un método de ejemplo de transferir la función de controlador IUT de un dispositivo a otro puede incluir proporcionar en un mensaje de protocolo de inicio de sesión (SIP) una indicación de la transferencia de la función de IUT:controlador. La indicación de la transferencia de la función de IUT:controlador puede indicarse utilizando una etiqueta de característica de medios. La etiqueta de característica de medios puede estar contenida en una cabecera de aceptar-contacto. El mensaje del protocolo de inicio de sesión (SIP) puede ser uno de entre una solicitud SIP INVITE, una solicitud SIP Re-INVITE, una solicitud SIP UPDATE, una solicitud SIP PRACK, una solicitud SIP REFER, una solicitud SIP PUBLISH, una solicitud SIP MESSAGE, una solicitud de SUBSCRIBE SIP, una solicitud de SIP NOTIFY, solicitud de SIP OPTIONS y una solicitud de SIP INFO. La etiqueta de característica de medios puede estar contenida en una cabecera de aceptar-contacto que a su vez está contenida dentro de una cabecera de referencia.

El método puede incluir recibir, en respuesta, una indicación de una transferencia IUT exitosa o una transferencia IUT fallida. La indicación puede incluir una respuesta SIP, una solicitud SIP UPDATE, una solicitud SIP PRACK, una solicitud SIP NOTIFY, una solicitud SIP PUBLISH, una solicitud SIP MESSAGE, una solicitud SIP OPTIONS o una solicitud SIP INFO. Alternativamente, la indicación puede ser una de entre una etiqueta de característica de medios en una cabecera de contacto, dentro del cuerpo de una solicitud SIP o respuesta SIP, dentro de una SIPfrag en un cuerpo de una solicitud SIP o respuesta SIP, o codificada en un formato XML.

Alternativamente, el método puede proporcionar la transferencia de la función de controlador IUT desde un punto de conexión a otro punto de conexión. La tecnología de punto de conexión puede incluir IEEE-802.11, IEEE-802.11a, IEEE-802.11 b, IEEE-802.11g, IEEE-802.11n, 3GPP-GERAN, 3GPP-UTRAN-FDD, 3GPP-UTRAN-TDD, 3GPP-E-UTRAN-FDD, 3GPP-E-UTRAN-TDD, ADSL, ADSL2, ADSL2+, RADSL, SDSL, HDSL, HDSL2, G.SHDSL, VDSL, IDSL, 3GPP2-1X, 3GPP2-1X-HRPD, 3GPP2-UMB, DOCSIS, IEEE-802.3, IEEE-802.3a, IEEE-802.3e, IEEE-802.3i, IEEE-802.3j, IEEE-802.3u, IEEE-802.3ab, IEEE-802.3ae, IEEE-802.3ak, IEEE-802.3aq, IEEE-802.3an, IEEE-802.3y, IEEE-802.3z, IEEE-802.3y, 3GPP-GERAN, 3GPP-UTRAN, 3GPP-E-UTRAN, 3GPP-WLAN, 3GPP-GAN o 3GPP-HSPA. En algunos casos, sin embargo, se pueden emplear otras tecnologías, clases o tipos de acceso.

Otro método de ejemplo de transferir la función de controlador IUT de un dispositivo a otro incluye recibir en un mensaje de protocolo de inicio de sesión (SIP) una indicación de la transferencia de la función de IUT:controlador. La indicación de la transferencia de la función de IUT:controlador puede indicarse utilizando una etiqueta de característica de medios. La etiqueta de característica de medios puede estar contenida en una cabecera de aceptar-contacto. El mensaje del protocolo de inicio de sesión (SIP) puede ser uno o más de una solicitud SIP INVITE, una solicitud SIP Re-INVITE, una solicitud SIP UPD<a>T<e>, una solicitud SIP PRACK, una solicitud SIP REFER, una solicitud SIP PUBLISH, una solicitud SIP MESSAGE, una solicitud de SUBSCRIBE SIP, una solicitud de SIP NOTIFY, una solicitud de SIP OPTIONS o una solicitud de SIP INFO. La etiqueta de característica de medios puede estar contenida en una cabecera de aceptar-contacto, a su vez contenida dentro de una cabecera de referencia. El método puede incluir el envío en respuesta de una indicación de transferencia IUT exitosa y transferencia IUT fallida. La indicación puede estar contenida en una respuesta SIP, una solicitud SIP UPDATE, una solicitud SIP PRACK, una solicitud SIP NOTIFY, una solicitud SIP pUb LISH, una solicitud SIP MESSAGE, una solicitud SIP OPTIONS y una solicitud SIP INFO. La indicación puede ser una de entre una etiqueta de característica de medios en una cabecera de contacto, dentro del cuerpo de una solicitud SIP o respuesta SIP, dentro de una SIPfrag en el cuerpo de una solicitud SIP o respuesta SIP, o codificada en formato XML. El método puede incluir realizar la función de controlador IUT activo para la sesión colaborativa.

El presente sistema puede configurarse además para dirigir una SOLICITUD SIP a través de una aplicación de acceso específica. Un método de ejemplo para identificar un flujo de registro a través de una red de acceso incluye proporcionar en una cabecera P-Access-Network-Info de una solicitud REGISTER del protocolo de inicio de sesión (SIP) un identificador que identifica el tipo de acceso de la red de acceso en sobre la que se transporta la solicitud SIP REGISTER, y proporcionar en la cabecera de contacto de una solicitud REGISTER del protocolo de inicio de sesión (SIP) una etiqueta de característica de medios que contiene un valor que identifica de forma única el flujo de registro sobre todos los demás registros realizados por el mismo dispositivo. La etiqueta de característica de medios puede contener un valor derivado del parámetro de cabecera de contacto "reg-id" incluido en la solicitud SIP REGISTER. La etiqueta de característica de medios puede contener un valor que es una cadena de texto. La etiqueta de característica de medios contiene un valor que es una cadena de texto introducida por el usuario. Un método de ejemplo para identificar un flujo de registro a través de una red de acceso incluye obtener de una cabecera P-Access-Network-Info de una solicitud REGISTER del protocolo de inicio de sesión (SIP), un identificador que identifique el tipo de acceso o la clase de acceso de la red de acceso sobre la que se transporta la solicitud SIP REGISTER, obtener de una cabecera de contacto de una solicitud REGISTER de protocolo de inicio de sesión (SIP) una etiqueta de característica de medios que contenga un valor que identifique de forma única el flujo de registro sobre todos los demás registros realizados por el mismo dispositivo, y asociar el tipo de acceso o la clase de acceso con el valor de la etiqueta de característica de medios. El contenido de la solicitud REGISTER del protocolo de inicio de sesión (SIP) se puede obtener utilizando al menos uno del cuerpo de una solicitud REGISTER de un tercero recibida, la cabecera P-Access-Network-Info en una solicitud REGISTER de un tercero recibida y el paquete de eventos de registro dentro del cuerpo de una solicitud SIP NOTIFY. El método puede incluir recibir una solicitud SIP o generar una solicitud SIP, determinar que la solicitud SIP debe enrutarse a través de un tramo de acceso particular identificado por un tipo de acceso o valor de clase de acceso, recuperar el valor de etiqueta de característica de medios asociado con el tipo de acceso o el valor de la clase de acceso, e incluir en la solicitud SIP en una cabecera de aceptar-contacto el valor de etiqueta de característica de medios recuperado. La solicitud SIP puede ser una de entre una solicitud SIP INVITE, una solicitud SIP Re-INVITE, una solicitud SIP UPDATE, una solicitud SIP PRACK, una solicitud SIP REFER, una solicitud SIP PUBLISH, una solicitud SIP MESSAGE, una solicitud SIP SUBSCRIBE, una solicitud de SIP OPTIONS y una solicitud de SIP INFO.

Un método de ejemplo para identificar un flujo de registro a través de una red de acceso sobre la que se enviará una solicitud incluye proporcionar en una cabecera de aceptar-contacto de una solicitud SIP una etiqueta de característica de medios que contiene un valor que identifica de forma única un flujo de registro de un dispositivo. La etiqueta de característica de medios puede contener un valor que es una cadena de texto. La etiqueta de característica de medios puede contener un valor que es una cadena de texto introducida por el usuario. La solicitud SIP puede ser una de entre una solicitud SIP INViTe , una solicitud SIP RE-INVITE, una solicitud SIP UPDATE, una solicitud SIP PRACK, una solicitud SIP REFER, una solicitud SIP PUBLISH, una solicitud SIP MESSAGE, una solicitud SIP SUBSCRIBE, una solicitud de SIP OPTIONS y una solicitud de SlP INFO. La etiqueta de característica de medios puede estar contenida en una cabecera de aceptar-contacto, a su vez contenida dentro de una cabecera de referencia.

La figura 14 es una ilustración de un flujo de mensajes alternativo para la transferencia de funcionalidad de medios/controlador a otro UE dentro de una sesión colaborativa usando el punto de referencia Gm. El flujo de mensajes ilustrado en la figura 14 muestra un método de ejemplo para transferir medios y funcionalidad de controlador IUT del UE-1 al UE-2, donde la sesión entrante se entrega a través del punto de referencia Gm y los medios se establecen a través de la red CS. En el ejemplo, se supone que el UE-1 y el UE-2 pertenecen al mismo abonado (es decir, al mismo conjunto de suscripción), las entidades de interfuncionamiento corresponden a MSC mejorado para ICS y siguen los procedimientos de terminación con medios CS utilizando el punto de referencia Gm mostrado en TS 23.292. En este ejemplo, cuando las entidades de interfuncionamiento corresponden al servidor MSC y MGCF, los procedimientos de configuración de portadora CS pueden seguir las etapas 11-17 en la figura 7.4.2.2.2-2 del TS 23.292.

Haciendo referencia a la figura 14, en la etapa 1401, el UE 1 decide transferir el medio-A y el control de sesión colaborativa al UE 2 y envía a las entidades IMS una solicitud de transferencia que indica que el control de sesión colaborativa actual y el medio-A se van a transferir al UE 2. En la etapa 1402 las entidades IMS reenvían la solicitud de transferencia al SCC AS y en la etapa 1403 el SCC AS identifica la solicitud de transferencia, verifica que el UE-2 está autorizado y es capaz de actuar como controlador, realiza T-ADS basándose en la capacidad del UE-2, las preferencias del usuario y/o la política en la red, y elige el dominio CS para la configuración del medio A. Si al UE-2 no se le permite actuar como controlador o la solicitud de transferencia no se puede realizar con éxito, el SCC AS rechaza la solicitud con el motivo y deja de seguir las etapas siguientes.

Aún haciendo referencia a la figura 14, en la etapa 1404 el SCC AS genera y envía a entidades IMS una solicitud INVITE que indica que el medio-A y el control de sesión colaborativa, y que el UE-2 inicia el procedimiento de establecimiento de portadora CS, tal como se muestra en TS 23.292. En la etapa 1405, las entidades IMS envían la solicitud INVITE recibida al UE-2, y en la etapa 1406, el UE-2 envía un mensaje de establecimiento de llamada CS a las entidades de interfuncionamiento. En la etapa 1401, las entidades de interfuncionamiento responden con un mensaje de llamada en curso y comienzan a configurar la ruta de señalización de control de portadora CS, y en las etapas 1408 y 1409 las entidades de interfuncionamiento envían una INVITE hacia el AS SCC a través de entidades IMS. En la etapa 1410, el UE-2, las entidades de interfuncionamiento y el AS SCC completan la configuración de la ruta de señalización de control de portadora CS. Se establece el control de sesión colaborativa entre el UE 2 y el SCC AS. El UE 2 se convierte en el UE controlador para la sesión colaborativa establecida. En la etapa 1411 se establece el medio A entre el UE 2 y la parte remota. El tramo remoto se actualiza en consecuencia. En la etapa 1412, después de la transferencia exitosa del control de sesión colaborativa y el medio-A al UE 2, el SCC AS envía a las entidades IMS un mensaje de resultado de la transferencia IUT, y en la etapa 1413 las entidades IMS reenvían el mensaje de resultado de la transferencia IUT al UE-1. Finalmente, en la etapa 1414 se libera el anterior medio A y control de sesión colaborativa. El UE 1 se convierte en un UE controlado.

La figura 15 es una ilustración de un flujo de mensajes alternativo para la transferencia de funcionalidad de medios/controlador a otro UE dentro de la sesión colaborativa utilizando el punto de referencia I1. El flujo de mensajes ilustrado en la figura 15 muestra un método de ejemplo para transferir la funcionalidad de controlador IUT del UE-1 al UE-2, donde la sesión entrante se entrega a través del punto de referencia I1 y los medios se establecen a través de la red CS. En este ejemplo, se supone que el UE-1 y el UE-2 pertenecen al mismo abonado (es decir, al mismo conjunto de suscripción), las entidades de interfuncionamiento corresponden a MSC mejorado para ICS y siguen los procedimientos de terminación con medios CS utilizando el punto de referencia I1 mostrado en TS 23.292. En este ejemplo, cuando las entidades de interfuncionamiento corresponden al servidor MSC y MGCF, los procedimientos de configuración de la portadora CS siguen las etapas 11-17 en la figura 7.4.2.2.2-2 del TS 23.292.

Haciendo referencia a la figura 15, en la etapa 1501, el UE 1 decide transferir el medio-A y el control de sesión colaborativa al UE 2 y envía a las entidades IMS una solicitud de transferencia que indica que el control de sesión colaborativa actual y el medio-A se van a transferir al UE 2. En la etapa 1502 las entidades IMS reenvían la solicitud de transferencia al SCC AS y en la etapa 1503 el SCC AS identifica la solicitud de transferencia, verifica que el UE-2 tiene permiso y es capaz de actuar como controlador, realiza T-ADS basado en la capacidad UE-2, la preferencia del usuario y/o la política en la red, y elige el dominio CS para la configuración del medio A. Si al UE-2 no se le permite actuar como controlador o la solicitud de transferencia no se puede realizar con éxito, el SCC AS rechaza la solicitud con el motivo y deja de seguir las etapas siguientes. En la etapa 1504, el SCC AS genera y envía al UE-2 una solicitud de llamada entrante a través del punto de referencia I1 que indica que el UE-2 debe iniciar el procedimiento de establecimiento de portadora CS y que el control de sesión colaborativa y el medio-A se transferirán al UE-2, como se muestra en TS 23.292.

Aún haciendo referencia a la figura 15, en la etapa 1505 el UE-2 envía un mensaje de establecimiento de llamada CS a las entidades de interfuncionamiento y en la etapa 1506 las entidades de interfuncionamiento responden con un mensaje de llamada en curso, y comienza a configurar la ruta de señalización de control de portadora CS. En las etapas 1507 y 1508, las entidades de interfuncionamiento envían una INVITE hacia el SCC AS a través de entidades IMS, y en la etapa 1509, el UE-2, las entidades de interfuncionamiento y el SCC AS completan la configuración de la ruta de señalización de control de portadora CS. Se establece el control de sesión colaborativa entre el UE 2 y el SCC AS. El UE 2 se convierte en el UE controlador para la sesión colaborativa establecida. En la etapa 1510 se establece el medio A entre el UE 2 y la parte remota. El tramo remoto se actualiza en consecuencia. En la etapa 1511, después de la transferencia exitosa del control de sesión colaborativa y del medio A al UE 2, el SCC AS envía a las entidades IMS un mensaje de resultado de la transferencia IUT. En la etapa 1512 las entidades IMS reenvían el mensaje de resultado de la transferencia IUT al UE-1, y en la etapa 1513 se libera el control de sesión colaborativa y del medio A anterior. El UE 1 se convierte en un UE controlado.

La figura 16 es una ilustración de un flujo de mensajes alternativo para la transferencia de información de sesión en curso iniciada por controlador. En el ejemplo mostrado en la figura 16, el UE-1, el UE-2 y el UE-3 pueden estar bajo la misma suscripción de usuario. Hay una sesión con medios - A entre el UE-2 y la parte remota y otra sesión con medios - B entre el UE-3 y la parte remota. La figura 16 presenta un flujo de información del UE-1 que solicita toda la información del estado de la sesión en curso para los UE IUT del usuario.

Haciendo referencia a la figura 16, en la etapa 1601 el UE-1 envía al SCC AS una solicitud sobre información del estado de la sesión en curso para los UE IUT del usuario. La solicitud puede incluir qué información se obtendrá en la respuesta. La información puede incluir las sesiones en curso para los UE IUT del usuario, el tipo de medio por una sesión en curso y/o el UE de origen y el UE objetivo por una sesión en curso. En la etapa 1602, el SCC AS comprueba todas las sesiones en curso para los UE IUT del usuario y filtra la información solicitada, es decir, hay una sesión A con el tipo de medio A entre el UE-2 y la parte remota y otra sesión B con el tipo de medio B entre el UE-3 y la parte remota. En la etapa 1603, el SCC AS envía al UE-1 una respuesta sobre toda la información del estado de la sesión en curso en el UE-2 y el UE-3.

En implementaciones del presente sistema donde el SCC AS sirve a un ICS UE de terminación y recibe una solicitud SIP INVITE inicial debido a los criterios de filtrado iniciales y el T-ADS tiene como resultado la elección de entregar medios en el dominio PS, el SCC AS puede actuar como un B2BUA. Si se registran múltiples contactos en el dominio PS y el T-ADS elige establecer diferentes tipos de medios utilizando diferentes IP-CAN, el SCC AS puede, para cada IP-CAN del dominio PS seleccionado, crear una solicitud SIP INVITE según 3GPP TS24.229. La solicitud SIP INVITE puede incluir i) una cabecera de aceptar-contacto que contiene la etiqueta de característica de medios g.3gpp.icsflow que contiene el valor asociado en el registro con el tipo de acceso o clase de acceso del IP-CAN del dominio PS seleccionado y la etiqueta de característica de medios g.3gpp.ics que contiene el valor "principal" junto con los parámetros "requerir" y "explícito", y ii) si ya existe un tramo existente para esta sesión o está en proceso de establecerse entre el SCC AS y el ICS UE que utiliza un IP-CAN diferente, una cabecera diálogo objetivo que contiene los parámetros de diálogo para ese diálogo existente entre el SCC AS y el ICS UE (el SCC AS SCC AS puede incluir una cabecera diálogo objetivo en la solicitud SIP INVITE para que el ICS UE pueda correlacionar diferentes solicitudes como parte de la misma sesión), y iii) un SDP para el o los tipos de medios seleccionados para establecer usando este IP-CAN.

Si se registran múltiples contactos en el dominio PS y el T-ADS elige establecer todos los tipos de medios sobre el mismo IP-CAN, el SCC AS puede crear una solicitud SIP INVITE según 3GPP TS24.229 y puede incluir en la solicitud i) una cabecera de aceptar-contacto que contiene la etiqueta de característica de medios g.3gpp.icsflow que contiene el valor asociado en el registro con el tipo de acceso o clase de acceso del IP-CAN del dominio PS seleccionado y la etiqueta de característica de medios g.3gpp.ics que contiene el valor "principal" junto con los parámetros "requerir" y "explícito", ii) si ya existe o está en proceso de establecerse un tramo existente para esta sesión entre el SCC AS y el ICS UE utilizando una dirección IP-CAN diferente, una cabecera diálogo objetivo que contiene los parámetros de diálogo para ese diálogo existente entre el SCC AS y el ICS UE (el SCC AS SCC AS puede incluir una cabecera diálogo objetivo en la solicitud SIP INVITE para que el ICS UE pueda correlacionar diferentes solicitudes como parte de la misma sesión), y iii) un SDP para todos los tipos de medios contenidos en la solicitud SIP INVITE inicial.

Si solo se registra un contacto en el dominio PS, el SCC AS puede crear una solicitud SIP INVITE según 3GPP TS24.229 y puede incluir en la solicitud i) una cabecera de aceptar-contacto que contenga la etiqueta de característica de medios g.3gpp. ics que contiene el valor "principal" junto con los parámetros "requerir" y "explícito", y ii) un SDP para todos los tipos de medios contenidos en la solicitud SIP INVITE inicial.

Haciendo referencia a continuación a la figura 17, se ilustra un sistema de comunicaciones inalámbricas que incluye una realización de un UE 1700 a modo de ejemplo. El UE se puede hacer funcionar para implementar aspectos de la descripción, pero la descripción no debe limitarse a estas implementaciones. Aunque se ilustra como un teléfono móvil, el UE puede adoptar varias formas, entre ellas un teléfono inalámbrico, un dispositivo de radiolocalización, un asistente digital personal (PDA), un ordenador transportable, una tableta, un ordenador portátil, teléfonos inteligentes, impresoras, faxes, televisores, decodificadores y otros dispositivos de visualización de vídeo, equipos de audio para el hogar y otros sistemas de entretenimiento para el hogar, sistemas de control y monitorización del hogar (por ejemplo, monitorización del hogar, sistemas de alarma y sistemas de control climático) y electrodomésticos mejorados tales como refrigeradores informatizados. Muchos dispositivos adecuados combinan algunas o todas estas funciones. En algunas realizaciones de la descripción, el UE 1700 no es un dispositivo informático de uso general como un ordenador transportable, un portátil o una tableta, sino que es un dispositivo de comunicaciones de propósito especial como un teléfono móvil, un teléfono inalámbrico, un dispositivo de radiolocalización, una PDA, o un dispositivo de telecomunicaciones instalado en un vehículo. El UE 1700 también puede ser un dispositivo, incluir un dispositivo o estar incluido en un dispositivo que tenga capacidades similares pero que no sea transportable, tal como un ordenador de escritorio, un decodificador o un nodo de red. El UE 1700 puede soportar actividades especializadas tales como juegos, control de inventario, control de trabajos y/o funciones de gestión de tareas, etc.

El UE 1700 incluye una pantalla 702. El UE 1700 también incluye una superficie sensible al tacto, un teclado u otras teclas de entrada denominadas, en general, 704 para la entrada por parte de un usuario. El teclado puede ser un teclado alfanumérico completo o reducido como QWERTY, Dvorak, AZERTY y tipos secuenciales, o un teclado numérico tradicional con letras del alfabeto asociadas a un teclado telefónico. Las teclas de entrada pueden incluir una rueda de desplazamiento, una tecla de salida o escape, una bola de seguimiento y otras teclas funcionales o de navegación, que pueden presionarse hacia adentro para proporcionar una función de entrada adicional. El UE 1700 puede presentar opciones para que el usuario las seleccione, controles para que el usuario los active y/o cursores u otros indicadores para que el usuario los dirija.

El UE 1700 puede aceptar además la entrada de datos del usuario, incluidos números para marcar o varios valores de parámetros para configurar el funcionamiento del UE 1700. El UE 1700 puede además ejecutar una o más aplicaciones de software o software inalterable en respuesta a comandos del usuario. Estas aplicaciones pueden configurar el UE 1700 para realizar diversas funciones personalizadas en respuesta a la interacción del usuario. Además, el UE 1700 puede programarse y/o configurarse por aire, por ejemplo, desde una estación base inalámbrica, un punto de acceso inalámbrico o un UE par 1700.

Entre las diversas aplicaciones ejecutables por el UE 1700 se encuentra un navegador web, que permite que la pantalla 702 muestre una página web. La página web se puede obtener a través de comunicaciones inalámbricas con un nodo de acceso a la red inalámbrica, una torre de telefonía móvil, un UE par 1700 o cualquier otra red o sistema 1702 de comunicación inalámbrica. La red 1702 está acoplada a una red cableada 1704, tal como internet. A través del enlace inalámbrico y la red cableada, el UE 1700 tiene acceso a información en varios servidores, tal como un servidor 1706. El servidor 1706 puede proporcionar contenido que puede mostrarse en la pantalla 702. Alternativamente, el UE 1700 puede acceder a la red 1702 a través de un UE par 1700 que actúa como intermediario, en una conexión de tipo retransmisión o tipo salto.

La figura 18 muestra un diagrama de bloques del UE 1700. Si bien se representan una variedad de componentes conocidos de los UA 1700, en una realización se puede incluir en el UE 1700 un subconjunto de los componentes enumerados y/o componentes adicionales no enumerados. El UE 1700 incluye un procesador de señal digital (DSP) 1802 y una memoria 1804. Como se muestra, el UE 1700 puede incluir además una antena y una unidad frontal 1806, un transceptor de radiofrecuencia (RF) 1808, una unidad de procesamiento de banda base analógica 1810, un micrófono 1812, un altavoz auricular 1814, un puerto para auriculares 1816, una interfaz de entrada/salida 1818, una tarjeta de memoria extraíble 1820, un puerto de bus serie universal (USB) 1822, un subsistema de comunicación inalámbrica de corto alcance 1824, una alerta 1826, un teclado 1828, una pantalla de cristal líquido (LCD), que puede incluir una superficie sensible al tacto 1830, un controlador LCD 1832, una cámara de dispositivo acoplado por carga (CCD) 1834, un controlador de cámara 1836 y un sensor del sistema de posicionamiento global (GPS) 1838. En una realización, el UE 1700 puede incluir otro tipo de pantalla que no proporcione una pantalla sensible al tacto. En una realización, el DSP 1802 puede comunicarse directamente con la memoria 1804 sin pasar por la interfaz de entrada/salida 1818.

El DSP 1802 o alguna otra forma de controlador o unidad central de procesamiento opera para controlar los diversos componentes del UE 1700 según el software o software inalterable integrado almacenado en la memoria 1804 o almacenado en la memoria contenida dentro del propio DSP 1802. Además del software o software inalterable integrado, el DSP 1802 puede ejecutar otras aplicaciones almacenadas en la memoria 1804 o disponibles a través de medios portadores de información tales como medios transportables de almacenamiento de datos como la tarjeta de memoria extraíble 1820 o mediante comunicaciones de red cableadas o inalámbricas. El software de aplicación puede comprender un conjunto compilado de instrucciones legibles por máquina que configuran el DSP 1802 para proporcionar la funcionalidad deseada, o el software de aplicación puede ser instrucciones de software de alto nivel para ser procesadas por un intérprete o compilador para configurar indirectamente el DSP 1802.

La antena y la unidad frontal 1806 pueden proporcionarse para convertir entre señales inalámbricas y señales eléctricas, permitiendo que el UE 1700 envíe y reciba información desde una red celular o alguna otra red de comunicaciones inalámbricas disponible o desde un UE par 1700. En una realización, la antena y la unidad frontal 1806 pueden incluir múltiples antenas para soportar operaciones de formación de haces y/o múltiples entradas y múltiples salidas (MIMO). Como saben los expertos en la materia, las operaciones MIMO pueden proporcionar diversidad espacial que puede usarse para superar condiciones difíciles del canal y/o aumentar el rendimiento del canal. La antena y la unidad frontal 1806 pueden incluir componentes de sintonización de antena y/o adaptación de impedancia, amplificadores de potencia de RF y/o amplificadores de bajo ruido.

El transceptor de RF 1808 proporciona desplazamiento de frecuencia, convirtiendo señales de RF recibidas en banda base y convirtiendo señales de transmisión de banda base en RF. En algunas descripciones, se puede entender que un transceptor de radio o un transceptor de RF incluye otra funcionalidad de procesamiento de señales tal como modulación/demodulación, codificación/decodificación, entrelazado/desentrelazado, ensanchamiento/desensanchamiento, transformada rápida inversa de Fourier (IFFT)/transformada rápida de Fourier (FFT), adición/eliminación de prefijos cíclicos y otras funciones de procesamiento de señales. Por claridad, la descripción aquí separa la descripción de este procesamiento de señal de la etapa de RF y/o radio y asigna conceptualmente ese procesamiento de señal a la unidad de procesamiento de banda base analógica 1810 y/o al DSP 1802 u otra unidad de procesamiento central. En algunas realizaciones, el transceptor de RF 1808, partes de la antena y el extremo frontal 1806 y la unidad de procesamiento de banda base analógica 1810 pueden combinarse en una o más unidades de procesamiento y/o circuitos integrados de aplicación específica (ASIC).

La unidad de procesamiento de banda base analógico 1810 puede proporcionar diverso procesamiento analógico de entradas y salidas, por ejemplo, procesamiento analógico de entradas desde el micrófono 1812 y los auriculares 1816 y salidas al auricular 1814 y los audífonos 1816. Con ese fin, la unidad de procesamiento de banda base analógica 1810 puede tener puertos para conectarse al micrófono incorporado 1812 y al altavoz auricular 1814 que permiten usar el UE 1700 como un teléfono celular. La unidad de procesamiento de banda base analógica 1810 puede incluir además un puerto para conectarse a unos auriculares u otra configuración de altavoz y micrófono en manos libres. La unidad de procesamiento de banda base analógica 1810 puede proporcionar conversión de digital a analógico en un sentido de la señal y conversión de analógico a digital en el sentido de la señal opuesto. En algunas realizaciones, al menos parte de la funcionalidad de la unidad de procesamiento de banda base analógica 1810 puede ser proporcionada por componentes de procesamiento digital, por ejemplo, por el DSP 1802 o por otras unidades de procesamiento central.

El DSP 1802 puede realizar modulación/demodulación, codificación/decodificación, entrelazado/desentrelazado, ensanchamiento/desensanchamiento, transformada rápida inversa de Fourier (IFFT)/transformada rápida de Fourier (FFT), adición/eliminación de prefijos cíclicos y otras funciones de procesamiento de señales asociadas con las comunicaciones inalámbricas. En una realización, por ejemplo, en una aplicación de tecnología de acceso múltiple por división de código (CDMA), para una función de transmisor, el DSP 1802 puede realizar modulación, codificación, entrelazado y ensanchamiento, y para una función de receptor, el DSP 1802 puede realizar desensanchamiento, desentrelazado, decodificación y demodulación. En otra realización, por ejemplo, en una aplicación de tecnología de acceso múltiple por división de frecuencias ortogonales (OFDMA), para la función de transmisor, el DSP 1802 puede realizar modulación, codificación, entrelazado, transformada rápida inversa de Fourier y adición de prefijo cíclico, y para una función de receptor, el DSP 1802 puede realizar la eliminación de prefijos cíclicos, la transformada rápida de Fourier, el desentrelazado, la decodificación y la demodulación. En otras aplicaciones de tecnología inalámbrica, el DSP 1802 puede realizar otras funciones de procesamiento de señales y combinaciones de funciones de procesamiento de señales.

El DSP 1802 puede comunicarse con una red inalámbrica a través de la unidad de procesamiento de banda base analógica 1810. En algunas realizaciones, la comunicación puede proporcionar conectividad a internet, permitiendo a un usuario obtener acceso a contenido en internet y enviar y recibir correo electrónico o mensajes de texto. La interfaz de entrada/salida 1818 interconecta el DSP 1802 y varias memorias e interfaces. La memoria 1804 y la tarjeta de memoria extraíble 1820 pueden proporcionar software y datos para configurar el funcionamiento del DSP 1802. Entre las interfaces pueden estar la interfaz USB 1822 y el subsistema de comunicación inalámbrica de corto alcance 1824. Se puede usar la interfaz USB 1822 para cargar el UE 1700 y también puede permitir que el UE 1700 funcione como un dispositivo periférico para intercambiar información con un ordenador personal u otro sistema informático. El subsistema de comunicación inalámbrica de corto alcance 1824 puede incluir un puerto de infrarrojos, una interfaz Bluetooth, una interfaz inalámbrica compatible con IEEE 802.11 o cualquier otro subsistema de comunicación inalámbrica de corto alcance, que puede permitir que el UE 1700 se comunique de forma inalámbrica con otros dispositivos móviles cercanos y/o estaciones base inalámbricas.

La interfaz de entrada/salida 1818 puede conectar además el DSP 1802 a la alerta 1826 que, cuando se activa, hace que el UE 1700 proporcione un aviso al usuario, por ejemplo, haciendo sonar un timbre, reproduciendo una melodía o vibrando. La alerta 1826 puede servir como un mecanismo para alertar al usuario sobre cualquiera de varios eventos tales como una llamada entrante, un nuevo mensaje de texto y un recordatorio de cita mediante una vibración silenciosa o la reproducción de una melodía preasignada específica para una persona que llama en particular.

El teclado 1828 se acopla al DSP 1802 a través de la interfaz 1818 para proporcionar un mecanismo para que el usuario haga selecciones, introduzca información y de otro modo proporcione entrada al UE 1700. El teclado 1828 puede ser un teclado alfanumérico completo o reducido tal como QWERTY, Dvorak, AZERTY y tipos secuenciales, o un teclado numérico tradicional con letras del alfabeto asociadas a un teclado telefónico. Las teclas de entrada pueden incluir una rueda de desplazamiento, una tecla de salida o escape, una bola de seguimiento y otras teclas funcionales o de navegación, que pueden presionarse hacia adentro para proporcionar una función de entrada adicional. Otro mecanismo de entrada puede ser el LCD 1830, que puede incluir capacidad de pantalla táctil y también mostrar texto y/o gráficos al usuario. El controlador LCD 1832 acopla el DSP 1802 al LCD 1830.

La cámara CCD 1834, si está equipada, permite al UE 1700 tomar fotografías digitales. El DSP 1802 se comunica con la cámara CCD 1834 a través del controlador de cámara 1836. En otra realización, se puede emplear una cámara que funcione según una tecnología distinta de las cámaras de dispositivo acoplado por carga. El sensor GPS 1838 está acoplado al DSP 1802 para decodificar señales del sistema de posicionamiento global, permitiendo así que el UE 1700 determine su posición. También se pueden incluir otros periféricos para proporcionar funciones adicionales, por ejemplo, recepción de radio y televisión.

La figura 19 ilustra un entorno de software 1902 que puede ser implementado por el DSP 1802. El DSP 1802 ejecuta controladores del sistema operativo 1904 que proporcionan una plataforma desde la que funciona el resto del software. Los controladores 1904 del sistema operativo proporcionan controladores para el hardware UA con interfaces estandarizadas que son accesibles al software de aplicación. Los controladores del sistema operativo 1904 incluyen servicios de administración de aplicaciones ("AMS") 1906 que transfieren el control entre aplicaciones que se ejecutan en el UE 1700. También se muestran en la figura 19 una aplicación de navegador web 1908, una aplicación de reproductor multimedia 1910 y subprogramas Java 1912. La aplicación de navegador web 1908 configura el UE 1700 para funcionar como un navegador web, permitiendo al usuario introducir información en formularios y seleccionar enlaces para recuperar y ver páginas web. La aplicación de reproductor multimedia 1910 configura el UE 1700 para recuperar y reproducir medios de audio o audiovisuales. Los subprogramas Java 1912 configuran el UE 1700 para proporcionar juegos, utilidades y otras funciones. Un componente 1914 podría proporcionar la funcionalidad descrita en el presente documento.

El UE 1700, el dispositivo de acceso y otros componentes descritos anteriormente podrían incluir un componente de procesamiento que sea capaz de ejecutar instrucciones relacionadas con las acciones descritas anteriormente. La figura 20 ilustra un ejemplo de un sistema 2000 que incluye un componente de procesamiento 2010 adecuado para implementar una o más realizaciones dadas a conocer en el presente documento. Además del procesador 2010 (al que se puede hacer referencia como unidad de procesamiento central (CPU o DSP), el sistema 2000 podría incluir dispositivos de conectividad de red 2020, memoria de acceso aleatorio (RAM) 2030, memoria de solo lectura (ROM) 2040, almacenamiento secundario 2050 y dispositivos de entrada/salida (E/S) 2060. En algunas realizaciones, un programa para implementar la determinación de un número mínimo de ID de proceso HARQ puede almacenarse en la ROM 2040. En algunos casos, algunos de estos componentes pueden no estar presentes o pueden combinarse en varias combinaciones entre sí o con otros componentes no mostrados. Estos componentes pueden estar ubicados en una única entidad física o en más de una entidad física. Cualesquiera acciones descritas en el presente documento como realizadas por el procesador 2010 podrían ser asumidas por el procesador 2010 solo o por el procesador 2010 junto con uno o más componentes mostrados o no mostrados en el dibujo.

El procesador 2010 ejecuta instrucciones, códigos, programas informáticos o scripts a los que podría acceder desde los dispositivos de conectividad de red 2020, RAM 2030, ROM 2040 o almacenamiento secundario 2050 (que podría incluir varios sistemas basados en disco tales como disco duro, disquete, o disco óptico). Si bien solo se muestra un procesador 2010, pueden estar presentes múltiples procesadores. Por lo tanto, si bien se puede considerar que las instrucciones son ejecutadas por un procesador, las instrucciones pueden ser ejecutadas simultáneamente, en serie o de otro modo por uno o varios procesadores. El procesador 2010 puede implementarse como uno o más chips de CPU.

Los dispositivos de conectividad de red 2020 pueden adoptar la forma de módems, bancos de módems, dispositivos Ethernet, dispositivos de interfaz de bus serie universal (USB), interfaces serie, dispositivos Token Ring, dispositivos de interfaz de datos distribuidos por fibra (FDDI), dispositivos de la red de área local inalámbrica (WLAN), dispositivos transceptores de radio tales como dispositivos de acceso múltiple por división de código (CDMA), dispositivos transceptores de radio del sistema global para comunicaciones móviles (GSM), dispositivos de interoperabilidad mundial para acceso por microondas (WiMAX) y/u otros dispositivos bien conocidos para conectarse a redes. Estos dispositivos de conectividad de red 2020 pueden permitir que el procesador 2010 se comunique con internet o una o más redes de telecomunicaciones u otras redes desde las que el procesador 2010 podría recibir información o a las que el procesador 2010 podría enviar información.

Los dispositivos de conectividad de red 2020 también podrían incluir uno o más componentes transceptores 2025 capaces de transmitir y/o recibir datos de forma inalámbrica en forma de ondas electromagnéticas, tales como señales de radiofrecuencia o señales de frecuencia de microondas. Alternativamente, los datos pueden propagarse en o sobre la superficie de conductores eléctricos, en cables coaxiales, en guías de ondas, en medios ópticos tales como fibra óptica o en otros medios. El componente transceptor 2025 podría incluir unidades receptoras y transmisoras separadas o un único transceptor. La información transmitida o recibida por el transceptor 2025 puede incluir datos que han sido procesados por el procesador 2010 o instrucciones que deben ser ejecutadas por el procesador 2010. Dicha información puede recibirse y enviarse a una red en forma, por ejemplo, de una Señal de banda base de datos de ordenador o señal incorporada en una onda portadora. Los datos pueden ordenarse según diferentes secuencias según sea deseable para procesar o generar los datos o transmitir o recibir los datos. La señal de banda base, la señal incrustada en la onda portadora u otros tipos de señales utilizadas actualmente o desarrolladas en el futuro pueden denominarse medio de transmisión y pueden generarse según varios métodos bien conocidos por un experto en la materia.

La RAM 2030 podría usarse para almacenar datos volátiles y quizás para almacenar instrucciones que ejecuta el procesador 2010. La ROM 2040 es un dispositivo de memoria no volátil que normalmente tiene una capacidad de memoria menor que la capacidad de memoria del almacenamiento secundario 2050. La ROM 2040 podría usarse para almacenar instrucciones y quizás datos que se leen durante la ejecución de las instrucciones. El acceso tanto a la RAM 2030 como a la ROM 2040 es normalmente más rápido que al almacenamiento secundario 2050. El almacenamiento secundario 2050 normalmente está compuesto por una o más unidades de disco o unidades de cinta y podría usarse para almacenamiento no volátil de datos o como un dispositivo de almacenamiento de datos de desbordamiento si la RAM 2030 no es lo suficientemente grande para contener todos los datos de trabajo. El almacenamiento secundario 2050 puede usarse para almacenar programas que se cargan en la RAM 2030 cuando dichos programas se seleccionan para su ejecución.

Los dispositivos de E/S 2060 pueden incluir pantallas de cristal líquido (LCD), pantallas táctiles, teclados, teclados numéricos, interruptores, diales, ratones, bolas de seguimiento, reconocedores de voz, lectores de tarjetas, lectores de cintas de papel, impresoras, monitores de vídeo u otros dispositivos de entrada conocidos. Además, se podría considerar que el transceptor 2025 es un componente de los dispositivos de E/S 2060 en lugar de o además de ser un componente de los dispositivos de conectividad de red 2020. Algunos o todos los dispositivos de E/S 2060 pueden ser sustancialmente similares a varios componentes representados en el dibujo descrito anteriormente del UE 1700, tales como la pantalla y la entrada.

Por ejemplo, los diversos elementos o componentes pueden combinarse o integrarse en otro sistema o ciertas características pueden omitirse o no implementarse.

Además, las técnicas, sistemas, subsistemas y métodos descritos e ilustrados en las diversas realizaciones como discretos o separados pueden combinarse o integrarse con otros sistemas, módulos, técnicas o métodos sin apartarse del alcance de la presente descripción. Otros elementos mostrados o discutidos como acoplados o directamente acoplados o comunicándose entre sí pueden estar acoplados indirectamente o comunicándose a través de alguna interfaz, dispositivo o componente intermedio, ya sea eléctrica, mecánicamente o de otro modo.

Claims (9)

REIVINDICACIONES

1. Un método en un nodo de red (212) para transferir una función de controlador de transferencia entre UE, IUT, desde un primer terminal (216) a un segundo terminal (218) asociado con una red, que comprende:

obtener un tipo de acceso y una etiqueta de característica de medios enviados a la red por el segundo terminal (218) en una cabecera P-Access-Network-Info y una cabecera de contacto, respectivamente, de una solicitud REGISTER de protocolo de inicio de sesión, SIP, conteniendo la etiqueta de característica de medios un identificador para un flujo de registro, conteniendo asimismo la etiqueta de característica de medios un marcador para indicar a qué tramo de acceso transferir un tipo de medios y conteniendo el tipo de acceso información que indica una tecnología de red de acceso utilizada por la red sobre la que es enrutada la solicitud SIP REGISTER;

almacenar el identificador de la etiqueta de característica de medios obtenida en asociación con el tipo de acceso obtenido;

recibir (101; 801), desde el primer terminal (216), una solicitud para una transferencia de control de sesión de una sesión desde el primer terminal (216) al segundo terminal (218); y

en respuesta a recibir la solicitud desde el primer terminal (216) y determinar que la solicitud debe enrutarse a través de dicho tramo de acceso, enviar (102; 803), a través de una red de acceso seleccionada según la tecnología de red de acceso indicada por el tipo de acceso obtenido, una solicitud SIP al segundo terminal (218) para una transferencia de control de la sesión desde el primer terminal (216) al segundo terminal (218), incluyendo la solicitud SIP un campo de cabecera de aceptar-contacto que contiene una etiqueta de característica de medios con un valor establecido en el identificador de la etiqueta de característica de medios obtenida almacenada en asociación con el tipo de acceso obtenido.

2. El método según la reivindicación 1, en el que la solicitud SIP para la transferencia de control es un mensaje SIP REFER.

3. El método según la reivindicación 1, en el que la solicitud de transferencia de control de la sesión comprende una solicitud de transferencia de medios.

4. El método según la reivindicación 1, en el que el nodo de red (212) comprende un servidor de aplicaciones de coherencia y continuidad del servicio, SCC AS.

5. El método según la reivindicación 1, en el que la tecnología de red de acceso indicada es una tecnología de red de área local inalámbrica, WLAN.

6. El método según la reivindicación 1, en el que la tecnología de red de acceso indicada es una tecnología de red de acceso celular.

7. El método según la reivindicación 1, en el que la solicitud para la transferencia de control de la sesión comprende una solicitud para transferir al segundo terminal (218) uno de los componentes de medios de una pluralidad de componentes de medios de la sesión.

8. Un nodo de red (212, 2000), que comprende:

por lo menos un procesador (2010) configurado para llevar a cabo el método según cualquiera de las reivindicaciones 1 a 7.

9. Un medio legible por ordenador (2030) que almacena instrucciones que, tras su ejecución por un procesador (2010) de un nodo de red (2000), hacen que el nodo de red lleve a cabo el método según cualquiera de las reivindicaciones 1 a 7.