PROCEDIMIENTO PARA GESTIONAR RECURSOS EN UNA PLATAFORMA PARA GESTIÓN DE SERVICIOS Y/O REDES DE TELECOMUNICACIÓN, PLATAFORMA CORRESPONDIENTE Y PRODUCTO DE PROGRAMA INFORMÁTICO ASOCIADO.

Un procedimiento para gestionar recursos en una plataforma para servicios y/o redes de telecomunicaciones,

incluyendo el procedimiento ejecutar agentes

CAMPO DE LA INVENCIÓN [0001] La presente invención se refiere a un procedimiento para gestionar recursos en una plataforma dirigida a gestionar redes y/o servicios de telecomunicación. En particular, la invención concierne a un procedimiento para asignar recursos en plataformas para gestión de redes y/o servicios de telecomunicaciones y una plataforma de gestión correspondiente.

ANTECEDENTES DE LA INVENCIÓN [0002] En el campo de las redes/servicios de comunicación, están provistas plataformas de gestión que incluyen una pluralidad de componentes como sistemas de soporte de operaciones (OSS) organizados en arquitecturas jerárquicas, a veces basados en agentes. [0003] El documento US6243396 desvela, por ejemplo, un sistema o plataforma de gestión de redes de comunicación que tiene una arquitectura jerárquica multicapa de autoridades de gestión interconectadas que controlan los recursos de la red de telecomunicación. Cada autoridad tiene un número de agentes responsables de la ejecución de procedimientos, que pueden ser agentes inteligentes o simplemente reactivos. En la arquitectura conocida, los agentes reactivos están ubicados dentro de una parte de plataforma de la autoridad y los agentes inteligentes están ubicados dentro de una parte controladora de la autoridad. Los agentes inteligentes y reactivos están agrupados en componentes funcionales para proporcionar funcionalidades FCAPS (Fallos, Configuración, Contabilidad, Rendimiento, Seguridad) a la plataforma. [0004] El documento WO01/02973 enseña el uso de una plataforma que comprende un coordinador de procesos centralizado para coordinación de agentes distribuidos, realizada típicamente con un motor de flujo de trabajo que ejecuta descripciones de flujo de trabajo (similares a organigramas) que comprenden delegación de trabajos a componentes (los agentes), recopilación de respuestas procedentes de los agentes, etcétera. [0005] El solicitante cree que las arquitecturas anteriores no aseguran que los agentes ejecuten trabajos delegados por el motor de flujo de trabajo. De hecho, los recursos informáticos disponibles para los agentes, como la potencia de computación, son limitados y no se supone que los recursos informáticos sean suficientes para adaptarse a los objetivos de negocio o la carga de trabajo solicitada a la plataforma.

En otras palabras, los recursos informáticos a disposición de los agentes pueden impedir alcanzar objetivos de negocio predeterminados que requieren que se realicen tareas, como por ejemplo el suministro de un servicio a un cliente, por los agentes. [0006] Por ejemplo, una tarea puede ser la finalización de un proceso determinado en un tiempo medio más corto que una duración de tiempo predefinida, o la finalización de un número determinado de procesos dentro de un plazo fijo. La enorme carga de trabajo sobre un agente puede impedir que el agente finalice la tarea en un tiempo medio predefinido o dentro del plazo fijo, haciendo, por lo tanto, que no se alcance el objetivo de negocio. [0007] Otro problema de la arquitectura basada en agentes que usa un coordinador de procesos centralizado, como la desvelada en el documento WO01/02973, es que el propio coordinador se convierte en un cuello de botella en el funcionamiento de la plataforma, y cuanto más lógica de proceso se externaliza de los agentes añadiendo flujos de trabajo al coordinador para mejorar la flexibilidad, más lento se vuelve el coordinador. Eso puede empeorar la capacidad de la arquitectura de hacer frente a los objetivos de rendimiento del negocio, como procesos con plazos para su ejecución. [0008] En el campo de la gestión de recursos informáticos, la solicitud de patente de EE.UU. nº 2003/0167270 desvela un sistema de gestión de recursos en un entorno distribuido compuesto por anfitriones que instancian copias de una aplicación escalable. El sistema de gestión de recursos genera señales para arrancar, parar o mover copias seleccionadas de una aplicación escalable a través de los anfitriones, basándose en información sobre copias de la aplicación y rendimiento del anfitrión. [0009] Esta clase de solución no es muy adecuada para una plataforma que comprende una arquitectura de agentes distribuidos coordinados por un coordinador de procesos o motor de flujo de trabajo por al menos las siguientes razones:

