ES2437067T3

ES2437067T3 - Módulo de aplicación y servidor de gestión remota con modelo de descripción de parámetros

Info

Publication number: ES2437067T3
Application number: ES07290579.7T
Authority: ES
Inventors: Werner Liekens; Christoph Stevens; Pascal Justen; Jan Coppens; Christele Bouchat; Willem Acke
Original assignee: Alcatel Lucent SAS
Current assignee: Alcatel Lucent SAS
Priority date: 2007-05-07
Filing date: 2007-05-07
Publication date: 2014-01-08
Anticipated expiration: 2027-05-07
Also published as: JP2010530149A; US20080282268A1; BRPI0811563A2; EP1990952A1; MX2009011560A; WO2008135279A1; KR20100027128A; US9148296B2; EP1990952B1; JP5343070B2; RU2495534C2; CN101304335B; RU2009145108A; IL201482A0; KR101469571B1; PL1990952T3; CN101304335A

Abstract

Un módulo (114) de aplicación, adaptado para ser remotamente instalado en un dispositivo (101) cliente y para serremotamente configurado desde un servidor (102) de gestión remota, comprendiendo para ello dicho módulo (114) deaplicaciones un modelo (120) paramétrico con al menos un parámetro (121) del modelo que puede ser comunicadoautomáticamente entre un cliente (113) de gestión remota que reside en dicho dispositivo (101) cliente y dicho servidor(102) de gestión remota, mediante un protocolo (103) de gestión remota, en el cual dicho protocolo (103) de gestión remota es el protocolo de gestión TR069; dicho cliente (113) de gestión remota comprende un agente de gestión de TR069 ejecutándose sobre una Máquina Virtual(111) de Java; dicho modelo (120) paramétrico es un modelo paramétrico de TR069, que comprende adicionalmente al menos unparámetro (122) de descripción, adaptado para describir formalmente dicho al menos un parámetro (121) del modelo ypara activar la creación automática de dicho al menos un parámetro (121) del modelo en dicho servidor (102) de gestiónremota.

Description

Módulo de aplicación y servidor de gestión remota con modelo de descripción de parámetros

Campo de la invención

La presente invención se refiere, en general, a la gestión remota, es decir, la instalación, configuración y eliminación de módulos de software de aplicaciones o servicios – los llamados “fajos” – en equipos de sedes de clientes (CPE), desde un servidor situado en cualquier parte en una red con conectividad hacia los dispositivos de los CPE. El servidor es denominado el servidor de auto-configuración o servidor de gestión remota en toda la extensión de esta solicitud de patente. Ejemplos de CPE o de dispositivos de clientes son un módem de Línea de Abonado Digital (DSL), un Equipo de Sobremesa (STB), un terminal inalámbrico tal como un teléfono móvil, un Asistente Digital Personal (PDA), etc. Más específicamente, la invención se refiere al aprendizaje del modelo paramétrico que forma parte, de manera inherente, de un fajo, o módulo de aplicación, recientemente instalado por el servidor de gestión remota.

Antecedentes de la invención

Los sistemas de gestión remota consisten en una plataforma de gestión en el dispositivo del cliente, un servidor de gestión remota en la red y un protocolo de gestión remota para la comunicación entre un cliente o agente de gestión que se ejecuta en la plataforma de gestión en el dispositivo del cliente y en el servidor de gestión remota.

Una plataforma de gestión ejemplar es la plataforma de servicio OSGi (iniciativa de Pasarela de Servicio Abierto), que es una plataforma de servicios basados en Java que se ejecuta sobre una Máquina Virtual de Java (JVM) dentro del dispositivo de cliente que está siendo gestionado en forma remota. La presencia de una plataforma de servicio OSGi en el dispositivo del cliente permite la instalación, actualización y / o eliminación remota de los fajos, es decir, módulos o componentes de software tales como, por ejemplo, una aplicación del Protocolo de Transferencia de Ficheros (FTP), desde un servidor de auto-configuración en cualquier parte de la red, sin perturbar el funcionamiento en el dispositivo del cliente. De esta manera, la instalación de una aplicación de software, la actualización de la aplicación de software a una nueva Versión, la reconfiguración de la aplicación, el agregado o activación de nuevas características de la aplicación y la eliminación de la aplicación del dispositivo del cliente se posibilitan sin despachar a un técnico a la sede del cliente, y sin requerir una intervención por parte del cliente. Gracias a la plataforma de gestión, los servicios o aplicaciones de software que se ejecutan en un único dispositivo del cliente pueden compartir sus capacidades entre sí.

