MX2008008901A - Sistema y metodo de seleccion de dominios que se pueden operar en un ambiente de red que incluye ims. - Google Patents

Abstract

En una modalidad, se describe un método de selección de dominios para su operación en un ambiente de red que incluye una red conmutada por circuitos (CS) y una red de subsistema de multimedia (IMS) de Protocolo de Internet (IP). En un nodo de red dispuesto en la red de IMS, se mantiene la información de estado relacionada con un dispositivo de quipo de usuario (UE) servido. La información de estado de preferencia se actualiza basándose en la información actualizada proporcionada por el dispositivo de UE. Una llamada entrante que dirige al dispositivo de UE se enruta a un dominio adecuado basándose en la información de estado, entre otros criterios.

Description

SISTEMA Y MÉTODO DE SELECCIÓN DE DOMINIOS QUE SE PUEDEN OPERAR EN UN AMBIENTE DE RED QUE INCLUYE IMS DESCRIPCIÓN DE LA INVENCIÓN La presente descripción de patente en general se refiere al enrutamiento de llamadas en redes de comunicación. En particular, y no a modo de limitación alguna, la presente descripción de patente se dirige a un sistema y método para selección de dominio que operan en un ambiente de red que incluye una red conmutada por circuitos (CS) y una red de subsistema de multimedia de IP (IMS), en donde se enrutará una llamada entrante a un dominio apropiado (por ejemplo dominio de CS o dominio de IMS) . La transferencia de voz sobre IP (VoIP) móvil es el proceso de dar continuidad a una llamada de voz a media que el usuario se mueve entre redes basadas en IP (por ejemplo, LAN inalámbrica (WLAN) o redes Wi-MAX, redes Conmutadas por Paquetes (PS) del Proyecto Conjunto de 3ra Generación (3GPP) , redes de Evolución a Largo Plazo (LTE) , etc.) y redes celulares conmutadas por circuitos. Para efectuar tal transferencia, los estándares actuales del Proyecto Conjunto de 3'' Generación (3GPP) especifican un elemento de función de control de continuidad de llamada (CCCF) que se dispone en una nueva arquitectura de red basada en IP referida como el subsistema de multimedia de IP (IMS) . Además, los estándares de 3GPP definen otra entidad, referida como una función de selección de dominio de red (NeDS), que interactúa con el elemento de CCCF para facilitar la selección de un dominio apropiado con respecto a las llamadas entrantes dirigidas a un dispositivo de equipo de usuario (UE) que cuenta con una capacidad de doble dominio (es decir, dominio de CS y dominio de IMS) . Sin embargo, se conoce que siguen existiendo varias lagunas en el desarrollo actual de funcionalidad de NeDS. BREVE DESCRIPCIÓN DE LOS DIBUJOS Se puede tener un entendimiento más completo de las modalidades de la presente descripción con la referencia a la siguiente descripción detallada cuando se analiza en relación con los dibujos anexos, en los cuales: la FIGURA 1 representa un ambiente de red que incluye una infraestructura de red conmutada por circuitos (CS) y una infraestructura de subsistema de multimedia de IP (IMS) en las que puede practicarse una modalidad de la presente descripción de patente; la FIGURA 2 representa una modalidad de un elemento de red que se opera para efectuar una selección de dominio para los propósitos de la presente descripción de patente; la FIGURA 3 representa un diagrama de flujo de una modalidad de la presente descripción de patente para enrutar una llamada entrante,- la FIGURA 4 representa un diagrama de flujo que se refiere a un modelo de interacción general entre un dispositivo de UE y un elemento de NeDS asociado de acuerdo con una modalidad; la FIGURA 5 representa un diagrama de bloques funcional que ilustra una pluralidad de interfaces proporcionadas con un elemento de NeDS de acuerdo con una modalidad; la FIGURA 6A representa una modalidad de un procesador de transición de estados con un elemento de NeDS que mantiene las transiciones de estados para un dispositivo de UE; la FIGURA 6B representa un esquema de política/preferencias para los propósitos de la presente descripción de patente; la FIGURA 7 representa un diagrama de flujo de mensajes para efectuar configuraciones de la política/preferencia en un elemento de NeDS de acuerdo con una modalidad de la presente descripción; la FIGURA 8 representa un diagrama de flujo de mensajes que se refiere al registro inicial con un elemento de NeDS en una modalidad; la FIGURA 9 representa un diagrama de flujo de mensajes que se refiere al registro inicial con un elemento de NeDS en otra modalidad; la FIGURA 10 representa un diagrama de flujo de mensajes que se refiere a la desactivación de activadores mediante un elemento de NeDS de acuerdo con una modalidad; la FIGURA 11 representa un diagrama de flujo de mensajes que se refiere a un proceso de registro generalizado con un elemento de NeDS en una modalidad; las FIGURAS 12 y 13 representan diagramas de flujo de mensajes que se refieren a un proceso de registro generalizado con un elemento de NeDS mediante el uso de mensajes de Datos de Servicio Suplementario no Estructurados (USSD) ; la FIGURA 14 representa un diagrama de flujo de mensajes que se refiere a la transmisión de mensajes entre un dispositivo de UE y un elemento de NeDS asociado con respecto al cambio de estado del dispositivo de UE en una modalidad; la FIGURA 15 representa un diagrama de flujo de mensajes que se refiere a la transmisión de mensajes entre un dispositivo de UE y un elemento de NeDS asociado con respecto al descubrimiento por parte del dispositivo de UE de un dominio conmutado por circuitos (CS); la FIGURA 16 representa un diagrama de flujo de mensajes que se refiere a la transmisión de mensajes entre un dispositivo de UE y un elemento de NeDS asociado con respecto al cambio de estado del dispositivo de UE en otra modalidad; la FIGURA 17 representa un diagrama de flujo de mensajes que se refiere a la transmisión de mensajes entre un dispositivo de UE y un elemento de NeDS asociado con respecto al cambio de estado del dispositivo de UE en aún una modalidad adicional; y la FIGURA 18 representa un diagrama de bloques de una modalidad de un dispositivo de comunicación que se opera para los propósitos de la presente descripción de patente. La presente descripción de patente en general se dirige a una arquitectura de selección de dominio para su operación en un ambiente de red que incluye una red de CS y una red de IMS. La información relacionada con un dispositivo de UE servido se mantiene en un nodo de red dispuesto en la red de IMS. La información de estatus de preferencia se actualiza con base en información de actualización proporcionada por el dispositivo de UE . Una llamada entrante o sesión que se dirige a un dispositivo de UE se enruta a un dominio apropiado con base en la información de estatus, entre otros criterios. Para los propósitos de la presente descripción y de las reivindicaciones establecidas más adelante, se entenderá que el término "llamada" abarca tanto "llamada" como "sesión". En un aspecto, se describe un nodo de red de IMS que representa un esquema de selección de dominio. La modalidad reclamada comprende: medios para mantener información de estatus relacionada con un dispositivo de UE que opera para recibir servicio del nodo de red; medios para actualizar la información de estatus con base en información de actualización recibida del dispositivo de UE; y medios para seleccionar un dominio apropiado con base en la información de estatus con respecto al enrutamiento de una llamada entrante dirigida al dispositivo de UE . En otro aspecto, en la presente se describe un dispositivo de UE que opera en un ambiente de red que incluye una red de CS y una red de IMS. La modalidad de UE reclamada comprende: medios para determinar que la información de estatus asociado con el dispositivo de UE ha cambiado; medios para proporcionar una actualización de cambio de información de estatus a un nodo de red dispuesto en la red de IMS; y medios para modificar por lo menos una parte de los criterios de política almacenados en el nodo de red con respecto al dispositivo de UE . En aún otro aspecto, en la presente se describe un método para selección de dominio que opera en un ambiente de red que incluye una red de CS y una red de IMS. La modalidad reclamada comprende: mantener información de estatus relacionada con un dispositivo de UE que opera para recibir servicio del nodo de red; actualizar la información de estatus con base en información de actualización recibida del dispositivo de UE; y seleccionar un dominio apropiado con base en la información de estatus con respecto al enrutamiento de una llamada entrante dirigida al dispositivo de UE.