**(Ver fórmula)**

o aplicación urgente;

**(Ver fórmula)**

**(Ver fórmula)**

copias. [0010] El documento US2003/0036886 desvela un motor de monitorización y control para gestión de nivel de servicio multicapa de servidores de aplicaciones web distribuidos. El sitio web proporciona servicios a usuarios a través de Internet. Los objetivos de nivel de servicios del usuario final (SLOs) como la disponibilidad y rendimiento se miden y se informa de ellos a un agente SLO. El usuario solicita pasar por varias capas en el sitio web, como una capa de cortafuego, una capa de servidor web, una capa de servidor de aplicaciones, y una capa de servidor de base de datos. Cada capa tiene varios componentes de servicios redundantes que pueden procesar solicitudes para esa capa. Los agentes locales, operando con cualquier gestor de recursos local, monitorizan los componentes de servicios en ejecución e informan a un agente de servicio. Los monitores de nodos también monitorizan el estado de los nodos de la red e informan al agente de servicio. Cuando un componente de nodo o servicio falla, el agente de servicio intenta reiniciarlo usando el agente local, o replica el componente de servicio a otros nodos. Cuando el agente SLO determina que no se está cumpliendo un SLO, ordena al agente de servicio que replique más componentes de servicio limitadores o aumente los recursos. [0011] El documento US2003/0233391 desvela un procedimiento y sistema para asignar recursos informáticos. El procedimiento puede implementarse en instrucciones de software en un asignador de recursos que asigna recursos entre cargas de trabajo que operan en el sistema. Los parámetros que definen los objetivos de nivel de servicio para la ejecución de cargas de trabajo se reciben desde un dispositivo de entrada del usuario. Al menos uno de los objetivos de nivel de servicio es un tope de utilización que limita la asignación global de recursos del sistema entre las cargas de trabajo. Los parámetros incluyen prioridades para los objetivos de nivel de servicio, incluyendo el tope de utilización. Como las cargas de trabajo se ejecutan en el sistema, se reciben datos de utilización que indican el uso de recursos del sistema. Los recursos se asignan a las cargas de trabajo según las prioridades de los objetivos de nivel de servicio y basándose en los datos de utilización. RESUMEN DE LA INVENCIÓN [0012] El objeto de la presente invención es, por lo tanto, proporcionar un procedimiento para gestionar recursos de una plataforma basada en agentes para gestionar servicios y/o redes de telecomunicaciones, que mejore la eficiencia de la plataforma logrando el rendimiento óptimo en la utilización de recursos para satisfacer objetivos de negocio predeterminados.

Otro objeto de la invención es una plataforma de gestión que tenga una lógica de proceso descentralizada para lograr mejores rendimientos de la plataforma en tanto que mejorando su flexibilidad. [0014] Según la presente invención, estos objetos se logran por medio de un procedimiento para gestionar recursos en una plataforma para gestionar servicios y/o redes de telecomunicaciones así como por la plataforma de gestión que tiene las características a las que se hace referencia en las reivindicaciones independientes. [0015] Más objetos de la invención son un producto de programa informático o conjunto de programas informáticos, una red de telecomunicaciones y un procedimiento para la configuración y funcionamiento de una plataforma de gestión de telecomunicaciones tal como se reivindica. [0016] En resumen, para superar los inconvenientes de la técnica anterior, la invención desvela un procedimiento y una plataforma correspondiente basados en un mecanismo predictivo y adaptativo impulsado por indicadores (por ejemplo, indicadores de clave de negocio) y objetivos...