El agente de gestión, o cliente de gestión, sirve como una interfaz entre el fajo o aplicación de software y el servidor de gestión remota, y permite que la plataforma de gestión en el dispositivo del cliente exhiba parámetros gestionables al servidor de gestión remota.

El papel del protocolo de gestión es proporcionar un mecanismo por el cual el servidor de auto-configuración pueda leer o escribir con seguridad valores paramétricos para configurar el software en el dispositivo del cliente y, eventualmente, monitorizar el estado y las estadísticas del dispositivo del cliente. Un protocolo de gestión ejemplar para la gestión remota segura de dispositivos de cliente es el protocolo TR-069 definido por el Foro DSL en su Informe Técnico TR-069, titulado “Protocolo de Gestión de redes WAN de CPE” que, por ejemplo, puede ser extraído en Internet mediante el siguiente URL (Localizador Uniforme de Recursos):

http://dslforum.org/aboutdsl/tr_table.html

El Protocolo TR-069 está basado en la Llamada a Procedimiento Remoto (RPC), es decir, un mecanismo genérico basado en mensajes, por el cual un servidor de auto-configuración es capaz de leer / escribir / configurar parámetros y atributos paramétricos de un componente de software que se ejecuta en un dispositivo de CPE. Cada parámetro consiste en un par de nombre y valor. El nombre identifica el parámetro específico y tiene una estructura jerárquica similar a la de los ficheros en un directorio, estando los distintos niveles separados por un “.” (punto). El valor de un parámetro puede ser uno de varios tipos de datos definidos. Cada parámetro puede además estar definido como un parámetro de solo lectura o de lectura-escritura, según que el servidor de auto-configuración esté autorizado solamente a leer el parámetro, o también a cambiar el valor del parámetro.

Un ejemplo específico podría ser un servicio o aplicación del Protocolo de Transferencia de HiperTexto (HTTP), que está instalado en un módem de ADSL o de VDSL para las comunicaciones entre cliente y servidor. Todos los parámetros de la aplicación del HTTP constituyen el modelo paramétrico de la aplicación del HTTP. Un parámetro ejemplar es el número o identificación del puerto donde la aplicación del HTTP está a la escucha. Se supone que el módem de ADSL o VDSL tiene una plataforma OSGi ejecutándose sobre una Máquina Virtual de Java. La plataforma OSGi permite compartir las capacidades de la aplicación del HTTP con otras aplicaciones, p. ej., un explorador de la Red. Mediante un agente de gestión del protocolo TR-069 instalado encima de la plataforma OSGi, los parámetros de la aplicación del HTTP pueden hacerse visibles y accesibles para un servidor de auto-configuración (ACS) en la red de DSL, o cualquier otro fajo al tanto del protocolo TR-069.

Para introducir nuevos parámetros del modelo al servidor de auto-configuración, p. ej., en la instalación de un nuevo fajo, la técnica anterior revela tres posibilidades.

Una primera solución posible para introducir un nuevo parámetro del modelo consiste en describir el parámetro mediante la estandarización. Los parámetros estandarizados del modelo son conocidos por los servidores de auto-configuración conformes al estándar y, en consecuencia, pueden ser descubiertos y cargados de manera autónoma desde el sector del cliente al sector del servidor, al instalar el nuevo fajo de software. Obviamente, la primera solución lleva tiempo y requiere consenso, y no es viable para nuevos parámetros del modelo no estandarizados o de propiedad industrial.

Una solución alternativa para introducir nuevos parámetros del modelo en el servidor de auto-configuración consiste en definir directamente estos nuevos parámetros del modelo, p. ej., en un fichero del lenguaje de marcado extendido (XML), y cargar manualmente el fichero de XML creado en el servidor de auto-configuración. La intervención manual de un operador, sin embargo, es propensa a errores, engorrosa y cara.