A continuación se describirá un sistema y método de la presente descripción de patente con referencia a diversos ejemplos de cómo pueden realizarse y utilizarse mejor las modalidades. Se utilizan números de referencia similares a lo largo de la descripción así como varias vistas de los dibujos para indicar partes similares o correspondientes, en donde los diversos elementos no necesariamente se encuentran dibujados a escala. Con referencia ahora a los dibujos, y en particular a la FIGURA 1, se representa un ambiente 100 de red ejemplar en el que puede practicarse una modalidad de la presente descripción de patente para efectuar un enrutamiento de llamada con respecto a una llamada entrante a un dominio apropiado (por ejemplo, dominio de CS o dominio de IMS) . Como se representa, el ambiente 100 de red incluye un espacio 104 de acceso comprendido de un número de tecnologías de acceso disponibles para una pluralidad de dispositivos 102-1 a 102-N de UE . Para los propósitos de la presente descripción, un dispositivo de UE puede ser cualquier dispositivo de comunicación atado o sin atar y puede incluir cualquier computadora personal (por ejemplo, escritorios, computadoras portátiles, computadoras de bolsillo o dispositivos informáticos portátiles) equipada con un módem inalámbrico adecuado o un dispositivo de comunicación móvil (por ejemplo, teléfonos celulares o dispositivos portátiles habilitados con datos capaces de enviar y recibir mensajes, exploración de web, etcétera) o cualquier dispositivo PDA mejorado o aparato con información integrada capaz de enviar correos electrónicos, correos de video, acceso a Internet, acceso a datos empresariales, transmisión de mensajes, programación y planificación, gestión de la información y similares. De preferencia, el dispositivo de UE puede operar en múltiples modos en los que puede ajustarse tanto para comunicaciones conmutadas por circuitos (CS) como para conmutadas por paquetes (PS), y puede pasar de un modo de comunicación a otro modo de comunicación sin pérdida de continuidad. El espacio 104 de acceso puede comprenderse tanto de redes CS como PS, las cuales pueden implicar tecnologías inalámbricas, tecnologías de línea alámbrica, tecnologías de acceso de banda ancha, etc. Por ejemplo, el número de referencia 106 se refiere a tecnologías inalámbricas, tales como redes del Sistema Global para Comunicación Móvil (GSM) y redes de Acceso Múltiple por División de Códigos (CDMA) aunque se contempla que las enseñanzas de las mismas también pueden extenderse a cualquier red celular compatible con el Proyecto Conjunto de 3ra Generación (3GPP) (por ejemplo 3GPP o 3GPP2 ) . El número de referencia 108 se refiere a redes de acceso de banda ancha que incluyen redes inalámbricas de área local o WLA s , redes Wi-MAX, así como redes fijas tales como DSL, banda ancha por cable, etc. Asimismo, la infraestructura 110 de PSTN de línea alámbrica convencional se ejemplifica como parte del espacio 104 de acceso. Una red 112 central de subsistema de multimedia de IP (IMS) se acopla a las diversas redes de acceso establecidas en lo anterior, incluyendo cualquier red basada en CS. Como se conoce bien, el estándar de IMS que el 3GPP define está diseñado para permitir que los proveedores del servicio gestionen una variedad de servicios que pueden distribuirse mediante IP a través de cualquier tipo de red, en donde IP se utiliza para transportar tanto tráfico portador como tráfico de señalización basado en el Protocolo de Inicio de Sesión (SIP) . En general, IMS es una estructura para gestionar las aplicaciones (es decir, los servicios) y las redes (es decir, el acceso) que es capaz de proporcionar servicios de multimedia. IMS define un "servidor de aplicación" como el elemento de red que distribuye servicios para su uso por lo abonados, por ejemplo, continuidad de llamadas de voz (VCC), Pulsar para Hablar (PTT), etcétera. IMS gestiona las aplicaciones al definir componentes de control comunes requeridos para cada servidor de aplicación (AS), por ejemplo, perfiles de los abonados, movilidad de IMS, acceso de red, autenticación, autorización de servicio, cobro y facturación, funciones entre operadores e interacción con la red telefónica heredada. Debe entenderse que aunque el organismo de estándares de 3GPP define a IMS, el cual se dirige principalmente a redes de GSM, otro grupo, 3GPP2 , se encarga de definir una arquitectura muy análoga referida como Dominio de Multimedia (MMD) . MMD es esencialmente un IMS para redes de CDMA y, puesto que MMD e IMS son casi equivalentes, el término "IMS" puede utilizarse en esta presente descripción de patente para referirse, en forma conjunta, tanto a IMS como a MMD cuando sea pertinente. Continuando con la referencia a la FIGURA 1, los números de referencia 114-1 a 114-N se refieren a una pluralidad de nodos de AS que se operan para soportar diversos servicios de IMS, por ejemplo, VCC , PTT, etcétera, como se menciona en lo anterior. Además, para efectuar la continuidad de llamadas y la selección de dominio apropiado, se puede proporcionar otro nodo de red o AS 120 como parte de la red 112 central del IMS local de los abonados, el cual implementa la funcionalidad referida como función de control de continuidad de llamada (CCCF) 116 y la selección de dominio de red (NeDS) 118. En esencia, la parte 116 de CCCF del AS 120 se opera como un nuevo elemento del servidor de aplicación de IMS que reside en la red de IMS local y que rastrea todas las sesiones de llamada y tráfico portador de voz sobre IP móvil (VoIP) relacionado, incluyendo la transferencia/enrutamiento de llamadas entre dominios CS e IMS. Como se describirá en mayor detalle en lo siguiente, la parte 118 de NeDS del AS 116 es responsable de la realización, entre otras cosas, de la gestión de registro/cancelación de registro entre las redes de IMS y de CS (por ejemplo, GSM o CDMA) , así como de la selección de dominio para enrutar llamadas entrantes. Aunque son funciones potencialmente separadas, es posible integrar las funcionalidades tanto de CCCF como de NeDS en un solo elemento 120 de red compatible con IMS, como se ilustra en la FIGURA 1. Adicionalmente , se pueden proporcionar estructuras apropiadas de bases de datos (por ejemplo, DB 122) y mecanismos temporizadores (por ejemplo temporizador 124) junto con el AS 120 para los propósitos que se describirán en mayor detalle en lo siguiente con respecto a la funcionalidad de NeDS, los cuales pueden distribuirse (por ejemplo, entre dos o más componentes) o integrarse en un solo elemento de red. Debido al alto grado de flexibilidad durante su aplicación, aquellos con experiencia en la técnica deben reconocer que el término "elemento de NeDS" que se utiliza a continuación en general se considera un sinónimo de "nodo de red" que tiene la funcionalidad de selección de dominio, el cual, a su vez, puede comprender una sola plataforma o una serie de plataformas. Por ejemplo, el nodo de red puede incluir funcionalidades tales como Función de Transferencia de Dominio (DTF) (también referida como Entidad Funcional FE-A) , Función de Adaptación de CS (CSAF) (también referida como FE-B) , Servicio de CAMEL (también referido como FE-C) y Función de Selección de Dominio (DSF) (también referida como FE-D) , las cuales se han especificado en la documentación TS 23.206 de 3GPP. la FIGURA 2 representa una modalidad de un elemento 200 de red para los propósitos de la presente solicitud de patente. Aquellos con experiencia en la técnica deben reconocer que la modalidad 200 puede operar junto con un elemento de CCCF como se establece en lo anterior con referencia a la FIGURA 1 aunque esto no es requerimiento necesario. Además, como se establece en lo anterior, la funcionalidad del elemento/nodo de red puede distribuirse entre un número de diferentes funciones especificadas en TS 23.206. Como se ilustra en la presente, el elemento o nodo 200 de NeDS incluye una representación de una función 202 de enrutamiento de dominio que es responsable de la conclusión de una llamada entrante, dependiendo de si la llamada se origina en IMS, se origina en CS, estado del dispositivo de UE, etc., así como cualquier, política y preferencia válida basada en el usuario y en el operador. Por lo tanto, se proporciona una estructura o lógica 204 de software/ firmware apropiada como parte del elemento 200 de NeDS para conservar información concerniente al dominio o dominios en el que se encuentra el dispositivo de UE . Con respecto a cada dominio en el que se encuentra el dispositivo de UE, se proporciona uno o más procesadores de estado para monitorear la información de estatus del dispositivo de UE, la cual puede considerarse que comprende una pluralidad de "estados" que tienen transiciones bien definidas. De preferencia, las transiciones de estado pueden efectuarse con base en normas, políticas, preferencias, así como información actualizada proporcionada mediante el dispositivo de UE . Por consiguiente, los modelos de transición de estado se operan para proporcionar una representación precisa del dispositivo de UE a la función 202 de enrutamiento de dominio para facilitar la selección de dominio apropiado con respecto a una llamada entrante. A modo de ilustración, los números de referencia 206-1 a 206-N se refieren a una pluralidad de modelos o procesadores de transición de estado que mantiene el elemento 200 de NeDs , que pueden aplicarse, en forma selectiva, con base en la información de dominio del dispositivo de UE . De acuerdo con una modalidad de la presente descripción de patente, el nodo de red de IMS que tiene la capacidad 200 de NeDS puede proporcionarse con bases de datos 208 y 210 internas apropiadas para mantener, en forma local, diversas políticas y preferencias basadas en el usuario y/o el operador que pueden actualizarse en forma periódica o, de otro modo, a través de mecanismos válidos durante la comunicación. De manera alterna o adicional, una base de datos 212 externa puede interconectarse con el elemento 200 de NeDs , de tal manera que la función 202 de enrutamiento de dominio puede preguntar a la base de datos sobre normas, políticas y preferencias válidas basadas en determinaciones relacionadas con el dominio o dominios y estado o estados en el que se encuentra el dispositivo de UE . Por consiguiente, debe entenderse que la funcionalidad general de NeDS de preferencia puede incluir módulo o módulos de firmware/software/estructura lógica apropiada para la aplicación de uno o más filtros con respecto a la conclusión de una llamada, en donde los filtros se operan para realizar una serie de determinaciones con base en el dominio actual de un dispositivo de UE, estado del dispositivo, información de presencia, políticas o preferencias válidas u otros criterios (en forma conjunta, "información de estatus"). Por lo tanto, en un nivel más alto de abstracción, la lógica general de servicio se opera para realizar lo siguiente: (a) determinar si un servicio de IMS (por ejemplo, VCC) debe activarse; y (b) enrutar la llamada entrante hacia el dominio correcto. La primera parte de la funcionalidad puede modularse con base en si el dispositivo de UE es apto para el servicio de IMS; ubicación del dispositivo de UE; y si la o las redes del dispositivo de UE se encuentran registradas o conectadas. Asimismo, la segunda parte de la funcionalidad de NeDS puede modularse con base en los dominios con los que se encuentra registrado el UE; estado o estados en los que se encuentra el UE con respecto al o los dominios con lo que se encuentra registrado; preferencias basadas en el operador; y preferencias basadas en el usuario. En las siguientes secciones de la presente descripción se presentará una modalidad de la arquitectura general de NeDS que se diseña para ejecutar los diversos componentes de la funcionalidad de NeDS establecida en lo anterior. Con referencia ahora a la FIGURA 3, se representa en la misma un diagrama de flujo de una modalidad de la presente descripción de patente para enrutar una llamada entrante. Como se menciona en lo anterior, inicialmente se realiza una determinación en el nodo servidor de NeDS sobre si los servicios basados en IMS deben activarse y/o si el dispositivo de UE al que se dirige la llamada entrante es apto para servicios de IMS. Una vez que se hayan cumplido estas condiciones, se puede realizar una serie de determinaciones mediante la función de enrutamiento de dominio del elemento de NeDS para facilitar el enrutamiento de llamadas. Se puede realizar una determinación con respecto al o los dominios en los que se encuentra el dispositivo de UE (bloque 302). Otra determinación implica la identificación del o los estados en los que se encuentra el dispositivo de UE con respecto a sus dominios (bloque 304) . Aún otra determinación implica la aplicación de las políticas y preferencias del usuario/operador con respecto a la llamada entrante (bloque 306) . Después, el nodo de red de NeDS determina la llamada entrante para el dominio apropiado/ funcionalidad con base en las determinaciones anteriores (bloque 308). La FIGURA 4 representa un diagrama de flujo que se refiere a un modelo de interacción entre un dispositivo de UE y un elemento de NeDS asociado de acuerdo con una modalidad. Como se ilustra, el dispositivo de UE se opera para registrarse inicialmente con su nodo de red de NeDS mediante el uso ya sea de una señalización de CS o una señalización de IMS (bloque 402). El dispositivo de UE puede proporcionar, después, actualizaciones de su o sus estados, dominios y políticas/preferencias al nodo de NeDS en forma algo periódica, por ejemplo, con base en mecanismos temporizadores (bloque 404). De manera alterna o adicional, el nodo de NeDS puede suscribirse a un agente de presencia asociado con el dispositivo de UE a través de una interconexión adecuada basada en presencia, lo cual le permite recibir notificaciones sobre cualquier cambio en el o los estados, dominios y políticas/preferencias del dispositivo de UE (bloque 406). Con base en la información actualizada, el nodo de red de NeDS mantiene un espacio preciso de estado/dominio/político para el dispositivo de UE con el fin de efectuar la selección de dominio y la conclusión de llamada (bloque 408).