1. Un procedimiento para gestionar recursos en una plataforma para servicios y/o redes de telecomunicaciones, incluyendo el procedimiento ejecutar agentes distribuidos (A1, A2, A3), incluyendo dichos agentes motores de procesos (PE) para ejecutar procesos de gestión, estando el procedimiento caracterizado por:

- establecer datos objetivo a cumplir, en los que dichos datos objetivo incluyen objetivos en las ejecuciones del proceso por los agentes distribuidos y limitaciones a la utilización de recursos;

- monitorizar, por medio de dichos motores de procesos incluidos en dichos agentes distribuidos, las ejecuciones de procesos mediante los agentes distribuidos (A1, A2, A3) y la utilización de recursos,

- recoger datos de rendimiento representativos de dichas ejecuciones de procesos y de dicha utilización de recursos;

- comparar los datos de rendimiento recogidos con los datos objetivo establecidos,

- establecer al menos una cláusula de penalización en base a una comparación entre los datos de rendimiento recogidos de dichos agentes y los datos objetivo establecidos; y

- reasignar recursos a dichos agentes (A1, A2, A3) para ejecuciones de procesos por agentes (A1, A2, A3) en base a dicha al menos una cláusula de penalización establecida.

2. Un procedimiento según la reivindicación 1, en el que la etapa de reasignación de recursos incluye modificar las prioridades de procesos en los agentes distribuidos (A1, A2, A3).

3. Un procedimiento según la reivindicación 1, en el que la etapa de reasignación de recursos incluye

- ejecutar una etapa de evaluación y una etapa de decisión a intervalos de

observación determinados, en el que

- la etapa de evaluación comprende

- recoger datos representativos tanto de ejecuciones de procesos como del

número de ejecuciones de procesos previstas durante al menos uno de intervalos de observación posteriores, y

- evaluar, en base a dichos datos recogidos, los recursos requeridos por dichos agentes, y

- la etapa de decisión comprende -comparar los recursos requeridos con los recursos disponibles para cada uno de dichos agentes (A1, A2, A3), y

- aplicar determinadas reglas de asignación de recursos a dichos agentes (A1, A2, A3) para modificar la utilización de recursos entre los agentes (A1, A2, A3) y/o cambiar las prioridades de procesos en los agentes (A1, A2, A3) y/o reasignar ejecuciones de procesos entre los agentes (A1, A2, A3).

4. Un procedimiento según cualquiera de las reivindicaciones anteriores, caracterizado por almacenar descripciones de procesos representativas de procesos en una base de datos de descripciones de procesos (PDB) asociada a dichos motores de procesos (PE).

5. Un procedimiento según la reivindicación 4, en el que las descripciones de procesos incluyen flujos de trabajo y/o reglas.

6. Un procedimiento según cualquiera de las reivindicaciones anteriores, que incluye

- proporcionar los agentes (A1, A2, A3) en niveles jerárquicos según una configuración multicapa de los agentes (A1, A2, A3).

7. Un procedimiento según la reivindicación 6, en el que las ejecuciones de procesos se asignan a la configuración multicapa de los agentes (A1, A2, A3) mediante un módulo gestor centralizado (MM).

8. Un procedimiento según la reivindicación 7, en el que

- la etapa de recogida de datos de rendimiento comprende

- transmitir dichos datos de rendimiento al módulo gestor centralizado (MM) y/o a una pluralidad de agentes de control del rendimiento locales (CA) asociados a los agentes (A1, A2, A3).

9. Un procedimiento según la reivindicación 7, que incluye