La tercera solución de la técnica anterior consiste en definir un nuevo atributo para el protocolo de gestión remota, p. ej., el protocolo TR-069, que sea un campo adicional para uno o varios mensajes, que permita transportar una descripción de parámetro, p. ej., un esquema del lenguaje de marcado extendido (XML) que define el nuevo parámetro, o los nuevos parámetros, del modelo, desde la interfaz de dirección norte del dispositivo de CPE hasta la interfaz de dirección sur del servidor de auto-configuración. Esta tercera solución de la técnica anterior ha sido descrita, por ejemplo, en la contribución dsi2006.873 de Christele Bouchat y Werner Liekens para la Especificación del Foro DSL TR69v2 o WT-148, que fue titulada “Introducir un nuevo atributo”, y presentada al Foro DSL en marzo de 2007. Aunque la última solución no requiere ya la intervención manual de un operador, es desventajosa en cuanto a que requiere la adaptación del protocolo de gestión de configuración. Ha de introducirse un atributo adicional, que nuevamente requiere consenso y estandarización. Incluso si se estandariza, la tercera solución plantea un problema de compatibilidad con servidores desplegados de autoconfiguración y aplicaciones de software existentes, que no prestan soporte al atributo adicional. Otro inconveniente de la tercera solución es su impacto negativo sobre las prestaciones de la configuración remota. En efecto, como resultado del atributo adicional, al menos dos mensajes han de ser comunicados entre el dispositivo del CPE y el servidor de autoconfiguración, a fin de introducir un nuevo parámetro del modelo al servidor. Primero, los nombres y valores de los parámetros son comunicados en respuesta, por ejemplo, a la instrucción GetParameterValues (ObtenerValoresParamétricos) del protocolo TR-069. A continuación, los atributos que incluyen el atributo que describe los nuevos parámetros son comunicados en respuesta, por ejemplo, a la instrucción GetParameterAttributes (ObtenerAtributosParamétricos) del protocolo TR-069.

El documento DE 20 2006 006 419 U1 y su equivalente US2007 / 147396 A1 revelan una solución para la conversión de tipos de servicio de dispositivos conectados con una pasarela de control. Un dispositivo posee información de descripción de dispositivos, y es operado en un primer tipo de servicio de dispositivo. Entre el dispositivo y una plataforma abierta se proporciona una pasarela de control, que aloja u obtiene la información de descripción de dispositivo del dispositivo, y entrega la información de descripción de dispositivo a una plataforma abierta. De esta manera, se resuelve el problema de la integración de diversos dispositivos conectados con, y controlados por, una pasarela de control en una plataforma de servicio abierto.

El Informe Técnico del Foro DSL TR-111 “Aplicación del protocolo TR-069 a la gestión remota de dispositivos en redes domésticas” (Diciembre de 2005) define, entre otras cosas, una extensión del protocolo TR-069 que permite a un ACS determinar la identidad de la pasarela a través de la cual está conectado un dispositivo dado. Por ejemplo, un ACS que establece la QoS (Calidad de Servicio) para un servicio específico puede necesitar proveer tanto el dispositivo como la pasarela a través de la cual está conectado ese dispositivo. El ACS tendría entonces que determinar la identidad de esa pasarela.

El documento “Requisitos de Gestión de Dispositivos – versión 1.2” de la Alianza Móvil Abierta (OMA) revela un conjunto de requisitos funcionales para la gestión de los parámetros modificables de un dispositivo, según se ven desde el punto de vista de la autoridad de gestión. No se pronuncia acerca del protocolo TR-069.

Es un objeto de la presente invención revelar un módulo (o fajo) de aplicación y un servidor de gestión remota (o ACS) que superan los inconvenientes de las soluciones de la técnica anterior, descritas en lo que antecede. En particular, es un objetivo revelar un módulo de aplicación y un servidor de gestión remota, capaces de descubrir nuevos parámetros del modelo no estandarizados de manera automatizada, que no requiere la adaptación del protocolo de gestión remota estandarizado, y que no afecta las prestaciones del mecanismo de gestión remota.

Resumen de la invención

Según la presente invención, los inconvenientes de la técnica anterior son superados, y los objetivos definidos anteriormente son realizados, por el módulo de aplicación definido en la reivindicación 1, que tiene un modelo paramétrico que comprende al menos un parámetro de descripción, adaptado para describir formalmente el nuevo parámetro del modelo y para activar la creación automática del nuevo parámetro del modelo en el servidor de gestión remota.

De tal modo, el modelo paramétrico de un fajo presenta parámetros adicionales que contienen una descripción formal de nuevos parámetros del modelo, p. ej., el nombre y tipo de un nuevo parámetro. Dado que la descripción forma parte de parámetros adicionales, no hay que definir ningún campo o atributo nuevo en el protocolo de gestión remota para comunicar la descripción del nuevo parámetro, o los nuevos parámetros, al servidor de gestión remota. Los parámetros adicionales, llamados parámetros de descripción en toda la extensión de esta solicitud de patente, serán comunicados automáticamente desde la interfaz de dirección norte del CPE hasta la interfaz de dirección sur del ACS en respuesta, por ejemplo, a la instrucción GetParameterValues (ObtenerValoresParamétricos) del protocolo TR-069, emitida por el ACS. Se supone adicionalmente que los parámetros de descripción activan dinámicamente la creación de los nuevos parámetros del modelo en el servidor de gestión remota. Al ser reconocido un nombre predefinido, o una parte predefinida del nombre de un parámetro de descripción, por parte del servidor de gestión remota, el servidor de gestión remota, por ejemplo, sabe que la información siguiente representará el nombre y tipo de un nuevo parámetro del modelo. El servidor de gestión remota, en otras palabras, aprende automáticamente la información que necesita para crear el nuevo parámetro del modelo a partir del parámetro, o parámetros, de descripción adjunto(s) que es / son comunicado(s) entre el CPE y el ACS, usando atributos o campos del protocolo existente. No se requiere ninguna estandarización ni intervención manual.