La FIGURA 5 representa un diagrama de bloques funcional que ilustra una pluralidad de interfaces proporcionadas con un elemento de NeDS, por ejemplo, NeDS 200, de acuerdo con una modalidad. Como se ilustra, la NeDS 200 de preferencia opera con una serie de entidades lógicas / funcionales a través de interfaces bien definidas que pueden ser referidas como puntos de referencia. Un punto de referencia "Pz" identifica la necesidad de una trayectoria de comunicación y, por lo tanto, algunas interfaces adecuadas entre la NeDS 200 y un agente 508 de red de presencia, lo cual permite que la NeDS 200 comunique los eventos de gestión de movilidad al agente de red de presencia. Con respecto al dominio basado en IP (es decir, dominio de PS), los eventos pueden comprender, pero no se limitan a: conectar, no accesible para notificación, desconectar, actualizar área de enrutamiento (RA) y similares. Asimismo, con respecto al dominio de CS, los eventos comprenden, pero no se limitan a: conectar, desconectar, actualizar área de ubicación (LA), etcétera. En una variación adicional, el punto de referencia Pz puede permitir que la NeDS 200 comunique eventos relacionados con las llamadas, tales como establecimiento de llamada con información de portador y liberación de la llamada. Adicionalmente , el punto de referencia Pz también puede permitir que la NeDS 200 comunique estados de movilidad, por ejemplo, desconectada, en espera, conectada, etc . , así como estados de sesión tales como contextos de PDP activos o inactivos. En términos de implantación, una modalidad ejemplar del punto de referencia Pz puede implicar una interfaz compatible con la transmisión de mensajes de Aplicaciones Personalizadas para Lógica Móvil Mejorada (CAMEL) basadas en 3GPP. Un punto de referencia "Pw" identifica la necesidad de una trayectoria de comunicación y, por lo tanto, algunas interfaces adecuadas entre la NeDS 200 y un dispositivo proxy 502 de presencia de entidad presentadora de datos, por ejemplo, como se define en TS 23.141 de 3GPP . El dispositivo proxy 502 de presencia de entidad presentadora de datos se opera como una entidad funcional que proporciona una funcionalidad relacionada con la entidad presentadora de datos, tal como la determinación del servidor de presencia asociado con una entidad presentadora de datos. Una base de datos 504 de punto activo de red de acceso inalámbrica (por ejemplo, puntos activos para redes LANs , Wi-MAX, etcétera) puede interconectarse con la NeDS 200 a través de un punto de referencia "z" que permite que la funcionalidad de enrutamiento de dominio de NeDS determine si un servicio de IMS (por ejemplo VCC) puede y/o debe realizarse en la red de acceso inalámbrica con la cual se encuentra registrada actualmente el UE . Tal determinación puede efectuarse al determinar la ubicación del UE con base en información del Sistema de Posición Global (GPS), información de identificación Global Celular o algún otro punto de referencia de entrada del usuario, tal como código de aeropuerto, nombre de una ciudad, acontecimiento, etc. Una función 506 de política se interconecta con la NeDS 200 a través de un punto de referencia "j" que permite que la NeDS 200 obtenga información sobre la política/preferencias del operador para el enrutamiento de una llamada. Con respecto a las politicas /preferencias del usuario, éstas pueden almacenarse en otro elemento de red denominado servidor local de abonado (HSS), por ejemplo HSS 512, que se interconecta con la NeDS 200 a través de un punto de referencia "y". Si la información de política del usuario no se almacena en el HSS 512, la funcionalidad de NeDS puede utilizar el punto de referencia j para obtener información apropiada sobre la política del usuario de una base de datos externa. Continuando con la referencia a la FIGURA 5, -la interfaz entre la NeDS 200 y el dispositivo 510 de UE se define mediante un punto de referencia "k" , en el cual el dispositivo de UE puede incluir un agente 514 de usuario de presencia con el que puede suscribirse la NeDS para recibir notificaciones de estatus basadas en presencia. Esta interfaz permite que la NeDS conozca el estado del dispositivo de UE en cada dominio (por ejemplo, conectado, desconectado, etc.); estado de cualquier conexión (por ejemplo, PDP activado, llamada en progreso, cuándo se establece la llamada, cuándo se termina la llamada, etc.); e información de ubicación con respecto al dispositivo de UE . Adicionalmente , esta interfaz también permite que los usuarios activen, desactiven, pregunten y/o notifiquen sus configuraciones de servicio de IMS en el nodo de NeDS . Como se mencionó en lo anterior, el HSS 512 puede interconectarse con la NeDS 200 a través de la referencia y, lo cual permite que la NeDS: (i) active un servicio de IMS (por ejemplo, VCC) al encender activadores apropiados de CAMEL; (ii) desactivar un servicio de IMS al apagar los activadores de CAMEL; y (iii) obtener información sobre la política de usuario para el enrutamiento de una llamada . La FIGURA 6A representa una modalidad de un procesador 600 de transición de estados proporcionado con un nodo de red, por ejemplo, NeDS 200, que mantiene transiciones de estados apropiadas para un dispositivo de UE . Esencialmente, los diversos estados ilustrados en el la FIGURA 6A definen una pluralidad de condiciones de estatus en las que se puede encontrar el dispositivo de UE y transiciones permitidas entre las mismas. A partir de un estado 602 nulo inicial, el dispositivo de UE puede pasar al estado 618, el cual define que el UE se conecta al dominio de CS y puede originar y concluir llamadas. El estado 616 define que el dispositivo de UE continúa conectado al dominio de CS y se encuentra activo en una llamada. El estado 612 define que el dispositivo de UE se conecta al dominio de CS y se registra en el dominio de IMS a través de, por ejemplo, una WLA , Wi-MAX, LTE, etc. Además, el dispositivo de UE se encuentra activo en una llamada en el dominio de CS y sólo puede originar y concluir llamadas en este dominio. El estado 606 define que el dispositivo de UE se conecta al dominio de CS y se registra en el dominio de IMS. El dispositivo de UE se encuentra activo en una llamada en el dominio de IMS y sólo puede originar y concluir llamadas en el dominio de IMS. Al igual que en el estado 618, el estado 608 define que el dispositivo de UE se registra en el dominio de IMS a través de, por ejemplo, una, WLAN, Wi-MAX, LTE, etc., y puede originar y concluir llamadas. El estado 610 define que el dispositivo de UE se registra en el dominio de IMS a través de, por ejemplo, una WLAN, y se encuentra activo en una llamada. El estado 604 define que el dispositivo de UE se conecta al dominio de CS y también se registra en el dominio de IMS, pero se encuentra inactivo en ambos dominios. El estado 614 define que el dispositivo de UE se conecta al dominio de CS y se registra en el dominio de IMS, y se encuentra activo en ambos dominios. Esta transición de estado existe cuando un servicio de IMS entre dominios, por ejemplo, VCC, se está realizando en realidad y puede estar presente durante un tiempo limitado.

