ES2265463T3 - Procedimiento de vigilancia de acuerdos de nivel de servicios. - Google Patents
Procedimiento de vigilancia de acuerdos de nivel de servicios. Download PDFInfo
- Publication number
- ES2265463T3 ES2265463T3 ES02006865T ES02006865T ES2265463T3 ES 2265463 T3 ES2265463 T3 ES 2265463T3 ES 02006865 T ES02006865 T ES 02006865T ES 02006865 T ES02006865 T ES 02006865T ES 2265463 T3 ES2265463 T3 ES 2265463T3
- Authority
- ES
- Spain
- Prior art keywords
- sla
- procedure
- events
- trouble
- event
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
- 238000000034 method Methods 0.000 title claims abstract description 53
- 238000012544 monitoring process Methods 0.000 title claims description 16
- 230000006378 damage Effects 0.000 claims abstract description 17
- 208000027418 Wounds and injury Diseases 0.000 claims description 14
- 208000014674 injury Diseases 0.000 claims description 14
- 230000008569 process Effects 0.000 claims description 8
- 238000009825 accumulation Methods 0.000 claims description 6
- 238000001514 detection method Methods 0.000 claims description 3
- 230000009466 transformation Effects 0.000 claims description 3
- 238000007726 management method Methods 0.000 description 15
- 238000012423 maintenance Methods 0.000 description 6
- 230000008439 repair process Effects 0.000 description 6
- 238000004891 communication Methods 0.000 description 3
- 238000001914 filtration Methods 0.000 description 3
- 238000009434 installation Methods 0.000 description 3
- 230000010354 integration Effects 0.000 description 3
- 230000004913 activation Effects 0.000 description 2
- 230000008859 change Effects 0.000 description 2
- 230000001419 dependent effect Effects 0.000 description 2
- 238000011156 evaluation Methods 0.000 description 2
- 230000003902 lesion Effects 0.000 description 2
- 238000012913 prioritisation Methods 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 1
- 230000015572 biosynthetic process Effects 0.000 description 1
- 230000000903 blocking effect Effects 0.000 description 1
- 238000012937 correction Methods 0.000 description 1
- 230000008878 coupling Effects 0.000 description 1
- 238000010168 coupling process Methods 0.000 description 1
- 238000005859 coupling reaction Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000004069 differentiation Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000005611 electricity Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 238000007689 inspection Methods 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 238000005259 measurement Methods 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
- H04L41/5003—Managing SLA; Interaction between SLA and QoS
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
- H04L41/5003—Managing SLA; Interaction between SLA and QoS
- H04L41/5009—Determining service level performance parameters or violations of service level contracts, e.g. violations of agreed response time or mean time between failures [MTBF]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
- H04L41/5032—Generating service level reports
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
- H04L43/0817—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0852—Delays
- H04L43/0864—Round trip delays
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0876—Network utilisation, e.g. volume of load or congestion level
- H04L43/0894—Packet rate
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/16—Threshold monitoring
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Alarm Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Debugging And Monitoring (AREA)
- Computer And Data Communications (AREA)
Abstract
Procedimiento de vigilancia de acuerdos de nivel de servicio SLA que incluye las etapas del procedimiento: A Seguimiento de una base de datos (DB1, DB2) con datos específicos del SLA; ¿ Detección (31) y memorización de los acontecimientos relevantes para el SLA; C Comparación de los acontecimientos memorizados relevantes para los SLA, con los datos informados a los SLA almacenados en la base de datos (DB1, DB2) y generación en todos los casos de un informe a partir de los resultados de la comparación; caracterizado porque, ¿ de un primer acontecimiento (EV, Ev1, Ev2) almacenado relevante para los SLA se genera un Trouble Ticket (TT1, Serv_T, Netw_T) y dependiendo de los acontecimientos (Ev1, Ev2) se ponen en un estado activo; ¿ por otro acontecimiento (Ev, Ev1) se desplaza un Trouble Ticket (TT1, Serv_T, Netw_T) a un estado inactivo; C¿ en la etapa del procedimiento C se acumula (SAL_Acc) la duración del estado activo del Trouble Tickets (TT1, Serv_T, Netw_T) y se comparan con al menos unode los límites de lesión (SLA_Viol); F en caso de sobrepasar (41) los limites de lesión (SLA_Viol) antes mencionados, se genera una notificación (36).
Description
Procedimiento de vigilancia de acuerdos de nivel
de servicios.
La presente invención se refiere a un
procedimiento de vigilancia de acuerdos de nivel de servicios, según
el preámbulo de la reivindicación 1, así como a un sistema según la
reivindicación 11.
Los acuerdos de nivel de servicios en la mayor
parte de los casos, se limitan a servicios y elementos de red, en
lo relativo a un operador frente a los clientes. Los fundamentos de
la conformación y vigilancia de los acuerdos de nivel de servicios
(en lo sucesivo se abreviará con las siglas SLA) se toman por
ejemplo del manual de dirección SLA [1] de los foros de
telegestión. En lo sucesivo para evitar imprecisiones, se usará allí
donde sea necesario, la nomenclatura en lengua inglesa. Así se usan
los conceptos Network Trouble Ticket y Service Trouble Ticket de
manera homogénea en lengua inglesa y en el preámbulo se resumen como
Ticket o Trouble Ticket o Problem Ticket.
En WO 98 / 42102 A1 (CROSSKEYS SYSTEMS
CORPORATION) se pone de manifiesto, para una red de datos, un
procedimiento de vigilancia de SLA, en el que con una base de datos
con el uso de un modelo de objeto con los datos referentes a SLA,
para la ejecución del procedimiento se prevén los siguientes
pasos:
- (a)
- Seguimiento de la base de datos con los datos del SLA referentes a los clientes;
- (b)
- obtención de los datos contenidos en las características sobre el Performance de las redes que tienen que ser vigiladas;
- (c)
- comparación continuada con los datos almacenados en la base de datos del SLA;
- (d)
- generación opcional de un informe de los datos precitados y de la comparación que contienen los Performance Levels para los clientes individuales frente a las obligaciones contraídas en el SLA
En WO 99 / 25085 (VISUAL NETWORKS) se propone un
procedimiento y un sistema, en el que mediante las llamadas pruebas
entre dos puntos finales de una red de conmutación de circuitos, se
mide la Network Performance, en particular mediante las métricas
"round-trip-delay" ( RTD) y
"data delivery ratio" (DDR). De esta manera se pueden medir
datos de medición individuales en lo que se refiere a vías de
comunicación pertenecientes a un punto final.
Los SLA, no sólo se limitan a lo referente al
denominado Performance sino también para otros objetos (por
ejemplo, para un servicio o una prestación de servicios) con los
clientes, como por ejemplo:
- -
- Disponibilidad (Availability) de una red o de un elemento de red;
- -
- Servicio de encargo (Service Provisioning).
Bajo la noción "Servicio de encargo" se
incluye por ejemplo el acoplamiento de una distancia o una potencia
concreta.
El objeto del SLA es por regla general una
notificación (Notifikation) de un cliente, cuando el correspondiente
SLA se lesiona. Con el concepto "cliente" no se refiere
necesariamente a un cliente de una empresa, sino también a un
centro, al que se le encarga para el mantenimiento de un concreto
SLA`s. Las soluciones mencionadas anteriormente sobre el estado de
la técnica, muestran las desventajas de que ellas son siempre de una
forma continua dependientes tecnológicamente y contienen siempre
sólo un objeto que se limita a lo referente al SLA. Se tiene que
entender como objeto en este contexto, por ejemplo un servicio o
una prestación de servicio; en concreto se trata aquí por ejemplo
de Fault Management, Performance Management o de un encargo de
servicio. Al mismo tiempo como se mencionó esta la desventaja
inmanente de que la monitorización, en lo que se refiere al SLA's,
se contenía siempre sólo para tal servicio o tal prestación de
servicios.
La presente invención tiene por objeto proponer
un procedimiento para la vigilancia de acuerdos de nivel de
servicios SLA, que es independiente tecnológicamente y homogéneo, de
manera que su aplicación tampoco permanezca limitada al campo de la
telecomunicación.
Este objetivo se resuelve conforme a la
invención, a través del procedimiento indicado en la reivindicación
de la patente 1 y por el sistema expuesto en la reivindicación 11.
Otras realizaciones ventajosas de la invención están indicadas en
otras reivindicaciones.
Por la generación de Trouble tickets por
cualquier acontecimiento y la acumulación selectiva de la duración
de los estados activos de un Trouble Tickets, puede el SLA`s ser
vigilado de maneras muy diferentes, con lo que el SLA`s se
compatibiliza con cualquier servicio, prestaciones de servicios y o
los elementos de red pertenecientes a los que pueda extenderse. Es
esencial que todos los acontecimientos sean acontecimientos que con
respecto a un SLA influencien la disponibilidad o calidad de unos
servicios o de unas prestaciones de servicios, se contemplen o bien
como acontecimiento inicial o como acontecimiento final y se
supervisan con Trouble Tickets. El procedimiento conforme a la
invención permite por ejemplo, que una
disponibilidad-SLA
(Availability-SLA) con el límite "mejor que
99%", un Performance-SLA con el límite
"aplazamiento menor que 85 ms" y una
Provisioning-SLA con el límite "primera puesta en
servicio dentro de 7 días después del cierre del contrato", se
vigilen en el procedimiento de forma homogénea.
Dado que,
en la etapa del procedimiento D los
acontecimientos tienen un origen técnico y no técnico, no se hace
ninguna diferenciación del manejo del SAL`s en lo que se refiere al
objeto y origen del evento requerido (reivindicación de la patente
2).
Caracterizado porque,
en la etapa del procedimiento D los
acontecimientos antes de la generación de un Trouble Tickets y
conforme a ello también los Trouble Tickets se clasifican y que en
la etapa del procedimiento C' la acumulación de la duración se
efectúa de manera dependiente de la pertenencia a una clase,
pueden ser vigilados los SLA's desde el punto de
vista del que ofrece el servicio, de maneras tan diferentes que la
"aportación negativo" que no es responsabilidad del que ofrece
el servicio, se puede reconocer, sin que el procedimiento se deba
cambiar en algo. Estas "aportaciones negativas" no conducen sin
embargo a una "sanción" del que ofrece el servicio
(reivindicación de la patente 3).
Dado que,
en la etapa del procedimiento E siguiente un
Touble Ticket situado en estado inactivo por un acontecimiento
reiterado se traslada al estado activo,
en el funcionamiento para un Touble Ticket
determinado pueden ser fijados el tiempo de expulsión o la ventana
de mantenimiento, sin que el que ofrece el servicio para su
rendimiento en una ventana de mantenimiento manual posteriormente
deba efectuar la corrección. Por lo tanto esto es ventajoso, porque
los trabajos de mantenimiento, normalmente con una generación
masiva de consecuencias, tienen para su continuación el perjuicio de
la masiva disponibilidad en un marco de tiempo en cuestión, por
ejemplo por desconexión de un trayecto (reivindicación de la
patente 5).
Dado que,
para la transformación a un estado inactivo de
unos datos Trouble Tickets, se deben consultar en una lista de
correspondencias y/o en la base de datos;
no experimentará el procedimiento ningún cambio,
cuando se introducen nuevos SLA'S o una nueva vinculación de
servicios- y objetos concretos, como por ejemplo puertos adicionales
(reivindicación de la patente 7).
Un ejemplo de realización de la invención se
explica a continuación por medio de los dibujos adjuntos. En ellos
se muestran:
Figura 1 Representación general para la
vigilancia de los SLA's;
Figura 2a, 2b, 2c el Trouble Tickets acoplado
al concepto del acontecimiento;
Figura 3 concepto en tres capas;
Figura 4 vigilancia del SLA con Trouble Tickets
pertenecientes a dos clases.
La figura 1, muestra un plano sinóptico de los
diferentes componentes para la supervisión de los SLA's. De las
redes diferentes o elementos de red como IP, SDH, etc., conforme a
la figura 1, provienen acontecimientos (en el lenguaje técnico se
denominan Event), que en las unidades del Service Activation S_Act,
Fault Management FM y Performance Management PM, se someten a una
primera evaluación y clasificación. La anotación de SLA y el
seguimiento de SLA de los acontecimientos ocurridos se juntan en el
denominado SLA- Monitoring. Conforme al estado de la técnica, estos
se ponían alguna vez en práctica de manera separada para el Fault
Management, Performance Management y para un encargo de servicios.
Consustancial a la invención se prevé ahora un proceso
SLA-Monitoring extensible, en el que junto con la
unidad de Service Assurance S_Ass se registra el conjunto de los
servicios y de las prestaciones de servicios referentes a uno o más
SLA's, se supervisa y mediante la notificación se informa a los
clientes. Este proceso de SLA-Monitoring común
abarca en esta forma de ejecución, junto con la unidad S_Ass, las
unidades mencionadas anteriormente S-Act, FM y PM
(como en la figura 1).De ser lesionadas una o más SLA's, se dará
del lugar CRN, una información preactiva sobre la lesión.
Paralelamente a esto se puede informar, en el punto de compensación
Bill, que la lesión del SLA en cuestión se dirige a una
descarga.
Para la generación (también denominada kreation)
del Trouble Tickets se toman como referencia las figuras 2a hasta
2c. Un Trouble Ticket TT (también denominado Problem Ticket) se
genera siempre a causa de unos acontecimientos. Un Trouble Ticket
TT contiene la descripción de un problema técnico o de una avería o
la admisión de un aviso de avería. Especialmente en caso de avisos
de avería registrados mediante el Trouble Tickets TT, se tiene que
tener en cuenta, que ahí no va también necesariamente unido un
problema técnico o administrativo. En la figura 2a está
representada la generación de un Trouble Tickets TT por la
Provisioning Events con las señales de referencia 22 se designa la
Terminal como "instalaciones ejecutadas". Se tiene que entender
por Provisioning cualquier prestación de servicios con un cliente,
que se puede producir en el lugar o también desde lejos. Esta
prestación de servicios con el concepto "instalación"
correspondiente se abarca de manera muy amplia. En la figura 2b
está representada la creación de dos Trouble Tickets TT1 y TT2
diferentes, que se atribuyen a Fault Events. La ordenada de las
figuras 2a y 2b no tiene ningún sentido métrico. En la figura 2c
esta representado el origen del Performance Events, es decir lo que
sobrepasa / queda por debajo de un Performance Levels. En la
representación gráfica se encuentra por ejemplo, para la tasa de
error Bit, en una representación inversa de la curva se podría, en
caso de tener el mismo significado los Events expuestos para la
creación de un Trouble Tickets TT, tomar como ejemplo el ancho de
banda de un enlace de vía. Otro ejemplo de un Performance Events es
la disponibilidad porcentual del puente de una central de
conmutación, esta disponibilidad es una función del tiempo. Común a
estos Events es que un Trouble Ticket TT se crea y permanece en una
forma activa, hasta que otro Event conduce al Ticket TT respectivo
a un estado inactivo. Es importante para una valoración posterior,
que los Trouble Tickets TT no desaparezcan como tales, sino que
estén en reposo o inactivos. En este método de inspección existen
realmente los Trouble Tickets TT1 y TT2 durante el tiempo indicado,
pero no en un estado activo.
La arquitectura de este proceso de
SLA-Monitoring común, esta en la figura 3
representado con una concepción en tres capas. Las tres capas
abarcan la elaboración de acontecimientos Filt_Corr (en el lenguaje
técnico denominado Event Processing), el Trouble Ticketing Meth_TT y
el SLA-Monitoring SLA_Moni. Conforme a ello están
resaltadas en la figura 3 ambas capas, la del servicio Level
Serv_lev y la del objeto Level Obj_Lev, por una línea de
limitación. Los acontecimientos Perf-Ev, Fa_Ev y
Prov_Ev, del que provienen conforme a la figura las unidades
Performance Management PM, Fault Management FM y Procisioning
Managemet Prov_M, se conducen por una correlación de acontecimientos
31 sobre la filtración de acontecimientos y la correlación de
acontecimientos Filt_corr de los denominados Trouble Ticketing
Meth_TT. De estos acontecimientos se generan juntos, con ayuda de
una tabla de correspondencias del objeto y del servicio 39, los
servicios- referidos Trouble Tickets Serv_ T o bien los Trouble
tickets ya generados, en particular los Network Tickets NetW_T se
conducen a un estado inactivo por los acontecimientos del filtro de
acontecimientos y en la correlación de acontecimientos Filt_Corr.
Este procedimiento 32 conduce a la creación de los Trouble Tickets
referidos al objeto (denominados también Problem Ticket) Netw_T. En
este ejemplo de realización, están los Tickets referidos al objeto
denominados Network Trouble Tickets, que con referencia también a la
figura 1 en la cual están representadas las distintas redes y
elementos de red ATM, SDH, etc. La generación de los Service Trouble
Tickets Serv_T antes mencionados, tienen lugar con los procesos 34
de los Network Trouble Tickets Netw_T y de la tabla de
correspondencias de los objetos y de los servicios 39.Los servicios
Truouble Tickets Serv_T se pueden generar también de forma manual
por una detección de las reclamaciones de los clientes sobre el
procedimiento 37. De una valoración de los servicios Trouble
Tickets Serv_T se lleva a cabo sobre los procedimientos 38 y 33,
una generación / transmisión de una aplicación de la reparación en
un centro de reparación Rep_C.
Las distintas clasificaciones relativas a la
priorización y a la prioridad, se visualizan en la representación
de la siguiente tabla 1. Com "Core node" se designa un nodo de
red, "Edge router" que está puesto para un Router al que
ofrece el servicio, "Customer modem" que está puesto para un
servicio periférico en el consumidor final. Con "SLA usage" se
designa el (negativo) desgaste relativo de unos SLA's.
| Vista de la red | Vista de los clientes | Vista del SLA | |||
| Prio | Problema | Prio | Problema | Prio | Problema |
| SLA usage: 50% | |||||
| 1 | 3 | Operador X | 2 | Operador X | |
| Core node | Core node | Code node | |||
| SLA usage: 95% | |||||
| 2 | 2 | Provider | 1 | Provider | |
| Edge router | Edge router | Edge router | |||
| SLA usage : 2% | |||||
| 3 | 1 | Bank Ltd | 3 | Bank Ltd | |
| Customer Modem | Customer Modem | Customer Modem |
\newpage
El proceso SLA-Monitoring en
sentido estricto, examina los Trouble Tickets sobre los procesos 35
y 38 frente a los criterios SLA y genera en el caso dado una
notificación para un cliente. En esta posición se indicada que tal
"cliente" no es necesariamente un "consumidor final", sino
que puede abarcar una posición en una interconexión de prestación
de servicios.
El examen conforme al invento frente a los
criterios SLA se aclara mediante la figura 4. En la representación
inferior están representados los acontecimientos Ev1 y Ev2, que como
tales ya se someten en la figura 3 a una clasificación conforme a
las características precedentes en relación con la unidad Filt_Corr.
De estos eventos se elaboran los correspondientes Network Trouble
Tickets (indicados con TT1 y TT2). Teniendo en cuenta la tabla de
correspondencias, se elaboran sólo para los Tickets TT1 los
correspondientes Service Trouble Tickets. Para los Tickets TT2 no
se elaboran, según la tabla de correspondencias, ningún Service
Trouble Tickets correspondiente.
La indicación de dos clases es aquí solo
ejemplar. En otra forma de ejecución se pueden prever, para
diferenciar, más de dos clases. A causa de estos acontecimientos
tiene lugar, según la representación central de la figura 4, una
generación de Trouble Tickets TT1 y TT2. La indicación 1 y 2 se
aplica sólo a las clases y no a los Trouble Tickets mismos. De los
eventos Ev2 de la clase 2, se generan asimismo Trouble Tickets, que
no se tienen en cuenta en el examen subsiguiente frente a los
criterios del SLA, por ejemplo si la clase 2 no está unida mediante
un SLA, o cuando en este instante está colocada una pantalla de
mantenimiento en la clase 2. Durante el tiempo, se acumula la
duración de los estados activos de los Service Trouble Tickets TT1 o
bien se integran en una observación matemática. Esta se tiene que
coger en la representación grafica superior conforme a la figura 4.
Como ya se explicó en la representación central, la ordenada no
tiene ningún significado en el sentido métrico, esto indica
exclusivamente el estado activo o inactivo del Trouble Tickets TT1 y
TT2. Un ejemplo de un Nerwork Trouble Tickets TT2 de la clase 2
para distinguirlo está representado con una línea rayada y un poco
más pequeño, con lo que la altura aquí es insignificante. En esta
integración/ acumulación es ahora esencial, en este ejemplo de
realización Network Trouble Tickets TT2, que la clase 2 en la
integración no arrastre ninguna cuota. La integración
ininterrumpida del Service Trouble Tickets TT1 de la clase 1 dirige
en un momento determinado a una lesión del
SLA-Levels asegurado. Esta frontera de lesión
SLA_Viol está representada en la figura 4 con una línea de rayas y
puntos. El desborde 41 de la frontera de lesión SLA_Viol provoca la
notificación de la mano de un cliente Cust.
En la anteriormente mencionada filtración de la
unidad Filt_Corr se puede tener en cuenta, que los acontecimientos
del Fault Management dependen de la hora del día para la generación
de Trouble Tickets, aquí una red Trouble Tickets Netw_T tiene como
consecuencia, que cada uno de los Ticket desde el principio está en
un estado inactivo y entonces no conduce a un Service Trouble
Tickets. Esto es necesario, por acontecimientos que aparecen o bien
Trouble Tickets, en una especifica ventana de mantenimiento
conforme al SLA, no se tienen en cuenta para la supervisión de los
SLA's.
En la representación de la figura 4, se contiene
también que un y el mismo Trouble Ticket TT1, por ejemplo un
Service Trouble Ticket, después de la fijación efectuada se reactiva
de nuevo en un estado inactivo. Esto es entonces necesario cuando
una prestación de servicios especifica o un servicio determinado,
según las razones de las que el cliente es responsable, no se puede
producir; por ejemplo: determinadas horas están explícitamente
excluidas por el cliente, dentro de las cuales se puede llevar a
cabo por el que ofrece el servicio, un trabajo como en fin de
semana o en periodo de actividad intensa, durante el cual ninguna
intervención se puede hacer. Tales periodos de bloqueo, pueden ser
por tanto una parte de un SLA y puede estar incluido en la base de
datos DB1 y/o DB2.
Para la clasificación antes mencionada entre la
red Trouble Tickets y el servicio Trouble Tickets, se tiene en
cuenta en la formación de la tabla de objetivos y en la tabla de
servicios, que se presenten del todo la red Trouble Tickets que no
son relevante de servicios, por ejemplo de
Test-Routern o de equipo en el estado
Stand-By.
La representación conforme a la figura 4 es sólo
"de una capa" en el sentido que en una forma de ejecución
preferente de la presente invención, existen varias fronteras de
lesiones SLA_Viol diferentes y/o la acumulación ocurre de forma
independiente sobre las distintas clases de Trouble Tickets. Por
ejemplo con tres fronteras de lesiones ordenadas
SLA_Viol1 < SLA_Viol2 <
SLA_Viol3
se deja diferenciar la vigilancia
del SLA frente a un cliente como se ve a
continuación:
SLA_Viol1 Para una frontera de lesión muy
inferior, tiene lugar la generación de un Service
Tickets de la mano de una persona
"supervisora", con lo que se pueden iniciar así medidas pro
activas;
SLA_Viol2 Un sobrepaso de estos Levels se usa
para efectuar una priorización de la mano de un centro de reparación
Rep_C, que se lleva a cabo sobre los procesos 38 y 33 conforme a la
figura 3;
SLA_Viol3 Notificación del cliente.
Estas fronteras de lesión adicionales SLA_Viol2
y SLA_Viol 3 pueden ser vistas como tales SLA's internas. Ellas se
diferencian del SLA, en que se pueden cerrar frente a un cliente
sólo para el valor límite y la dirección del destino de la
notificación. Desde otro punto de vista, se toman como base estos
ejemplos tres al mismo tiempo para la vigilancia del SLA's, es
decir clientes de SLA, SLA internos y un denominado SLA maestro.
Estos SLA's anteriormente mencionados, se trabajan de la misma
manera y preferentemente de forma paralela, ellas se diferencian
entre si solamente en la parametrización, como el valor límite de
lesión SLA y la dirección del destino para la notificación.
La clasificación anterior contiene que Trouble
Tickets son o no tenidos en cuenta. En otra forma de ejecución de
la invención puede el SLA-Monitoring propuesto
implementarse para clases diferentes de manera separada.
Dependiendo de las clases a las que se refieren, en notificaciones
del sobrepaso del valor límite, pueden sólo conforme a los datos
anteriores, tener lugar SLA_Viol2 y SLA_Viol3 sin una notificación
del cliente, en el que el concepto cliente, se tiene que entender
aquí en el sentido usual. Esto permite en todo caso, una
supervisión del SLA mas diferenciado en lo relativo a un objeto para
un cliente, en él se pueden introducir las medidas necesarias en un
momento en el que todavía no se ha manifestado absolutamente nada un
problema frente a un cliente.
Las diferentes etapas del procedimiento, como
por ejemplo la generación del Trouble Tickets como también los
precedentes del seguimiento de la base de datos DB1, DB2 y la
comparación con las fronteras de lesión, se llevan a cabo
preferentemente en procesos en tiempo real. Así pueden estar
implementados todos o solo partes de las etapas del procedimiento
antes citadas en procesos en tiempo real.
El ejemplo de realización explicado de la
presente invención sin embargo, no está limitado de ninguna manera
a redes de comunicación, sino que puede ser igualmente aplicable
para otros objetos técnicos, que pueden ser objetos de los SLA's,
como por ejemplo en el área de abastecimiento de energía eléctrica o
vías de comunicación.
- 22
- Instalación efectuada
- 24
- Errores eliminados
- 31
- Event Collection, Colección de acontecimientos
- 32
- Creación de un problema relativo al objeto Tickets
- 33
- Iniciación de un encargo de reparación
- 34
- Creación de un problema relativo al objeto Tickets
- 35
- Examen de los Trouble Tickets frente a los criterios SLA
- 36
- Notificación de una lesión SLA
- 37
- Detección, suministro de reclamación del cliente
- 38
- Priorización de encargos de reparación
- 39
- Tabla de correspondencias de objetos y servicios
- 41
- Lesión de un criterio SLA
- Bill
- Billing, facturación
- Cl
- Client, Web Client
- Cust
- Cliente
- CRM
- Customer Relationsship Management
- DB1, DB2
- Base de datos
- EA1
- Bus genérico, para poder acceder a la base de datos de tecnologías diferentes, de manera que las bases de datos existentes no se deben de duplicar.
- EV, Ev1, Ev2
- Event, acontecimientos
- Fa_Ev
- Fault Event
- Filt_Corr
- Filtración de acontecimientos y correlación de acontecimientos
- FM
- Fault Management
- Ln
- Servicios de conmutación de circuitos, por ejemplo idioma
- Man
- Recopilación manual de las reclamaciones de los clientes
- Meth_TT
- Trouble Ticketing
- Netw_T
- Trouble Ticket relativo al objeto, red Trouble Ticket, Network Trouble Ticket
- NI
- Network Interface; interfaz de red
- Not
- Notifikation, información
- Obj_Lev
- Capa del objeto, Object Level
- Oth_M
- Other Management, otros servicios de dirección
- PM
- Performance Management
- Perf_Ev
- Performance Event
- Prov_Ev
- Provisioning Event
- Rep_C
- Centro de reparación, Field Service
- S_Prov
- Service Provisioning
- S_Ass
- Service Assurance
- S_Act
- Service Activation
- Serv_Lev
- Service Ebene, Service Level
- Serv_T
- Service Trouble Ticket
- SLA_Acc
- SLA Accounting
- SLA_Moni
- SLA Monitoring, grabación SLA, seguimiento SLA
- SLA_Viol
- Límite de lesión SLA, valor límite SLA
- t
- Duración
- TT, TT1, TT2
- Trouble Ticket
- U1
- Interfaces del usuario
- ATM
- Asynchroner Transfer Modus
- IP
- Internet Protocol
- SDH
- Synchrone Digitale Hierarchie
- SLA
- Service Level Agreement
- [1]
- TeleManagement Forum office
- 1201 Mt. Kemble Avenue
- Morristown, NJ 07960 USA
- Tel : +1 973 425 1900
- Fax: +1 973 425 1515
Claims (11)
1. Procedimiento de vigilancia de acuerdos de
nivel de servicio SLA que incluye las etapas del procedimiento:
- A
- Seguimiento de una base de datos (DB1, DB2) con datos específicos del SLA;
- B
- Detección (31) y memorización de los acontecimientos relevantes para el SLA;
- C
- Comparación de los acontecimientos memorizados relevantes para los SLA, con los datos informados a los SLA almacenados en la base de datos (DB1, DB2) y generación en todos los casos de un informe a partir de los resultados de la comparación;
caracterizado porque,
- D
- de un primer acontecimiento (EV, Ev1, Ev2) almacenado relevante para los SLA se genera un Trouble Ticket (TT1, Serv_T, Netw_T) y dependiendo de los acontecimientos (Ev1, Ev2) se ponen en un estado activo;
- E
- por otro acontecimiento (Ev, Ev1) se desplaza un Trouble Ticket (TT1, Serv_T, Netw_T) a un estado inactivo;
- C'
- en la etapa del procedimiento C se acumula (SAL_Acc) la duración del estado activo del Trouble Tickets (TT1, Serv_T, Netw_T) y se comparan con al menos uno de los límites de lesión (SLA_Viol);
- F
- en caso de sobrepasar (41) los limites de lesión (SLA_Viol) antes mencionados, se genera una notificación (36).
2. Procedimiento según la reivindicación 1,
caracterizado porque
en la etapa del procedimiento D los
acontecimientos ( EV, Ev1) tienen un origen técnico (IP; SDH,
ATM; Ln) y no técnico (man).
3. Procedimiento según una de las
reivindicaciones 1 o 2,
caracterizado porque
en la etapa del procedimiento D los
acontecimientos (EV, Ev1) se clasifican antes de la generación de
un Trouble Tickets y en consecuencia tambien el Trouble Tickets
(TT1, TT2) y que en la etapa del procedimiento C' se efectúa la
acumulación de la duración dependiendo de la pertenencia a una
clase.
4. Procedimiento según una de las
reivindicaciones 1 hasta 2,
caracterizado porque,
en la fase del procedimiento D se efectúa la
acumulación (SLA_Acc) de las duraciones por clase.
5. Procedimiento según una de las
reivindicaciones 1 hasta 4
caracterizado porque,
tras la fase del procedimiento E, se vuelve a
poner un trouble tickets (TT) que se encuentra en estado inactivo,
por un acontecimiento ( Ev1, EV2) reiterado se transforma en un
estado activo.
6. Procedimiento según la reivindicación 5,
caracterizado porque,
para la transformación en un estado inactivo de
unos Trouble Tickets (TT1, TT2), se consultan los datos de una
tabla de correspondencias (39).
7. Procedimiento según la reivindicación 5,
caracterizado porque,
\newpage
para la transformación en un estado inactivo de
un trouble tickets (TT1, TT2) se consultan los datos de una tabla
de correspondencias (39) y/o de la base de datos (DB1, DB2).
8. Procedimiento según una de las
reivindicaciones 3 hasta 7,
caracterizado porque, varias SLA's se
vigilan paralelamente.
9. Procedimiento según la reivindicación 8,
caracterizado porque, varios SLA's
muestran respectivamente un valor límite del SLA (SLA_Viol) que les
es propio y la notificación se transmite a las direcciones de
destino especifico al SLA.
10. Procedimiento según una de las
reivindicaciones 1 hasta 9,
caracterizado porque,
las etapas del procedimiento A hasta E se llevan
a cabo en procesos en tiempo real.
11. Sistema que tiene medios para la ejecución
de los pasos del procedimiento conforme a una de las
reivindicaciones 1 hasta 8.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP02006865A EP1349314B1 (de) | 2002-03-26 | 2002-03-26 | Verfahren zur Überwachung von Service-Level-Agreements |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2265463T3 true ES2265463T3 (es) | 2007-02-16 |
Family
ID=27798801
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES02006865T Expired - Lifetime ES2265463T3 (es) | 2002-03-26 | 2002-03-26 | Procedimiento de vigilancia de acuerdos de nivel de servicios. |
Country Status (4)
| Country | Link |
|---|---|
| EP (1) | EP1349314B1 (es) |
| AT (1) | ATE334528T1 (es) |
| DE (1) | DE50207632D1 (es) |
| ES (1) | ES2265463T3 (es) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7568124B2 (en) | 2006-06-02 | 2009-07-28 | Microsoft Corporation | Driving data backups with data source tagging |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| AU6714498A (en) * | 1997-03-14 | 1998-10-12 | Crosskeys Systems Corporation | Service level agreement management in data networks |
| US7725570B1 (en) * | 1999-05-24 | 2010-05-25 | Computer Associates Think, Inc. | Method and apparatus for component to service mapping in service level management (SLM) |
| US6556659B1 (en) * | 1999-06-02 | 2003-04-29 | Accenture Llp | Service level management in a hybrid network architecture |
-
2002
- 2002-03-26 ES ES02006865T patent/ES2265463T3/es not_active Expired - Lifetime
- 2002-03-26 DE DE50207632T patent/DE50207632D1/de not_active Expired - Lifetime
- 2002-03-26 AT AT02006865T patent/ATE334528T1/de not_active IP Right Cessation
- 2002-03-26 EP EP02006865A patent/EP1349314B1/de not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| DE50207632D1 (de) | 2006-09-07 |
| EP1349314A1 (de) | 2003-10-01 |
| ATE334528T1 (de) | 2006-08-15 |
| EP1349314B1 (de) | 2006-07-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11469992B2 (en) | Systems and methods for managing multi-layer communication networks | |
| US7684321B2 (en) | System for supply chain management of virtual private network services | |
| ES2227543T3 (es) | Gestion de redes de comunicaciones. | |
| US8717869B2 (en) | Methods and apparatus to detect and restore flapping circuits in IP aggregation network environments | |
| US7058861B1 (en) | Network model audit and reconciliation using state analysis | |
| US20090161679A1 (en) | Method and apparatus for customer-controlled routing management | |
| US8855003B2 (en) | Method and apparatus for providing end to end virtual private network performance management | |
| US20110103229A1 (en) | Dynamic network configuration | |
| US6836798B1 (en) | Network model reconciliation using state analysis | |
| CN110533789A (zh) | 一种基于区块链的设备巡检管理方法及装置 | |
| ES2265463T3 (es) | Procedimiento de vigilancia de acuerdos de nivel de servicios. | |
| CN114566268A (zh) | 医院资源优化配置系统 | |
| US9559973B1 (en) | Wireless communication link bandwidth utilization monitoring | |
| ES2310611T3 (es) | Un medio y un metodo relacionados con la optimizacion del funcionamiento y planificacion de redes. | |
| ES2281357T3 (es) | Procedimiento generico para el alineamiento en un entorno multigestor. | |
| CN101980269A (zh) | 区域卫生一体化信息管理系统 | |
| WO2001089141A2 (en) | Network overview report | |
| Pang | Successful service design for telecommunications: a comprehensive guide to design and implementation | |
| US8509083B2 (en) | Band management apparatus and band management method | |
| ES2299838T3 (es) | Procedimiento para la determinacion automatica del alcance de los daños derivados de un fallo de los componentes tecnicos integrados en un ciclo de produccion. | |
| Greene et al. | Carrier-grade: Five nines, the myth and the reality | |
| Kelley et al. | The role of perceived barriers in the use of a comprehensive prenatal care program | |
| Willis | Challenges and pitfalls of operating a rural accountable care organization | |
| TWI306341B (es) | ||
| Helberg | Integrated management of Eskom's private telecommunications network |