Además del módulo o fajo de aplicación definido por la reivindicación 1, la invención actual se refiere a un servidor de gestión remota, o ACS, según lo definido por la reivindicación 8, capaz de instalar y configurar remotamente un módulo de aplicación en un dispositivo del cliente, y que con el mismo comprende medios para recibir un modelo paramétrico con al menos un parámetro del modelo desde el módulo de aplicación, mediante un protocolo de gestión remota, medios para recibir uno o más parámetros de descripción que describen formalmente dicho al menos un parámetro del modelo, y medios para activar automáticamente la creación de dicho al menos un parámetro del modelo en el servidor de gestión remota, usando el parámetro, o parámetros, de descripción.

Una característica optativa del módulo de aplicación consiste en el hecho de que el parámetro, o parámetros, de descripción puede(n) ser parámetro(s) de solo lectura, según lo indicado por la reivindicación 2.

De esta manera, cuando sea realizada una auditoría por el servidor de gestión remota, recibirá toda la información necesaria para crear, analizar sintácticamente, almacenar y gestionar nuevos parámetros del modelo, pero el servidor de gestión remota no podrá cambiar la información contenida por los parámetros de descripción. Como consecuencia, se torna imposible dañar la información descriptiva que permite la creación de un parámetro del modelo.

Otro aspecto optativo del módulo de aplicación definido por la reivindicación 3 es que el parámetro, o los parámetros, de descripción comprende(n) un activador en su nombre, para activar la creación automática de los uno o más parámetros del modelo en el servidor de gestión remota.

De hecho, un nombre de parámetro predefinido, p. ej., “Parámetro.dinámico” o “Parámetro.de.descripción”, o una parte predefinida del nombre del parámetro, permitirá al servidor de gestión remota distinguir parámetros de descripción de parámetros del modelo cuando audite al cliente de gestión. Al reconocer el nombre de parámetro predefinido o la parte predefinida del nombre, el servidor de gestión remota sabe que la siguiente información incluirá información descriptiva que permite al servidor de gestión remota crear un nuevo parámetro del modelo.

Optativamente, según lo indicado por la reivindicación 4, la presencia de la palabra “Dinámico” en el nombre del parámetro puede activar la creación de un nuevo parámetro del modelo.

En efecto, si, por ejemplo, una aplicación de FTP es instalada en un dispositivo del CPE, puede ser necesario crear un nuevo parámetro del modelo, llamado “DispositivoPasarelaInternet.Servicio.FTP.url”. Con el mismo, la aplicación de FTP puede contener en su modelo paramétrico un parámetro de descripción con el nombre “DispositivoPasarelaInternet.Parámetro.Dinámico.1.Nombre” y, como valor, la cadena “DispositivoPasarelaInternet.Servicio.FTP.url”. En una auditoría por parte del servidor de gestión remota, éste último reconocerá la palabra “Dinámico” en el nombre del parámetro adicional y concluirá por ello que debe ser creado un nuevo parámetro del modelo con el nombre “DispositivoPasarelaInternet.Servicio.FTP.url”. Obviamente, cualquier otro nombre, o parte del nombre, predefinido, o cualquier otra convención que permita al servidor de gestión remota reconocer un parámetro de descripción es funcionalmente equivalente, y la invención actual no está restringida a una manera específica de distinguir parámetros de descripción de parámetros del modelo.

Otro aspecto optativo es que el parámetro, o los parámetros, de descripción puede(n) comprender un parámetro de nombre para describir el nombre de un nuevo parámetro del modelo. Este aspecto está definido en la reivindicación 5.

Adicionalmente, o alternativamente, el parámetro, o los parámetros, de descripción puede(n) comprender un parámetro de tipo para describir formalmente el tipo de un nuevo parámetro del modelo. Esto está indicado por la reivindicación 6.

Además, optativamente, el parámetro, o los parámetros, de descripción puede(n) comprender un parámetro de definición para definir formalmente un nuevo parámetro del modelo en un lenguaje humano. Esta opción está definida por la

reivindicación 7.

