CONTROL SELECTIVO DE CAPACIDADES DE EQUIPO DE USUARIO Esta invención se relaciona con sistemas de comunicación electrónica, y más particularmente con sistemas de comunicación electrónica que tienen equipo de usuario configurable con diferentes componentes de software. En la actualidad, varios actores están involucrados en el manejo del software y hardware de un equipo de usuario (UE) , tal como un teléfono móvil u otro dispositivo de comunicación en un sistema de comunicación inalámbrico. El software pueden ser aplicaciones, ser4vicios y módulos, incluyendo el sistema de operación (OS) , almacenado en y usado por el UE. El fabricante del UE típicamente instala una colección de software en el UE en el momento en que se fabrica el dispositivo. Posteriormente, un usuario final puede modificar el software del UE descargando las aplicaciones de UE, etc., de diferentes fuentes a través de, por ejemplo, el Internet. El fabricante del UE, el operario del sistema de comunicación al que está suscrito el UE o en el que el UE está visitando, y/o una tercera parte autorizada, dependiendo de convenios de negocios, también pueden modificar remotamente parte o todo el software de UE. Después de estas modificaciones y en otros casos, el UE se puede comportar inapropiadamente . Desde el punto de
vista de un operario de sistema por ejemplo, el comportamiento inapropiado incluye disminuir del UE la capacidad del sistema de comunicación aumentando el número de control u otros mensajes intercambiados con el sistema. El comportamiento de UE inapropiado puede presentarse en un número de foras, v.gr., interacciones inesperadas entre módulos de software en el UE, módulos de software malicioso, etc. Un usuario podría descargar una aplicación maliciosa o mal formada, por ejemplo, una aplicación Java, que interactúa con la pila de protocolo de red a través de interfaces de programación de aplicación (APIs) abiertas en el UE. Como resultado, el UE podría enviar repetidamente solicitudes de servicio a una red de operario. La aprobación de tipo siempre de hace de todo el software de señalización de radio. Por ejemplo, el software de tipo aprobado en el UE puede exponer una funcionalidad como llamada de emergencia y servicio de subsistema de multimedia (IMS) de protocolo de Internet (IP) al ambiente Java y más generalmente la capa de aplicación. Comparado, por ejemplo, con el ajuste normal de una llamada, una solicitud será denegada si no hay suficientes recursos de red para satisfacer la solicitud, que puede ser un problema para una funcionalidad como llamada de emergencia que es una solicitud
de prioridad elevada. Este puede no ser un problema grande en la actualidad, pero más y más funcionalidad se expondrá a la capa de aplicación y cada vez< más UEs pueden descargar software. Cuando las particularidades permitidas se exponen a la capa de aplicación, se pueden usar mal; por ejemplo, una aplicación de UE puede tratar de registrar una sesión de IMS 1000 veces por minuto. Si esa aplicación es copiada a otros UEs, resultarla un problema serio para el operario de red. Las técnicas para tratar con comportamiento inapropiado de UE incapacitando servicios a un UE se ha discutido en organizaciones de normalización tales como el Third Generation Partnership Projet (3GPP) , El 3GPP promulga especificaciones para el sistema de telecomunicaciones de GSM y sus mejoras como Regímenes de Datos Mejorados para Evolución de GSM (EDGE) , el sistema de telecomunicaciones móvil universal (UMTS), y sistemas que emplean múltiples accesos de división de código de banda ancha (WCDMA) . Por ejemplo, la Sección 4.5 de la Especificación Técnica de 3GPP (TS) 22.011 V7.6.0 (marzo de 2007), Accesibilidad de Servicio (Publicación 7) y Sección 4.5 de 3GPP TS 22.011 V8.0.0 (marzo de 2007), Accesibilidad de Servicio (Publicación 8) se relacionan con el control de las capacidades de UE. Una lista de servicios de capacidad de UE
selectivas se puede mantener en la UE, y si un servicio en la lista está indicado como incapacitado, el UE no solicita el servicio de la red. Los servicios sobre la lista de capacidades selectivas incluyen funciones de control de llamada (CC) , servicios suplementarios (SS) , llamadas de emergencia, servicios de mensaje corto (SMS) a través de enlaces conmutados por circuito (CS) y conmutados por paquete (PS) , un servicio de ubicación (LCS), servicios basados en servicio de radio de paquete general de GSM (GPRS) , un servicio de difusión de multimedia y multicálculo (MBMS) , y un IMS . 3GPP TS 22.011 sigue el Reporte Técnico de 3GPP (TR)= 23.805 VO.3.1 (septiembre de 2005), Incapacitación Selectiva de Capacidades de UE; Porte sobre Opciones Técnicas y Conclusiones (Publicación 7), y 3GPP TS 24.305 V0.1.0 (marzo de 20' 06). La Incapacitación Selectiva de Capacidad de UE de 3GPP (SDoUE) Objeto de Manejo (MO) (Publicación 7) . 3GPP TR 23.805 V0.3.1 y TS 24.305 V0.1.0 introdujeron la lista de capacidades selectivas y manejo de dispositivo (DM) de acuerdo con la Alianza Móvil Abierta (OMA) para incapacitar las capacidades de UE, pero no describió ninguno de los parámetros necesarios para un SDoUE MO ni ninguna de las reglas y comportamiento correspondiente del UE cuando se
incapacitan/capacitan servicios o funciones. La OMA desarrolló especificaciones para Manejo de Dispositivo (DM) de dispositivos de comunicación, y las versiones 1.1.2 y 1.2 de esas especificaciones definen un protocolo para manejar configuración, datos y ajustes en los dispositivos de comunicación. Las normas de OMA y otra información están disponibles en http : //wwwopenmobilealliance.. o.rg . OMA DM se puede usar para manejar la configuración y MOs de UEs desde el punto de vista de diferentes Autoridades de DM, incluyendo ajuste de información de configuración inicial en UEs, subsecuentemente actualizar la información persistente en UEs, retirando la información de manejo de UEs, y eventos de procesamiento y alarmas generadas por los UEs. Utilizar OMA DM, terceras partes pueden configurar los UEs en representación de los usuarios finales. Una tercera parte, tal como un operario de red, proveedor de servicios y departamento de manejo de información corporativa, pueden ajustar remotamente los parámetros de UE e instalar o mejorar el software a través de MOs apropiados en el UE. Un MO es generalmente un objeto de software que puede estar escrito, por ejemplo, de conformidad con SyncML, que es una especificación de lenguaje de marca de un protocolo de representación basado en SML, protocolo de
sincronización y protocolo de DM, enlaces de transporte para los protocolos, y un marco de descripción de dispositivo para DM. Como se ilustra en la Figura 1, una Autoridad 102 de Manejo de DM (MA) expide una solicitud a un Servidor 104 de DM, por ejemplo, para provisión de parámetros en uno o más UEs. El Servidor 104 de DM envía una Notificación Iniciada por Servidor a un UE 106, que establece una Sesión de DM con el Servidor 104 de DM, que pregunta al UE los ajustes actuales (que pueden incluir extensiones específicas de UE) . El Servidor 104 de DM envía mandos de DM para ajustar la configuración del UE para conformarse a los requerimientos establecidos por la DM MA 102. El UE 106 y el Servidor 104 de DM terminan su Sesión de DM, y el UE es capaz de tener acceso a servicios de datos de red usando los parámetros de conectividad configurados. El DM MA o el Servidor de DM puede almacenar los parámetros de conectividad en una "tarjeta inteligente" o lo semejante, de manera que el UE pueda usarlos cuando el UE consume los parámetros. Un UE puede, por ejemplo, usar un MO de Conectividad para ajustes independientes de aplicación para conectarse a una red. Un MO de Conectividad para la red proporcionaría información de conectividad que se relaciona
con los parámetros y medios necesarios para tener acceso a la infraestructura de red, incluy6endo portadores de red, protocolos, direcciones de Punto de Acceso de Red (NAP) , y direcciones de representante. De conformidad con las especificaciones de OMA, un capacitor de MO de Conectividad maneja la dirección de conectividad de datos inalámbricos especificando un juego de esquema de objeto de DM que se puede exponer mediante un Cliente de DM y dirigirse por un servidor de DM. Los esquemas de objeto tienen tres partes: un objeto de manejo de nivel superior que es portador-neutro; un juego de parámetros específicos de portador; y un subárbol para exponer parámetros específicos de vendedor. Los parámetros de conectividad enlazados usando Aprovisionamiento de Cliente (CP) subsecuentemente se pueden dirigir y manejar a través del servidor de DM, que puede añadir nuevos representantes y puntos de acceso de red usando un paquete de DM normalizado. El aprovisionamiento es el proceso mediante el que un cliente en un dispositivo está configurado, y generalmente cubre tanto a través del aprovisionamiento de aire (OTA) como otro aprovisionamiento, v.gr., mediante una tarjeta de módulo de identidad de suscriptor (SIM) . Sin embargo, es difícil usar OMDA DM para incapacitar y capacitar remotamente servicios para tratar con
comportamiento de UE de conformidad con 3GPP TS 22.011. Entre los problemas que se presentan está el hecho de que los servicios que se van a incapacitar/capacitar operan en capas de la pila de protocolo que son inferiores a los usuales para una Sesión de DM. Otro problema involucra la necesidad de seguridad aceptable al controlar dichas particularidades de operación básicas del UE. De esta manera, la aplicación de OMA DM para incapacitar capacidades de un UE no es directa. COMPENDIO De conformidad con aspectos adicionales de esta invención, se proporciona un método para operar un UE en una red móvil de tierra pública (PLMN) . El método incluye los pasos de determinar que el UE solicita inapropiadamente cuando menos un servicio de la PLMN; informar a una entidad de manejo en un PLMN local (HPLMN) de la solicitud inapropiada; solicitar, por la entidad de manejo de HPLMN, un servidor de computadora de manejo de dispositivo en la HPLMN para incapacitar el servicio inapropiadamente solicitado en el UE; enviar, del servidor de HPLMN, un mensaje al UE para establecer una sesión de manejo entre el UE y el servidor, y tener acceso a un objeto de manejo de SDoUE en el UE de modo que se incapacite el servicio inapropiadamente solicitado. De conformidad con aspectos adicionales de esta
invención, se proporciona un medio legible por computadora que tiene instrucciones que, cuando se ejecutan por un procesador en un UE en una PLMN, ocasionan que el procesador realice los pasos de: determinar que el UE solicita inapropiadamente cuando menos un servicio de la PLMN; informar a una entidad de manejo en una HPLMN de la solicitud inapropiada; solicitar, por la entidad de manejo de HPLMN, un servidor de computadora de manejo de dispositivo en la HPLMN para incapacitar el servicio inapropiadamente solicitado en el UE; enviar, del servidor de HPLMN, un mensaje al UE para establecer una sesión de manejo entre el UE y el servidor; y tener acceso a un objeto de manejo de SDoUE en el UE de modo que el servicio inapropiadamente solicitado sea incapacitado. BREVE DESCRIPCIÓN DE LOS DIBUJOS Los diversos objetos, particularidades y ventajas de esta invención se entenderán leyendo esta descripción en conjunción con los dibujos, en los cuales: La Figura 1 ilustra una disposición de manejo de dispositivo; La Figura 2 es una gráfica de flujo de un método para operar un UE y una red de comunicación; La Figura 3 es una gráfica de flujo de otro método para operar un UE y una red de comunicación;
La Figura 4 es un diagrama de bloque de un equipo de usuario; La Figura 5 ilustra un control de puerta en un equipo de usuario; La Figura 6 es una gráfica de flujo de un método para controlar la activación de contexto de PDP; La Figura 7 es un diagrama de bloque de un sistema de comunicación, que incluye un equipo de usuario y una porción de una red; y La Figura 8 ilustra una red. DESCRIPCIÓN DETALLADA. Esta solicitud se enfoca en sistemas de comunicación inalámbrica que cumplen con las especificaciones promulgadas por el 3GPP para economía de explicación, pero se entenderá que los principios descritos en esta solicitud se pueden implementar en otros sistemas de comunicación. También se entenderá que esta descripción está escrita en términos de ??? DM, pero esta descripción no debe interpretarse como estando limitada a OMDA DM. Independiente del mecanismo utilizado para incapacitar o capacitar los servicios en un UE, es ventajoso que el UE sea selectivamente controlable de una forma normalizada. Los inventores han reconocido de OMDA DM se puede
usar para incapacitar y capacitar un servició o función especifico (o juego de servicios o funciones) aún cuando algunos de esos servicios/funciones se necesiten cuando OMA DM se use para capacitar esos servicios/funciones nuevamente. Esta solicitud describe un SDoUE MO y operación de un UE que utiliza el SDoUE MO en un sistema de comunicación. El artesano entenderá que el SDoUE MO es generalmente un módulo de software que incluye parámetros que se pueden usar para incapacitar y capacitar selectivamente capacidades de un UE. Actualmente se considera ventajoso usar el mecanismo de propiedad de Lista de Control de Acceso (ACL) de OMA DM para conceder o negar derechos de acceso a servidores de OMA DM a fin de modificar nodos y objetos de hoja del SEoUE MO. El mecanismo de propiedad de ACL se describe actualmente en la Enabler Reléase Definition OMDA-ERELD-DM-Vl_2, que se incorpora aquí por referencia. Debido a razones de seguridad, un operario de HPLMN de UE puede usar el mecanismo de ACL para permitir o prohibir que otros operarios de red (v.gr., operarios de PLMNs visitadas (VLPMNS) ) tengan acceso al SDoUE MO de UE a través de un servidor de DM de VPLMN mientras que el UE está navegando como se describe abajo . El siguiente Cuadro 1 ilustra una estructura de
árbol lógica de ejemplo, que incluye nodos y objetos de hoja, de un SDoUE MO. Cuadro 1. Estructura lógica de ejemplo de un SDoUE MO
¿Nombre? ¿CS Llamadas?
— ~ ¿Servicios Suplementarioa? — ¿CS_SMS? — iPS_SMS? _ . ¿cs_i,cs? — iPS_L S7
Como es típico de anotación de OMD DM, <X> en el cuadro 1 es un nódo sujetador de lugar que toma cualquiera de dos valores, v.gr., 0 y 1, y uno o más nodos y objetos de hoja se proporcionar bajo ese nodo. El artesano entenderá que, de conformidad con OMA DM, el SDoUE MO tiene un Identificador de MO asociado, que permite a los servidores de DM encontrar el SDoUE al manejar un dispositivo particular. El otro nodo y objetos de hoja del SDoUE MO ilustrado en el Cuadro 1 son como sigue, y se apreciará que algunos nodos y objetos de hoja se pueden omitir, otros nodos y objetos se
hoja se pueden proporcionar, y nodos y objetos de hoja pueden tener diferentes nombres, si se desea; Nombre, que es una hoja para ajustes de SDoUE MO; CS_Llamadas, que es una hoja que indica una preferencia para capacitar o incapacitar procedimientos de control de llamada (CC) CS originada en el UE excepto por llamadas de emergencia; CS_Llamadas de Emergencia, que es un nodo interior que indica una preferencia del operario para capacitar o incapacitar procedimientos de CC de emergencia de' CS (v.gr., incapacitados en donde el valor de CS_Llamadas de Emergencia se ajusta a 1), que se especifican en 3GPP TS 24.008 por ejemplo; País, que es una hoja que representa un país, que se puede identificar mediante un código de pais móvil (MCC) , y capacita inclusión de información que indica en cual MCC los procedimientos de CS CC de emergencia se incapacitan (v.gr., en cual se ajusta el valor de CS_Llamadas de Emergencia a 1); Red, que es una hoja que puede representar una red, que se puede identificar mediante un código de red móvil (MNC), y capacitar, con la hoja de Pais, la inclusión de información que indica en cuyal MCC y MNC se incapacitan los
procedimientos CS CC de emergencia; Servicios Suplementarios, que es una hoja que capacita o incapacita operaciones SS originadas en UE; CS_SMS, que es una hoja que capacita o incapacita SMS originados en UE a través de enlaces de CS; PS_SMS, que es una hoja que capacita o incapacita SMS originados en UE a través de enlaces de PS; CS_LCS,que es una hoja que capacita o incapacita operaciones de LCS originados en UE a través de enlaces CS; PS_LCS, que es una hoja que capacita o incapacita operaciones de LCS originadas en UE a través de enlaces PS; GPRS_SM_PDP, que es una hoja que capacita o incapacita procedimientos de Manejo de Sesión (SM) de GPRS originados por UE para contextos de protocolo de datos de paquete (PDP) , v.gr., activación, desactivación, y modificación de contexto de PDEP; 6PRS_SM_MBMS, que es una hoja que capacita o incapacita procedimientos de GPRS SM para contextos de MBMS, v.gr., activación y desactivación de contexto de MBMS; IMS, que es una hoja que capacita o incapacita procedimientos de IMS para enviar solicitudes de registro de IMS; Texto, que es una hoja que incluye información que
se puede mostrar por el UE al usuario; Números de Cuidado de Cliente, que es un nodo interior que capacita o incapacita una referencia a una lista de números de servicio de cuidado del cliente; Números de Cuidado de Cliente/<X>/Número de Cuidado de Cliente, que es una hoja que representa un número de servicio de cuidado de cliente que se puede usar por el usuario al determinar la causa de no disponibilidad de servicios específicos; Servidor de Aler4ga/D, que es una hoja que indica un identificador de Servidor de DM y permite informar al Servidor de DM acerca de un SDoUE MO que se ha modificado; IMS_Llamadas de Emergencia, que es un nodo interior que indica una preferencia de operario de red para capacitar o incapacitar procedimientos de llamada de energía a través de IMS, que se especifican en 3GPP TS 24.229, por ejemplo; IMS_Llamadas de Emergencia/<X>/'País/Red, que es una hoja que representa una red, que se puede identificar mediante un MNC, y capacita, con la hoja de País, la inclusión de información que indica en cual MCC y MNC se incapacitan los procedimientos de llamada de emergencia a través de IMS; y Ext, que es un nodo interior que se puede usar para
información acerca del SDoUE MO, v.gr., vendedor de aplicación, vendedor de UE, etc. Una hoja típicamente toma cualquiera de dos valores, v.gr., ya sea 0 o 1, y se apreciará que el valor particular tomado no es crítico, solamente el efecto de un valor particular necesita predeterminarse. Por ejemplo, cuando el valor de hoja de CS_Llamadas se ajusta a 1, el UE inicia la liberación de todas las llamadas activas excepto por llamadas de emergencia, y entra a un estado "nulo" tal como aquel descrito en 3GPP TS 24.008. El UE no usa los procedimientos CC originados por UE excepto para llamadas de emergente y número (s) de servicio de cuidado de cliente, si se indican por la hoja de Texto, hasta que el valor de hoja de CS_Llamadas se ajusta a 0. Cuando el valor de hoja de CS_Llamadas de
Emergencia se ajusta a 1 y el UE detecta una red móvil de tierra pública predeterminada (PLMN) , que se puede identificar mediante un MCC y MNC, entonces el UE inicia un procedimiento de señalización para liberar todas las llamadas de emergencia. Además. E, UE no puede usar procedimientos de CC para establecer llamadas de emergencia sino hasta que el valor de hoja de CS_Llamadas de Emergencia se ajusta a 0 o el UE detecta un MCC y MNC que no coinciden con cualquiera de
sus pares de códigos almacenados. Cuando el valor de hoja de Servicios Suplementarios se ajusta a l, el UE termina todas las operaciones de SS activas, y no invoca operaciones de SS y sus respuestas sino hasta que el valor de hoja de Servicios Suplementarios se ajusta a 0. Cuando la hoja CS_SMS se ajusta a l, el UE no usa el dominio CS para transferencia de SMS originada en UE sino hasta que el valor de hoja de CS_SMS se ajusta a 0. De manera similar, cuando la hoja PS_SMS se envía a l, el UE no usa el dominio PS para transferencia de SMS originado por UE sino hasta que el valor de hoja PS_SMS se ajusta a 0. Cuando el valor de hoja de CS_LCS se ajusta a l, el UE no usa el dominio US para operaciones de servicio de LCS originados por UE sino hasta que el valor de hoja de CS_LCS se ajusta a "0". De manera similar, cuando el valor de hoja de PS_LCS se ajusta a l, el UE no usa el dominio PS para operaciones de servicio de LCS originadas por UE sino hasta que el valor de hoja de PS_LCS se ajusta a 0. Cuando el valor de hoja GPRS_SM_PDP se ajusta a 1, el UE libera todos los recursos asignados para contextos de PDP activos, y el UE puede borrar los datos de contexto de PDP y entrar a un estado de espera o reposo. El UE no usa los
procedimientos GPRS SM originados por Ue sino hasta que el valor de hoja GPRS_SM_PDP se ajusta a 0, aún cuando el Ue ventajosamente se puede permitir usar los procedimientos de GPRS SM originados por UE para activación de contexto de PDP en casos particulares. Por ejemplo, los procedimientos de GPRS SM originados por UE para activación de contexto de PDP se puede usar al recibir un mensaje de notificación de OMA DM indicando que el UE debe iniciar una sesión de OMA DM al servidor de DM que se había ajustado al valor incapacitado de la hoja de GPRS_SM_PDP. Por otro ejemplo, los procedimientos de GPRS SM originados por UE para activación de contexto de PDP se pueden usar cuando son necesarios ya sea para establecer una llamada de emergencia a través de IMS (v.gr., si el valor de IMS_Llamadas de Emergencia se ajusta a 0) o para enviar un mensaje de alerta genérico de OMA DM. Cuando el valor de hoja de GPRS_SM_MBMS se ajusta a 1, el UE libera recursos asignados para contextos de MBMS activos, y puede borrar los datos de contexto de MBMS. El UE no usa procedimientos de GPRS SM para contextos de MBMS sino hasta que el valor de hoja de GPRS_SM_MBMS se ajusta a 0. Cuando el valor de hoja de IMS se ajusta a l, el UE inicia el procedimiento de desregistro iniciado por usuario para IMS, y no envía una solicitud de registro de IMS sino
hasta que el valor de hoja de IMS se ajusta a 0. Se observará que incapacitar Contextos de GPRS_SM_PDP es un segundo paso para incapacitar un IMS de mal comportamiento enviando repetidamente solicitud de registros de IMS. La información contenida en la hoja de Texto debe estar en el lenguaje seleccionado por el UE y puede ayudar a determinar la causa de no disponibilidad de servicios específicos y qué hacer. Por ejemplo, la hoja de Texto puede incluir una sarta de texto que indica el (los) servicios incapacitados y uno o más números de teléfono, direcciones de Internet, etc. para servicio de cliente. El valor de hoja Servidor AlertaID se puede usar por el UE para enviar un mensaje de alerta genérico de DM en cualquier momento que el SDoUE MO se modifica por un servidor de OMDA DM que es diferente del servidor indicado por el valor de hoja de Servidor de AlertaID. El Cuadro 2 es una definición de ejemplo de un mensaje de Alerta genérico de DM apropiado . Cuadro 2. Mensaje de alerta genérico de DM de Ejemplo <Alerta> <MmdlD>2</CmdID> >Dato>1226</Dato> <1 - Alerta genérico -> <Artículo>
<Fuente><LocURI>./SDoUE</LocURIx/Fuente> <Meta> <Tipo xmin="syncml rmetinf"> <Invertido-Dominio-Nombre : org.3gpp.SDoUE, cambiosrealizadosalerta </Tipo> <Formato xmin="syncml rmetinf">char</Formato </Meta> <Dato> CS-SMS incapacitado; Vodafone UK <!-El nodo/hoja modificado y estado; ID de servidor OMA DM que hizo el cambio -> </Dato> </Articulo> </Alerta> Se observará que el elemento de Tipo de un mensaje de alerta genérico de DM tal como aquel ilustrado en el Cuadro 2 se puede ajustar ventajosamente a "Reservado-Dominio-Nombre: org .3gpp . SDoUE, cambiosrealizadoslaerta" . También se observará, sin embargo, que los nombres y estructura particulares mostrados no son esenciales como técnicas descritas en esta aplicación se pueden implementar con otros nombres y estructuras de árbol.
Cunado el valor de hoja de IMS_L1amadas de Emergencia se ajusta a 1 y el UE detecta el cubrimiento por un PLMN (identificado por MCC y MNC) como se indica por cualquiera de los pares de nodos de País y Red almacenados, entonces el UE inicia un procedimiento de señalización para liberar todas las llamadas de emergencia a través de IMS. Además, el UE no usa procedimientos de IMS para establecer llamadas de emergencia hasta que el valor de hoja de IMS_Llamadas de Emergencia se ajusta a 0 o el Ue detecta un MCC y MNC que no coinciden con ninguno de los pares de nodos de País y Red almacenados. Un ejemplo de un marco de descripción de dispositivo (DDF) que implementa la estructura lógica arriba descrita de un SDoUE MO se proporciona abajo como Cuadro 3. El artesano entenderá que las particulares se pueden redisponer, añadir, omitir de, y renombrar en el DDF sin abandonar esta invención. El SDoUE MO ventajosamente es capaz de incapacitar y capacitar servicios mientras que el UE está ya sea en PLMN de casa (HPLMN) , que es el PLMN que mantiene la suscripción del UE, o en un PLMN visitado (VPLMN) . También es deseable para ambos el HPLMN y el VPLMN proporcionar una indicación al UE en cuando a cuales funciones el UE está o no permitido a
usar. Dos métodos alternativos de operar el UE y red se describen abajo. En el primer método, el SDoUE MO está completamente controlado por el operario de casa del usuario (HPLMN) y solamente el HPLMN puede incapacitar/capacitar los servicios en el UE. Este primer método se ilustra en la gráfica de flujo de la Figura 2 e incluye los siguientes pasos. El VPLMN, o el HPLMN para ese asunto, observa (paso 202) que uno o más actos de UEs repetidamente para solicitar servicios/conexiones a la red y (excepcionalmente) falla en detectarse e incapacitarse mediante medidas conservadores de capa de aplicación, es decir, el HPLMN o VPLMN observa un mal comportamiento de UE. Dependiendo de la arquitectura del HPLMN y VPLMN y de los servicios proporcionados, diferentes nodos de red están involucrados al observar un UE de mal comportamiento. Por ejemplo, para servicio basado en el dominio CS, un centro de conmutación móvil (MSC) , el registro de ubicación de visita (VLR) , y servidor de suscriptor de casa (HSS) usualmente estarían involucrados. Para servicios basados en PS, un nodo de soporte de GPRS de servicio (SGSN) usualmente está involucrado. Para IMS, se puede involucrar una función de llamada de servicio/control de sesión (S-CSCF) . De esta
manera, estos nodos de red, o procesadores más particularmente en dichos nodos, incluyen programación apropiada para detectar mal comportamiento de UE. Desde un punto de vista funcional, el mal comportamiento detectado puede ser reportado a un nodo de control de policía, que puede estar colocado con o integrado en un Servidor de DM, para acción apropiada. Una red que tiene dichas entidades se describe con mayor detalle abajo. Si el mal comportamiento es observado por un VPLMN, el VPLMN informa al HPLMN, v.gr., un centro de cuidado de cliente del HPLMN, del UE de mal comportamiento (paso 204) . Esta comunicación se puede llevar a cabo de diversas maneras, v.gr., a través de interfaces de servicio de Internet que conectan centros de cuidado de cliente del HPLMN y VPLMN. El centro de cuidado de cliente de HPLMN solicita al servidor 104 de DM de HPLMN que incapacite el servicio que se usa mal por el mal comportamiento de UE (paso 206) . El Servidor 104 de DM de HPLMN envía un mensaje apropiado, tal como un mensaje de sesión iniciada por notificación, al UE de mal comportamiento para establecer una sesión de manejo de DM hacia el UE de mal comportamiento (paso 208) . Los mensajes de sesión iniciada por notificación se describen, por ejemplo, en OMA TS-DM-Protocol-Vl_2-20060424-C. En la seción de manejo
establecida, el Servidor de Dm de HPLMN tiene acceso al SDo UE MO (paso 210), incapacitando el servicio mal usado ajustando el valor de parámetro apropiado en el SDoUE MO. Cuando un servicio o función se incapacita por un PLMN, una sarta de texto se muestra usualmente al usuario del UE que contiene formas de contactar un centro de cuidado de cliente apropiado a fin de obtener información acerca de, por ejemplo, el servicio/función incapacitado, ayuda con la determinación de la causa de no disponibilidad del servicio/función, y recapacitación del servicio/función. En el segundo método para operar un UE y red, el SDoUE MO se controla por el HPLMN, pero un VPLMN también puede incapacitar/capacitar servicios y de esta manera tener acceso y modificar el SDoUE MO. En este segundo método, la información necesaria para tener acceso al SDoUE MO se hace disponible al VPLMN para tener acceso e incapacitar/capacitar los servicios a un UE que navega en el VPLMN. La información necesaria para el VPLMN a tener acceso al UE y el SDoUE MO de preferencia está configurado en el UE por el HPLMN. La información que el HPLMN necdesita proporcionar en el UE para el VPLMN es un DM cuenta MO, que es de preferencia uno de los Objetos normalizados de OMDA DM descritos en OMA-TS-DM-StdObj -Vl_2-20060424-C, y la
conectividad necesaria (v.gr., una Conectividad MO necesitada9 para el Ue para conectarse al VPLMN, que también es de preferencia uno de los Objetos Normalizados de OMA DM. Se entenderá que "conectividad" aquí es la información de conectividad que el UE necesita a fin de ajustar una conectividad de IP hacia el Servidor de DM de HPLMN, v.gr., el nombre "telia-enlínea . se" como Nombre de Punto de Acceso (APN) cuando se conecta a través de GPRS a la red de Telia. La provisión de la información necesaria puede suceder en cualquier momento, v.gr., en la fabricación del UE, la primer vez que el UE se conecta, y cuando el UE navega hacia el VPLMN. El servidor OMA DM de HPLMN configura los derechos de acceso del UE de modo que parte del SeOUE MO es manejable por el VPLMN. El HPLMN, por ejemplo, puede usar el mecanismo ACL de OMA DM para definir cual VPLMN puede tener acceso al SDoUE MO. La información necesaria puede ser descargada en el UE a través de una sesión de manejo de DM establecida . El segundo método para operar un UE y un sistema de comunicación se ilustra en la gráfica de flujo de la Figura 3. en el paso 302, el VPLMN advierte un UE de mal comportamiento, justo como en el primer método ilustrado en la Figura 2. En el paso 304, el centro de cuidado de cliente
del VPLMN solicita al Servidor 104 de DM de VPLMN que incapacite el servicio que está mal usado por el Ue de mal comportamiento. El Servidor DM de VPLMN envía un mensaje apropiado, tal como un mensaje de sesión iniciada de notificación OMA, al UE de mal comportamiento para establecer una sesión dee manejo de DM hacia el UE de mal comportamiento (paso 306) . Si el UE acepta la solicitud de acceso para modificar el SDoUE MO, el VPLMN es capaz de capacitar/incapacitar funciones especificadas por los parámetros de SDoUE. La sesión de manejo establecido permite al Servidor DM 104 de VPLMN tener acceso al SDoUE MO para incapacitar el servicio mal usado (paso 308) . El HPLMN puede desear estar informado de cualquier cambio realizado al SDoUE MO del UE. En ese caso, el método incluye además notificar el HPLMN cuando un VPLMN ha hecho cambios al SDoUE MO (paso 310) . Por ejemplo, el UE de mal funcionamiento puede notificar al HPLMN que cambios a su SDoUE MO se han hecho enviando un mensaje de alerta genérico de DM al Servidor DM de HPLMN. El Servidor DM recibe la notificación, y como es usual, la Autoridad de DM decida qué hacer cuando dicha notificación llega. Se entenderá que el VPLMN, en lugar de o aún además del UE, puede notificar al HPLMN de cambios hechos en el SDoUE MO del UE, pero en este
momento no se especifica protocolo para este propósito. Para implementar el método ilustrado en la Figura 3, la estructura del SDoUE O ilustrado en el Cuadro 1 se debe modificar añadiendo un parámetro que contiene el identificador del Servidor DM 104 de HPLMN, al que el mensaje de alerta genérico de DM se envía cuando se cambia el SDoUE MO del UE. Se entenderá que el primero y segundo métodos incluyen particularidades que soportan aspectos de seguridad del SDoUE MO, v.gr., resistencia a ataque a hombre en la mitad. Actualmente, OMA DM usa seguridad de capa de transporte inalámbrica/capa de casquillos de seguridad versión 3 (WTLS/SSL3) con un mínimo de encripción de 128 bits y permite la implementación con más encripción segura y otras listas de cifra. El portador entre el Ue y el Servidor DM está normalmente a través de IP y el portador de GPRS (o Dominio PS) . De esta manera, en el caso cuando el servicio de GPRS y activación de contexto de PDP se incapacitan, el problema de activación de un contexto de PDP para comunicación de Servidor UE-DM se tiene que resolver. De conformidad con esta invención, el problema se resuelve viendo conceptualmente la activación como una solicitud de portador iniciada por red.
Los inventores han reconocido que SMS terminada en UE nunca necesita ser incapacitada y de esta manera OMDA DM puede usar el mecanismo de Empuje de protocolo de aplicación inalámbrica (WAP) para establecer al portador de GPRS necesitado para comunicación del Servidor UE-DM. La aplicación de Empuje WAP se deja disparar activaciones de contexto de PDP selectivamente, en particular a un Servidor DM, mientras que otras aplicaciones en el Ue se bloquean de solicitar activación de Contexto de PDP mediante la incapacitación del servicio de GPRS y activación de contexto de PDP. Se apreciará que un UE, por ejemplo, puede usar un MO de conectividad para ajustes independientes de aplicación para conectarse a una red WAP que proporcionaría información de conectividad que se relaciona con los parámetros y medios necesarios para tener acceso a la infraestructura WAP , incluyendo portadores de red, protocolos, direcciones de Punto de Acceso de Red (NAP) , y direcciones de representante. Un representante WAP es un punto de extremo para el protocolo de transporte inalámbrico (WTP) , el protocolo de sesión inalámbrica (WSP) , y el protocolo WTLS, así como un representante que es capaz de tener acceso al contenido de WAP. Un mandatario WAP puede tener funcionalidad de modo que, por ejemplo, un mandatario WSP o un mandatario de aplicación
de telefonía inalámbrica (WTA) . Un mandatario físico es una dirección específica con funcionalidad de mandatario, v.gr., una dirección de IP más portillo para un mandatario accesible por IP, y una dirección de entidad de mensaje corto (SME) más puerto para un mandatario accesible a través del SMS. Un mandatario lógico es un juego de mandatarios físicos que pueden compartir el mismo contexto WSP y WTLS (espacio de valor de identificación de sesión compartida) . De conformidad con las especificaciones de OMDA, un capacitador MO de Gonectividad maneja la dirección de conectividad de datos inalámbrica especificando un juego de esquemas de objeto de DM que se puede exponer por un Cliente de DM y se dirigan mediante un Servidor DM. Los esquemas de objeto tienen tres partes: un objeto de manejo de nivel superior que es portador-neutro; un juego de parámetros específicos de portador; y un subárbol para exponer parámetros específicos de vendedor. Los parámetros de conectividad enlazados usando Aprovisionamiento de Cliente (CP) se pueden dirigir subsecuentemente y manejar a través del Servidor DM, que pueden añadir nuevos mandatarios y NAPs usando un paquete DM normalizado. El aprovisionamiento es el proceso mediante el que un cliente, tal como un cliente WAP en un dispositivo, está configurado, y generalmente cubre
ambos, a través del aprovisionamiento de aire (OTA) y otro aprovisionamiento, v.gr., mediante una tarjeta SIM. Se apreciará que OMA DM necesita que el UE establezca un procedimiento GPRS SM originado por UE (v.gr., un contexto PDP) para permitir al Servidor OMA DM hacer contacto y configurar el SDoUE MO a fin de capacitar/incapacitar servicios. Como se describe en esta solicitud, el Ue se deja establecer un procedimiento GPRS SM originado por UE para ese caso. Además, cuando procedimientos GPRS originados por UE para contextos de PDP se incapacitane, el UE tiene que iniciar el procedimiento de señalización para desactivación del contexto PDP de todos los contextos PDP de conformidad con 3GPP TS 24.008 y el UE no se deja usar los procedimientos GPRS SM originados por Ue para contextos PDP hasta que los procedimientos GPRS SM originados por UE para contextos PDP se capacitane. El UE, sin embargo, se deja usar los procedimientos GPRS SM originados por UE para activación de contexto PDP en los siguientes caso: durante recibo de un mensaje de notificación de OMDA DM indicando que el UE iniciará una sesión OMDA DM al Servidor de OMDA DM que ajustó el valor de incapacitación de la hoja GPRS_SM_PDP; y cuando el procedimiento de activación de contexto
PDP originado por UE es necesario a fin ya sea de establecer una llamada de emergencia a través de IMS 8si el valor de IMS_Llamadas de Emergencia está ajustado a 0) o enviar un mensaje de alerta genérico OMDA DM. Otro ejemplo es el caso de llamadas de emergencia de CS e IMS. A fin de no incapacitar procedimientos de llamada de emergencia en regiones en donde se requiere el soporte, el operario de red puede indicar en cual país y/o re están incapacitados los procedimientos de control de llamada de emergencia. Los procedimientos de llamada de emergencia luego se pueden incapacitar hasta que se indique de otra manera o hasta que el UE determina que ha entrado a un país o red que no está indicado como incapacitado. Si los procedimientos de control de llamada de emergencia están incapacitados y el UE nuevamente recupera cubrimiento en un país o red indicado como incapacitado, la no disponibilidad del servicio de llamada de emergencia tomará efecto nuevamente. Los nodos de País y Red en el SDoUE MO, si están presentes, se pueden considerar un par de nodos, en donde MCC + MNC = operario de red, pero es posible indicar un pais/región ajusfando solamente el valor del nodo de País (v.gr., ajusfando MCC al valor numérico que indica Suecia) . De esta manera, la llamada de emergencia incapacitada será
efectiva en todo el país, Suecia. El comportamiento de la lógica en el UE ventajosamente sigue reglas tales como las siguientes cuando activaciones de contexto PDP originadas por Ue se han incapacitado pero el Ue se deja hacer una activación de Contexto PDP para uso de DM: 1. la particularidad se activa en un UE que se ha enlazado con y configurado por un Servidor de DM; 2. el Cliente DM del UE solicita activación de texto de PDP solamente cuando ha recibido una notificación de
OMA DM a través del mecanismo de Empuje WAP; y 3. la notificación de DM lleva la ID de Servidor de DM y un indicador de integridad de seguridad apropiado o clave, tal como una raya MD5. La Figura 4 es un diagrama de bloque de un UE 106 típico, que incluye un transceptor 402 que es apropiado para intercambiar señales de radio con estaciones de base (BSs) en una red (no mostrada en la Figura 4) . La información llevada por esas señales se maneja por un procesador 404, que puede incluir uno o más subprocesadores, y que ejecuta uno o más módulos de software y aplicaciones, incluyendo el SDoUE MO descrito en esta solicitud, para llevar a cabo las operaciones del UE 106 de conformidad con los MOs arriba
descritos. La entrada de usuario a la terminal se proporciona a través de un teclado u otro dispositivo, y la información presentada al usuario se proporciona a una presentación 406. Las aplicaciones de software se pueden almacenar en una memoria 408 de aplicación apropiada, y el dispositivo también puede descargar y/o ocultar información deseada en una memoria 410 apropiada. El dispositivo 106 también incluye una interfaz 412 que se puede usar para conectar otros componentes, tales como una computadora, teclado, etc., al UE 106. Para proteger contra activaciones de contexto PDP inapropiadamente disparadas por una aplicación mal operada, la implementación de la particularidad de incapacitación selectiva en el UE 106 puede emplear un control de puerta interna, que se ilustra por la Figtura 5. En la Figura 5, el software en un UE 106 se ilustra como separado en una parte de aplicación, que soporta un Cliente 502 de DM, y una parte de acceso, que soporta una funcionalidad 504 de SMS y una funcionalidad 506 de GPRS. El software en la aplicación y partes de acceso se pueden comunicar a través de APIs 508, 510. Un control 512 de puerta, que ventajosamente está implementado por una programación o lógica apropiada en ambos el SMS 504 y GPRS 506, opera de tal manera que una solicitud
de activación de contexto PDP que llega a un API 508, k 510 se envía solamente cuando una notificación de Empuje WAP apropiada se ha recibido previamente hacia el cliente 502 de DM. La puerta 512 puede usar la ID de aplicación en el mensaje de notificación de Empuja WAP como una clave. La puerta 512 se abre haciendo disponible la clave, y una solicitud de un contexto PDP del Cliente 502 de DM se acepta solamente si está disponible una clave en el GPRS 506 cuando la solicitud es recibida a través del API 510. Además de generar una clave, la funcionalidad de puerta puede incluir un cronómetro que limita la duración de la validez de la clave . La Figura 6 es una gráfica de flujo de un método de ejemplo para controlar la activación de contexto PDP usando la puerta 512 que se puede incluir en los métodos ilustrados en las Figuras 2 y 3. En el paso 602, una notificación de Empuje WAP llevada en un mensaje SMS es recibida por el SMS 504 de un Servidor 104 DM. Como se anotó arriba, la notificación de Empuje WAP incluye una ID de Aplicación apropiada, y en respuesta a la notificación (paso 604), la funcionalidad de puerta en el SMS 504 expide una clave, y opcionalmente se inicia un cronómetro. El Cliente 502 de DM recibe la notificación de Empuje WAP, y si es de un Servidor
DM autorizado, es decir, si tiene la ID apropiada, el Cliente 502 de DM solicita un contexto PDP de la funcionalidad 506 GPRS (paso 606) . El GPRS 506 acepta la solicitud del Cliente de DM si está disponible una clave (paso 608), e inicia un procedimiento de activación de contexto PDP (paso 610) . Se apreciará que la funcionalidad de la puerta 512 se puede implementar de muchas formas, por ejemplo mediante software incluido en el SMS 504 y/o el GPRS 506. Además de usar el SDoUE MO para proteger su capacidad de red contra comportamiento inapropiado por los UEs, los operarios de red pueden eonctrorar usos para el mismo. Por ejemplo, cuando un usuario final no ha pagado un servicio solicitado o se ha suscrit5o a un servicio y posteriormente a dejado de pagar por el servicio, un operario puede usar el SDoUE MO para incapacitar el software de UE o funcionalidad asociada con el servicio. Se entenderá que en un ambiente de OMA DM, la toma de decisión usualmente no se hace al nivel del Servidor de DM; el MA hace decisiones y luego los Servidores de DM llevan a cabo las operaciones. Un UE también puede tener varios Mas y Servidores de DM respectivos. Por ejemplo, un teléfono móvil se puede manejar por un MA de un operario de red inalámbrico a través de varios de los Servidor de OMA DM de
operario, y por un MA del empleador de usuario de teléfono a través de otros Servidores OMDA DM. El operario puede ser responsable por manejar la conectividad para la red de operario, incluyendo mantener una lista de navegación de los ajustes de navegación más baratos que es válida para la subscripción del usuario al operario. El empleador puede ser responsable de seguir y manejar todas las aplicaciones corporativas en el dispositivo. El usuario del teléfono también puede decidir, completamente desconocido a cualquiera de los Servidores OMA DM, descargar e instalar otro software en el dispositivo. La Figura 7 es un diagrama de bloque de un sistema 700 de comunicación que incluye una porción de una red 702 típica y un UE 106 que es capaz de tener sus servicios selectivamente incapacitados y capacitados con un SDoUE MO como se describe en esta solicitud. Se entenderá que muchas disposiciones de entidades de red distintas a aquella ilustrada en la Figura 7 se pueden usar, que un UE también puede conectarse a una red tal como el Internet a través de redes de área local inalámbrica (WLAN) tal como IEEE 802.11, Simas (IEEE 802.16), etc., y que el UE puede usar un 3GPP de intertrabajo WLAN. En la Figura 7, el UE 106 comunica con la red 702,
que típicamente incluye una red 704 de acceso de radio (RAN) , tal como una red 3GPP o GSM7EDGE, y entidades de red de núcleo, incluyendo un SGSN 706, un nodo 708 de soporte de GPRS de puerta (GGSN) , y un registro 710 de ubicación de casa (HLR) . El GGSN 70 se comunica con otras redes, tal como el Internet y un VPLMN, y otras entidades, tal como una infraestructura 712 WAP y un Servidor 104 de DM. La RAN 704 típicamente incluye una o más BSs y controladores de estaciones de base, o Nodo Bs y controladores de red de radio (RNCs) , que son convencionales. Los RNCs controlar varias funciones de red de radio, incluyendo por ejemplo instalación de contenedor de acceso de radio, diversidad de pasada entre BSs, etc. Más generalmente, cada RNC dirige llamadas a y desde un UE a través de las BSs apropiadas, que se comunican entre sí a través de canales de enlace descendente (es decir, base a móvil o adelante) y enlace ascendente (es decir, móvil a base o reversa) . Cada BS sirve un área geográfica que está dividida en una más células y típicamente está acoplada a su RNC correspondiente por líneas de teléfono dedicadas, enlaces de fibra óptica, enlaces de microonda, etc. Las entidades de núcleo-red (SGSN, GGSN, etc.) están adaptadas para manejar muchos tipos de datos. En una
red GSM/EDGE típica, los contextos PDP para administrar flujos de datos se establecen, o activan, en el GGSN 608 en respuesta a solicitudes del UE 106. Se entenderá que un UE también puede conectarse a la red a través de acceso WLAN. Para entendimiento más fácil, la red 702 se puede organizar basada en la funcionalidad hacia la capa o plano de control, una capa o plano de conectividad, y una capa o plano de aplicación, como se ilustra en la Figura 8. En esta ilustración, los UEs y redes de acceso de radio se ilustran mediante "nubes", y otras entidades de red se ilustran mediante otras nubes. Esta organización se describe con mayor detalle, v.gr., en H. Hameleers y col., "IP Technology in CDMA/GSM Core Networks", Ericsson Review No. 1, pág. 14-27 (2002) . La capa de control recibe servidores de control de red, tales como Servidores 104 DM, que incluyen procesadores programados, que está a cargo de llamada o establecimiento de sesión, modificación, y liberación. Los servidores de control también podrían manejar dirección de movilidad, seguridad, carga y funciones de intertrabajo que se relacionan con redes externas en el nivel de plano de control. La capa de conectividad recibe guiadores, interruptores, puertas de señalización, puertas de medios (MGWs) , y otras funciones de plano de usuario. Los guiadores e interruptores proporcionan
capacidades de transporte para tráfico sobre los planos de control y usuario. Los MG s facilitan el intertrabajo en el plano de usuario, incluyendo intertrabajo entre diferentes tecnologías de acceso de radio y formatos de medios. La interfaz entre la capa de control y la capa de conectividad consiste principalmente de protocolos de control de puerta. Los servidores de control de red usan estas interfaces para manipular recursos de MG en la capa de conectividad. La capa de aplicación, que se implementa como parte de la red de servicio, recibe servidores de aplicación y contenido. Hay dos interfaces entre la red de núcleo y la red de servicio: una interfaz horizontal y una interfaz vertical. La interfaz horizontal entre la red de núcleo y la red de servicio se refiere a modo de búsqueda-a-búsqueda regular o de cliente/servidor de operación para aplicaciones típicas de usuario final, tales como buscar en WEB, correo electrónico y servicios de audio/video. Estas aplicaciones son normalmente invocadas por un usuario final pero podrían también ser invocadas por un servidor de aplicación. La interfaz vertical permite que aplicaciones que residen en servidores de aplicación específicos complementen o modifiquen los procedimientos normales para establecer llamadas o sesiones a
través de la red de núcleo. Estas aplicaciones de intertrabajo con la red de núcleo a través de un juego de APIs normalizados. En el dominio CS, un centro de servicios móvil (MSC) , MSC de puerta (GMSC) y servidores de centro de conmutación de servicios en tránsito (TSC) son parte de la capa de control. Un MGW correspondiente pertenece a la capa de conectividad. En el dominio PS, ambos SGSN y el GGSN se pueden considerar que son parte de la capa de conectividad -contienen algo de funcionalidad de control - pero su funcionalidad dominante reside en proporcionar conectividad de IP. Con 3GPP, un "dominio" añadido a la red de núcleo móvil es el IMS, que tiene como entidades de red principales una función de control de llamada/sesión (CSCF) ; una función de control de puerta de medios 8MGCF) ; una función de control de puerta de rotura (BGCF) ; una parte de control de función de recurso de medios 8MRF) , o MRFC; una parte de procesamiento de MRF (MRFP) ; una puerta de medios (MG) y una puerta de señalización 8SG) . Una base de datos de suscriptor maestra, llamada el servidor de suscriptor de casa (HSS), es común al dominio CS, el dominio Ps y el IMS. Cuador 3. ejemplo de un DDF de un SDoUE MO <¿xmi versión= ! 2.0" codificación="UTF-8"?>
<!DOCTYPE MgmtTree PÚBLICO"-//OMA//DTD SYNCML-DMDDF 1.2//EN" http://www.openmovilealliance, org/tech/DTD/cm_ddf-v_l . dtd> <Arbol Mgmt> <VerDTD>l .2</VerDTD> <Hombre>-El fabricante de dispositivo—</Hombre> <Mod>—El dispositivo modelo—</Mod> <Nodo> <Nombre de Nodo>x<Nombre de Nodo> <Propiedades DF> <Tipo de Acceso> <Obtener/> </Tipo de Acceso> <Descripción>ajustes SDoUE</Descri8pción> <Fromato DF> <Ocurrencia> <Cero o Uno/> </Ocurrencia> <Titulo DF>E1 Ojbeto de Manejo de SDoUE . </TituloDFT> <Tipo de DF> <Nombre de DDF/> </Tipo de DF> </Propiedades de DF>
<Nodo> <Nombre de Nodo<Noiribre<Nombre de Nodo> <Propiedades DF> <Tipo de Acceso> <Obtener/> </Tipo de Acceso> <Formato DF> <chr/> </Formato DF> <Ocurrencia> <Cero o Uno/> </Ocurrencia> <Titulo DF> nombres mostrable de usuario para el nodo.</Título DF> <Tipo DF> <MIME>Texto/pano</MIME> </Tipo DF> </Propiedades DF> </Nodo> <Nodo> <Nombre Nodo>CS_Llamadas</Nombre Nodo> <Propiedades DF> <Tipo de Acceso
<Obtener/> </Tipo de Acceso> <Formato DF> <bool> </Formato DF> <Ocurrencia> <Cero o Uno/> </ocurrencia> <Título DF>Indicación de si móvil originó llamadas CS y capacitado . </Título DF> <Tipo DF> <MIME>texto/plano</MIME> </Tipo DF> </Propiedades DF> </Nodo> <Nodo> <Nombre Nodo>CS_Llamadas de Emergencia</NombreNodo> <Propiedades DF> <Tipo de Acceso <Obtener/> </Tipo de Acceso> </Formato DF> <bool>
</Formato DF> <Ocurrencia> <Cero o Uno/> </ocurrencia> </Título DF>Indicación de procedimientos de llamada de emergencia CS capacitados .</Título DF> <Tipo DF> <MIME>texto/plano</MIME> <Tipo DF> </Propiedades DF> <Nodo> <Nombre Nodox/Nombre Nodo> <Propiedades DF> <Tipo de Acceso> <Obtener/> </Tipo de acceso <Formato DF> <nodo/> </Formato DF> <Ocurrencia> <Cero o Más/> </Ocurrencia>
<Tipo de DF> <Nom re DDF><//Nombre DDF> </Tipo DF> </Propiedades DF> <Nodo> <Nombre Nodo>País</Nombre Nodo> <Propiedades DF> <Tipo de Acceso> <Obtener/Z </Tipo de Acceso <Formato DF> <chr/> </Formato DF> <Ocurrencia> <Uno/> <Ocurrencia> <Titulo DF> Un país o región cado por un Código de País móvil (MCC) ,<Título DFT> <Tipo DF> <MIME>texto/plano</MIME> </Tipo DF> </Propiedades DF> <Nodo>
(Nombre Nodo>Red</Nombre Nodo> <Propiedades DF> <Tipo de Acceso <Obtener/> </Tipo de Acceso> <Formato DF> <chr/> </Formato DF> <Ocurrencia> <Cero o Uno/> <Ocurrencia> <Titulo DFZUn código de red identificado por un Código de Red Móvil (MNC) , </TítuloDF> <Tipo DF> <MIME>testo/plano</MIME> </Tipo DF> </Nodo> </Nodo> </Nodo> </Nodo> zNombre Nodo>Servicios Suplementarios</Nombre
Nodo> <Propiedades DF>
<Tipo de Aceso> (Obtener/> </Tipo de Acceso <Formato DF> <Ocurrencia> <Título df>Indicación de si operaciones de servicio Suplementario originado en móvil están capacitadas .</Título DF> <Tipo DF> <MIME>Teto/plano</MIME> </Tipo DF> </Propiedades DF> </Nodo> <Nodo> <Nombre nodoZCS-SMS</Nombre Nodo> <Propiedades DF> <Tipo de Acceso> <0btener/> </Tipo de Acceso <Formato DF> <Ocurrencia> (bool> </Formato DF>
</Ocurrencia> <bool> </Ocurrencia> <Titulo DF>Indicación de si SMS originado través de CS está capacitado . </Título DF> <Tipo DF> <MIME>texto/plano</MIME> >/Tipo DF> </Propiedades DF> </Nodo> <Nodo> <Nombre Nodo>PS_SMS</Nombre de Nodo> <Propiedades DF> <Tipo de Acceso> <Obtener/> </Tipo de Acceso> <Formato DF> <bool> </Formato DF> <Ocurrencia> >Cero o Uno/> </Ocurrencia>
<Título DF>Indicación de si SMS originado en móvil a través de PS está capacitado . </Titulo DF> <Tipo de DF> <MIME>Texto/plano</MIME> <(To^p de DF> </Propiedades DFR> </Nodo> <Nodo> <Nombre Nodo>CA_LCS</Nombre Nodo> <Propiedades DF> <Tipo de Acceso> <Obtener/> </Tipo de Acceso> </Formato DF> (bool> </Formato DF> <Ocurrencia> <Cero o Uno/Z <Ocurrencia> <Titulo DF<Indicaci'ñonb de si LCS originada en móvil a través de CS está capacitada . z/Título DF> <Tipo DF>
<MIME>texto/plano</MIME> <Tipo DR> </Propiedades DF> </Nodo> <Nodo> <Nombre Nodo>PS_LCS</Nombre Nodo> <Propiedades DF> >Tipo de Acceso <0btener/> </Tipo de Acceso <Formato DF> >Cero o Uno/> <Ocurrencia> <Título DF>Indicación de si LCS originado en móvil a través de PS está capacitado . </Titulo DF> <Tipo DF> <MIMJE>texto/plano</MIME> c/Tipo DF> </Propiedades DF> </Nodo> <Nodo> <Nombre Nodo>GRPS SM PDP</Nombre Nodo>
<Propiedades DF> <Tipo de Acceso> <Obtener/> </Tipo de Acceso <Formato DF> <bool> <Formato DF> <Ocurrencia> <Xweo o Uno/> <Ocurrencia> <Titulo DF>Indicación de si procedimientos GPRS SM originado en móvil para contextos PDP están capacitados .</Título DF> <Tipo DF> <MIME>texto/plano</MIME> </Tipo DRT> z/Propiedades DF> </Nodo> <Nodo> <Nombre Nodo>IMS</Nombre Nodo> <Propiedades DFR> <Tipo de Acceso> <0btener/-<
</Tipo de Acceso <Formato DF> <Bool> </Formato DF> <Ocurrencia> <Cero o uno/Z <Ocurrencia> <Título DF>Indicación si procedimientos de IMS para enviar solicitud de registro de IMS están capacitadas .</Titulo DF> <Tipo DF> <MIME>testo/plano</MIME> </Tipo de DF> z/Propiedades DF> </Nodo> <Nodo> <Nombre Nodo>Texto</Nombre nodo> <Propiedades DF> <Tipo de Acceo> <Obtener/> </Tipo de Acceso <Formato DF> <chr>
<Formato DF> <Ocurrencia> <Cero o Uno/> </OcurrenciaZ <Título DF>Información para ser mostrada por el teléfono . </Título DF> <Tipo DF> <MIME>texto/plano</MIME> <Tipo DF> </Propiedades DF> </Nodo> <Nodo> <Nombre Nodo>Números Cuidado
Cliente</Nombre Nodo> <Propiedades DF> <Tipo de acceso> <0btener/> </Tipo de Acceso> <Formato DF> <chr/> </Formato DF> <Ocurrencia> <Cero o Uno/>
<Ocurrencia> <Título DF> Los números de cuidado cliete.</Título <Tipo DF> </Propiedades DF> <Nodo> >Nombre NodoXNombre Nodo> <Propiedades DF> <Tipo de Acceso <0bteher/> </tipo de Acceso <Formato DF> <Nodo /> </Formato DF> <Ocurrencia> <Uno o Más/> <Ocurrencia> <Tipo de DF> (Nombre DDFx/nombre DDF> </Tipo DR> </Propiedades DF> <Nodo>
<Nombre de nodo>Número de Servicio de Clientez</Nombre de nodo> <Propiedades DF> <Tipo de acceso <Obtener/> </Tipo de acceso> </Formato DF> <CHR /> </Formato DF> <Ocurrencia> <Uno /> </ocurrencia> </Título DFZUnh número de servicio de cuidado de cliente >/Título DF> c/tipo DF> <MIME>texto/plano</MIME> </Tipo DF> </Nodo> -/Nodo <Nodo> (Nombre Nodo>Servidor ID de alerta</Nomjbre
Nodo <Propiedades DPFZ <Tipo de Acceso
<Obtener/> </Tipo de Acceso </Formato DF> <Nodo/> >Formato DF> <Ocurrencia> <Cero o Uno/> <Ocurrencia> <Título DF<Un identificador de servido OMD DM para alertar .</Título DF> <Tipo DF> <MIME>texto/plano<MIME> </Tipo DF> </Nodo> <Nodo> <Nombre Nodo> IMS_Llamadas de Emergencia</Nombre
Nodo> <Propiedades DF> <Tipo de Acceso> <Obtener/> </Tipo de Acceso> <Formato DF> <bool>
</Formato DF> <Ocurrencia> <Cero o uno/> </Ocurrencia> <Título DF>Indicación de si procedimientos de llamada de emergencia a través de IMS están capacitados </Título DF> <Tipo DF> <MIME>texto/lano</MIME> </Tipo DF> </Propiedades DF> <Nodo> <Nombre Nodox/Nombre Nodo> <Propiedades DF> <Tipo de Acceso> <Obtener/> </Tipo de Acceso> <Formato DF> <nodo/> </Formato DF> <Ocurrencia> >Cero o Más/>
</Ocurrencia> <Tipo DF> >Nombre DFX/Noiabre DF> </Tipo DF> <Nodo> <Nombre Nodo>Pais</Nombre
Nodo> <Propiedades DF> <Obtener/< </Tipo de Acceso <Formato DF> <chr/> <Formato DF> <Ocurrencia> <Uno/> <Ocurrencia> <Titulo DF>Un pais o región identificada por un Código de Pais Móvil (MCC . </Fitulo DF> <Tipo DF> <MIME>texto/plano</MIME> </Tipo DF> </Propiedades DF> <Nodo>
<nom re Nodo>Red</Nombre
Nodo <Propiedades DF> <Tipo de Acceso> <Obtener/> </Tipo de Acceso> <Formato DF> <chr/> </Formato DF> <Ocurrencia> <Cero o Uno/> </Ocurrencia> <Título DF>Un código de red identifica por un Código de Red Móvil (MNC) </Titulo DF> <Tipo DF> <MIME>texto/plano</MIME> </Tipo DF> </Propiedades DF> </Nodo> </Nodo> </Nodo> </Nodo) <Nodo>
<Nombre nodo>Ext</nombre Nodo> <1- El nodo de Extensión inicia aquí -> <Propiedades DF> <Tipo de Acceso> <Obtener/> </Tipo de Acceso> <Formato DF> <nodo/> </Formato DF> <Ocurrencia> <Cero o Uno/> </Ocurrencia> <Titulo DF> Una colección de todos los objetos de Extensión </Titu71o DF> <Tipo DF> <Nombre DF/> </Tipo DF> >/Nodo> </Nodo> </árbol Mgmt> Se apreciará que un UE puede implementar las técnicas descritas en esta solicitud sin usar la estructura der árbol arriba descrit5a y DDF, que son meramente ejemplos
específicos que tienen nombres de nodo específicos, etc. El DDF de ejemplo es un formato legible por máquina, que se puede leer4 mediante herramientas apropiadasw que crean la estructura de árbol con poca ayuda adicional. Las implementaciones que usan diferentes nombres usarán diferentes DDFs. La invención aquí descrita se puede considerar que está moralizada completamente dentro de cualquier forma de medio de almacenamiento legible por computador que tiene almacenado en el mismo un juego apropiado de instrucciones para uso por o en conexión con un sistema de ejecución de instrucción, aparato, o dispositivo, tal como un sistema basado en computadora, sistema que contiene procesador, u otro sistema que puede sujetar instrucciones de un medio y ejecutar las instrucciones. Como se usa aquí, "un medio legible por computadora" puede ser cualquier medio que puede contener, almacenar, comunicar, propagar, o transportar el programa para uso por o en conexión con el sistema de ejecución de instrucción, aparato, o dispositivo. El medio legible por computadora puede ser por ejemplo pero no limitado a un sistema electrónico, magnético, óptico, electromagnético infrarrojo o semiconductor, aparato, dispositivo o medio de propagación. Ejemplos más específicos
(una lista no exhaustiva) del medio legible por computadora incluyen una conexión eléctrica que tiene uno o más alambres, un diskette de computadora portátil, una RAM, una ROM, y una memoria de lectura solamente programable borrable (EPROM o memoria Instantánea) . Se espera que esta invención se pueda implementar en una amplia variedad de ambientes, incluyendo por ejemplo dispositivos de comunicación móvil. También se apreciará que los procedimientos arriba descritos se lleva a cabo repetitivamente como sea necesario. Para facilitar el entendimiento, aspectos de la invención se describen en términos de secuencias de acciones que se pueden realizar, por ejemplo, por elementos de un sistema de computadora programable. Se reconocerá que varias acciones se podrían realizar por circuitos especializados 8v.gr., puertas lógicas discretas interconectadas para realizar una función especializada o circuitos integrados específicos de aplicación), mediante instrucciones de programa ejecutadas por uno o más procesadores, o mediante una combinación de ambos. De esta manera la invención se puede modalizar en muchas formas diferentes, no todas las cuales se describen arriba, y todas estas formas se contempla que están dentro
del alcance de la invención. Para cada uno de los diversos aspectos de la invención, cualquiera de estas formas puede referirse como una "lógica configurada para" realizar una acción descrita, o alternativamente como "lógica que" realiza una acción descrita. Se enfatiza que los términos "comprende" y "que comprende", cuando se usan en esta solicitud, especifican la presencia de particularidades, enteros pasos o componentes manifestados y no impiden la presencia o adición de una o más de otras particularidades, enteros, pasos, componentes o grupos de los mismos. Las modalidades particulares arriba descritas son meramente ilustrativas y no se deben considerar restrictivas en forma alguna. El alcance de la invención se determina mediante las siguientes reivindicaciones, y todas las variaciones y equivalentes que queden dentro de la escala de las reivindicaciones se pretende que queden abarcadas en las mismas .