Aunque la FIGURA 6A no ilustra en forma explícita ningún sub-estado, se contempla que ciertos estados basados en IMS puedan tener uno o más sub-estados, dependiendo de la implantación actual. En una modalidad ejemplar, los sub-estados pueden conocerse a partir del dispositivo de UE en sí. Por ejemplo, puede existir un sub-estado que define que el dispositivo de UE se asocia con, por ejemplo, una red WLAN, Wi-MAX o LTE, pero que aún no tiene una dirección de IP local. Una vez que se asigna una dirección de IP local al dispositivo de UE, éste puede pasar a otro sub-estado que define esta condición aunque el dispositivo aún no se -haya registrado con la red de IMS. Tal estado puede existir cuado se requiera algún tipo de autorización del dispositivo de UE antes de que éste pueda utilizar la WLAN para llegar a la red central de IMS. Aquellos con experiencia en la técnica deben reconocer que aunque se hace referencia con respecto a una WLAN en el procesador/modelo 600 de transición de estados de la FIGURA 6A, también pueden incluirse transiciones de estado con respecto a otras redes inalámbricas basadas en IP. Por consiguiente, el término "estados de IMS" puede comprender estados con respecto a ambas WLA s , así como otras redes de acceso inalámbricas basadas en IP para los propósitos de la presente descripción de patente. Como se señaló en lo anterior, se pueden proporcionar diversas políticas/preferencias, por ejemplo, políticas y preferencias basadas en el operador, políticas y preferencias basadas en el usuario y cualquier combinación de las mismas (en forma conjunta, "criterios de política") para modular el proceso de selección de dominio de la funcionalidad de NeDS, de acuerdo con las modalidades establecidas en la presente. La FIGURA 6B ilustra un esquema 650 de política que puede representarse como una estructura de base de datos, ya sea basada en red o basada en dispositivo, para los propósitos de la presente descripción, en donde el número de referencia 652 se refiere a espacio de política total válido con respecto a un UE . Las políticas 654 ejemplares basadas en el operador pueden agruparse en dos categorías: (i) políticas que afectan la distribución 656 de llamadas en IMS (es decir, conclusión de una llamada entrante, originada en el dominio de IMS); y (ii) políticas que afectan la distribución 658 de llamadas en CS (es decir, conclusión de una llamada entrante, originada en el dominio de CS) . Asimismo, las políticas 660 basadas en usuario también pueden clasificarse, de manera similar, en políticas 662 de distribución de llamadas en IMS y políticas 664 de distribución de llamadas en CS. Las políticas 656 de distribución de llamadas en IMS basadas en el operador pueden comprender los siguientes ejemplos: Cuando el dispositivo de UE se registra en CS, las llamadas/sesiones de IMS se distribuyen hacia el lado de CS, aun si el dispositivo se encuentra registrado en IMS. Cuando el dispositivo de UE se registra en CS, las llamadas/sesiones de IMS se distribuyen hacia el lado de IMS, aun si el dispositivo se encuentra registrado en CS, independientemente de cualquier consideración de Calidad del Servicio (QoS) . Cuando el dispositivo de UE se registra en CS, las llamadas/sesiones de IMS se distribuyen hacia el lado de IMS, para una QoS mínima dada, aun si el dispositivo se encuentra registrado en CS. - Cuando el dispositivo de UE se registra en CS, las llamadas / sesiones de IMS no se distribuyen hacia el lado de CS cuando IMS no se encuentra disponible. - No se especifica ninguna política. Asimismo, las políticas 658 de distribución de llamadas en CS basadas en el operador pueden comprender los siguientes ejemplos: - Cuando el dispositivo de UE se registra en IMS, las llamadas/sesiones de CS se distribuyen hacia el lado de IMS, aun si el dispositivo se encuentra registrado en CS . - Cuando el dispositivo de UE se registra en IMS, las llamadas/sesiones de CS se distribuyen hacia el lado de IMS, para una QoS mínima dada, aun si el dispositivo se encuentra registrado en CS . - Cuando el dispositivo de UE se registra en IMS, las llamadas/sesiones de CS se distribuyen hacia el lado de CS, aun si el dispositivo se encuentra registrado en IMS. - Cuando el dispositivo de UE se registra en CS, las llamadas/sesiones de CS no se distribuyen hacia el lado de IMS cuando CS no se encuentra disponible. - No se especifica ninguna política. De manera similar, las políticas 662 de distribución de llamadas en IMS basadas en el usuario pueden comprender los siguientes ejemplos: - Cuando el dispositivo de UE se registra en CS, las llamadas/sesiones de IMS se distribuyen hacia el lado de CS, aun si el dispositivo se encuentra registrado en IMS. - Cuando el dispositivo de UE se registra en CS, las llamadas/sesiones de IMS se distribuyen hacia el lado de IMS, aun si el dispositivo sé encuentra registrado en CS, independientemente de cualquier consideración de Calidad del Servicio (QoS) . - Cuando el dispositivo de UE se registra en CS, las llamadas/sesiones de IMS se distribuyen hacia el lado de IMS, para una QoS mínima dada, aun si el dispositivo se encuentra registrado en CS . - Cuando el dispositivo de UE se registra en CS, las llamadas / sesiones de IMS no se distribuyen hacia el lado de CS cuando IMS no se encuentra disponible. - No se especifica ninguna política. Adicionalmente , las políticas 664 de distribución de llamadas en CS basadas en el usuario pueden comprender los siguientes ejemplos: - Cuando el dispositivo de UE se registra en IMS, las llamadas/sesiones de CS se distribuyen hacia el lado de IMS, aun si el dispositivo se encuentra registrado en CS . - Cuando el dispositivo de UE se registra en IMS, las llamadas/sesiones de CS se distribuyen hacia el lado de IMS, para una QoS mínima dada, aun si el dispositivo se encuentra registrado en CS. - Cuando el dispositivo de UE se registra en IMS, las llamadas/sesiones de CS se distribuyen hacia el lado de CS, aun si el dispositivo se encuentra registrado en IMS. - Cuando el dispositivo de UE se registra en CS, las llamadas / sesiones de CS no se distribuyen hacia el lado de IMS cuando CS no se encuentra disponible. - No se especifica ninguna política. Además, se pueden implantar políticas o reglas 666 de enrutamiento adicionales con base en datos de identidad de línea de llamada (CLI), en donde se pueden definir uno o más márgenes de números de la parte que llama de E.164 para un tratamiento de enrutamiento particular. Un margen puede comprender una lista de cualquier tamaño arbitrario, I, en donde I = 1, 2, N. Para cada margen definido, las políticas ejemplares pueden incluir si la llamada entrante se va a distribuir hacia: (i) el lado de IMS solamente; (ii) el lado de CS solamente; (iii) concluir primero para el lado de IMS y, si no se tiene éxito, concluir entonces para el lado de CS; (iv) concluir primero para el lado de CS y, si no se tiene éxito, concluir entonces para el lado de IMS; (v) sin tratamiento preferencial ; etcétera. El esquema 650 de política/preferencia ejemplares también puede incluir un mecanismo 668 para resolución de conflictos en el que se aplican normas o prioridades apropiadas en caso de un posible conflicto. Entre las políticas basadas en el usuario y las políticas basadas en el operador se pueden implantar las siguientes opciones: (i) la política de usuario siempre tiene preferencia, (ii) la política del operador siempre tiene preferencia; (iii) cuando no exista ninguna política del usuario, se utilizará la política del operador; y (iv) cuando no exista ninguna política del operador, se utilizará la política del usuario. Además, se puede proporcionar una norma para que las políticas 666 de enrutamiento basadas en CLI tengan preferencia sobre las políticas de distribución de llamadas en IMS y en CS, independientemente de si éstas se basan en el usuario o se basan en el operador. Como se describe en lo anterior, las diversas políticas y preferencias 652 pueden almacenarse en forma local en el elemento de NeDS o pueden proporcionarse en una base de datos externa que tenga acceso al elemento de NeDS a través de una interconexión apropiada. Adicionalmente , las políticas y preferencias del usuario, así como otra información relacionada, pueden almacenarse en un módulo removible, tal como una Tarjeta Universal de Circuito Integrado (UICC) , Módulo Universal de Identidad del Abonado (USIM) , Módulo Removible de Identidad del Usuario (RUIM) , Flash Compacta, tarjeta de memoria Digital Segura (SD), etc., que pueda proporcionarse como parte del dispositivo de UE . Además, un abonado puede operar el dispositivo de UE para efectuar configuraciones apropiadas de las políticas del usuario en el elemento de NeDS mediante el uso de mensajes válidos basados en IMS o basados en CS. La FIGURA 7 representa un diagrama de flujo de mensajes para efectuar configuraciones de la política/preferencia en un elemento de NeDS, por ejemplo, NeDS 200, de acuerdo con una modalidad de la presente descripción. Como se observará en lo siguiente, aunque los diagramas de flujo de mensajes de la presente descripción pueden ilustrarse con elementos conocidos, tales como centrales de conmutación móviles (MSC), Registros de localización de visitantes (VRL) y servidores locales del abonado (HSS), éstos pueden generalizarse como nodos de red que tienen funcionalidades específicas tales como, por ejemplo, una entidad de MSC/VLR que puede realizar control de llamadas, control de servicios y conmutación de medios. Por consiguiente, debe ser aparente que, independientemente de las aplicaciones particulares establecidas en la presente, las funcionalidades ejemplares también pueden efectuarse mediante plataformas separadas. Como se ilustra en la FIGURA 7, el dispositivo 510 de UE puede generar un mensaje 704 de USSD en el dominio de CS para activar, preguntar, desactivar o modificar las políticas y preferencias del usuario en la NeDS 200. Típicamente, el flujo de mensajes puede transmitirse a través de elementos de red, tal como una central de conmutación móvil (MSC) y registro de localización de visitantes (VLR) asociado, referidos en forma colectiva como nodo 702, dispuestos entre el dispositivo de UE y su nodo 200 de NeDS de IMS local. Un mensaje 706 de USSD de respuesta se propaga a través de la MSC/VLR de NeDS 200 al dispositivo 510 de UE con información apropiada cuando se solicite . De manera alterna, el flujo de mensajes para efectuar las configuraciones de la política/preferencia del usuario en la NeDS 200 puede implementarse en el dominio de IMS mediante el uso de otros protocolos de transmisión de mensajes, tales como mensajes de Protocolo de Acceso a la Configuración (XCAP) de Lenguaje de Marcación Ampliable (XML) o mensajes de edición de SIP. Independientemente de si se utilizan mensajes basados en IMS o basados en CS, el dispositivo 510 de UE se opera para incluir uno o más de los siguientes elementos de información: identidad del Abonado (por ejemplo, Identidad Privada del Usuario, tal como Identidad Internacional de Abonado Móvil o IMSI, Número de Identificación Móvil o MIN, Identificador de Acceso a la Red o NAI , etc.); identidad de equipo o Identificador de Caso (por ejemplo, Identidad Internacional de Equipo Móvil o IMEI o IMEISV; Número de Serie Electrónico o ESN, número de identificación personal o PIN, dirección de control de acceso a medios o MAC, etc.); URI o GRUU de Agente de Usuario Globalmente Enrutable, los cuales pueden ser una combinación de IMSI e IMEI; información de política; y la o las acciones que se llevarán a cabo (por ejemplo, activar, desactivar, modificar, preguntar y similares). Por ejemplo, el usuario puede activar un servicio de IMS (por ejemplo, VCC) y, después, se puede establecer un número de políticas del usuario con respecto a las llamadas de IMS y/o llamadas de CS, tales como las que se describen en lo anterior. Asimismo, el usuario también puede desactivar un servicio de IMS a través de mensajes apropiados en el dominio de CS o de IMS. Cuando se interroga por el usuario, el mensaje de respuesta de la NeDS 200 puede indicar que el servicio de IMS interrogado se desactiva o, si se encuentra activo, se pueden incluir políticas/preferencias válidas. Mediante el uso de la opción de modificar, el usuario puede ser capaz de alterar una o más políticas y preferencias válidas del usuario con respecto al servicio de IMS incluido en la consulta. A modo de ejemplo, a continuación se establece una tabla con mensajes de XML para efectuar políticas/preferencias en el nodo de red de la NeDS .