De tal modo, los ejemplos de parámetros de descripción que describen formalmente un nuevo parámetro del modelo son un parámetro de nombre, un parámetro de tipo y un parámetro de definición. Evidentemente, la invención actual no está restringida a una elección específica de un parámetro de descripción, o a un conjunto de parámetros de descripción. El conjunto de parámetros de descripción para nuevos parámetros del modelo puede tener la misma constitución para cada nuevo parámetro del modelo, p. ej., el nombre y el tipo, o bien puede tener una constitución distinta para nuevos parámetros distintos del modelo, p. ej., nombre y tipo para un primer parámetro nuevo del modelo, nombre, tipo y subtipo para un segundo parámetro nuevo del modelo, y nombre, tipo y descripción para un tercer parámetro nuevo del modelo, etc.

Como ya se ha mencionado en la parte introductoria de esta solicitud de patente, el Foro DSL ha definido en su Informe Técnico TR-069 un protocolo para la gestión remota, es decir, una manera de nombrar parámetros de una manera jerárquicamente estructurada, y una manera de leer / escribir de manera segura estos parámetros desde una ubicación remota en la red, a través de una secuencia de mensajes. Obviamente, el concepto de parámetros de descripción que describen formalmente nuevos parámetros del modelo y que activan automáticamente la creación de nuevos parámetros del modelo de ese tipo no está limitado a un protocolo específico de gestión remota, existente o futuro. Variantes de protocolos de gestión son, por ejemplo, el protocolo de Gestión de Dispositivos de la Alianza Móvil Abierta, OMA-DM, para dispositivos de clientes móviles, o el SNMP (Protocolo Sencillo de Gestión de Redes).

Breve descripción de los dibujos

La Fig. 1 ilustra una red que incluye una realización del servidor 102 de gestión remota según la presente invención, y un dispositivo 101 de cliente en el cual está instalada una realización del módulo 114 de aplicación según la presente invención; y

la Fig. 2 ilustra el modelo 120 de parámetros del módulo 114 de aplicación de la Fig. 1 en mayor detalle.

Descripción detallada de la(s) realización(es)

La Fig. 1 muestra un dispositivo 101 del CPE, p. ej., un módem de ADSL o VDSL, con conectividad 103, conforme al protocolo TR-069, con un servidor 102 de auto-configuración, situado en algún lugar en Internet. El dispositivo 101 del CPE tiene una plataforma OSGi 112, con el agente 113 de gestión del TR-069 ejecutándose sobre una Máquina Virtual 111 de Java. La Fig. 1 muestra además un módulo 114 de aplicación, p. ej., una aplicación de software cliente / servidor de FTP, que está instalada remotamente y gestionada mediante el agente 113 de gestión del TR-069. Al instalar, la aplicación 114 de software comparte por ello su modelo 120 paramétrico con el agente 113 de gestión del TR-069. Este modelo 120 paramétrico contiene los parámetros 121 del modelo y los parámetros 122 de descripción. Los parámetros 122 de descripción constituyen un modelo formal de descripción del protocolo TR-069 para describir los parámetros 121 del modelo del TR-069, según se explicará en los párrafos siguientes.

El modelo 120 paramétrico del TR-069 para la aplicación 113 de FTP, trazado en detalle en la Fig. 2, contiene tres parámetros del modelo y una descripción formal de los tres parámetros del modelo. La descripción formal adopta la forma de tres parámetros adicionales, que describen respectivamente el nombre, el tipo y la definición para cada uno de los parámetros del modelo.

Los tres parámetros del modelo de la aplicación 113 de FTP se llaman:

-: DispositivoPasarelaInternet.servicio.FTP.url

-: DispositivoPasarelaInternet.servicio.FTP.conexión

-: DispositivoPasarelaInternet.servicio.FTP.contraseña

El primer parámetro, DispositivoPasarelaInternet.servicio.FTP.url, contiene un URL (Localizador Universal de Recursos) que designa un fichero o un directorio en un anfitrión de Internet, accesible usando la aplicación FTP. La sintaxis de un tal URL del FTP está descrita en el documento IETF RFC 959. El segundo parámetro, DispositivoPasarelaInternet.servicio.FTP.conexión, contiene el nombre de conexión, o el nombre de usuario, que será usado por la aplicación FTP para acceder al anfitrión de Internet, y el tercer parámetro, DispositivoPasarelaInternet.servicio.FTP.contraseña, contiene la contraseña necesaria para acceder al anfitrión de Internet. En el ejemplo específico de la Fig. 2, estos tres parámetros, en la instalación de la aplicación FTP, tienen como valores iniciales las respectivas cadenas “FTP://host.dom/”, “minombre” y “micontraseña”.