- proporcionar al menos un agente maestro (MA) en la capa superior de dicha configuración multicapa de agentes (A1, A2, A3), asignando el agente maestro (MA) las ejecuciones de procesos a los agentes (A1, A2, A3) situados en sub-capas de dicha configuración multicapa.

10. Un procedimiento según cualquiera de las reivindicaciones anteriores, que comprende, para cada agente (A1, A2, A3), las etapas de

- insertar una petición de ejecución de procesos en una cola de procesos de prioridad multinivel (WFQ) según un criterio de prioridad;

- programar las ejecuciones de procesos en base a la cola de procesos de prioridad multinivel (WFQ).

11. Un procedimiento según la reivindicación 10, que incluye programar ejecuciones de procesos mediante al menos un hilo de motor de procesos (TH1,..., THn) asociado a cada agente.

12. Un procedimiento según la reivindicación 10, en el que las peticiones de ejecución de procesos en la cola de procesos de prioridad multinivel (WFQ) se actualizan en base a un criterio de expiración de temporización.

13. Un procedimiento según la reivindicación 8 y 11, en el que cada agente control (CA) controla el número de hilos de motor de procesos (TH1,..., THn) y la utilización de recursos por los agentes.

14. Un procedimiento según la reivindicación 8, en el que

- el agente de control (CA) ejecuta un algoritmo de equilibrado de carga para determinar la carga de los agentes; y

- cada agente (A1, A2, A3) envía peticiones de ejecución de procesos a otros agentes (A1, A2, A3) en base a un criterio, que incluye al menos una evaluación de la carga de los agentes según lo determinado por el agente de control (CA).

15. Una plataforma para gestionar recursos para servicios y/o redes de telecomunicaciones, que comprende

- una pluralidad de agentes distribuidos (A1, A2, A3) capaces de gestionar ejecuciones de procesos (WF1,..., WFn) en el que dichos motores de procesos (PE) incluidos en los agentes distribuidos están configurados para monitorizar las ejecuciones de procesos y la utilización de recursos por los agentes distribuidos (A1, A2, A3) y

- un módulo gestor centralizado (MM), configurado para

- establecer datos objetivo a cumplir por la plataforma, en los que dichos datos objetivo incluyen objetivos en las ejecuciones del proceso (WF1,..., WFn) por los agentes distribuidos y limitaciones a la utilización de recursos a cumplir por la plataforma;

- recoger datos de rendimiento representativos de dichas ejecuciones de procesos y de dicha utilización de recursos por los agentes distribuidos (A1, A2, A3);

- comparar los datos de rendimiento recogidos con los datos objetivo establecidos,

- establecer al menos una cláusula de penalización en base a una comparación entre los datos de rendimiento recogidos de dichos agentes y los datos objetivo establecidos; y

- reasignar recursos a dichos agentes (A1, A2, A3) para ejecuciones de procesos por agentes (A1, A2, A3) en base a dicha al menos una cláusula de penalización establecida.

16. Una plataforma según la reivindicación 15, caracterizada porque dicho módulo gestor centralizado (MM) comprende un módulo de asignación de recursos (RA) que incluye

- un módulo de evaluación configurado para

- recoger datos representativos tanto de ejecuciones de procesos como del número de ejecuciones de procesos previstas para un intervalo de observación posterior, y

- evaluar, en base a dichos datos recogidos, los recursos requeridos por dichos agentes, y

- un módulo de decisión configurado para

- comparar los recursos requeridos con los recursos disponibles para cada uno de dichos agentes (A1, A2, A3), y

- aplicar determinadas reglas de reasignación de recursos a dichos agentes (A1, A2, A3) para modificar la utilización de recursos entre los agentes (A1, A2, A3) y/o cambiar las prioridades de procesos en los agentes (A1, A2, A3) y/o reasignar ejecuciones de procesos entre los agentes (A1, A2, A3).

17. Una plataforma según la reivindicación 15 a 16, caracterizada porque dicho módulo gestor centralizado (MM) incluye