Tabla I <?xml vers¡on=" 1.0" encoding="UTF-8" standalone="no"?> <!--W3C Schema generated by XMLSpy v2006 sp2 U (http://www.altova.com)--> <!-Please add namespace attributes, a targetNamespace attribute and import elements according to your requirements--> <xs:schema xmlns:xs="http://www. w3.org/2001/XMLSchema" elementFormDefault="qualified"> <xs:import namespace="http://www.w3.org/XML/1998/namespace"/> <xs:element name="vccmessage"> <xs:complexType> <xs:sequence> <xs:element ref="operation"/> </xs:sequence> <xs:artribute name="subscriberID" use="required" type="xs:string"/> <xs:attribute name="terminalID" use="required" type="xs:string"/> </xs:complexType> </xs:clement> <xs:element name="operation"> <xs:complexType> <xs:sequence> <xs:element ref="delivery" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="action" default="activate"> <xs:simpleType> <xs:restriction base="xs:NMTO EN"> <xs:enumeration value="deactivate"/> <xs:enumeration value="modify"/> <xs:enumeration value="activate'7> <xs:enumeration value="interrogate"/> </xs:restriction> </xs:simpleType> </xs:attribute> </xs :complexType> </xs:element> <xs:element name="delivery"> <xs:complexType> <xs:sequence> <xs:element ref="policy" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="type" default="none"> <xs:simpleType> <xs:restriction base="xs:NMTO EN"> <xs:enumeration value="all"/> <xs:enumeration value="none"/> <xs:enumeration value="IMS"/> <xs:enumeration value="CS"/> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:complexType> </xs:element> <xs:element name="policy"> <xs : complexType> <xs:complexContent> <xs:restriction base="xs:anyType"> <xs:attribute name="name" default <xs:simpleType> <xs:restriction base="xs: TOKEN"> <xs:enumeration value="none'7> <xs:enumeration value="P0 > <xs:enumeration value="Pl "/> <xs:enumeration value="P2 > <xs:enumeration value="P37> </xs:restriction> </xs:simpleType> </xs:attribute> < xs:restriction> </xs :complexContent> < xs:complexType> </xs:element> </xs:schema> A continuación se proporciona otro ejemplo de activación de política en XML se proporciona en la Tabla II. Tabla II <?xml version=" 1.0" encoding="UTF-8" ?> . <!- sample VCC message for subscriberlD 00001234 and terminalID 1 A2B3C4D — > . <» ._ operation: Actívate — > delivery type: CS — > policy: When CS registered IMS calis are delivered to IMS side even if CS registered. — > delivery type: IMS — > policy: When IMS registered CS calis are delivered to IMS side even if CS registered irrespective of any QoS. — > <vccmessage xmlns:xsi="http://www.w3.org/2001/XMLSchemá-instance" xsi :noNamespaceSchemaLocation="vccmessage.xsd" subscriberID="00001234" terminalID=" 1 A2B3C4D"> <operation action="activate"> <delivery type="CS"> ^policy name="P2" /> </delivery> «ielivery type="IMS"> policy name= O" /> </delivery> </opcration> </vccmessage> policy codes: —> PO - Cuando las llamadas del Dominio B registradas en el Dominio A se distribuyen al Dominio A aun si el Dominio B se registró independientemente de cualquier QoS: - <!- - Pl - Cuando las llamadas del Dominio B registradas en el Dominio A se distribuyen hacia el lado del Dominio A aun si el Dominio B se registró para una QoS mínima dada --> - < ! - - P2 - Cuando las llamadas del Dominio B registradas en el Dominio A se distribuyen hacia el lado del Dominio B aun si se registró el Dominio A - -> - <!- - P3 - Cuando las llamadas del Dominio B registradas en el Dominio A se distribuyen hacia el lado del Dominio A cuando el Dominio B no se encuentra disponible - -> _ < I _ _ Nota: El Dominio se define mediante el atributo de tipo del elemento de distribución. Los Dominios A y B mutuamente exclusivos, es decir, si A=IMS entonces B=CS y viceversa Se pueden utilizar diversas estructuras de codificación ej emplares en el fluj o de mensa] es establecido en lo anterior para efectuar las configuraciones de la política/preferencia del usuario en la NeDS 200. A modo de aplicación ejemplar, debe apreciarse que se puede utilizar la codificación binaria tanto de 8 bits como de 4 bits en una sintaxis basada en XML , cuya estructura general se ilustra a continuación: Operación a Realizar Duración Opción de Distribución (Ninguna, CS, IMS) Duración Política (1 a N) Opción de Distribución (Ninguna, CS, IMS) Duración Política (1 a N) Las siguientes tablas ilustran estructuras de codificación binaria de 8 bits con respecto a las operaciones y opciones de distribución: Tabla III Tabla V La FIGURA 8 representa un diagrama de flujo de mensajes que se refiere al registro inicial con un nodo de red en una modalidad. Como se ilustra, cuando el dispositivo 510 de UE se conecta a una red que utiliza señalización de CS, el HSS 512 se opera para informar al nodo 200 de red servidor acerca del estatus de conexión del dispositivo de UE . El número de referencia 802 se refiere a los mensajes válidos de procedimiento de conexión entre el UE 510 y MSC/VLR 702. Asimismo, el número de referencia 804 se refiere a los mensajes de procedimiento de conexión entre MSC/VLR 702 y el HSS 512. Como se menciona en lo anterior, el MSC/VLR es esencialmente un nodo de red responsable del control de sesión y/o medios de conmutación, tal como la voz. El HSS 512 es esencialmente una función de la base de datos que contiene, pero no se limita a, información acerca de los servicios a los que un abonado se ha suscrito, configuración de usuario de los servicios suscritos, políticas del usuario, políticas del operador y cómo se supone que se comportan los diversos elementos de red cuando se aplican las políticas o combinaciones de políticas. Después del procedimiento 804 de conexión, el HSS 512 genera un mensaje 806 de notificación para la NeDS 200 para informar el estatus de conexión del UE . Con la recepción de la notificación 806, se puede iniciar un temporizador (bloque 808) que se mantiene hasta que se recibe un mensaje de registro de parte del dispositivo 510 de UE . Con la recepción del mensaje 812 de registro en la NeDS 200, se detiene el temporizador (bloque 814), indicando que el dispositivo de UE es apto para servicios de IMS. También puede iniciarse un mecanismo temporizador (bloque 810) en el dispositivo de UE cuando se genera el mensaje 812 de registro para que pueda asegurarse la validez de un mensaje 816 de respuesta de registro de la NeDS 200. Con la recepción del mensaje 816 de respuesta, el temporizador del UE puede detenerse (bloque 818) . La FIGURA 9 representa un diagrama de flujo de mensajes que se refiere al registro inicial con un nodo de red en otra modalidad en la que se utiliza la señalización de IMS (por ejemplo, a través de una red basada en IP, tal como una red GPRS, red LTE, Wi-MAX o una WLAN) . Después del procedimiento 908 de conexión del dispositivo de UE con la MSC 702 mediante el uso de señalización de CS se llevan a cabo los procedimientos apropiados de Actualización de Localización (LU) y Datos de Inserción del Abonado (ISD) entre el HSS 512 y la MSC 702. Adicionalmente , después del procedimiento 912 de conexión del dispositivo de UE con una red basada en IP, por ejemplo, GPRS, un Nodo de Soporte Servidor de GRPS (SGSN) 902 se opera para realizar procedimientos 914 válidos de LU y/o ISD con el HSS 512. En respuesta, se genera un mensaje 916 de notificación para informar a la NeDS 200 acerca del estatus de conexión con respecto al dispositivo 510 de UE, con lo cual se puede iniciar un mecanismo temporizador (bloque 918) . Después de crear un contexto de PDP (número de referencia 920) con un Nodo de Soporte Pasarela de GPRS (GGSN) 904, el UE 510 se registra con una Función Servidora de Control de Sesión de Llamada (S-CSCF) 906 a través de un mensaje 922 de registro. En respuesta, la S-CSCF 906 realiza un procedimiento 924 de registro de una 3ra parte con la NeDS 200, con lo cual se puede detener el mecanismo temporizador (bloque 926) . Como una aplicación adicional, después de que se ha llevado a cabo el registro con la red de IMS, el nodo 200 de la NeDS puede enviar una solicitud 928 de Opciones de SIP al dispositivo 510 de UE solicitando sus capacidades (por ejemplo, capacidades de servicio de IMS, en particular) . En respuesta, el UE 510 genera un mensaje 930 CORRECTO de SIP, el cual puede incluir indicaciones apropiadas con respecto a las capacidades solicitadas. Después, el dispositivo 510 de UE puede proporcionar un Mensaje de Edición de SIP o mensaje 932 de XCAP a la NeDS 200, el cual contiene información de configuración apropiada (por ejemplo, información de política, actualizaciones, acciones que se llevarán a cabo, etcétera) . En otra aplicación, el nodo de IMS que tiene la funcionalidad de CCCF/NeDS se opera para informar al HSS que desactive los activadores de CAMEL . La FIGURA 10 representa un diagrama de flujo de mensajes que se refiere a la desactivación de activadores mediante un elemento de NeDS de acuerdo con una modalidad. Como en lo anterior, el dispositivo 510 de UE se conecta con la MSC/VLR 702 mediante el uso del o los procedimientos 802 de conexión válidos. Se puede iniciar un mecanismo temporizador en el dispositivo 510 de UE cuando se genere el mensaje 812 que se propaga a través de la infraestructura de MSC/VLR hacia la NeDS 200. Con la recepción del mensaje 812, se puede iniciar un mecanismo temporizador (bloque 1002) en el nodo 200 de la NeDS. Asimismo, la NeDS 200 genera un mensaje 1004 de desactivación para el HSS 512 que indica que los activadores de CAMEL relacionados con uno o más servicios de IMS seleccionados (por ejemplo, VCC) se encuentran desactivados. En respuesta, el HSS 512 proporciona un mensaje 1006 de notificación a la NeDS 200, con lo cual se detiene el mecanismo temporizador (bloque 1008) . Mensajes 1010 de respuesta apropiados se propagan nuevamente de la NeDS 200 hacia el dispositivo 510 de UE. Puesto que se requiere que el dispositivo de UE y su información se registre al final con la funcionalidad de la NeDS, la CCCF puede implicarse en la comunicación de información necesaria a la NeDS asociada con la misma, particularmente en los casos en los que el dispositivo de UE se opera para registrarse con el nodo de CCCF solamente. Como se describe en lo anterior, el registro con la NeDS puede efectuarse a través del dominio de IMS o a través del dominio de CS. Asimismo, los procesos de registro válidos de preferencia se llevan a cabo después de que el dispositivo de UE se conecta ya sea a una red de CS o a una red de PS . A modo de aplicación ejemplar, puede especificarse que el registro de la NeDS se lleva a cabo primero a través de señalización de IMS. Sin embargo, si la señalización de IMS no se encuentra disponible (por ejemplo, debido a que no existe ninguna cobertura de GPRS o de WLAN) , el registro puede proceder mediante el uso de señalización de CS, como se describe en lo anterior. La FIGURA 11 representa un diagrama de flujo de mensajes que se refiere a un proceso de registro generalizado con un nodo de red en una modalidad, sin implicar un nodo de HSS. Después de conectarse con una red de CS a través de procedimientos 802 de conexión válidos, el UE 510 se opera para generar un mensaje 1102 de registro que se propaga a través de una infraestructura 702 de MSC/VLR hacia la NeDS 200. El mensaje 1102 de registro puede aplicarse mediante el uso de, pero no limitado a, mensajes de USSD (descritos en mayor detalle en lo siguiente) o mensajes de Servicio de Mensaje Corto (SMS) . La NeDS proporciona los mensajes 1104 de respuesta válidos al UE 510. A modo de aplicación ejemplar, el mensaje 1102 de registro efectuado en el dominio de CS puede contener uno o más de los siguientes elementos de información: GRUU; GRUU soportado; identidad del abonado (por ejemplo, IMSI); identidad de equipo o Identi ficador de Caso (por ejemplo, IMEI/IMEISV, PIN, ESN, etc.); localización del abonado (por ejemplo, información de GPS, información de CGI relacionada con las redes registradas, puntos de referencia de entradas del usuario, tales como código de aeropuerto, ciudad, punto de interés o datos de acontecimientos, código postal y similares); información de ID de red relacionada con las redes disponibles (por ejemplo, información de CGI relacionada con redes celulares de área ancha, información de Identificador de Aparato de Servicio (SSID) relacionada con WLANs , redes Wi-MAX, etc.); información de temporizador de actualización de localización; estatus de conexión de PS (es decir, conectado o desconectado); información de temporizador de actualización de enrutamiento ; estatus de contexto de PDP (es decir, conectado o desconectado) ; estatus de red de IP, por ejemplo, estatus de WLAN (asociada, asignada a dirección de IP local, contactada con PDF, etc.); y politicas /preferencias del abonado. Como se explica en lo anterior, GRUU puede comprenderse de una combinación de IMSI e IMEI y se opera para indicar un ID de caso único (por ejemplo IMEI) y la Dirección de Registro (por ejemplo, SIP URI ) . Los datos de localización pueden utilizarse para determinar si un servicio de IMS (por ejemplo VCC) debe ejecutarse o desactivarse (por ejemplo, en un país o región en la que VCC no esté soportada) . Adicionalmente , los datos de localización también pueden utilizarse para determinar si el dispositivo de UE se encuentra registrado actualmente en una red compatible con el servicio de IMS. La información de ID de red puede utilizarse para soportar la capacidad de redirección. En otras palabras, el dispositivo de UE puede redirigirse a una red o WLA celular diferente mediante el nodo de red de IMS con base en las redes disponibles y sus capacidades, así como cualquier requerimiento de servicio especificado por el dispositivo de UE . La funcionalidad de NeDS puede utilizar la información de temporizador de actualización de localización para coordinar la actualización de la información entre el dispositivo de UE y la NeDS. La funcionalidad de NeDS puede utilizar la información de temporizador de actualización de enrutamiento para determinar qué tan frecuente se registrará en forma periódica con la red de PS con el fin de verificar si el temporizador de actualización de enrutamiento se ha reiniciado o no. El comportamiento del dispositivo 510 de UE con respecto al registro a través de la señalización de CS puede resumirse como sigue. Después de enviar el mensaje de registro, el dispositivo de UE puede iniciar un temporizador (ya sea con codificación personal o configurarse en el UE (por ejemplo, ya sea en un módulo removible, tales como los que se describen en lo anterior o una memoria integrada en el UE, cualquiera de los cuales puede configurarse durante la comunicación) para establecer una ventana de tiempo dentro de la cual pueda esperarse una respuesta por parte de la función de NeDS . Si no se recibe ninguna respuesta, el dispositivo de UE puede configurarse par intentar el proceso de registro un número de veces seleccionado (por ejemplo, cinco intentos), después de los cuales puede considerarse que la trayectoria de comunicación ha fallado y/o el servicio de IMS no se encuentra disponible. Si el mensaje de respuesta se recibe en la ventana de tiempo o con una entrada válida, el dispositivo de UE se opera para detener el mecanismo temporizador . Si el mensaje de respuesta incluye una indicación de que la VCC no debe realizarse, el dispositivo de UE no puede realizar ninguna transferencia de IMS a CS y viceversa. Como resultado, el dispositivo de UE no puede realizar ninguna señalización para la VCC. Si el dispositivo de UE recibe un GRUU a través del mensaje de respuesta, el GRUU recibido puede almacenarse en forma local ya sea en la memoria del UE o en el módulo removible acoplado al mismo. De manera opcional, se puede proporcionar un temporizador de actualización de NeDS en el mensaje de respuesta al dispositivo de UE, el cual también puede almacenarse en forma local, de preferencia que informe sobre cualquier valor de falla. En una variación adicional, el dispositivo de UE puede recibir uno o más códigos PLMN para las redes en las cuales no se encuentra registrado actualmente. Si se incluyen tales códigos, el dispositivo de UE puede realizar una exploración en bandas y tecnologías válidas para encontrar la o las redes. Después, con el descubrimiento, el dispositivo de UE puede realizar procedimientos de conexión con respecto a la red encontrada y puede repetir los procesos de registro y posregistro. De manera alterna, si no se encuentra ninguna red, el o los códigos PLMN recibidos pueden pasarse por alto. De manera similar, el comportamiento de registro del dispositivo 510 de UE a través de la señalización de IMS puede resumirse como sigue. Una vez que el dispositivo de UE se ha autenticado con éxito con una red de CS o una red de PS, éste puede entonces registrarse con el nodo de NeDS a través de una infraestructura válida de datos de paquete, tal como, por ejemplo, GPRS , a través de mensajes de SIP (por ejemplo, Notificación de SIP o Edición de SIP) o mensajes de XCAP, como se describe en lo anterior. Independientemente del protocolo de mensajes existente que se utilice, el mensaje de registro de preferencia incluye una serie de elementos de información similares a los elementos de información descritos en lo anterior con respecto al registro a través de la señalización de CS. Además, el UE también puede activar diversos mecanismos temporizadores y procesos de posregistro después del registro a través de la señalización de IMS, muy similares a los procesos establecidos en lo anterior con respecto al comportamiento del UE en el registro basado en CS. A modo de ilustración, las FIGURAS 12 y 13 representan diagramas de flujo de mensajes que se refieren a un proceso de registro generalizado basado en CS con un elemento de NeDS mediante el uso de mensajes de USSD. El dispositivo 510 de UE genera un mensaje 1204 de registro de USSD móvil originado (MO-USSD) para su propagación hacia la NeDS 200 a través de una infraestructura 702 de MSC/VLR. En respuesta, la NeDS 200 envía un mensaje de confirmación (MO-USSD-Ack) 1208. Después, la función 200 de NeDS proporciona otro mensaje, respuesta 1210 de USSD móvil terminada (MT-USSD) , al dispositivo 510 de UE que contiene información apropiada. En respuesta, el dispositivo de UE genera para la misma un mensaje de confirmación (MT-USSD-Ack) 1214. Los números de referencia 1202/1212 y 1206/1216 se refieren a los procesos del temporizador del lado del dispositivo y del lado de la NeDS, respectivamente, como se describe en detalle en lo anterior. La modalidad de flujo de mensajes mostrada en la FIGURA 13 es esencialmente similar a la modalidad de flujo de mensajes mostrada en la FIGURA 12, excepto que no se utiliza ningún mensaje de confirmación de USSD separado. Por consiguiente, los números de referencia 1304 y 1306 se refieren al registro de MO-USSD y mensajes de respuesta, respectivamente, en donde el mensaje 1306 de respuesta incluye tanto la confirmación como la información necesaria. Asimismo, los números de referencia 1302 y 1308 se refieren a los procesos del temporizador del lado del dispositivo como se describe en lo anterior. Después del registro, el dispositivo de UE puede proporcionar información de estatus actualizada al elemento de NeDS con base en una o más de las siguientes condiciones : (i) terminación del temporizador de actualización de localización de NeDS; (ii) cambio en el estatus de dominio de CS; y (üi) cambio en el estatus de dominio de IP (por ejemplo, estatus con respecto a la WLAN) . En una aplicación, la transición de la información actualizada puede controlarse a través de mensajes basados en presencia que utilizan las interfaces de dispositivo de UE/NeDS descritas en lo anterior. Por ejemplo, la función de NeDS puede suscribirse al agente de usuario del UE, de tal manera que con la detección de cualquier cambio en el estatus de CS, estatus de IMS, eventos del temporizador, etc., se puedan proporcionar notificaciones apropiadas a la NeDS. La FIGURA 14 representa un diagrama de flujo de mensajes que se refiere a la transmisión de mensajes entre un dispositivo de UE y un elemento de NeDS asociado con respecto al cambio de estado del dispositivo de UE en una modalidad. La NeDS 200 genera un mensaje 1402 de registro de SIP para el dispositivo 510 de UE que incluye diversos cambios de estado solicitados. Un mensaje 1406 de respuesta del dispositivo de UE incluye actualizaciones de estatus apropiadas de acuerdo con la solicitud. De manera alterna, cuando el dispositivo 510 de UE se registra con la NeDS 200, se puede regresar un indicador en el mensaje de respuesta de USSD/SMS o SIP, indicando que se requiere tal información de presencia. En los casos en los que se aplica la notificación periódica (por ejemplo, con base en la terminación de un temporizador de NeDS) , se puede utilizar ya sea señalización de CS o señalización de IMS. Cuando finalice el temporizador de NeDS, el UE se opera para enviar un mensaje de actualización que incluye cambios de estatus con respecto a cualquiera de los elementos de información descritos en lo anterior, por ejemplo, GRUU; identidad del abonado, identidad de equipo; localización de abonado (por ejemplo, información de GPS, información de CGI relacionada con las redes registradas, etc.); información de ID de red (por ejemplo, CGIs y/o SSIDs); información de temporizador de actualización de localización; estatus de conexión de PS; información de temporizador de actualización de enrutamiento ; estatus de contexto de PDP, estatus de LAN; y políticas/preferencias del abonado. El dispositivo de UE puede aplicar un mecanismo temporizador separado con respecto al proceso de transmisión de mensajes de actualización. Con la transmisión de un mensaje de actualización, un temporizador puede comenzar a identificar una ventana de respuesta. Si no se recibe ninguna respuesta o confirmación de la función de NeDS en la ventana de respuesta (es decir, el temporizador finaliza), el UE puede intentar la retransmisión del mensaje de ac ualización un número de veces seleccionado (por ejemplo, un máximo de cinco veces) antes de que se considere que el mensaje de actualización ha fallado. Si el dispositivo de UE pierde cobertura de CS y la función de NeDS puede realizarse a través de otra tecnología de acceso por radio (por ejemplo, WLAN, Wi-MAC, LTE, etc.), el dispositivo de UE incluye lógica para informar a la NeDS que la cobertura de CS se ha perdido a través de un mensaje de "pérdida de cobertura de CS" . Además, los siguientes elementos de información pueden incluirse, pero no limitarse, en el mensaje de pérdida de cobertura: GRUU; identidad del abonado (ID pública del Usuario y/o ID privada del Usuario); identidad de Terminal (dirección MAC, IMEI/IMEISV, PIN, ESN, etc.); localización del abonado, información de ID de red (por ejemplo, SSIDs y/o CGIs); y estatus de conexión de CS . Debe apreciarse que este mensaje de pérdida de cobertura CS puede aplicarse mediante el uso de mensajes de Notificación o Edición de SIP. Además, este procedimiento puede llevarse a cabo al mismo tiempo que se encuentra una llamada en progreso en el dominio de WLA . Por consiguiente, si el dispositivo de UE encuentra nuevamente cobertura de CS, el dispositivo de UE incluye lógica para informar a la función de NeDS . La FIGURA 15 representa un diagrama de flujo de mensajes que se refiere a la transmisión de mensajes entre un dispositivo de UE y un elemento de NeDS asociado con respecto al descubrimiento por parte del dispositivo de UE de un dominio de CS. Como se ilustra (número de referencia 802), la conexión en la nueva red de CS encontrada puede ser opcional. El dispositivo 510 de UE proporciona un mensaje 1502 de actualización que incluye los siguientes elementos de información: GRUU; identidad del abonado; identidad de Terminal; localización del abonado; información de ID de red (por ejemplo, SSIDs y/o CGIs), estatus de conexión de CS; y estatus de WLAN/IMS. Al igual que el control de la transmisión del cambio de estatus del dominio de CS a través de mensajes basados en presencia, los cambios de estatus de WLAN/IMS también pueden notificarse a la función de NeDS a través de procedimientos habilitados con presencia, como se ilustra en la FIGURA 16. El número de referencia 1602 se refiere a un mensaje de Registro de SIP que permite que la función 200 de NeDS reciba cambios de estatus de WLAN/IMS a medida que éstos ocurren a través de un mensaje de respuesta (por ejemplo, Notificación de SIP) 1604 generado mediante el dispositivo de UE . Además, en una modalidad separada, el dispositivo de UE también puede incluir lógica para proporcionar cambios de estado de WLAN/IMS a través de la señalización de CS, como se ilustra en la FIGURA 17, en donde el número de referencia 1702 se refiere a un mensaje de actualización (por ejemplo, mediante el uso de USSD, etc.) que incluye actualizaciones apropiadas para el dominio de WLAN/IMS. Además, independientemente de si se utilizan los mensajes de SIP (es decir, Notificación o Edición) o si se utilizan mensajes de USSD, se pueden incluir elementos de información adicionales en el mensaje de actualización: GRUU; identidad del abonado; identidad de terminal; localización del abonado; información de ID de red (por ejemplo, SSIDs y/o CGIs), estatus de WLAN/IMS. La FIGURA 18 representa un diagrama de bloques de una modalidad de un dispositivo de comunicación que opera como un dispositivo de UE inalámbrico, por ejemplo, UE 510, que tiene capacidad de doble dominio (es decir, dominio de CS y dominio de IMS) para los propósitos de la presente descripción de patente. Aquellos con experiencia en la técnica reconocerán, a partir de la referencia a la presente, que aunque una modalidad del UE 510 puede comprender una disposición similar a la que se muestra en la FIGURA 18, puede existir una serie de variaciones y modificaciones en el hardware, software o firmware con respecto a los diversos módulos representados. Además, un dispositivo de UE puede considerarse como una combinación de un dispositivo de equipo móvil (ME) y un módulo de almacenamiento removible que tiene las diversas piezas de información descritas en detalle en lo anterior. Por consiguiente, la disposición de la FIGURA 18 debe considerarse como ilustrativa en lugar de limitativa con respecto a las modalidades de la presente descripción de patente. Un microprocesador 1802 que proporciona el control general de una modalidad del UE 510 se acopla en forma operativa a un subsistema 1804 de comunicación que es apto para comunicaciones multimodales (por ejemplo, dominio de CS, dominio de IP, tales como IMS/WLA /Wi-MAX, etcétera) . El subsistema 1804 de comunicación por lo general incluye uno o más receptores 1808 y uno o más transmisores 1814, así como componentes asociados, tales como uno o más módulos 1810 de oscilador local (LO) y un módulo de procesamiento, tal como un procesador de señales digitales (DSP) 1812. Como será aparente para aquellos con experiencia en el campo de las comunicaciones, el diseño particular del módulo 1804 de comunicación puede depender de las redes de comunicación con las cuales se pretende que opere el dispositivo móvil (por ejemplo, una red CDMA, una red GSM, WLAN, etcétera) . Sin embargo, independientemente del diseño particular, se proporcionan señales que la antena 1806 recibe a través de infraestructuras 1805 de acceso apropiadas (por ejemplo, torres celulares de estaciones base, puntos activos de WLA , etc.) al receptor 1808, el cual puede realizar tales funciones de receptor comunes, tales como amplificación de señal, conversión descendente de frecuencia, filtrado, selección de canal, conversión análoga-digital (A/D) y similares. De manera similar, se procesan las señales que se van a transmitir, incluyendo modulación y codificación, por ejemplo, mediante DSP 1812, y se proporcionan al transmisor 1814 para su conversión digital-análoga (D/A) , conversión ascendente de frecuencia, filtrado, amplificación y transmisión a través de la interfaz radio-aérea mediante la antena 1816. El microprocesador 1802 también puede interconectarse con subsistemas de dispositivo adicionales, tales como de entrada/ salida (I/O) 1818 auxiliares, puerto 1820 en serie, pantalla 1822, teclado/teclado numérico 1824, bocina 1826, micrófono 1828, memoria de acceso aleatorio (RAM) 1830, un subsistema 1832 de comunicación de corto alcance y cualquier otro subsistema de dispositivo, por ejemplo, los mecanismos temporizadores descritos en lo anterior, por lo general designados con el número de referencia 1833. Para controlar el acceso y proporcionar almacenamiento de datos también se puede proporcionar un Módulo de Identidad del Abonado (SIM) o Módulo Removible de Identidad del Usuario (RUIM) o una interfaz 1834 de UICC en comunicación con el microprocesador 1802. En una aplicación, la interfaz 1834 de SIM/RUIM/UICC se opera con una tarjeta de SIM/RUIM/UICC que tiene una serie de configuraciones 1844 de tecla y otra información 1846, tal como identificación y datos relacionados con el abonado tales como politicas /preferencias del usuario, periodos del temporizador , etc. El software del sistema operativo y software de lógica de servicio válido pueden representarse en un módulo de almacenamiento permanente (es decir, almacenamiento no volátil), tal como memoria 1835 Flash. En una aplicación, la memoria 1835 Flash puede separarse en diferentes áreas, por ejemplo, área de almacenamiento para programas 1836 de computadora (por ejemplo, lógica de procesamiento de servicio), asi como regiones de almacenamiento de datos, tales como estado 1837 del dispositivo, libreta 1839 de direcciones, otros datos 1841 del Administrador de Información General y otras áreas de almacenamiento de datos por lo general designadas con el número de referencia 1843. Se puede proporcionar una pila 1845 de transporte para efectuar uno o más protocolos de transporte por radiopaquete apropiados. Además, se proporciona un agente de presencia, módulo 1848 de lógica de actualización, para efectuar la funcionalidad del dispositivo de UE que se establece en detalle en lo anterior. Esencialmente, el módulo 1848 de lógica se opera junto con otras estructuras para facilitar lo siguiente: (i) registro con la NeDS (CS o IMS); (ii) informar a la NeDS acerca de los dominios en los que el dispositivo de UE se encuentra registrado actualmente; (iii) identificar el estado del dispositivo de UE en los dominios registrados; (iv) identificar la información de localización relativa al dispositivo de UE (para facilitar si los servicios de IMS deben realizarse); y (v) proporcionar actualizaciones de estatus a la NeDS con base en presencia y/o mecanismos tempori zadores . Con base en la descripción detallada en lo anterior, a continuación se establecerá en detalle adicional el comportamiento de NeDS después de recibir el mensaje de registro, actualizaciones de localización iniciales e información de actualización posterior. Con respecto al registro a través de la señalización de CS, la función de NeDS se opera para examinar los contenidos de la cadena de mensajes y determinar si se incluyó o no un GRUU. Si no se recibió ningún GRUU, la función de NeDS se opera para generar un GRUU mediante el uso del ID del abonado y el ID de equipo. El GRUU construido se opera como un indexador para almacenar la información recibida en la función de NeDS. Se puede marcar que el registro de GRUU resultante se encuentra en uno de los estados que se identifican en la FIGURA 6A. Para propósitos de registro inicial, los estados válidos pueden ser: (i) CS Conectado/Inactivo (estado 618) o (ii) CS Conectado/ Inactivo e IMS Registrado/Inactivo (estado 604). Por otro lado, si se ha obtenido un GRUU del dispositivo de UE, la función de NeDS se opera para determinar si ya existe un registro para el GRUU recibido. Si es así, el registro de GRUU se actualiza con base en la información proporcionada. Si no existe ningún registro, se crea un nuevo registro de GRUU con base en el GRUU recibido e información asociada. De manera alterna, si el dispositivo de UE no soporta la capacidad de GRUU, la NeDS se opera para generar un registro con base en una Identidad Privada del Usuario (PUI), la cual puede ser una IMSI , MI , PIN, etc. En este caso, la PUI /IMSI puede utilizarse para indexar los registros en la NeDS. Además, como se menciona en lo anterior, la funcionalidad de NeDS puede incluir lógica para examinar la localización del dispositivo de UE y determinar si se debe proporcionar un servicio de IMS (por ejemplo, VCC) . En una aplicación relacionada, si el servicio de IMS no debe llevarse a cabo, la función de NeDS incluye lógica para informar al elemento de HSS que desactive cualquier accionador de CAMEL en el HSS si se ha utilizado CAMEL (por ejemplo, como se muestra en la FIGURA 10) . En forma relacionada, la función de NeDS también puede informar al dispositivo de UE que no se realizará el servicio de IMS (por ejemplo, al proporcionar o establecer un indicador de servicio de IMS en el mensaje de respuesta para el dispositivo de UE) . Por otro lado, si se va a realizar el servicio de IMS, la función de NeDS se opera para examinar la localización del UE para determinar si el UE se encuentra en una red que soporta el servicio de IMS solicitado. Si la red no soporta el servicio de IMS, la función de NeDS puede informar al dispositivo de UE que pase a otra red que soporte el servicio de IMS. Como se menciona en lo anterior, se pueden proporcionar uno o más códigos PLMN al dispositivo de UE que se identifican como aptos para soportar el servicio de IMS (es decir redirección de la red) . A modo de aplicación, la función de NeDS puede consultar una base de datos interna o externa mediante el uso de los datos de ID de red proporcionados mediante el dispositivo de UE para determinar cuál red soporta el servicio de IMS. Adicionalmente, la función de NeDS también pude incluir la capacidad para informar al dispositivo de UE, a través de un mensaje adecuado, qué tan seguido necesita ser notificado de que el dispositivo de UE se encuentra disponible en el dominio de CS, cuya notificación puede aplicarse al proporcionar un temporizador de actualización de localización de CS en la respuesta del UE . La función de NeDS puede iniciar su temporizador de actualización después de enviar este mensaje al dispositivo de UE . Como una aplicación por defecto, el temporizador de actualización de localización de NeDS puede ser el mismo que el temporizador de actualización de localización de CS . Además, la función de NeDS de preferencia puede incluir la capacidad de solicitar información de presencia de un servidor de presencia mediante el uso de protocolos definidos a través de interfaces apropiadas como se describe en lo anterior. Además, la función de NeDS también puede informar al dispositivo de UE si se requiere alguna información de presencia, tal como, por ejemplo, pérdida de CS o WLAN, etc., mediante indicadores apropiados dentro de una estructura del mensaje de respuesta/solicitud . Con respecto al registro de IMS, también se puede diseñar un comportamiento sustancialmente similar en la f ncionalidad de NeDS. Como se explica en lo anterior, la función de NeDS también puede incluir la capacidad de enviar un mensaje de Opciones de SIP al dispositivo de UE (mostrado en la FIGURA 9) . Si la respuesta del dispositivo de UE es que no puede soportar un servicio de IMS, se pueden proporcionar dos aplicaciones ejemplares. En una aplicación, el elemento de NeDS puede informar al nodo de HSS que desactive cualquier activador de CAMEL, al igual que en el comportamiento de registro de CS descrito en lo anterior. De manera alterna, el elemento de NeDS puede realizar una nota de que para esta combinación particular de abonado/UE el servicio no se encuentra disponible. De este modo, para llamadas originadas móviles cuando se recibe un DP Inicial de la MSC , el número de la parte llamada puede regresarse a la MSC como el número que se utilizará para la llamada saliente. Además, si se utilizan los mensajes de USSD, el número original de la parte llamada puede regresarse como el número que se utilizará en el establecimiento. Con la recepción de los mensajes de Edición de SIP o de XCAP como parte del procedimiento de registro de IMS, la función de NeDS se opera para examinar los contenidos en la misma y construir el o los registros apropiados en la NeDS con base en si se ha proporcionado o no un GRUU, muy similar al comportamiento de registro de CS descrito en lo anterior. Asimismo, la NeDS puede determinar si se debe proporcionar un servicio de IMS con base en la información de localización mediante el uso de bases de datos internas /externas y, con base en tales determinaciones, la NeDS puede desactivar activadores de CAMEL apropiados en el HSS en la medida en que CAMEL pueda utilizarse. Al igual que en el comportamiento de registro de CS, la redirección a otras redes también puede ser posible en este caso. Con respecto a las actualizaciones de localización iniciales, la función de NeDS se opera para recibir del HSS o de un servidor proxy de presencia de entidad presentadora de datos una indicación de que una conexión de PS y una actualización de localización asociada se han llevado a cabo. En respuesta a la misma, la función de NeDS se opera para iniciar un temporizador para esperar un registro del UE mediante el uso de un registro ya sea de USSD (del lado de CS) o de 3ra parte (del lado de IMS, como se ejemplifica en la FIGURA 9) . Si se lleva a cabo cualquiera de estos dos eventos de registro, se puede detener el temporizador. Por otro lado, si el temporizador finaliza sin un registro, se puede considerar que el dispositivo no es apto para servicios de IMS. Al igual que en el tratamiento proporcionado con respecto a la situación en la que no se soporta el servicio de IMS, cuando se recibe un DP Inicial de la MSC para llamadas originadas móviles, el número de la parte que llama puede regresarse a la MSC como el número que se utilizará para la llamada saliente. Con respecto a la recepción de actualizaciones periódicas del dispositivo de UE, la función de NeDS se opera para examinar los contenidos de los mensajes de actualización válidos (por ejemplo, a través de USSD o SMS en el dominio de CS, o a través de la Edición de SIP en el dominio de IMS) y actualizar sus registros de abonado/UE y/o estados en consecuencia. De preferencia, la NeDS se opera para correlacionar los registros internos mediante la indexación de GRUU o indexación de PUI como se describe en lo anterior. Con la recepción de un cambio de estatus de CS, la función de NeDS se opera para actualizar la información de modelo de estado asociada con ese GRUU o PUI/IMSI particular. Con base en el modelo de transición de estado establecido en la FIGURA 6A, si el estado de CS es "desconectado", el único estatus válido puede ser IMS Registrado/ Inactivo (estado 608) o IMS Registrado/Activo (estado 610). Asimismo, si el estatus de CS es "conectado" , los estados válidos pueden ser CS Conectado/Inactivo (estado 618), CS Conectado/ Inactivo e IMS Registrado/Inactivo (estado 604) o CS Conectado/ Inactivo e IMS Registrado/Activo (estado 606) . De manera similar, si la función de NeDS recibe un cambio de estatus de IMS/WLAN, el procesador de estados asociado con la misma se opera para actualizar por consiguiente la información de modelo de estado válida con base en el GRUU o PUI/IMSI. Si el estatus de IMS es "IP local asignado" o "asociado", los estados válidos pueden ser CS Conectado/Inactivo (estado 618) o CS Conectado/Activo (estado 616) . Si el estatus de IMS es "PDF conectado", los estados válidos pueden ser IMS Registrado/Inactivo (estado 608), CS Conectado/Inactivo e IMS Registrado/ Inactivo (estado 604) o CS Conectado/Activo e IMS Registrado/ Inactivo (estado 612). Se considera que la operación y construcción de las modalidades de la presente solicitud de patente serán aparentes a partir de la descripción detallada establecida en lo anterior. Aunque las modalidades ejemplares mostradas y descritas pueden haberse caracterizado como preferidas, deberá entenderse fácilmente que se pueden realizar diversos cambios y modificaciones en las mismas sin apartarse del alcance de la presente descripción que se establece en las siguientes reivindicaciones .

Claims (32)

1. REIVINDICACIONES 1. Un nodo de red que opera para disponerse en una red de subsistema de multimedia (IMS) de Protocolo de Internet (IP), el nodo de red caracterizado porque comprende: medios para mantener información de estatus relacionada con un dispositivo de equipo de usuario (UE) que operan para recibir servicio del nodo de red; medios para actualizar la información de estatus con base en la información de actualización recibida del dispositivo de UE; y medios para seleccionar un dominio apropiado con base en la información de estatus con respecto al enrutamiento de una llamada entrante dirigida al dispositivo de UE.
2. 2. El nodo de red de conformidad con la reivindicación 1, caracterizado porque la información de actualización se recibe del dispositivo de UE a través de mensajes de Protocolo de Inicio de Sesión (SIP) .
3. 3. El nodo de red de conformidad con la reivindicación 1, caracterizado porque la información de actualización se recibe del dispositivo de UE a través de mensajes de Datos de Servicio Suplementario no Estructurados (USSD) .
4. 4. El nodo de red de conformidad con la reivindicación 1, caracterizado porque la información de actualización se recibe del dispositivo de UE a través de mensajes de Servicio de Mensaje Corto (SMS) .
5. 5. El nodo de red de conformidad con la reivindicación 1, caracterizado porque la información de actualización se recibe del dispositivo de UE a través de mensajes de Protocolo de Acceso a la Configuración (XCAP) de Lenguaje de Marcación Ampliable (XML) .
6. 6. El nodo de red de conformidad con la reivindicación 1, caracterizado además porque comprende medios para almacenar criterios de política con respecto al dispositivo de UE.
7. 7. El nodo de red de conformidad con la reivindicación 6, caracterizado porque por lo menos una parte de los criterios de política se operan para establecerse por el dispositivo de UE mediante el uso de por lo menos una de señalización de CS y señalización de IMS.
8. 8. El nodo de red de conformidad con la reivindicación 1, caracterizado además porque comprende medios para determinar si el dispositivo de UE es apto para un servicio de IMS.
9. 9. El nodo de red de conformidad con la reivindicación 1, caracterizado porque la información de actualización se recibe del dispositivo de UE en forma periódica .
10. 10. El nodo de red de conformidad con la reivindicación 1, caracterizado porque la información de actualización se recibe del dispositivo en respuesta a un mecanismo de notificación basado en presencia.
11. 11. El nodo de red de conformidad con la reivindicación 1, caracterizado porque la información de actualización comprende una pérdida de indicación de cobertura con respecto a una red celular conmutada por circuitos .
12. 12. El nodo de red de conformidad con la reivindicación 1, caracterizado porque la información de actualización comprende una pérdida de indicación de cobertura con respecto a una red de acceso inalámbrica conmutada por paquetes .
13. 13. Un dispositivo de equipo de usuario (UE) que opera para disponerse en un ambiente de red que incluye una red conmutada por circuitos (CS) y una red de subsistema de multimedia (IMS) de Protocolo de Internet (IP), caracterizado porque comprende: medios para determinar que la información de estatus asociada con el dispositivo de UE ha cambiado; medios para proporcionar una actualización de cambio de información de estatus a un nodo de red dispuesto en la red de IMS ; y medios para modificar por lo menos una parte de los criterios de política almacenados en el nodo de red con respecto al dispositivo de UE .
14. 14. El dispositivo de UE de conformidad con la reivindicación 13, caracterizado porque por lo menos una parte de los criterios de política comprende un criterio de política basado en el usuario.
15. 15. El dispositivo de UE de conformidad con la reivindicación 13, caracterizado porque por lo menos una parte de los criterios de política comprende un criterio de política basado en el operador.
16. 16. El dispositivo de UE de conformidad con la reivindicación 13, caracterizado porque los medios para proporcionar la actualización de cambio de información de estatus se operan con mensajes de Protocolo de Inicio de Sesión (SIP) .
17. 17. El dispositivo de UE de Conformidad con la reivindicación 13, caracterizado porque los medios para proporcionar la actualización de cambio de información de estatus se operan con mensajes de Protocolo de Acceso a la Configuración (XCAP)de Lenguaje de Marcación Ampliable (XML) .
18. 18. El dispositivo de UE de conformidad con la reivindicación 13, caracterizado porque los medios para proporcionar la actualización de cambio de información de estatus se operan con mensajes de Datos de Servicio Suplementario no Estructurados (USSD) .
19. 19. El dispositivo de UE de conformidad con la reivindicación 13, caracterizado porque los medios para proporcionar la actualización de cambio de información de estatus se operan con mensajes de Servicio de Mensaje Corto (SMS) .
20. 20. El dispositivo de UE de conformidad con la reivindicación 13, caracterizado porque los medios para modificar los criterios de política se operan con por lo menos una de señalización de CS y señalización de IMS.
21. 21. El dispositivo de UE de conformidad con la reivindicación 13, caracterizado porque los medios para proporcionar la actualización de cambio de información de estatus se operan para proporcionar la actualización de cambio de información de estatus en forma periódica.
22. 22. El dispositivo de UE de conformidad con la reivindicación 13, caracterizado porque los medios para proporcionar la actualización de cambio de información de estatus se operan para proporcionar la actualización de cambio de información de estatus en respuesta a un mecanismo de notificación basado en presencia.
23. 23. El dispositivo de UE de conformidad con la reivindicación 13, caracterizado porque la actualización de cambio de información de estatus comprende una pérdida de indicación de cobertura con respecto a la red celular conmutada por circuitos.
24. 24. El dispositivo de UE de conformidad con la reivindicación 13, caracterizado porque la actualización de cambio de información de estatus comprende una pérdida de indicación de cobertura con respecto a la red de acceso inalámbrica conmutada por paquetes .
25. 25. El dispositivo de UE de conformidad con la reivindicación 13, caracterizado porque la información de estatus comprende un dominio con el cual el dispositivo de UE se encuentra registrado actualmente.
26. 26. El dispositivo de UE de conformidad con la reivindicación 13, caracterizado porque la información de estatus comprende el estado del dispositivo de UE .
27. 27. El dispositivo de UE de conformidad con la reivindicación 13, caracterizado porque la información de estatus comprende la información de presencia del dispositivo de UE.
28. 28. Un método para selección de dominio que opera en un ambiente de red que incluye una red conmutada por circuitos (CS) y una red de subsistema de multimedia (IMS) de Protocolo de Internet (IP), caracterizado porque comprende: mantener información de estatus relacionada con un dispositivo de equipo de usuario (UE) que operan para recibir servicio del nodo de red; actualizar la información de estatus con base en la información de actualización recibida del dispositivo de UE; y seleccionar un dominio apropiado con base en la información de estatus con respecto al enrutamiento de una llamada entrante dirigida al dispositivo de UE .
29. 29. El método para selección de dominio de conformidad con la reivindicación 26, caracterizado porque la información de actualización se recibe del dispositivo de UE a través de mensajes de Protocolo de Inicio de Sesión (SIP) .
30. 30. El método para selección de dominio de conformidad con la reivindicación 25, caracterizado porque la información de actualización se proporciona por el dispositivo de UE a través de mensajes de Datos de Servicio Suplementario no Estructurados (USSD) .
31. 31. El método para selección de dominio de conformidad con la reivindicación 25, caracterizado porque la información de actualización se proporciona por el dispositivo de UE a través de mensajes Servicio de Mensaje Corto (SMS) .
32. 32. El método para selección de dominio de conformidad con la reivindicación 25, caracterizado porque la información de actualización se proporciona por el dispositivo de UE a través de mensajes de Protocolo de Acceso a la Configuración (XCAP) de Lenguaje de Marcación Ampliable (XML) .