Además, el modelo 113 paramétrico contiene, para cada uno de los anteriores parámetros del modelo, tres parámetros de descripción con nombres predefinidos, reconocibles por el servidor 102 de auto-configuración cuando se lleva a cabo una auditoría de parámetros. Los nombres predefinidos de los tres parámetros de descripción son:

-: DispositivoPasarelaInternet.Parámetro.Dinámico{i}.Nombre -DispositivoPasarelaInternet.Parámetro.Dinámico{i}.Tipo -DispositivoPasarelaInternet.Parámetro.Dinámico{i}.Definición En el presente documento, {i} representa el índice del parámetro del modelo al cual corresponde el parámetro de

descripción. En el ejemplo anterior, por ejemplo, puede suponerse que el índice del primer parámetro del modelo, DispositivoPasarelaInternet.servicio.FTP.url, es 1, el índice del segundo parámetro, DispositivoPasarelaInternet.servicio.FTP.conexión, es 2 y el índice del tercer parámetro, DispositivoPasarelaInternet.servicio.FTP.contraseña, es 3. El primero de los tres parámetros de descripción describe formalmente el nombre del nuevo parámetro del modelo a crear, el segundo de los tres parámetros de descripción describe formalmente el tipo del nuevo parámetro del modelo a crear y el tercero de los tres parámetros de descripción define el nuevo parámetro del modelo en lenguaje humano.

Para los tres parámetros del modelo de la aplicación 114 de FTP: -DispositivoPasarelaInternet.Servicio.FTP.url -DispositivoPasarelaInternet.Servicio.FTP.conexión -DispositivoPasarelaInternet.Servicio.FTP.contraseña el fajo 114 también implementa de tal modo los siguientes 9 parámetros de descripción: -DispositivoPasarelaInternet.Parámetro.Dinámico.1.Nombre, con el valor:

“DispositivoPasarelaInternet.Servicio.FTP.url”; -DispositivoPasarelaInternet.Parámetro.Dinámico.1.Tipo, con el valor: “Cadena”; -DispositivoPasarelaInternet.Parámetro.Dinámico.1.Definición, con el valor: “URL que designa el fichero o directorio de un anfitrión de Internet accesible usando la aplicación FTP.”; -DispositivoPasarelaInternet.Parámetro.Dinámico.2.Nombre, con el valor “DispositivoPasarelaInternet.Servicio.FTP.conexión”; -DispositivoPasarelaInternet.Parámetro.Dinámico.2.Tipo, con el valor: “Cadena”; -DispositivoPasarelaInternet.Parámetro.Dinámico.2.Definición, con el valor: “Nombre de conexión usado por la aplicación FTP para acceder al anfitrión de Internet.”; -DispositivoPasarelaInternet.Parámetro.Dinámico.3.Nombre, con el valor: “DispositivoPasarelaInternet.Servicio.FTP.contraseña”; -DispositivoPasarelaInternet.Parámetro.Dinámico.3.Tipo, con el valor: “Cadena”; y -DispositivoPasarelaInternet.Parámetro.Dinámico.3.Definición, con el valor: “Nombre de usuario usado por la aplicación FTP para acceder al anfitrión de Internet.”. Cuando el fajo 114 del FTP es descargado e instalado en el dispositivo 101 del CPE, el fajo 114 registra sus parámetros del TR-069 en el agente 113 de gestión del TR-069. En otras palabras, cuando el fajo 114 del FTP es descargado e instalado en la plataforma OSGi 112 dentro del dispositivo 101 del CPE, todo el modelo 120 paramétrico del TR-069 se

da a conocer al agente 113 de gestión del TR-069. Este agente 113 es por ello informado de que los siguientes parámetros del TR-069 disponen de soporte por parte de la aplicación 114 recién instalada: -DispositivoPasarelaInternet.servicio.FTP.url

-: DispositivoPasarelaInternet.servicio.FTP.conexión

-: DispositivoPasarelaInternet.servicio.FTP.contraseña

-: DispositivoPasarelaInternet.Parámetro.Dinámico.1.Nombre

-: DispositivoPasarelaInternet.Parámetro.Dinámico.1.Tipo

-: DispositivoPasarelaInternet.Parámetro.Dinámico.1.Definición

-: DispositivoPasarelaInternet.Parámetro.Dinámico.2.Nombre

-: DispositivoPasarelaInternet.Parámetro.Dinámico.2.Tipo

-: DispositivoPasarelaInternet.Parámetro.Dinámico.2.Definición