- una base de datos de descripción de procesos (PDB) para almacenar descripciones de procesos representativas de aspectos comportamentales y funcionales de la plataforma.

18. Una plataforma según la reivindicación 17, caracterizada porque dicho módulo gestor centralizado (MM) incluye además

- una Consola de creación de servicio (SCC) dispuesta para la definición, creación y modificación de las descripciones de procesos en la base de datos de descripción de procesos (PDB).

19. Una plataforma según la reivindicación 17, caracterizada porque las descripciones de procesos incluyen flujos de trabajo y/o reglas.

20. Una plataforma según la reivindicación 15 a 19, caracterizada porque

- dicha pluralidad de agentes distribuidos (A1, A2, A3) están organizados en niveles jerárquicos según una configuración multicapa, y porque

- dicho módulo gestor centralizado (MM) está configurado para asignar ejecuciones de procesos a dicha configuración multicapa de agentes.

21. Una plataforma según las reivindicaciones 15 a 20, caracterizada por

- agentes de control del rendimiento locales (CA) asociados a al menos un conjunto de agentes distribuidos (A1, A2, A3), y porque

- dichos motores de procesos (PE) incluyen módulos de monitorización de recursos (RM) configurados para

- transmitir dichos datos de rendimientos al módulo gestor centralizado (MM) y/o a los agentes de control del rendimiento locales (CA) asociados a los agentes (A1, A2, A3).

22. Una plataforma según la reivindicación 20, caracterizada por

- al menos un agente maestro (MA) situado en la capa superior de dicha configuración multicapa de agentes (A1, A2, A3) y configurado para asignar ejecuciones de procesos a agentes (A1, A2, A3) situados en sub-capas de dicha configuración multicapa.

23. Una plataforma según las reivindicaciones 15 a 22, caracterizada por

- al menos una máquina de procesamiento (H) que incluye al menos un conjunto de dicha pluralidad de agentes distribuidos (A1, A2, A3).

24. Una plataforma según la reivindicación 23, caracterizada porque al menos un agente de control del rendimiento local (CA) está asociado a dicha al menos una máquina de procesamiento (H).

25. Una plataforma según la reivindicación 24, caracterizada porque dicho al menos un agente de control del rendimiento local (CA) incluye:

- un módulo de monitorización del rendimiento local común (RM) dispuesto para recoger datos de rendimiento representativos de la utilización de recursos y la ejecución de procesos por los agentes (A1, A2, A3) y transmitir los datos de rendimiento al módulo gestor centralizado (MM);

- un controlador de hilos común (TC) acoplado al monitor de recursos (RM) dispuesto para crear hilos de motor de procesos (TH1,... , THn) para ejecutar procesos de espera (WF1,... , WFn); y

- un módulo despachador común (D) acoplado a los hilos de motor de procesos (TH1,..., THn) y dispuesto para enviar peticiones de ejecución de procesos a otros agentes (A1, A2, A3) según un algoritmo de equilibrado de carga predeterminado.

26. Una plataforma según la reivindicación 15, caracterizada porque el módulo gestor (MM) incluye

- un módulo de planificación de capacidad configurado para

- prever la disponibilidad de recursos en un intervalo de observación en base al rendimiento histórico y a datos representativos de la presente utilización de los recursos.

27. Una plataforma según la reivindicación 15, caracterizada porque el módulo gestor (MM) incluye

- una consola administrativa (AC) configurada para: -definir la configuración de hardware de la plataforma; y -definir limitaciones a las ejecuciones de procesos.

5 28. Una red de telecomunicaciones que incluye una plataforma según cualquiera de las reivindicaciones 15 a 27.

29. Producto de programa informático o conjunto de programas informáticos de productos de programas informáticos que pueden cargarse en la memoria de al

10 menos un ordenador y que comprende partes de código de software para realizar las etapas de cualquiera de las reivindicaciones 1 a 14.