-: DispositivoPasarelaInternet.Parámetro.Dinámico.3.Nombre

-: DispositivoPasarelaInternet.Parámetro.Dinámico.3.Tipo

-: DispositivoPasarelaInternet.Parámetro.Dinámico.3.Definición

Cuando una auditoría es realizada por el servidor 102 de auto-configuración en el cliente 113 de gestión del TR-069, p. ej., emitiendo la instrucción GetParameterValues (ObtenerValoresParamétricos) del TR-069, el servidor 102 de autoconfiguración recibirá automáticamente todos los datos necesarios para crear / analizar sintácticamente / almacenar y gestionar los tres nuevos parámetros del modelo. En efecto, al recibir el primer parámetro del modelo, DispositivoPasarelaInternet.servicio.FTP.url, el servidor 102 de auto-configuración no reconocerá el nuevo parámetro del modelo y decidirá, por lo tanto, memorizar la información recibida. Al reconocer el nombre de parámetro predefinido del primer parámetro de descripción, DispositivoPasarelaInternet.Parámetro.Dinámico.1.Nombre, el servidor 102 de autoconfiguración sabe que la siguiente información incluye el nombre del parámetro recién definido y aprende esta información. De manera similar, al reconocer el nombre de parámetro predefinido DispositivoPasarelaInternet.Parámetro.Dinámico.1.Tipo, el servidor 102 de auto-configuración sabe que la siguiente información incluye el tipo del parámetro recién definido y aprende esta información. Por último, al reconocer el nombre de parámetro predefinido DispositivoPasarelaInternet.Parámetro.Dinámico.1.Definición, el servidor 102 de autoconfiguración sabe que la siguiente información incluye la definición en lenguaje humano del parámetro recién definido y aprende esta información. Con la información aprendida a partir de los valores de estos tres parámetros de descripción, el servidor de auto-configuración creará luego y analizará sintácticamente el nuevo parámetro del modelo DispositivoPasarelaInternet.servicio.FTP.url.

De manera similar a lo descrito en el párrafo precedente, el servidor 102 de auto-configuración aprenderá

automáticamente: la información que necesita para crear el segundo parámetro nuevo del modelo

DispositivoPasarelaInternet.servicio.FTP.conexión y: el tercer parámetro nuevo del modelo

DispositivoPasarelaInternet.servicio.FTP.contraseña.

Gracias a la presencia de los parámetros 122 de descripción en el modelo 120 paramétrico y a la inteligencia en el servidor 102 de auto-configuración para reconocer estos parámetros de descripción y activar la creación de los parámetros del modelo, usando la información aprendida a partir de los parámetros de descripción, no se necesita ninguna carga manual de ninguna descripción de parámetro en el servidor 102 de auto-configuración. En consecuencia, se evita la edición de cualquier fichero de descripción del modelo paramétrico en el lenguaje XML.

Dado que los parámetros de descripción son automáticamente transferidos en respuesta a una auditoría de parámetros del servidor 102 de auto-configuración, no se necesita ninguna carga adicional, como resultado de lo cual no se ven afectadas las prestaciones de la gestión remota. El ejemplo actual es además ventajoso en cuanto a que no se consume ninguna memoria adicional en el sector del cliente, y en cuanto a que no se necesita predefinir ningún campo nuevo en el protocolo TR-069 para comunicar la nueva información del fajo, es decir, los parámetros de descripción, desde la interfaz de dirección norte del dispositivo 101 del CPE a la interfaz de dirección sur del servidor 102 de auto-configuración.

Por ejemplo, el modelo de aplicación puede ser cualquier componente o paquete de software, tal como, por ejemplo, los Servicios de Http, la Conexión, la Gestión de Configuración, las Preferencias, el Análisis Sintáctico del XML, el Acceso a Dispositivos, la Administración de Paquetes, la Administración de Permisos, el Nivel de Inicio, la Administración de Usuarios, el Conector de Entrada / Salida, la Administración de Cables, Jini, el Exportador UPnP, el Rastreo de Aplicaciones, los Fajos Rubricados, los Servicios Declarativos, la Gestión de Energía, la Gestión de Dispositivos, las Políticas de Seguridad, Diagnósticos / Monitorización, Estructura de Capas del Entramado, etc. En otras palabras, se contempla abarcar todas y cada una de las modificaciones, variaciones y equivalentes que caigan dentro del espíritu y el alcance de los principios subyacentes básicos y cuyos atributos esenciales estén reivindicados en esta solicitud de

patente. El lector de esta solicitud de patente entenderá adicionalmente que las palabras “comprende” o “comprender” no excluyen otros elementos o etapas, que las palabras “un” o “uno” no excluyen una pluralidad y que un elemento único, tal como un sistema de ordenador, un procesador u otra unidad integrada, puede cumplir las funciones de varios medios enumerados en las reivindicaciones. Ningún signo de referencia en las reivindicaciones será interpretado como limitador

5 de las respectivas reivindicaciones en cuestión. Los términos “primero”, “segundo”, “tercero”, “a”, “b”, “c” y similares, cuando son usados en la descripción o en las reivindicaciones, son introducidos para distinguir entre elementos o etapas similares, y no están necesariamente describiendo un orden secuencial o cronológico. De manera similar, los términos “extremo superior”, “extremo inferior”, “sobre”, “debajo” y similares son introducidos con fines descriptivos y no necesariamente para indicar posiciones relativas.

Claims

REIVINDICACIONES

1. Un módulo (114) de aplicación, adaptado para ser remotamente instalado en un dispositivo (101) cliente y para ser remotamente configurado desde un servidor (102) de gestión remota, comprendiendo para ello dicho módulo (114) de aplicaciones un modelo (120) paramétrico con al menos un parámetro (121) del modelo que puede ser comunicado automáticamente entre un cliente (113) de gestión remota que reside en dicho dispositivo (101) cliente y dicho servidor

(102) de gestión remota, mediante un protocolo (103) de gestión remota,

en el cual dicho protocolo (103) de gestión remota es el protocolo de gestión TR069;

dicho cliente (113) de gestión remota comprende un agente de gestión de TR069 ejecutándose sobre una Máquina Virtual

(111) de Java;

dicho modelo (120) paramétrico es un modelo paramétrico de TR069, que comprende adicionalmente al menos un parámetro (122) de descripción, adaptado para describir formalmente dicho al menos un parámetro (121) del modelo y para activar la creación automática de dicho al menos un parámetro (121) del modelo en dicho servidor (102) de gestión remota.
2.

Un módulo (114) de aplicación según la reivindicación 1, caracterizado porque dicho al menos un parámetro (122) de descripción comprende al menos un parámetro de solo lectura.
3.

Un módulo (114) de aplicación según la reivindicación 1, caracterizado porque dicho al menos un parámetro (122) de descripción comprende un activador en su nombre, para activar la creación automática de dicho al menos un parámetro

(121) del modelo en dicho servidor (102) de gestión remota.
4.

Un módulo (114) de aplicación según la reivindicación 3, caracterizado porque dicho activador comprende la palabra “Dinámico”.
5.

Un módulo (114) de aplicación según la reivindicación 1, caracterizado porque dicho al menos un parámetro (122) de descripción comprende un parámetro de nombre (DispositivoPasarelaInternet.Parámetro.Dinámico.1.Nombre) para describir formalmente el nombre de dicho al menos un parámetro (121) del modelo.
6.

Un módulo (114) de aplicación según la reivindicación 1, caracterizado porque dicho al menos un parámetro (122) de descripción comprende un parámetro de tipo (DispositivoPasarelaInternet.Parámetro.Dinámico.1.Tipo) para describir formalmente el tipo de dicho al menos un parámetro (121) del modelo.
7.

Un modulo (114) de aplicación según la reivindicación 1, caracterizado porque dicho al menos un parámetro (122) de descripción comprende un parámetro de definición (DispositivoPasarelaInternet.Parámetro.Dinámico.1.Definición) para definir formalmente dicho al menos un parámetro (121) del modelo en un lenguaje humano.
8.

Un servidor (102) de gestión remota, adaptado para instalar y configurar un módulo (114) de aplicación en un dispositivo (101) cliente, que comprende un cliente (113) de gestión remota, comprendiendo dicho servidor (102) de gestión remota medios para recibir automáticamente un modelo (120) paramétrico con al menos un parámetro (121) del modelo desde dicho módulo (114) de aplicación, mediante un protocolo (103) de gestión remota,

en el cual dicho protocolo (103) de gestión remota es el protocolo de gestión remota TR069;

dicho cliente (113) de gestión remota comprende un agente de gestión TR069 ejecutándose sobre una Máquina Virtual

(111) de Java;

dicho modelo (120) paramétrico es un modelo paramétrico TR069;

y dicho servidor (102) de gestión remota comprende adicionalmente medios para recibir automáticamente al menos un parámetro (122) de descripción, adaptado para describir formalmente dicho al menos un parámetro (121) del modelo, y medios para activar automáticamente la creación de dicho al menos un parámetro (121) del modelo en dicho servidor

(102) de gestión remota, usando dicho al menos un parámetro (122) de descripción.