Sistema de Gestion para La Deteccion de Fallas Temprana en La Bts de Red Digitel

Sistema de gestión para detección temprana de fallas en las BTS de la Red Digitel
SISTEMA DE GESTIÓN PARA DETECCIÓN TEMPRANA

DE FALLAS EN LAS BTS DE LA RED DIGITEL
Lozada, Jessica
[email protected]
Resumen
Considerando el constante crecimiento de la red GSM de la Corporación Digitel y

la gran cantidad de equipos existentes en el subsistema de radio bases, las labores de
monitoreo difícilmente pueden ser realizadas en tiempo real. Adicionalmente cuando
ocurren fallas en los equipos de la red no siempre se activan alarmas en la plataforma
de monitoreo con la que dispone la empresa, complicando aún más la detección de
posibles anomalías. Por estas razones se planteó el diseño y desarrollo de un sistema
de gestión que proporciona análisis y soluciones preliminares de las fallas o
anomalías presentes en las radio bases de la red Digitel, con la finalidad de facilitar la
detección y resolución de fallas en el menor tiempo posible disminuyendo así los
tiempos de afectación de servicio.
El trabajo especial de grado contempla el análisis de la información referente al

funcionamiento de red GSM de Digitel, estudio de las mediciones disponibles en el
subsistema de radio bases e identificación de los indicadores que permiten determinar
la necesidad de un mantenimiento correctivo o preventivo en los equipos de la red. El
sistema realiza el análisis de las estadísticas asociadas al control de llamadas para
cada estación con el objeto de detectar fallas en los equipos de la red, identificar las
rutinas de mantenimiento que deben ser aplicadas y, en caso de ser posible, realizar la
ejecución automática de las mismas.
Palabras Claves: Red GSM, Indicadores de rendimiento, Detección de fallas.

Dedicatoria y Agradecimientos
Este trabajo de grado se lo dedico especialmente a mi mamá y a mis hermanos,

Gustavo y José Alberto, que con su apoyo y con la seguridad brindada desde siempre
me han motivado a alcanzar cada uno de mis logros, en esta oportunidad, el de haber
culminado exitosamente el desarrollo del presente proyecto.
En primer lugar le agradezco a dios y a papá las bendiciones que sin duda me han
acompañado durante los meses dedicados a este trabajo.
Le agradezco a la Universidad Católica Andrés Bello por ser la fuente de los

conocimientos que me sirvieron de base para el desarrollo del proyecto.
A los compañeros de Digitel por su disposición a guiarme en las tareas planteadas y

por darme la oportunidad de aprender con su trabajo. Le doy las gracias
especialmente a mi tutor y a todo el equipo de Optimización: Juan, Luis, Neudys,
Francisco, Danny, Carola y Cesar a quien le agradezco la oportunidad brindada.
Finalmente le agradezco a Guillermo por ser siempre mi mejor compañía, a mi lado

en los momentos más importantes, como lo fue durante el desarrollo de este trabajo
de grado. Gracias
Página ii
Índice General
Resumen ......................................................................................................................... i
Dedicatoria y Agradecimientos ..................................................................................... ii
Índice General .............................................................................................................. iii
Índice de Figuras ........................................................................................................... v
Introducción .................................................................................................................. 1
Capítulo I....................................................................................................................... 2
Planteamiento del Proyecto ........................................................................................... 2
I.1 Planteamiento del Problema.............................................................................. 2
I.2 Objetivo General. .............................................................................................. 2
I.3 Objetivos Específicos. ....................................................................................... 3
I.4 Justificación. ..................................................................................................... 4
I.5 Limitaciones y Alcance. .................................................................................... 4
Capítulo II ..................................................................................................................... 5
Marco Referencial ......................................................................................................... 5
II.1 Estándar GSM y Arquitectura de Red ................................................................... 5
II.1.1 Subsistema de Estaciones Base (BSS) ..................................................... 6
II.1.2. Subsistema de Conmutación y Red (NSS) ............................................... 8
II.1.3 Subsistema de Administración .................................................................. 9
II.2. Canales físicos y lógicos ................................................................................... 11
II.3. Diagramas de Procesos para establecimiento, control y manejo de llamadas ... 14
II.4. Indicadores de Rendimiento Analizados ............................................................ 17
Página iii
Capítulo III .................................................................................................................. 21
Metodología y Desarrollo ........................................................................................... 21
III.1. Análisis de la Red GSM de Digitel. .................................................................. 21
III.2. Estudio de las mediciones disponibles en el subsistema de radio bases. ........... 22
III.3. Estudio de acciones correctivas y preventivas para la resolución de fallas en los

equipos BTS de la red. ................................................................................................ 23
III.4. Diseño e Implementación del Sistema. ............................................................. 23
Capítulo IV .................................................................................................................. 25
Resultados ................................................................................................................... 25
IV.1. Diseño del Sistema........................................................................................... 25
IV.1.1. Métodos de Análisis de los Indicadores de Rendimiento ..................... 27
IV.1.1.1. Análisis de los Indicadores de Voz ................................................ 28
IV.1.1.2. Análisis del Link Budget en las Antenas ....................................... 38
IV.1.1.3. Análisis de Sleeping Cells para Datos ........................................... 40
IV.1.2 Establecimiento de la Conexión remota a las BSC ................................ 41
IV.2. Implementación del Sistema. ........................................................................... 43
IV.2.1. Modelo de la Base de Datos ................................................................. 44
IV.2.2. Estructura de la Aplicación ................................................................... 45
IV.2.2.1 Actualización de los Perfiles ........................................................... 46
IV.2.2.2. La detección temprana de fallas ..................................................... 47
IV.2.2.3. El administrador del sistema .......................................................... 48
IV.3. Una corrida de la Detección Temprana de Fallas desde el Administrador del

Sistema.... .................................................................................................................... 49
Página iv
Capítulo V ................................................................................................................... 58
Conclusiones y Recomendaciones .............................................................................. 58
Referencias Bibliográficas .......................................................................................... 60
APÉNDICE A ............................................................................................................. 62
Descripción de la Base de Datos del Sistema ............................................................. 62
APÉNDICE B ............................................................................................................. 70
Interfaces de Usuario del Sistema ............................................................................... 70
ANEXO A ................................................................................................................... 89
MODEM ENFORA SA-GTM ...................................................................................... 89
Índice de Figuras
Figura 1. Subsistemas en GSM ..................................................................................... 6
Figura 2. Subsistema de Estaciones Base .................................................................... 7
Figura 3. Elementos del Subsistema de Conmutación ................................................. 8
Figura 4. Subsistema de Administración ..................................................................... 9
Figura 5. División de las Bandas de Frecuencia ......................................................... 11
Figura 6. Esquema de los Tipos de Canales Lógicos .................................................. 13
Figura 7. Diagrama del Proceso de HandOver entre BTS .......................................... 15
Figura 8. HandOver interno a una BSC entre BTS .................................................... 16
Figura 9. Diseño General del Sistema ......................................................................... 25
Figura 10. Diagrama de Actividades........................................................................... 28
Página v
Figura 11. Representación Grafica de la Hipótesis 1 .................................................. 30
Figura 12. Estructura de la Tabla de los Perfiles de Contadores ................................ 31
Figura 13. Gráfica de los Perfiles de Contadores........................................................ 33
Figura 14. Grafica de la Función Variación ................................................................ 36
Figura 15. Estructura de la Tabla de los Perfiles de Link Budget............................... 39
Figura 16. Modelo Entidad Relación .......................................................................... 45
Figura 17. Barra de Herramientas ............................................................................... 50
Figura 18. Interfaz de Edición de Parámetros ............................................................. 51
Figura 19. Interfaz de Visualización de Resultados .................................................... 53
Figura 20. Ventana de Notificación de Fallas vía mail ............................................... 54
Figura 21. Ventana de Archivo con el detalle de Falla ............................................... 54
Figura 22. Ventana de Notificación de Alarmas Activas vía mail .............................. 55
Figura 23. Ventana de Archivo con el detalle de Alarmas Activas ............................ 56
Figura 24. Indicador de Drop Call de CASARAPA2 en el tiempo ............................ 57
Página vi
Introducción
El diseño e implementación de un sistema que facilite las labores de detección de

fallas en los equipos del subsistema de radio bases de la Corporación Digitel en el
menor tiempo posible es el fundamento sobre el cual se sostiene el presente Trabajo
Especial de Grado. En el documento presentado se explica de una manera clara y
concisa la metodología seguida para el desarrollo del proyecto.
En el capítulo uno se describe el planteamiento del proyecto, con sus alcances,

limitaciones, objetivos y una explicación de las razones que justifican el proyecto. El
segundo capítulo contiene los resultados de la revisión bibliográfica realizada
referente a la arquitectura de la red analizada. El capítulo tres muestra la metodología
y desarrollo donde se explican los pasos seguidos para el diseño e implementación
del proyecto. El capítulo cuatro corresponde a los resultados obtenidos. Finalmente
en el capítulo cinco se recogen las conclusiones sobre los logros, resultados y
experiencias obtenidas del proyecto realizado, además de ciertas recomendaciones
sobre aspectos que pueden cambiarse en el sistema. Adicionalmente, se encuentran
los anexos y apéndices, en los cuales se recoge información complementaria a la
investigación realizada y que puede ser usada para futuros desarrollos que mejoren el
desempeño del sistema ya implementado.
Con el presente documento podrá conocer de forma sencilla los análisis que se
llevan a cabo para el monitoreo del subsistema de radio bases en una red GSM.
Continúe la lectura.
Página 1
Capítulo I
Planteamiento del Proyecto
El capítulo de Planteamiento del Proyecto está basado fundamentalmente en la

descripción y justificación del problema expuesto en la propuesta de Trabajo Especial
de Grado, los objetivos planteados, el alcance y las limitaciones del proyecto. Cada
uno de estos aspectos serán los desarrollados en el presente capítulo.
I.1 Planteamiento del Problema.
La arquitectura de la red GSM de la Corporación Digitel se encuentra en constante

crecimiento, lo cual produce que el monitoreo del subsistema de radio bases sea una
tarea que no puede ser realizada en tiempo real. Por otro lado, existen un porcentaje
de fallas de los equipos de la red que no activan alarmas en la plataforma de
monitoreo actual, complicando aún más la detección de posibles anomalías. El
tiempo que toma identificar una falla y definir la rutina correctiva repercute
directamente en la calidad del servicio ofrecida a los clientes.
I.2 Objetivo General.
Diseñar, desarrollar e implementar un sistema de monitoreo y gestión, que facilite

la detección y resolución de fallas en las radio bases, la definición y notificación de
acciones correctivas y rutinas de mantenimiento preventivo, para los equipos de BTS
de la red Digitel.
Página 2
I.3 Objetivos Específicos.
1. Recopilar y analizar información referente a:
1.1. Funcionamiento de la red GSM de Digitel.
1.2. Mediciones disponibles en el subsistema de radio bases de la red GSM.
1.3. Fallas de mayor ocurrencia en los equipos de radio bases.
1.4. Descripción de alarmas, acciones correctivas y las rutinas de

mantenimiento preventivo para cada tipo de BTS.
2. Identificar los indicadores que permiten determinar la necesidad de un

mantenimiento correctivo o preventivo y la identificación de una posible falla en
el sistema.
3. Diagramar y estructurar las bases de datos necesarias para el sistema.
4. Desarrollar la interfaz del sistema (Interfaz Humano – Máquina).
5. Diseñar y desarrollar:
5.1 Mecanismos de detección de fallas a través de las mediciones disponibles

en el subsistema de radio bases.
5.2 Rutinas de mantenimiento preventivo para cada tipo de radio base, así
como también, las acciones correctivas para cada tipo de falla.
5.3 El sistema de notificación de fallas.
6. La conexión remota al sistema, que permitirá el monitoreo y gestión del

subsistema de radio bases (Web, WAP o SMS).
7. Realizar las pruebas necesarias para comprobar el correcto funcionamiento del

sistema desarrollado.
Página 3
I.4 Justificación.
El desarrollo del proyecto surge de la necesidad de contar con un sistema que

proporcione el análisis y soluciones preliminares de fallas o anomalías en el
subsistema de radio bases en el menor tiempo posible, de forma remota y automática
a fin de lograr reducir el tiempo de análisis de fallas, el conocimiento previo
necesario y el tiempo de afectación del servicio.
I.5 Limitaciones y Alcance.
Puesto que los sistemas de mediciones de rendimiento de la red son actualizados en

períodos de una hora, la respuesta del sistema desarrollado no es en tiempo real. El
análisis que se lleva a cabo se realiza con la información obtenida de los equipos de
la red una hora antes a la hora en que se inicia la ejecución del sistema de monitoreo
y gestión desarrollado.
El alcance del proyecto es proporcionar una solución que facilite la detección,

diagnósticos y notificación de fallas, acciones correctivas y rutinas de mantenimiento
preventivo en el subsistema BSS de la Red Nokia Digitel en el menor tiempo posible,
mejorando así las herramientas actualmente utilizadas por el personal de la empresa
para estas labores.
Página 4
Capítulo II
Marco Referencial
En este capítulo se desarrollan todos los aspectos teóricos requeridos para el

desarrollo del proyecto. Se explica el estándar GSM, la arquitectura de red con la
descripción detallada de los subsistemas que la conforman, y demás conceptos
relacionados a las mediciones de desempeño de los equipos de la red.
II.1 Estándar GSM y Arquitectura de Red
La red GSM (Global System for Mobile communications) es un sistema móvil

celular basado en el estándar de Servicio Global para comunicaciones Móviles que
utiliza tanto tecnología TDMA (Time Division Multiple Access) como FDMA
(Frequency Division Multiple Access) para transmitir y recuperar información. Usa
paquetes de datos a tiempos predeterminados en una frecuencia específica, de modo
tal que se pueden llevar a cabo varias conversaciones en forma simultánea usando la
misma frecuencia pero distintas ranuras de tiempo o TimeSlot. (Laizzo, 2005)
Las especificaciones del estándar se crearon tomando en cuenta las características

que faciliten un sistema global, capaz de ser instalado en diferentes regiones y que
garantice compatibilidad entre las mismas. Para lograr este objetivo, se planificó la
red GSM de manera modular, donde cada módulo se denominó Subsistema. Así, un
operador interesado en adquirir tecnología GSM no estaría obligado a adquirir toda la
plataforma a un solo fabricante. Otra ventaja de esta modularidad es la asignación de
procesos a diferentes nodos de la red. No existe un único elemento encargado de
todos los procesos relativos al servicio, sino que la operación de estos la llevan a cabo
diferentes elementos en diferentes subsistemas. (Gold, 1998)
Página 5
En este sentido, se crearon tres subsistemas: el de Estaciones Base, el de

Conmutación y el de Administración, los cuales se describen a continuación. En la
Figura 1 se presenta un esquema de la red GSM con sus diferentes subsistemas y
elementos.
Figura 1. Subsistemas en GSM (tomado de Systra. Gold, R.)
II.1.1 Subsistema de Estaciones Base (BSS)
El Subsistema de estaciones Base o BSS (Base Station Subsystem) proporciona al

sistema GSM funciones específicas que permiten transferir llamadas desde el NSS al
MS (Mobile Station). También transfiere llamadas desde la BSS y MS e información
acerca de las alarmas hacia el NMS (Network Switching Subsystem) de la red. Es la
entidad responsable del establecimiento de las comunicaciones con las estaciones
móviles que se encuentran dentro de su área de influencia. Esta área de influencia
puede ser constituida por una o más células radio cada una de ellas con una estación
base.
El BSS está compuesto por tres elementos principales: la Estación Base

Controladora o BSC (Base Station Controller), las Estaciones Bases Transceptoras o
BTS (Base Transceiver Station) y los Transcoder o TC (Transcoder) como se
muestra en la Figura 2.
Página 6
Figura 2. Subsistema de Estaciones Base (tomado de Systra. Gold, R.)
La BSC es el elemento central del BSS, controla la red de radio y se encarga del
control de la interfaz aire. Sus funciones principales son el establecimiento de la
conexión entre el MS y el NSS, el soporte de la señalización de las interfaces Aire y
A, la administración de la movilidad, la recolección de información estadística, y el
mantenimiento de las BTS, al permitir el manejo y control de la información de
alarmas.
Las BTS son los elementos del sistema más cercanos al usuario luego de los MS y
se encargan del manejo de la interfaz aire, su señalización, y los procesos aplicados a
la señal que se transmitirá al MS con miras a garantizar una señal libre de errores.
Una Estación Base BTS está constituida por un conjunto de transceptores (TRX)
que cubren la misma área. La estación base incluye además de los transceptores un
módulo que realiza la función de control común de estos transceptores (BCF) y otro
que maneja la transmisión entre ésta y la BSC (TRU), unidades de control de energía
y extractores de calor, entre otros.
Los TC son elementos que se ocupan de decodificar y re-codificar la información

con lo que la hace compatible entre el BSS y el NSS.
Página 7
II.1.2. Subsistema de Conmutación y Red (NSS)
El Subsistema de Conmutación y Red o NSS (Network Switching SubSystem)

proporciona la conmutación entre el subsistema GSM y las redes externas (PSTN,
PDN, etc) junto con las bases de datos utilizadas para la gestión adicional de la
movilidad y de los abonados. Los principales componentes del Subsistema de
Conmutación y Red se muestran en la Figura 3.
Figura 3. Elementos del Subsistema de Conmutación (tomado de Systra. Gold, R.)
El MSC (Mobile Switching Center) es el elemento de conmutación del sistema,

capaz de detectar las características de la llamada (procedencia, destino, tipo) y
realizar las conexiones necesarias. También lleva a cabo las funciones de
interconexión de redes (IWF: InterWorking Function) que se utilizan cuando se hace
necesaria la adaptación de la red GSM con alguna red externa. El manejo de datos y
servicios del suscriptor es otra función del MSC, así como recolectar información
referente a la facturación para enviarla al elemento encargado de su procesamiento, el
BC (Billing Center).
Página 8
El HLR (Home Location Register) es una gran base de datos en donde se encuentra
almacenada permanentemente toda la información de los subscriptores.
El VLR (Visitor Location Register) provee un registro temporal de los usuarios

activos en la red, dentro del área de servicio de ese VLR
El procedimiento de autenticación es llevado a cabo por la estación móvil MS, el

centro de autenticación o AC (Authentication Center) y el VLR. El AC mantiene la
información de seguridad relacionada a la identidad del suscriptor y lleva a cabo el
proceso de autentificación del suscriptor. El EIR (Equipment Identity Register)
mantiene la información de seguridad relacionada al MS y aplica algoritmos de
seguridad
II.1.3 Subsistema de Administración
El NMS (Network Management Subsystem) se encarga del monitoreo y gestión de

los diferentes elementos, funciones y eventos de los subsistemas NSS y BSS, como se
muestra en la Figura 4.
Figura 4. Subsistema de Administración (tomado de Systra. Gold, R.)
Página 9
La recolección de datos estadísticos es llevada a cabo por el MSC y todos los

registros: VLR, HLR, AC y EIR en el NSS y de igual forma, por las BTS, BSC y TC
en el BSS. Como es de suponer, en cada lugar se recolectan diferentes tipos de
estadísticas. Cuando el operador requiere del control total de los datos obtenidos,
estos se transfieren al NMS a través de una red que interconecta los elementos
mencionados con servidores de datos y luego los datos son procesados utilizando las
herramientas de análisis de este subsistema. En general, es necesaria la recolección
de información en ambos lados de cada interfaz definida, y de esta manera, al
comparar los resultados obtenidos, el operador puede tener una idea de la calidad de
la red y de su uso.
La información de monitoreo de los diferentes elementos, funciones y eventos se ha

dividido haciendo que el NSS tenga tres funciones básicas: Administración de
Configuración, Administración de Fallas y Administración de Desempeño. La
Administración de Configuración se encarga de mantener actualizada la información
de operación y estado de configuración de los diferentes elementos de BSS y NSS. La
Administración de Fallas tiene como propósito la rápida corrección de fallas las
cuales se notifican por medio de alarmas de operación del sistema. La Administración
de Desempeño recolecta mediciones de los diferentes elementos de la red y los
almacena para que el operador pueda asociar diferentes mediciones con el fin de
generar reportes indicativos del desempeño de la red y comparar dichos reportes a lo
largo del tiempo.
Los indicadores de desempeño o rendimiento de la red (Performance Indicators) se

calculan con la información de las mediciones que son almacenadas en Contadores
existentes en las BSC (BSC Counters), los cuales se incrementan siempre que ocurren
determinados eventos tanto a nivel de BTS como de BSC y MSC, por ejemplo,
durante el establecimiento, duración y culminación de llamadas. Para entender la
información almacenada en estos contadores es necesario conocer los conceptos de
canales (físicos y lógicos) y como se realizan los procesos de generación, control y
manejo de llamadas. (Gold, 1998)
Página 10
II.2. Canales físicos y lógicos
El sistema GSM puede operar en la banda de 900 MHz, la de 1800 MHz y la de

1900 MHz. Cada una de estas bandas se divide a su vez en dos sub-bandas de 25
MHz cada una: Una para la transmisión de Radio Frecuencia desde el móvil hacia la
radio base (UpLink) y otra para la transmisión de RF de la radio base hacia el móvil
(DownLink). Ambas sub-bandas se dividen en 125 portadoras de RF de un ancho de
banda de 200 KHz. La división de la totalidad de la sub-banda de 25 MHz es lo que
se conoce como Acceso Múltiple por División de Frecuencia (FDMA)
Cada portadora es capaz de llevar canales de voz y datos utilizando la tecnología

TDMA, con la cual un canal de radio frecuencia es dividido en ocho períodos cortos
de tiempo consecutivos llamados Timeslot o ranuras de tiempo La Figura 5 muestra
un esquema de la división de las bandas de frecuencia. (Laizzo, 2005)
Figura 5. División de las Bandas de Frecuencia (tomado de Sistemas Celulares.

Laizzo, A.)
El significado de Canal Físico se refiere a cada una de las ocho posiciones en las
que se subdividen los canales de radio frecuencia. Un canal físico puede usarse
indistintamente para tráfico de voz como tráfico de datos. Sencillamente es el espacio
físico utilizado para llevar la información de un punto a otro. En las BTS los canales
físicos corresponden a cada una de las 8 ranuras de tiempo que constituyen un TRX.
Página 11
El contenido de los canales físicos se denomina canales lógicos y se refiere a la

función o rol que cumple la información que se traslada usando una ranura de tiempo
determinada
Para entender este concepto, se describe de forma sencilla el proceso que se lleva a
cabo para que un móvil pueda recibir una llamada: En primer lugar el subscriptor
tiene que ser previamente localizado, para ello la red envía un mensaje de búsqueda a
todas las BTS dentro del área de localización donde el usuario se haya registrado la
última vez. El móvil responde al llamado solicitando un canal para poder establecer la
comunicación. Luego la red reconoce la petición y localiza un canal disponible con la
finalidad de transmitir los datos referentes a la llamada. Por último el móvil recibe la
información del canal y se traslada al canal asignado. Durante la conversación, el
móvil mide la potencia de la señal a la que está conectada y la portadora de sus
adyacencias, y envía los reportes de medida a la BSC
En cada uno de los pasos del proceso descrito (búsqueda, asignación del canal de
tráfico y monitoreo de potencia) se requiere de un canal lógico ya que los datos
transmitidos por ellos es diferente.
Hay dos tipos de canales lógicos, denominados canales de control común y canales
dedicados. Los canales comunes se refieren a aquellos que difunden información
hacia los móviles. Los canales dedicados son aquellos que se establecen para el
intercambio de señalización entre el móvil y la BTS, BSC o MSC.
Una radio base puede tener varios TRX, pero siempre hay uno encargado de llevar
los canales de control común. En la Figura 6 se muestra un esquema con los
diferentes tipos de canales lógicos
Página 12
Figura 6. Esquema de los Tipos de Canales Lógicos (tomado de Sistemas Celulares.

Laizzo, A)
 Canales de Radiodifusión: Son canales de bajada punto a multipunto. Hay tres

tipos:
1. FCCH (Frecuency Correction Channel): Ayuda al móvil a sintonizarse a una
BTS Consiste en una ráfaga de puros ceros que actúan como bandera para que
los móviles ubiquen a un grupo de TRX
2. SCH (Synchronisation Channel): Contiene el código de identificación de la
BTS con el cual se corrobora que la frecuencia medida por el móvil
corresponde a la estación base correcta.
3. BCCH (Broadcast Control Channel): Contiene detalles de la red e
información específica de la celda.
 Canales de Control Común: Se utilizan para el establecimiento de conexiones

punto a punto:
1. PCH (Paging Channel): Sirve para localizar un móvil en un área determinada.
2. RACH (Random Access Channel): Es utilizado por el móvil para solicitar un
canal de tráfico bien sea para iniciar o recibir una llamada.
Página 13
3. AGCH (Access Grant Channel): Canal encargado de asignar un canal de

Control Dedicado (SDCCH)
 Canales de Control Dedicado: Son utilizados para el establecimiento de las

llamadas, envío de reportes de medida y handover. Hay tres tipos:
1. SDCCH (Stand Alone Dedicated Channel): Utilizado para señalización del
sistema: establecimiento de la llamada, autenticación, actualización de
ubicación, asignación de canal de tráfico y transmisión de mensajes cortos.
2. SACCH (Show Associated Control Channel): Hay un canal SACCH asociado
a cada canal SDCCH y un canal de tráfico. Este transmite reporte de
medición, control de potencia.
3. FACH (Fast Associated Control Channel): Al momento de realizar un
handover, se requiere de un rápido intercambio de señalización por lo que se
sustituye 20 mseg de la trama de voz en el canal de tráfico por este canal de
señalización.
 Canales de Tráfico: Son de uso dedicado ya que cada canal se utiliza para un
usuario específico y nadie puede acceder a ese canal mientras esté siendo
utilizado por el usuario a quien fue asignado. Transmiten voz y datos a una tasa
media (HR Half Rate) de 6.5 Kbps o a una tasa full (FR Full Rate) de 13 Kbps
II.3. Diagramas de Procesos para establecimiento, control y manejo

de llamadas
Los procesos que son llevados a cabo entre los equipos de la red para el
establecimiento, control y manejo de llamadas están bien definidos en diagramas que
contienen la información de cada uno los eventos que ocurren, ya sea cuando estos se
ejecuten de forma exitosa o no. Por ejemplo, los procesos de HandOver son
necesarios para:
Página 14
1. Darle continuidad a una llamada. Asegura que una llamada pueda mantenerse
cuando un móvil se encuentra en movimiento desde el área de cobertura de
una celda hasta otra.
2. Mejorar la calidad de llamada. Asegura que, si un móvil se mueve en un área
de poca calidad o poca cobertura, la llamada pueda ser transferida desde la
celda servidora a una celda vecina de mejor calidad sin que se caiga
3. Distribuir el tráfico. Asegura que el tráfico en la red esté distribuido de forma
óptima. Cuando la capacidad de la celda servidora es máxima, el móvil debe
pasar a otra vecina con menos tráfico
Las mediciones reportadas por el móvil y las BTS son las permiten a la BSC tomar
la decisión de llevar a cabo el HandOver de una llamada. En caso de considerarlo
necesario se inicia el proceso correspondiente, el cual esta representado con un
diagrama de pasos como el mostrado en la Figura 7.
Figura 7. Diagrama del Proceso de HandOver entre BTS (tomado de Systra. Gold, R.)
Página 15
El diagrama de pasos mostrado aplica al tipo de HandOver interno a una BSC entre
celdas distintas. La Figura 8 muestra una representación más gráfica
Air A
BTS BSC TC
BTS
Old Cell / BTS New Cell / BTS
Figura 8. HandOver interno a una BSC entre BTS (tomado de Systra. Gold, R.)
En el diagrama se observa que luego de que la BSC recibe las mediciones del móvil
y la BTS, y decide realizar el handover. Ésta envía un mensaje de petición de
requerimientos físicos a la BTS a la cual se intenta transferir la llamada (BTS2). Si
ésta lo recibe envía una confirmación a la BSC, en caso contrario, se termina la
petición de handover y la llamada continua en la BTS vieja (BTS1). En ambos casos
se incrementa el BSC Counter asociado a cada evento.
La BSC al hacer la reservación del canal hace la activación enviando un mensaje a

la BTS2. Cuando la BTS2 envía el Ackwnoledge continúa la petición de handover.
Si la petición de handover es permitida, se crea una conexión unidireccional con la

cual el MSC puede ser capaz inmediatamente de comunicarse con el MS. Por otro
lado, la BSC inicia el almacenamiento de mensajes para evitar la pérdida de
información
Página 16
Seguidamente la BSC envía el mensaje de solicitud de handover a la BTS servidora

de la llamada (BTS1) y ésta a su vez se encarga de hacerla llegar al móvil. El MS
debe entonces pedir el acceso a la BTS 2 de manera de que se le envíe la información
de los requerimientos físicos con lo cual se hace la conexión bidireccional con el
MSC. Luego de que MS haya culminado satisfactoriamente el proceso de
señalización envía un mensaje por la nueva BTS, con esto informa a la BSC que
detenga el almacenamiento de los mensajes puesto que la comunicación está
establecida.
Después de completado el handover, la BSC libera el canal en la BTS1 enviándole

un mensaje, la cual responde con un Ackwoledge.
Para cada uno de los pasos descritos existen contadores que guardan información
tanto de los eventos realizados exitosamente como aquellos en los que ocurrió alguna
falla. El detalle de los contadores no puede ser agregado al presente capitulo por la
política de confidencialidad impuesta por la empresa, sin embargo, a continuación se
describen algunos de los involucrados en el cálculo de los indicadores de
rendimientos analizados en el presente trabajo.
II.4. Indicadores de Rendimiento Analizados
Los indicadores de rendimiento analizados detalladamente son los de Call Setup

Failure, Handover Failure y Drop Call para el análisis de las estadísticas asociadas al
control de llamadas de voz.
1. Call Setup Failure, es un indicador del porcentaje de fallas producidas por

errores en el proceso de establecimiento de llamadas, autenticación y asignación del
canal de tráfico. Estos procesos son llevados a cabo por el sistema enviando
información de señalización a través del canal SDCCH. La fórmula para obtener el
porcentaje de fallas de este indicador incluye contadores como:
Página 17
 SDCCH_BUSY_ATT: Almacena el número de intentos no exitosos de tomar

el canal SDCCH debido a que todos los canales SDCCH están ocupados.
 SDCCH_RADIO_FAIL: Almacena el número de transacciones fallidas a

través del canal SDCCH debido a fallas de radio
 SDCCH_BTS_FAIL: Almacena el número de transacciones fallidas debido a

fallas en la BTS
2. Handover Failure, un indicador del porcentaje de fallas producidas por errores

en el proceso de darle continuidad a una llamada al pasar de una BTS a otra, de un
canal a otro dentro de la misma BTS, de una BSC a otra, o de un MSC a otro. Este
proceso se conoce como HandOver (HO). El porcentaje de fallas de este indicador se
calcula como:
Handover Failure (%) = 100 * (HO fallidos) / (Intentos de HO) %
= 100 * (Intentos HO – HOs exitosos) / (Intentos de HO) %
= 100 * [1 – (HOs exitosos)/(Intentos de HO)] %
De esta fórmula se deduce que los contadores utilizados guardan información del
número de HOs exitosos y el total de intentos de HO. Algunos de los contadores son:
 MSC_I_SUCC_HO: Almacena el número de handover entrantes exitosos

controlados por el MSC
 BSC_O_SUCC_HO: Almacena el número de handover salientes exitosos

controlados por la BSC
 CELL_TCH_TCH_AT: Almacena el número de intentos de handover desde

un canal TCH a otro canal TCH
Página 18
3. Drop Call, es un indicador del porcentaje de fallas producidas por errores durante
una llamada en curso, provocando interrupción de la llamada. Algunos de los
contadores involucrados para el cálculo del porcentaje de fallas de este indicador son:
 TCH_RF_OLD_HO: Almacena el número de asignaciones de TCH fallidos

debido a fallas de radio en el canal viejo durante un handover a otro canal
TCH.
 TCH_TR_FAIL: Almacena el número de asignaciones de TCH fallidos

debido a fallas de en el transcoder
 TCH_BTS_FAIL: Almacena el número de transacciones fallidas a través del

canal de TCH debido a fallas en la BTS
Otro indicador de rendimiento de la red importante que permite identificar posibles

anomalías en el funcionamiento de las antenas recibe el nombre de Link Budget, el
cual requiere del análisis de la información de la Potencia de las antenas en
DownLink (potencia con la que transmite la BTS al móvil) y en UpLink (potencia
recibe la BTS del móvil). Para analizar este indicador se necesitan las estadísticas de
un período de tiempo considerable en el que se pueda identificar la variación
progresiva o degradación de las antenas según sus niveles de potencia transmitida y
recibida. Cuando las antenas no presentan problemas en su funcionamiento, la
diferencia entre la potencia en UpLink y DownLink permanece constante. Para este
indicador de rendimiento se analizan los contadores de:
 AVE_DL_SIGN_STR: Almacena el promedio de la potencia en DownLink

durante un día
 AVE_UL_SIGN_STR: Almacena el promedio de la potencia en UpLink

durante un día
Para el análisis del servicio de datos (GPRS General Packet Radio Service) existen
otros indicadores de rendimiento. El sistema implementado contempla identificar las
Página 19
estaciones que manejen tráfico de datos en UpLink pero no en DownLink, lo que

significa que, cuando una BTS recibe solicitudes de descarga de datos de parte de
equipos móviles y ésta no hace transferencia de paquetes, se presume que la estación
pueda estar presentando alguna falla. Cuando eso ocurre se dice que la estación se
encuentra en Sleeping Cell. Los contadores analizados para identificar BTS en
Spleeping Cell son:
 NBR_OF_DL_TBF: Almacena el número de TBFs (Temporary Block

Flows) manejados en DownLink. Los TBFs son unidades de transporte para
los paquetes de datos.
 NBR_OF_UL_TBF: Almacena el número de TBFs manejados en UpLink
El estudio de la información que se maneja en los diagramas de procesos para el

establecimiento, control y manejo de llamadas, el conocimiento de la arquitectura de
la red GSM, la función de los equipos que constituyen la red y demás conceptos
desarrollados en este marco teórico son base fundamental para entender los capítulos
a continuación descritos
Página 20
Capítulo III
Metodología y Desarrollo
El proyecto de Trabajo Especial de Grado se dividió en cuatro actividades

principales, donde cada una de ellas tiene a su vez actividades específicas que
permitieron cumplir en los plazos establecidos los objetivos pautados inicialmente.
Las actividades se describen a continuación:
III.1. Análisis de la Red GSM de Digitel.
La metodología seguida para el análisis de la red GSM se basa en una consulta

bibliográfica en manuales de operación y libros proporcionados por la empresa, de los
cuales se extrajeron los contenidos agregados al Marco Teórico del proyecto,
cuidando el tema de la confidencialidad impuesta por la empresa en estos desarrollos.
Se hizo el estudio de cada uno de los subsistemas que conforman la red: el BSS
(Base Station Subsystem), el NSS (Network Switching Subsystem) y el NMS
(Network Management Subsystem); las funciones y la constitución de los equipos del
BSS. Se analizó la relación entre sus posibles fallas, su respuesta ante las mismas y la
generación de alarmas automáticas.
Se analizaron también los procesos de generación, control y manejo de llamadas.

Para ello se estudiaron diagramas de señalización entre el móvil y los equipos del
BSS y NSS involucrados en los diferentes procesos: MS (Mobile Station), BTS (Base
Transreceiver Station), BSC (Base Station Controler) y MSC (Mobile Switching
Center). Estos procesos proporcionan información de los llamados BSC Counters, los
cuales son contadores almacenados en la base de datos de la empresa, que guardan
registro del número de veces que ocurren determinados eventos tanto a nivel de BTS
Página 21
como de BSC y MSC, por ejemplo, durante el establecimiento, duración y

culminación de llamadas. Los BSC Counter contienen la información de las
mediciones obtenidas del subsistema del radio bases.
Existen gran cantidad de contadores por lo cual se hizo necesario realizar un estudio
detallado para identificar aquellos que permiten determinar la necesidad de
mantenimiento preventivo o correctivo.
III.2. Estudio de las mediciones disponibles en el subsistema de radio

bases.
El estudio de las mediciones disponibles en el subsistema de radio bases se realizó

con la revisión de manuales de Nokia, empresa fabricante de los equipos de la red, los
cuales contienen la descripción de los diferentes contadores, las tablas donde se
almacenan y las diferentes razones que producen su incremento.
Con la combinación de contadores según fórmulas matemáticas se calculan

diferentes indicadores de rendimiento de la red (PI Performance Indicators), los
cuales representan el desempeño en las BTS asociados a los procesos de control de
llamadas tanto de voz como de datos. La información de estas fórmulas se obtuvo
igualmente de la revisión de manuales de Nokia.
El estudio de las mediciones disponibles representa un punto importante dentro del

desarrollo del proyecto puesto que para identificar posibles fallas en los equipos de la
red se diseñaron e implementaron varios métodos para analizar la información
almacenada por los diferentes contadores involucrados.
Página 22
III.3. Estudio de acciones correctivas y preventivas para la

resolución de fallas en los equipos BTS de la red.
Para definir las acciones correctivas y rutinas de mantenimiento preventivo que son
aplicadas para atender las fallas de mayor ocurrencia en las BTS se estudiaron las
alarmas existentes en la red y se realizaron entrevistas con el personal de Operación y
Mantenimiento. La información obtenida se agregó a una tabla que muestra para cada
tipo de falla las razones que la producen y las rutinas preventivas o correctivas a cada
una de ellas.
Realizar entrevistas con el personal fue necesario puesto que, aunque la empresa
cuenta con una herramienta de Nokia que describe las alarmas generadas por los
equipos y la rutina que debe llevarse a cabo para cancelarla, con frecuencia estas
acciones no son aplicadas por razones de costo. En muchos casos la herramienta
indica que debe reemplazarse el equipo afectado cuando en la práctica pueden existir
acciones más eficientes para la resolución de las fallas. Con esta información el
sistema automáticamente identifica las acciones que se deben llevar a cabo para
atender las fallas detectadas.
III.4. Diseño e Implementación del Sistema.
El diseño del sistema se realizó tomando en cuenta los recursos disponibles en la

empresa para la obtención de las mediciones de desempeño de la red. Además se
diseñó considerando los requerimientos tanto de la empresa como los propios del
sistema. Las diferentes consideraciones analizadas para lograr el diseño finalmente
implementado se encuentran descritas en el siguiente capitulo así como la descripción
detallada del software desarrollado.
Página 23
Página 24
Capítulo IV
Resultados
En el presente Trabajo Especial de Trabajo se considera como resultado todo el

proceso de análisis y evaluación previa con el que se hizo posible definir el diseño
final del proyecto, así como también la aplicación implementada a partir de dicho
diseño. Ambos aspectos se describen a detalle en el presente capítulo.
IV.1. Diseño del Sistema.
El sistema de gestión diseñado es una herramienta que facilita la detección y

resolución de fallas en las radio bases a través del análisis estadístico de los diferentes
contadores que guardan información del desempeño de la red. En la Figura 9 se
muestra el esquema general de su funcionamiento.
Figura 9. Diseño General del Sistema
Página 25
El funcionamiento del sistema se diseñó partiendo de la conexión a la base de datos

de la empresa (OSS) para la obtención de la data almacenada en los BSC Counters.
Con esa información se calculan los porcentajes para los diferentes indicadores de
rendimiento (PI) durante un período de tiempo. Los resultados obtenidos son
analizados para identificar aquellas BTS que presentan alteraciones en su
funcionamiento en relación a lo normal o esperado de los equipos, lo que sugiere
posibles fallas en los mismos.
En caso de que se detecten interferencias en la interfaz aire que afectan servicio, el

sistema descartara a las BTS afectadas puesto que será la causa de la variación de los
indicadores de rendimiento y no una falla producto del mal funcionamiento de los
equipos.
Por otro lado, el sistema contempla detectar automáticamente las alarmas que se
encuentran activas al momento de analizar los indicadores de rendimiento. Esto se
debe a que cuando ocurre una falla en un equipo puede activarse o no una alarma en
la plataforma de monitoreo actual. Si se genera una alarma, la información permite
identificar las causas de la variación en los porcentajes de fallas calculados. Por
ejemplo, si una BTS genera una alarma que indica falla en un TRX (Unidad
transceptora), sus indicadores se verán afectados ya que la estación no podrá cursar
llamadas a través del equipo. En caso de que no se detecten alarmas en los equipos, la
información obtenida de los contadores se analiza para identificar las posibles causas
que producen la variación en los indicadores de rendimiento.
Una vez identificadas las fallas y sus posibles causas se consulta la información de
las acciones correctivas o preventivas almacenadas en la base de datos implementada
para el sistema. Según sea el tipo de falla, las rutinas pueden ser aplicadas de forma
automática o pueden requerir de la participación del personal de la empresa.
Para realizar las acciones automatizadas el sistema utiliza una interfaz remota a los
equipos BTS estableciendo un canal de comunicación entre el PC y las BSC de la red
a través de la intranet de la empresa.
Página 26
Por último, los resultados del análisis estadístico y de las alarmas detectadas son
notificados vía mail con la información que sirve de soporte al personal de
mantenimiento para la resolución de las fallas. Adicionalmente, puesto que la
notificación puede ser más efectiva vía SMS, se implementó un módulo para el envío
de las estaciones que presentan alarmas al terminal móvil del personal encargado de
atender las fallas.
IV.1.1. Métodos de Análisis de los Indicadores de Rendimiento
Los indicadores de rendimiento analizados detalladamente para ser utilizados en el

proyecto fueron aquellos continuamente monitoreados por el personal de la empresa,
con la finalidad de reducir el tiempo de análisis invertido. Se definió que el sistema
analice específicamente los indicadores de Call Setup Failure, Handover Failure y
Drop Call para el análisis de las estadísticas asociadas al control de llamadas de voz.
Durante el desarrollo del proyecto se diseñaron varios métodos para analizar estos
indicadores.
Como se muestra en la Figura 10, los métodos parten siempre de una hipótesis, la
cual es puesta a prueba para luego analizar los resultados obtenidos. Del análisis se
obtiene como resultado una lista de estaciones que pueden estar presentando fallas en
un momento determinado. Esta lista es revisada utilizando las herramientas existentes
en la empresa con la finalidad de identificar si realmente esas estaciones requieren de
una rutina de mantenimiento preventivo o correctivo. Si los resultados no son del
todo significativos se plantea una nueva hipótesis a probar con la finalidad de obtener
mejores soluciones.
Página 27
Hipótesis
Pruebas
Análisis y Diseño a
Conclusiones Implementar
Figura 10. Diagrama de Actividades
Para analizar los indicadores de Link Budget y Sleeping Cell no se hizo necesario el
planteamiento de varias hipótesis. En estos casos el método de análisis implementado
fue diseñado por el personal de la empresa basado en su experticia.
A continuación se explican cada uno de los métodos diseñados e implementados

para los diferentes indicadores de rendimiento.
IV.1.1.1. Análisis de los Indicadores de Voz
Los indicadores de Call Setup Failure, HandOver Failure y Drop Call están
asociados al rendimiento de los equipos durante las llamadas de voz. Para garantizar
este servicio, la empresa define los llamados KPI (Key Performance Indicators), los
cuales son porcentajes de fallas permisibles para cada uno de los indicadores de
rendimiento (PI Perfoemance Indicator). Con los KPI la empresa asegura la calidad
de servicio ofrecida a sus clientes. Para el porcentaje de fallas debidas a problemas en
el establecimiento de llamadas (CSF) el KPI definido es del 5%, el de HandOver
(HOF) es 7% y el de llamadas caídas (DC) es 3%.
Página 28
Existen estaciones cuyos porcentajes superan estos umbrales aún cuando no

presentan fallas en su funcionamiento. Por ejemplo, esto es posible cuando la
configuración de los equipos BTS no permite satisfacer las solicitudes de llamadas
por falta de capacidad física.
Adicionalmente se sabe que los porcentajes varían de una hora a otra según el
desempeño de los equipos. Por ejemplo, es altamente probable que el porcentaje de
fallas de una BTS que presta servicio a un área de oficinas sea bajo durante las horas
y días no laborables, mientras que cuando hay actividades puede ocurrir que la
capacidad de llamadas de la BTS sea copada y por tanto nuevos intentos de llamadas
sean bloqueados, incrementando así los porcentajes de fallas.
Basado en lo anterior se planteo la siguiente hipótesis:
Hipótesis 1: Las estaciones que posiblemente presentan fallas en su

funcionamiento según sus indicadores de CSF, HOF y DC son aquellas que satisfacen
simultáneamente las siguientes condiciones:
1. El porcentaje de fallas actual para cada indicador de rendimiento supera su

respectivo KPI: (%) Fallas Actual > KPI
2. El porcentaje de fallas actual supera al de la semana anterior a la misma hora.

Esto permite analizar el rendimiento de las BTS bajo las mismas condiciones. Se
considera además un cierto porcentaje permisible (margen) con respecto al de la
semana anterior, el cual es definido a través de una interfaz de usuario, como se
muestra en la siguiente inecuación:
(%) Fallas Actual > (%) Fallas de la Semana Anterior + Margen

a la misma hora
La Figura 11 muestra la representación grafica de la hipótesis 1 planteada

utilizando un diagrama de barras superpuestas. La barra de color rojo representa el
comportamiento de una estación que posiblemente presenta fallas.
Página 29
Fallas (%)
% Fallas Actuales
% Margen
KPI
% Fallas Semana
Anterior
Indicador
Figura 11. Representación Grafica de la Hipótesis 1
Se experimentó a diferentes horas y días, variando el parámetro de Margen para

cada indicador, con la finalidad de analizar si las estaciones que resultaban de este
método presentaban realmente fallas en su funcionamiento.
Al verificar el estado de operación de las BTS resultantes, utilizando las

herramientas con las que dispone actualmente el personal, se observó que algunas de
ellas no presentaban fallas. Además existían estaciones que tenían un bajo
rendimiento y no eran detectadas con análisis realizado por el sistema.
Los resultados obtenidos permitieron identificar que las estadísticas de la semana

anterior podían no reflejar el funcionamiento normal de la BTS. Por ejemplo, si una
estación registró una falla durante la semana anterior, sus estadísticas están alteradas,
por lo cual no es significativo comparar contra ellas.
Para mejorar la hipótesis planteada se decidió llevar un histórico que almacenara la

información de los contadores en función de días y horas, con esto se obtiene una
mejor aproximación al comportamiento real de las BTS. Para ello se diseñó e
Página 30
implementó una tabla en la base de datos del sistema en la que se agrega la data leída
del OSS de cada hora del día, los 7 días de la semana.
A medida que se agregue mayor cantidad de data con información actualizada de

los contadores será posible calcular mejores promedios con los cuales comparar en
rendimiento actual de los equipos. Este proceso se denomina Afinación de los
Perfiles.
Para el cálculo del promedio, se tiene la información del número de afinaciones

realizadas al perfil de cada contador y un campo que guarda la suma de sus valores.
La Figura 12 muestra la estructura de la Tabla de los Perfiles de Contadores
S uma C o ntadores
N umero de A finac io nes
F echa U ltim a Actua lizac io n
Figura 12. Estructura de la Tabla de los Perfiles de Contadores
El Promedio por contador se calcula entonces como:
Prom_ContN = Suma_ContN / Número de Afinaciones
Página 31
La fecha de cuando se realizó la última actualización del perfil es también de mucha

importancia ya permite asegurar que no se realizará más de una afinación a la
semana, evitando de esta forma agregar data ya procesada. De no ser así se podría
tener data duplicada en la base de datos del sistema, afectando por ende los valores
promedio manejados
Hipótesis 2: El porcentaje de fallas actual debe ser mayor al valor promedio, el

cual es definido para cada día y hora utilizando la estructura de Perfiles de
Contadores, más un cierto margen de incremento permisible con respecto a dicho
valor promedio como se muestra en la siguiente ecuación:
(%) Fallas Actual > (%) Fallas Promedio + Margen

según ‘Perfiles’
El Margen se define con un porcentaje del promedio de fallas del día y hora
analizado. El término Variación que se muestra en la siguiente inecuación es el que
indica el porcentaje de incremento permisible del promedio de fallas
(%) Fallas Actual > [ (1 + Variación) * (%) Fallas Promedio ]

Por ejemplo, una Variación igual a 0.3 representa un incremento del 30% del
promedio de fallas. Como se muestra en la Figura 13, si el promedio de fallas actual,
(para el día Jueves a las 5 pm) es 10% y la Variación es de 0.3, el sistema considerará
que una estación presenta un posible problema en su funcionamiento si su porcentaje
de fallas actual es superior al 10.3%.
Página 32
% Fallas
Jueves, 5 pm
10.3
10
24 48 72 96 120 144 Horas

Lun Mar Mie Jue Vie Sab Dom
Figura 13. Gráfica de los Perfiles de Contadores
Definir el Margen en función del porcentaje de fallas leído de los Perfiles resulta
efectivo sabiendo que cuando el valor promedio de los indicadores de rendimiento de
una BTS es elevado, generalmente se debe a que el comportamiento normal de la
estación es altamente variable, por lo que detectar una falla en su funcionamiento es
posible cuando el valor del indicador es considerablemente mayor a su rendimiento
promedio. Para esos casos debe considerarse un margen más grande. En caso
contrario, cuando una BTS mantiene bajos sus indicadores, se recomienda monitorear
el rendimiento de los equipos con márgenes más bajos
Durante esta parte del desarrollo se realizaron también pruebas con los parámetros
estadísticos de desviación estándar y varianza, con la finalidad de identificar si con
estas medidas de dispersión era posible definir el margen necesario para detectar
posibles fallas. De estas medidas se tiene información de la lejanía de una serie de
datos respecto a la media. Para ello se obtuvo información de una base de datos que
guarda el valor de cada indicador de rendimiento con las medidas obtenidas del
subsistema de radio bases al final de cada día. Con la data de un mes de todas las
estaciones se realizó el cálculo de la varianza y desviación estándar.
Página 33
Los resultados obtenidos tendían siempre a cero, de lo que se concluye que el

comportamiento de las estaciones al final del día es bastante cercano al promedio para
un grupo de datos de un mes. Las fallas ocurridas en las estaciones no afectan
significativamente las medidas de dispersión calculadas. Éste cálculo no fue agregado
al diseño finalmente implementado.
Para iniciar las pruebas de la hipótesis planteada se realizaron cuatro afinaciones de

los perfiles de contador, lo que equivale a procesar la información de un mes (en cada
afinación se carga la data de una semana). Se realizaron pruebas a diferentes horas y
días cambiando el valor del parámetro Variación. La lista de estaciones que
posiblemente presentan fallas se revisó a detalle obteniendo que efectivamente
muchas de las BTS resultantes tenían alguna irregularidad en su funcionamiento.
Igualmente, las estaciones que el personal conocía que presentaban alguna falla
estaban resultando del análisis realizado. Sin embargo, salían otras estaciones que no
eran significativas puesto que no tenían ninguna falla en sus equipos.
Revisando detalladamente el comportamiento de las estaciones no significativas se

observó que en muchos casos el tráfico de llamadas cursadas es poco, lo cual produce
que los porcentajes de fallas puedan incrementarse considerablemente. Por ejemplo,
si el porcentaje promedio de llamadas caídas de una BTS es de 5%, y el número
actual de llamadas cursadas es 10, su Drop Call actual puede variar a 10% con sólo 1
llamada caída, lo que no implica que la estación presente alguna falla.
Para contemplar que el sistema analice en función del tráfico de llamadas cursadas
se diseñó que el valor del parámetro Variación no sea definido como una constante
sino como una función que modele el comportamiento estudiado en relación al
número de llamadas.
Página 34
Hipótesis 3: El porcentaje de fallas actual debe ser mayor al promedio más un

cierto porcentaje de incremento permisible con respecto a dicho valor promedio. Este
incremento viene definido por el parámetro Variación. El valor de este parámetro se
obtiene luego de evaluar una función expresada en términos del número de llamadas
cursadas, como se muestra a continuación:
(%) Fallas Actual > [ (1 + Variación) * (%) Fallas Promedio ]

Donde:
Variación = Base_min * [ ( 1 – e ( -1 / llamadas ) ) * Ajuste +1 ]
El parámetro Variación es una función exponencial con la cual el porcentaje

permisible con respecto al promedio es mayor cuando el número de llamadas
cursadas es menor, y va disminuyendo a medida que se incrementan las llamadas
hasta llegar al valor al cual tiende la función.
El factor Base_min define el valor al cual tiende la función para un número elevado
de llamadas. Esto se deduce de evaluar la función cuando las llamadas tienden a
infinito. De esa evaluación se tiene que la exponencial tiende a 1, y por lo tanto
(-1/llamadas)
(1– e )*Ajuste tiende a 0, resultando entonces el valor de Base_min.
El factor Ajuste define las pendientes de la curva haciendo que su descenso sea más
o menos suave, además, influye en el valor de la función cuando el número de
llamadas tiende a cero.
En la gráfica mostrada en la Figura 14 se observa los valores del parámetro

Variación en función del número de llamadas cursadas para valores de Base_min
=1.2 y Ajuste=5.
Página 35
Gráfica que muestra la Función de Variación
Variación 3
0
20
40
60
80
1
10
12
14
16
18
20
22
24
26
28
30
Num Llamadas
Figura 14. Grafica de la Función Variación
Base_min y Ajuste son factores positivos, mayores que cero con los que es posible
afinar el análisis hasta obtener los mejores resultados.
Cada indicador de rendimiento tiene asociado sus propios factores (Base_min y

ajuste) los cuales se pueden manipular para obtener la escala que mejor se aproxime a
la solución deseada.
Luego de realizar diferentes pruebas para distintos valores de Base_min y Ajuste se

logró obtener que las estaciones que cursan pocas llamadas no salieran como
resultado del análisis sino cuando su porcentaje de fallas actual estuviese
considerablemente superior a su promedio
Para la implementación de esta solución se decidió eliminar la condición planteada

de que el sistema detecte posibles fallas solo si sus indicadores de rendimiento
superan los respectivos KPIs (umbrales definidos por la empresa). Esto se definió en
la primera hipótesis pero para el diseño final se consideró que una estación puede
fallar aún cuando no supere los KPI. Si por ejemplo, el HOF promedio en una
estación es de 0.5% y sube a 6.5%, el equipo puede tener algún problema a pesar de
que el KPI establecido para HOF es de 7%.
Página 36
En el diseño finalmente implementado también se considera que el sistema analice

las estaciones de bajo tráfico con la información no sólo de la última hora, sino que
agrupe varias horas consecutivas. La razón es que en estas estaciones los indicadores
de rendimiento normalmente varían considerablemente de una hora a otra, por lo que
agrupando varias horas se tiene una mejor aproximación al comportamiento esperado.
Para ello se definió el parámetro de Tráfico en Erlangs, con el cual el sistema
establece que toda BTS cuyo tráfico actual sea mayor al valor de dicho parámetro se
analizara como estación de alto trafico. En caso contrario, será considerada una BTS
de bajo tráfico. Este parámetro al igual que la cantidad de horas a agrupar puede ser
definido a través de la interfaz de usuario implementada para el sistema.
Causas del Incremento en los Porcentajes de Fallas
Para identificar las causas que producen el incremento de los indicadores de

rendimiento de la red de voz se identifican cuáles son los contadores que guardan
registro de fallas en el establecimiento y duración de una llamada. Para ello se utiliza
la información de los manuales de Nokia que muestran la descripción de los
diferentes BSC Counters.
El sistema agrega al detalle de fallas suministrado al personal la información de los

cinco contadores que registran los valores más altos, ya que son ellos quienes hacen
que su porcentaje de fallas se incremente de tal forma, esto según la experiencia
adquirida empleando las herramientas actuales.
Otra información importante que permite discriminar si los porcentajes de fallas son
realmente significativos es la cantidad de llamadas y el número de solicitudes de
canales de señalización que cursan las estaciones. Es por ello que en el detalle de
fallas que arroja el sistema también se agrega la siguiente información:
 Para el caso de Call Setup Failure, se calcula el número de solicitudes de

canales SDCCH y el número de SDCCH fallidos:
Página 37
SDCCH_Request = SDCCH_SEIZ_ATT
SDCCH Fallidos = SDCCH_Request * %CallSetup_Failure / 100
 Para el caso de Drop Call, se calcula el número total de llamadas y el número

de llamadas caídas:
Núm_Llamadas = TCH_NORM_SEIZ + MSC_I_SDCCH_TCH + …
Núm_Llamadas_Caídas = Núm_Llamadas * %DropCall / 100
 Para el caso de HandOver Failure, se calcula el número de HandOver y el

número de HandOver Fallidos:
Núm_HO = MSC_I_TCH_TCH_AT + MSC_I_SDCCH_TCH_AT + …
Núm_HO_Fallidos = Núm_HO * %HandOver_Failure / 100
IV.1.1.2. Análisis del Link Budget en las Antenas
Para detectar fallas en el funcionamiento de las antenas el sistema analiza el

indicador de Link Budget, el cual se define como la diferencia entre la señal en
DownLink y en UpLink, medida en dB, en un momento determinado, por ello el
sistema lo calcula como:
Link_Budget = AVE_DL_SIGN_STR - AVE_UL_SIGN_STR
El Link Budget de un día específico se calcula con la información de los contadores

del día anterior. Esto se debe a que ellos guardan el promedio de las señales en dB
durante las 24 horas de un día, por lo que no es posible tener disponible esta
información sino luego de culminado el mismo.
Página 38
Cuando las antenas mantienen el valor del Link Budget en el tiempo se espera que
no presenten fallas en su funcionamiento. Según eso se puede definir que el valor
promedio de los contadores involucrados durante un período de tiempo considerado
representa el comportamiento normal esperado.
Para calcular el valor promedio de Link Budget de cada estación se utiliza la

información almacenada en una tabla creada en la base de datos del sistema con una
estructura similar a la utilizada para los Perfiles de Contadores como se muestra en la
Figura 15
Figura 15. Estructura de la Tabla de los Perfiles de Link Budget
El número de días a considerar para el cálculo del promedio se obtiene luego de

definir el período de tiempo contra el que se desee comparar. Esta fecha de inicio y
fin del período es establecida a través de una interfaz de usuario.
Para determinar que una BTS pueda estar presentando fallas que afecten los niveles
de señal entre ella y el Móvil se obtiene el valor promedio del Link Budget
correspondiente de la estación y se define un margen en dB permisible. Si la BTS
presenta fallas de Link Budget debe cumplir la siguiente inecuación:
Link_Budget_Actual > Link_Budget_Promedio + Margen
Página 39
El Margen se define con la información suministrada del personal puesto que por
experiencia conocen que cuando la variación con respecto al promedio es mayor a
3dB la antena posiblemente presenta algún problema. Esta información fue
comprobada revisando el histórico de las estadísticas arrojadas por BTS cuyas
antenas fueron reemplazadas a causa de degradación de la potencia.
Comprobar que la hipótesis planteada es válida para cualquier caso de fallas de

antenas por Link Budget no fue posible puesto que es poco común que ocurran
problemas de este tipo. El valor del Margen puede ser modificado a través de una
interfaz de usuario.
IV.1.1.3. Análisis de Sleeping Cells para Datos
Para identificar estaciones que presenten fallas en el servicio de datos se analiza el

indicador de Sleeping Cells, con el cual se conocen las BTS que no responden a las
solicitudes de descarga de datos de parte de los equipos móviles, lo cual quiere decir
que estas estaciones reciben peticiones (tráfico de datos en UpLink) pero no
responden (tráfico en DownLink)
El análisis de Sleeping Cells requiere de la información obtenida del subsistema de

radio bases, específicamente de las Unidades Controladoras de Paquetes (PCU), para
conocer el número de TBFs (Temporary Block Flows) transmitidos y recibidos, para
ello el sistema obtiene de la base de datos de la empresa las estadísticas
correspondientes a la última hora.
Debido a que en la red es normal la presencia de tráfico de datos que correspondan

a señalización y no a solicitudes de móviles, se consideró definir para el análisis del
sistema un número de TBFs en UpLink que sirva de umbral para descartar aquellas
estaciones que no cursan datos en DownLink por no haber solicitudes. El umbral es el
número máximo de TBFs que se consideran como tráfico de datos por señalización.
Página 40
Si se supera el umbral el sistema se considera que la BTS está recibiendo solicitudes

de parte del móvil por lo que en caso de que no se registren descargas, se presume
que la estación tiene fallas por Sleeping Cell.
Una BTS presenta fallas por estar en Sleeping Cell cuando:
NBR_OF_DL_TBF = 0 y NBR_OF_UL_TBF > Umbral
Las pruebas realizadas definiendo un Umbral según el conocimiento de la red de

datos del personal de operaciones y mantenimiento. El valor establecido es de 100
TBFs en UpLink. Las pruebas realizadas indican que para valores por encima de este
umbral la estación presenta algún problema en la transferencia de datos. El valor de
este Umbral puede variarse a través de una interfaz de usuario implementada.
IV.1.2 Establecimiento de la Conexión remota a las BSC
Las BSC son las estaciones controladoras a través de las cuales se manejan los
equipos del subsistema de radio bases cuando se ejecutan labores de mantenimiento
de forma remota. Estableciendo una conexión entre los PC y las BSC se monitorea
por ejemplo el estado de operación de los equipos, es decir, si estos se encuentran
bloqueados o no para el tráfico de llamadas o si tienen alarmas presentes que deban
ser atendidas para no afectar el servicio. También se pueden llevar a cabo acciones
como de reseteo de los equipos para la resolución de fallas sin necesidad de
desplazarse al lugar donde se encuentra el problema.
Para establecer la comunicación con las distintas BSC de la red, el cliente debe
conectarse a uno de los dos routers existentes, identificados por una dirección IP. En
estos routers el cliente encontrará todas las ubicaciones (direcciones IP) de las BSC
pertenecientes al sistema. Una vez determinada la ubicación de la BSC deseada, se
debe autenticar contra dicha BSC, a través de un par usuario/contraseña, para poder
acceder a la consola donde se ejecutan los comandos MML.
Página 41
A cada uno de los comandos enviados a las BSC se obtiene una respuesta con
formato fijo. Por ejemplo, para consultar las alarmas activas en una BSC se ejecuta el
comando ZEOL. La información arrojada se presenta en el siguiente formato:
BSCNAMEXXXX BCF-### BTS-### YYY-MM-DD HH:MM:SS

TRX-### BTSNAMEXXXXX
ENABLE
ALARM #ALARMA DESCRIPCIÓN ALARMA
La respuesta a todos los comandos es almacenada en un archivo de texto de donde

se lee las posiciones en las que se encuentra la información necesaria para el sistema,
como los números de las BCF, BTS y ranuras de tiempo afectados.
El sistema implementado envía automáticamente comandos para:
1. Consultar alarmas activas en los equipos
2. Ejecutar rutinas preventivas o correctivas para la resolución de las fallas

detectadas,
Conocer las alarmas activas en los equipos de la red permite complementar el

análisis realizado por el sistema. Si la falla detectada activa alarmas en la plataforma
de monitoreo actual, esta información con frecuencia ayuda a determinar las causas
de las alteraciones registradas en las estadísticas arrojadas por los equipos.
Para la resolución de las fallas detectadas se obtiene la información de las acciones

a aplicar de forma automática de la Tabla de Rutinas de Atención, la cual define para
cada tipo de alarma los pasos a seguir, como se muestra en Tabla 1.
Página 42
Num. Nombre Descripción Rutina

Alarma Alarma
Falla que indica que el sistema ha 1. Bloquear la ranura de tiempo

bloqueado la ranura de tiempo afectada.
porque el control de llamada ha 2. Bloquear TRX.
TRAFFIC fallado un número de veces en la 3. Luego de esperar un tiempo,
7725 CHANNEL activación de los canales TCH. desbloquear TRX.
ACTIVATION 4. Cuando el TRX este
FAILURE Si la alarma aparece trabajando WO, se desbloquea
simultáneamente en varias ranuras la ranura de tiempo
de tiempo y en varios TRX 5. Si la falla continúa, resetear el
distintos, y automáticamente se sector
cancela, la alarma es consecuencia 6. Si la falla persiste, reemplazar
de algún problema de transmisión. el TRX
Tabla 1. Modelo de la Tabla de Alarmas
Los comandos MML enviados automáticamente por el sistema son:
 ZEEI: Para obtener la configuración de la BTS, el estado de operación,

frecuencia, tráfico de llamadas
 ZEOL: Para obtener las alarmas activas en las BTS controladas por una BSC
específica
 ZERS: Para Resetar TRX
 ZEFR: Para Resetear BCF
 ZEQS: Para Resetear BTS
IV.2. Implementación del Sistema.
El mecanismo de detección temprana de fallas, la determinación de rutinas

correctivas y la aplicación de las mismas debe ser automatizado con una
implementación de software.
Página 43
La funcionalidad principal del sistema es la detección temprana de fallas y la

determinación de rutinas correctivas para su aplicación, pero para el proceso de
notificación a usuarios se requirió la implementación de varias funcionalidades que
permiten el envío y configuración de dichas notificaciones.
La aplicación utiliza diversas herramientas para implementar las distintas

funcionalidades, como un manejador de base de datos relacionales para almacenar la
información hasta librerías disponibles en el lenguaje de programación utilizado para
el envío de correos electrónicos, por ejemplo.
La implementación del software se realizó en el lenguaje de programación Visual

Basic 6.0 por las facilidades que presta para el desarrollo de aplicaciones en un
entorno gráfico (GUI Graphical User Interface) y la variedad de bibliotecas para
manejo de base de datos, puertos, entre otros.
A continuación se describen los aspectos resultantes del sistema diseñado y

desarrollado.
IV.2.1. Modelo de la Base de Datos
Toda aplicación que requiera almacenar datos a través del tiempo debe contar con
un medio de almacenamiento. Las bases de datos relacionales son muy usadas en la
actualidad, razón por la cual se escogió como el medio a utilizar para almacenar toda
la información requerida por el software implementado.
Se realizó un Modelo de Entidad-Relación que muestra gráficamente como está

organizada la información en una base de datos relacional. Luego de las pruebas
concepto realizadas al modelo se implementó la base de datos en el manejador
MySQL 5.
En la Figura 16 se muestra el modelo final, sin embargo los detalles de cada una de
las tablas y relaciones se describen en el Apéndice A.
Página 44
Figura 16. Modelo Entidad Relación
IV.2.2. Estructura de la Aplicación
La aplicación realiza dos tareas principalmente: Actualiza los perfiles de los

contadores y analiza los contadores para hacer la detección temprana de fallas. Cada
una de estas tareas fue implementada en un ejecutable distinto y se corren cada cierto
tiempo de forma automática para mantener actualizadas las estadísticas y reportar las
anomalías detectadas a los operadores de la red.
Página 45
Las implementaciones de estas tareas fueron separadas porque pueden ejecutarse

con una periodicidad distinta, ya que la afinación de perfiles requiere de un tiempo
considerablemente mayor al requerido por la detección temprana de fallas.
Para poder manipular a detalle los elementos del sistema, se implementó un tercer
ejecutable. Este cuenta con una interfaz gráfica de usuario mediante la cual el usuario
puede editar los perfiles de los contadores, editar los perfiles de Link Budget,
configurar las notificaciones, entre otras opciones.
IV.2.2.1 Actualización de los Perfiles
Este ejecutable no cuenta con una interfaz grafica de usuario ya que es ejecutado
automáticamente por un programador de tareas. Su hilo de ejecución principal realiza
las siguientes operaciones:
 Se conecta con la base de datos de la empresa (OSS)
 Para cada BTS, consulta los valores de los contadores para cada hora de cada
día de la semana anterior.
 Se actualiza cada uno de esos contadores en la base de datos del sistema

implementado
Observando las operaciones realizadas por este ejecutable se puede entender

claramente que el volumen de datos manejados es considerablemente alto, cosa que
se ve reflejado en los tiempos de ejecución del mismo. En las pruebas del sistema, se
obtuvieron tiempos de aproximadamente minuto y medio por estación (en una PC
Pentium 4 CPU 2.8GHz con 760 MB de RAM). Actualmente existen más de 1200
estaciones en la red de la empresa, lo que indica tiempos de ejecución de mas de un
día.
Página 46
IV.2.2.2. La detección temprana de fallas
Al igual que las actualizaciones, este ejecutable no cuenta con una interfaz gráfica
de usuario. Su hilo de ejecución principal realiza las siguientes instrucciones:
 Se conecta con la base de datos de la empresa (OSS)
 Para cada BTS, se consulta cada uno de los contadores necesarios
 Haciendo uso de los perfiles almacenados en la base de datos del sistema

implementado, se procede a realizar el análisis de los indicadores
 Si se detecta una falla o alarma, se envía una notificación al personal

responsable para el momento de la ejecución (vía SMS y/o correo
electrónico).
 De ser posible, se ejecuta automáticamente la acción correctiva, conectándose

directamente a la BSC afectada.
Este ejecutable es el responsable de detectar las fallas del sistema y de darles

solución temprana, ya sea ejecutando directamente la acción correctiva o notificando
al personal operativo que se encuentra de guardia al momento en que se ejecutó la
detección.
En la implementación del módulo que realiza las notificaciones, se usó la librería de

Visual Basic Microsoft Outlook 11.0 Object Library para el envío de correo
electrónico. Para la notificación vía SMS se utilizó un MODEM Enfora SA-G, el cual
se conecta al computador a través del puerto serial utilizando la librería de Visual
Basic Microsoft Com Control 6.0. A través de este puerto se realiza el envío de los
llamados Comandos AT con los que el MODEM recibe la información necesaria para
el envío del SMS: número de teléfono destino y texto del mensaje. Los detalles de las
características del MODEM utilizado y descripción de los comandos AT se
encuentran en el Anexo A.
Página 47
La configuración de la periodicidad de la afinación de los perfiles y de la detección

de fallas se hace a través de un sistema externo que corra los ejecutables
correspondientes cada cierto tiempo. Actualmente esta programación es realizada por
el Manejador de Tareas Programadas del Sistema Operativo Windows.
IV.2.2.3. El administrador del sistema
Este es el ejecutable que permite al usuario interactuar con el sistema,

permitiéndole manipular la configuración del mismo y además le permite acceder las
funcionalidades periódicas (la afinación y la detección de fallas) para ejecutarlas de
forma manual. Las interfaces implementadas en este ejecutable permiten:
 Configurar las notificaciones.
o Agregar y Eliminar personal de guardia
o Definir periodos de guardia del personal
 Configurar Servidor
o Datos de conexión con las BSC de la red
o Modificación de los parámetros empleados en la evaluación de los

indicadores (Ej: Margen en db para el análisis del Link Budget).
o Configuración de los envíos de notificaciones (SMS y correo

electrónico)
 Actualizar BTS de la Red
o Ya que el sistema implementado mantiene una lista de las BTS de la

red, se implementó un proceso de actualización en el cual se pueden
integrar las nuevas BTS.
 Consulta de alarmas de los equipos
Página 48
o Permite consultar, agregar y eliminar las alarmas propias de los

equipos a monitorear por el sistema.
 Manejar Perfiles
o Permite consultar, afinar o reiniciar los contadores de una BTS o BSC

individualmente.
 Manejar Perfiles de Link Budget
o Ya que estos perfiles no se afinan, se permite editar el periodo de

tiempo a usar de referencia para el análisis.
 Ejecutar Detección Temprana de Fallas
o Permite hacer una corrida para detectar fallas en toda la red.
Es importante destacar que las configuraciones aquí modificadas afectan a los

ejecutables de Afinación de Perfiles y Detección Temprana de Fallas (ya que
comparten la misma base de datos).
En el Apéndice B se muestra el detalle de cada una de las interfaces implementadas

para la manipulación de la información almacenada en la base de datos del sistema.
IV.3. Una corrida de la Detección Temprana de Fallas desde el

Administrador del Sistema
El ejecutable Administrador del Sistema cuenta con la barra de herramientas

mostrada en la Figura 17 donde se observa el menú con las diferentes funcionalidades
implementadas y botones de acceso directo a alguna de ellas.
Página 49
Para realizar una corrida del sistema de detección de fallas desde el Administrador
se utiliza el botón de Ejecutar Análisis, desde donde se inician los diferentes
procedimientos con los que se obtienen las BTS cuyo desempeño no es el deseado.
Figura 17. Barra de Herramientas
Luego de consultar a la base de datos del sistema el valor de los diferentes

parámetros requeridos, la aplicación muestra dicha información en una interfaz de
usuario como la mostrada en la Figura 18. La ejecución del análisis por defecto se
realiza con esta información, sin embrago, en esta interfaz es posible editar cualquiera
de los valores para la corrida a realizar.
Página 50
Figura 18. Interfaz de Edición de Parámetros
El parámetro Tráfico indica el umbral en Erlangs definido para identificar las

estaciones de bajo tráfico y de alto tráfico necesario para realizar el análisis de sus
estadísticas según les corresponda.
Análisis BTS de Bajo Tráfico permite seleccionar la cantidad de horas que se

desea agregar al análisis realizado, es decir, se agrupan las estadísticas obtenidas a la
hora actual con las del número de horas anteriores al seleccionado. En el ejemplo, si
la aplicación corre a las 5:13 PM, como se muestra en el campo Hora, el análisis de
las BTS de bajo tráfico se realiza sobre las estadísticas de 4:00 a 4:59 PM, y a estas se
les agrega las de la hora anterior (de 3:00 a 3:59 PM) porque la cantidad seleccionada
es 1 Hora en el campo Análisis BTS de Bajo Tráfico.
Página 51
Los parámetros de Base_min y Ajuste para los indicadores Call Setup Faiulre
(CSF), HandOver Failure (HOF) y Drop Call (DC) definen la función de Variación
empleada para el análisis en cada caso.
En la sección Interferencia se define el Margen en porcentaje con el que descarta

el análisis de las estadísticas en aquellas estaciones que presenten un porcentaje de
interferencia por encima al margen definido.
El Margen en la sección Link Budget define el valor en dB permisible por encima

del promedio que determina si las estaciones presentan o no fallas en el
funcionamiento de sus antenas.
El parámetro NBR_OF_UL_TBF en Spleeping Cell define el número de TBFs en

UpLink que sirve de umbral para identificar a las estaciones que presentan fallas por
este concepto y descartar las que no cursan datos en DownLink pero por no haber
solicitudes en UpLink
El UserName y Password los utiliza el sistema para autenticarse en cada una de las
BSC de la red.
El botón de Conectar inicia la ejecución del análisis con los valores definidos. La
herramienta calcula el tráfico en Erlangs de todas las estaciones con la información
que obtiene de la base de datos de la empresa a la última hora, con ello se define si es
una BTS de alto trafico o de bajo trafico. Para cada caso el sistema consulta las
estadísticas y realiza las evaluaciones necesarias. Los resultados obtenidos se
muestran en una interfaz como la mostrada en la Figura 19.
Página 52
Figura 19. Interfaz de Visualización de Resultados
En la Figura 19 se muestra que la estación CASARAPA2 presenta una falla de

Drop Call el día 3 de Octubre a las 9 AM, la cual fue enviada vía mail al personal
configurado para recibir la notificación como se muestra en la Figura 20. El detalle de
la falla se muestra en un archivo de texto como se observa en la Figura 21
Página 53
Figura 20. Ventana de Notificación de Fallas vía mail
Figura 21. Ventana de Archivo con el detalle de Falla
Página 54
La Figura 21 muestra que la variación en el porcentaje de fallas por llamadas caídas

en CASARAPA2 se debe al incremento del contador SDCCH_BCSU_RESET, el
cual indica, según la documentación de Nokia para este contador, que el canal
SDCCH se pierde debido al boqueo del TRX a razón del reseteo continuo de la
unidad BCSU (Base Station Controller Signalling Unit), siendo esto indicador del
mal funcionamiento del equipo.
La consulta de las alarmas activas en los equipos utilizando los comandos MML
genera un archivo de texto del que se lee la información enviada vía mail y SMS al
personal de la empresa. Al mail enviado se adjunta la descripción de las alarmas y de
las rutinas de atención que deben ser aplicadas para cancelarlas (Ver Figuras 22 y 23).
Para este ejemplo se obtuvo que en las alarmas detectadas no había ninguna
asociada a CASARAPA2. Con este caso se comprueba que con frecuencia ocurren
fallas en los equipos de la red que no activan alarmas en la plataforma de monitoreo
actual.
Figura 22. Ventana de Notificación de Alarmas Activas vía mail
Página 55
Figura 23. Ventana de Archivo con el detalle de Alarmas Activas
Para verificar que realmente se trata de una falla en la BTS se utilizan las
herramientas con las que dispone el personal para estas labores. Una de ellas es la
aplicación Daily Optimizer, la cual calcula el promedio de los indicadores de
rendimiento durante las 24 horas de un día. Los resultados que se muestran con esta
herramienta se obtienen una vez finalizado el día lo que implica que detectar una falla
podía tomar gran cantidad de tiempo.
Para el ejemplo de CASARAPA2, una vez detectada la falla se aplico la rutina de

resetear el equipo, con esto se logro solventar el problema y por tanto disminuir el
valor del indicador de Drop Call en la estación, como se muestra en la Figura 24
obtenida de la herramienta Daily Optimizer.
Página 56
Figura 24. Indicador de Drop Call de CASARAPA2 en el tiempo
Las rutinas correctivas implementadas fueron desarrolladas bajo la supervisión del

personal encargado, quienes probaron y validaron cada una de ellas. Sin embargo, por
políticas de seguridad de la compañía no se permite la ejecución de ninguna de estas
rutinas sin la presencia de un miembro autorizado del personal, por lo cual la
aplicación, de momento, no ejecuta estas rutinas de forma automática.
Página 57
Capítulo V
Conclusiones y Recomendaciones
La detección temprana de fallas en las BTS de la red es posible analizando las

estadísticas obtenidas de las mediciones disponibles en el subsistema de radio bases y
revisando las alarmas generadas por los equipos de forma automática. De esta manera
se logra minimizar el tiempo necesario para identificar alguna falla en los equipos.
La estrategia de analizar las estadísticas con el comportamiento de las BTS durante

la hora anterior permite que el sistema detecte las fallas con un tiempo máximo de
una hora de afectación del servicio, lo que resulta más óptimo que las herramientas
actualmente utilizadas para estas labores.
Llevar un histórico de las mediciones de los equipos por cada hora y día de la
semana permite comparar el funcionamiento de las BTS bajo las mismas condiciones
en cualquier momento que se realice el análisis de los indicadores de rendimiento.
Con ello se considera el hecho de que las estaciones normalmente varían sus
porcentajes de fallas según el día y hora.
Los datos estadísticos deben ser representativos del comportamiento normal de las
estaciones por lo que es recomendable que cuando ocurre una falla que afecte
significativamente la información almacenada de la estación, esta no sea procesada
para el cálculo del promedio. De no ser así será necesario que el sistema realice varias
afinaciones de los perfiles para volver a obtener los valores normales de la estación.
Para el análisis de fallas por Sleeping Cell no se requiere almacenar un histórico del
comportamiento de la BTS ya que cuando una estación recibe solicitudes de descarga
de datos y esta no responde, es de presumir que el equipo presenta alguna falla.
Página 58
El establecimiento de la comunicación con las BSC además de permitir conocer de

forma automática las alarmas generadas por los equipos facilita la ejecución de las
rutinas de mantenimiento preventivas o correctivo para atender las fallas cuando sea
posible, sin necesidad de conocer la sintaxis de los comandos MML requeridos. Esta
combinación de funcionalidades es de gran utilidad para reducir los tiempos de
resolución de las fallas detectadas.
La notificación vía mail y SMS resulta ser un mecanismo eficiente para distribuir
los resultados del análisis del sistema, además de que es de fácil implementación
gracias a las librerías disponibles en Visual Basic 6.0
Por la cantidad de información que necesita ser procesada por el sistema para
realizar los análisis de todas las estaciones de la red, se recomienda que la ejecución
de la misma se haga en una PC con los siguientes mínimos: Pentium 4 CPU 2.8GHz
con 760 MB de RAM.
La implementación de una pequeña aplicación de administración, con interfaz de

usuario, para modificar los diferentes parámetros requeridos por el sistema para la
análisis y notificación permiten que la aplicación se adapte a posibles cambios que
puedan ocurrir tanto en la red como en los diferentes departamentos involucrados.
Página 59
Referencias Bibliográficas
 Cornell, Gary (1999). Visual Basic 6.0 Manual de Referencia. (1° ed.). Madrid,
España: Mc Graw Hill.
 Charte, F. (1998). Programación con Visual Basic 6. Adquiera los fundamentos

básicos de programación. Madrid: Ediciones Anaya Multimedia.
 Gold, R. (1998). SYSTRA. NOKIA Training Material. System Training for GSM
1900. (3° ed.). Texas, USA.
 Laizzo, Armando (2005). Sistemas Celulares. (1° ed.). Caracas, Venezuela:

Corporación Digitel Tim.
 Mishra, Ajay. (2004) Fundamentals of Cellular Network Planning and

Optimization. (1° ed.). Inglaterra: John Wiley & Son.
 Nokia. (2002). BSS Network Doctor Formulas
 Nokia. (1998). Database Description for BSC Measurements. USA
 Nokia. (2001) NetAct_Documentation_20030325. Intranet Digitel.
 Nokia. (2002). Training Material. BSS Essentials Course. Texas, USA.
Página 60
Referencias Electrónicas:
 Data Sheet Modem Enfora SA-G TM [Información en Línea], disponible:

https://www.enfora.com/downloads/specsheets/GSM1208HR.pdf [Consulta:
2006, Julio 10]
 Set de Comandos AT Modem Enfora SA-GTM. [Información en Línea],

disponible:www.enfora.com/downloads/Intnotes/Enabler-
IIG%20AT%20Command%20Set%20GSM0107PB001MAN.pdf [Consulta: 2006,
Agosto 14]
 Tutorial MySQL 5. [Información en Línea], disponible:

http://dev.mysql.com/doc/refman/5.0/en/tutorial.html. [Consulta: 2006,
Febrero 20]
Página 61
APÉNDICE A
Descripción de la Base de Datos del Sistema
Página 62
Para almacenar los datos persistentes del sistema se diseñó e implementó una base
de datos relacional en el manejador MySQL 5.0. El diseño incluye los conceptos de
clave primaria, clave foránea e integridad referencial, para garantizar que los datos
almacenados se mantengan libres de errores. La figura A1 muestra el modelo
Entidad-Relación finalmente implementado.
Figura A1. Modelo Entidad – Relación
La Tabla BTS, mostrada en la Tabla A1, guarda información de las estaciones que
se encuentran integradas a la red. Se mantiene actualizada leyendo de la base de datos
de la empresa. La integridad referencial del modelo asegura que no habrá información
en el sistema que no corresponda a las BTS incluidas en esta tabla.
Página 63
Tabla A1. Modelo Entidad BTS
Para cada BTS se tiene una tabla PERFILES y una tabla LINK_BUDGET,
mostrada en la tabla A2 y A3, respectivamente. En la tabla PERFILES, se almacena
el valor procesado de cada contador, con el número de afinaciones y el promedio. La
decisión de colocar los contadores como columnas de la tabla permite que el tiempo
requerido por el sistema para llevar a cabo una actualización de los perfiles de todas
las estaciones sea el mínimo, ya que, por la estructura que tiene la base de datos de la
empresa, el número de inserciones necesarias es mínimo. Con esta estrategia, la
mejora en el tiempo de respuesta del sistema es inversamente proporcional a su
extensibilidad ya que para agregar un nuevo contador se debe cambiar la estructura de
la base de datos agregando una columna a la tabla. La tabla LINK_BUDGET guarda
el promedio de la potencia de las antenas en Uplink y Downlink, para cada día.
Tabla A2. Modelo Entidad Perfiles
Página 64
Tabla A3. Modelo Entidad LINK_BUDGET
En la tabla TIPO_DE_ALARMA que se muestra en la tabla A4 se almacena la

información de las alarmas de mayor ocurrencia definidas durante la fase
Levantamiento de Información. Es posible agregar nuevos tipos de alarmas y
modificar o eliminar las existentes utilizando una interfaz de usuario implementada.
Tabla A4. Modelo Entidad Tipo de Alarmas
La tabla PASO_DE_LA_RUTINA (Tabla A5) guarda la información del orden de

ejecución con el que se deben llevar a cabo los pasos que son automatizados por el
sistema, es decir, para cada tipo de alarma están definidos unos pasos con los cuales
es posible atacar o notificar las alarmas que ocurran en una estación. La tabla
PASOS_AUTOMATIZADOS contiene, como su nombre lo indica, los pasos que
puede llevar a cabo el sistema de forma remota y automática como se muestra en la
Tabla A6.
Página 65
Tabla A5. Modelo Entidad Paso de la Rutina
Tabla A6. Modelo Entidad Paso Automatizado
En la tabla ALARMA se mantiene la información de las alarmas activas que están

presentes en los equipos de la red al momento de la ejecución de la aplicación. La
hora de activación es almacenada como se muestra en la tabla A7. Estas alarmas se
obtienen al leer el archivo de texto que contiene la información arrojada, luego de
enviar el comando correspondiente a cada una de las BSC a través de la conexión con
los router de la empresa.
Tabla A7. Modelo Entidad Alarma
Página 66
La tabla HISTORIAL_DE_APLICACION se relaciona con

PASO_AUTOMATIZADO con la finalidad de poder conocer las rutinas que el
sistema ha llevado a cabo de forma automática para atacar las alarmas, con la
información del día y la hora en que se aplicaron, como se muestra en la tabla A8.
Tabla A8. Modelo Entidad Historial de Aplicación
Para determinar a quien notificar la aplicación de una rutina se crea la tabla

DEPARTAMENTO (Tabla A9) que está asociada con TIPO_DE_ALARMA a través
de la tabla DEBE_SER_ATENDIDA_POR (Tabla A10). Con esta relación es posible
saber para cada tipo de alarma el departamento de la empresa que debe ser notificado.
Tabla A9. Modelo Entidad Departamento
Tabla A10. Modelo Entidad Debe ser atendida por
Página 67
Cada departamento tiene un personal, que es almacenado en la tabla PERSONAL

(Tabla A11).
Tabla A11. Modelo Entidad Personal
A su vez, cada personal del departamento tiene una tabla CONFIGURACION como
la mostrada en la Tabla A12 en la que se almacena las guardias de un mes y su
disponibilidad en horas laborables para hacer la notificación del sistema. Esta tabla se
actualiza a través de una interfaz visual.
Tabla A12. Modelo Entidad Configuración
Página 68
Adicionalmente, se tiene una tabla CONF_SERVIDOR (Tabla A13), donde se

almacenan los datos de necesarios para comunicarse con el servidor de la empresa,
además de datos de configuración de la aplicación.
Tabla A13. Modelo Entidad Conf_Servidor
Página 69
APÉNDICE B
Interfaces de Usuario del Sistema
Página 70
La interfaz de usuario permite visualizar el resultado del análisis estadístico

realizado por el sistema y facilita el manejo de la base de datos para asegurar que la
misma guarde la información necesaria para la ejecución de la aplicación, sin
necesidad de conocer su estructura, minimizando así posibles errores al realizar
cambios de configuración, afinación de perfiles, actualización de BTS, etc.
La aplicación se inicia con la barra de herramientas mostrada en la Figura B1,

donde se observa el menú con las diferentes funcionalidades implementadas y
botones de acceso directo a alguna de ellas.
Figura B1. Barra de Herramientas
Las funciones de cada elemento del menú se muestran a continuación:
Perfiles Perfiles Link

Notificación Alarmas
Contador Budget
 Afinar  Consultar  Cargar Guardias  Consultar

 Consultar  Editar  Personal:  Agregar
 Reiniciar Agregar  Eliminar
Eliminar
Configuración BTS
Servidor Integradas
 Editar  Actualizar
Página 71
El botón de Ejecutar mostrado en la barra de herramienta permite iniciar el análisis

estadístico. Una vez iniciado se muestra la siguiente interfaz con la configuración de
los diferentes parámetros necesarios por el sistema:
Figura B2. Interfaz de configuración de Parámetros
 El parámetro Tráfico indica el umbral en Erlangs

 Análisis BTS de Bajo Tráfico permite seleccionar la cantidad de horas que se
desea agregar al análisis actual, es decir, se agrupan las estadísticas obtenidas en
la hora actual con las del número de horas anteriores al seleccionado.
 Los parámetros de Base_min y Ajuste para los indicadores CSF, HOF y DC
definen la función de Variación empleada para el análisis en cada caso.
 En la sección Interferencia se define el Margen en porcentaje con el que
descarta el análisis de las estadísticas en aquellas estaciones que presenten un
porcentaje de interferencia por encima del umbral definido.
Página 72
 El Margen en la sección Link Budget define el valor en dB permisible por

encima del promedio que determina si las estaciones presentan o no fallas en el
funcionamiento de sus antenas.
 El parámetro NBR_OF_UL_TBF en Spleeping Cell define el número de TBFs
en UpLink que sirve de umbral para identificar a las estaciones que presentan
fallas por este concepto
 El UserName y Password los utiliza el sistema para consultar las alarmas activas
a través de la conexión a las BSC
En la pestaña de Notificación mostrada en la interfaz se visualiza la configuración

empleada por el sistema para informar al personal de la empresa el resultado del
análisis realizado. La interfaz es la siguiente:
Figura B3. Interfaz Parámetros para Notificación
Página 73
La Notificación se realiza vía Correo Electrónico y/o vía SMS. Es posible hacer la
configuración para notificar al personal durante las horas laborables (8 AM a 5 PM) y
no laborables según se desee.
Notificar Alarmas Activas envía un mail al personal de O&M correspondiente con

el archivo Detalle_Alarmas.txt que contiene la descripción de las alarmas y las rutinas
que se recomiendan aplicar para cancelarlas. En el ejemplo se muestra que el sistema
solo notifica alarmas durante las horas laborables. La configuración del personal y las
alarmas a notificar se realiza con otras interfaces que se muestran más adelante.
Notificar Monitor KPI se refiere al resultado del análisis estadístico. Se envía el

mail con el archivo Detalle_Fallas.txt que contiene la descripción de las posibles
fallas al personal de Optimización.
Vía SMS se notifican solo las alarmas activas, ya que por este medio resulta
complicado agregar toda la información arrojada del análisis estadístico. Se envían
los números de identificación de las alarmas, las BTS alarmadas, las BSC y BCF a la
cual pertenecen.
La interfaz muestra por defecto el valor de todos los parámetros almacenados en la

base de datos del sistema, específicamente en la tabla Conf_Serv, como se explica
más adelante.
En caso de hacer cambios en los valores por defecto, éstos no serán almacenados a
través de esta interfaz. Sólo servirán para la ejecución en proceso de la aplicación.
Para hacer los cambios persistentes deben realizarse por la opción Configuración
Servidor mostrada en la barra del menú.
El botón de Conectar inicia la ejecución del análisis y una vez finalizado se

muestra la siguiente interfaz con los resultados obtenidos:
Página 74
Figura B4. Interfaz de Resultados
El resultado del cálculo de porcentajes de fallas se muestra por separado para las
BTS de Alto Tráfico y las de Bajo Tráfico (interfaz con 2 pestañas), esto según el
parámetro definido por el usuario ‘Tráfico en Erlangs’. En ambos casos se detallan
los porcentajes de fallas obtenidos para los indicadores de performance, tanto los
calculados con las estadísticas actuales como los obtenidos de las estadísticas
promediadas leídas de los perfiles almacenados en la base de datos del sistema.
Las columnas Tráfico en Erlangs, CSF, HOF, DC y Num Llamadas corresponden a

valores actuales para cada BTS mostrada y, las de CSFProm, HOFProm y DCProm a
sus valores promedios.
Página 75
En la parte inferior se muestra el resultado del análisis de las estadísticas para cada
indicador. La aplicación identifica las estaciones con posibles fallas y los contadores
que producen el incremento en los porcentajes de fallas obtenidos. También se
muestran las estaciones que salen del análisis de Link Budget y de Sleeping Cell
Toda esta información es agregada al archivo Detalle_Fallas.txt para su notificación
vía mail.
A continuación se describen el resto de las funcionalidades implementadas según se

muestra en la barra de menú de la aplicación:
Perfiles Contador
Este menú permite manipular la información de los Perfiles generados para cada
contador necesario para el análisis de los indicadores de performance:
 Afinar: Agrega la data de la semana anterior a los promedios almacenados en la

base de datos del sistema. La interfaz permite afinar por estación seleccionando
de la lista mostrada la BTS que se desea afinar. También es posible afinar por
BSC seleccionando una de la lista. En ambos casos se muestra la selección del
usuario en la ventana y para iniciar el proceso debe presionar el botón Aceptar.
El proceso de afinación por BSC resulta bastante prolongado. Durante la ejecución

de ambos procesos se muestra el avance en la barra de estado y una vez finalizada la
afinación se observa el mensaje “Perfil Actualizado!”.
Página 76
Figura B5. Interfaz de Afinación de Perfiles de Contadores
 Consultar: Permite visualizar la data de los perfiles de contadores almacenada en

la base datos del sistema. Para ello el usuario debe seleccionar de la lista mostrada
la BTS a consultar y el contador en específico. Los contadores se identifican con
el número y el nombre del mismo
Al presionar el botón Graficar se muestra la ventana con la información por día de

la semana del contador y BTS seleccionados
Página 77
Figura B6. Interfaz de Consulta Perfiles de Contadores
La ventana de Gráfica mostrada a continuación muestra el valor exacto del contador

haciendo click sobre la curva el día y hora que se desee. Se tienen también las
opciones de Guardar a disco, Imprimir, etc. en los botones laterales y con en los de la
parte inferior es posible graficar utilizando otros tipos de gráficos (2D, 3D, etc). El
color también es posible cambiarlo haciendo click sobre la gráfica
Página 78
Figura B7. Interfaz de Visualización de Perfil de Contador
 Reiniciar: Borra el contenido almacenado en la base de datos del contador y BTS

seleccionado, y realiza una primera afinación del mismo. Es posible también
Reiniciar por BSC. La interfaz muestra una barra de estado mientras se lleva a
cabo la afinación mostrando al final el mensaje “Perfil Reiniciado!”
Página 79
Perfiles Link Budget
Este menú permite manipular la información de los Perfiles generados para el

análisis del Link Budget de las BTS
 Consultar: Muestra gráficamente el valor del Link Budget almacenado en la base

de datos del sistema. Para ello el usuario debe seleccionar la BTS a consultar
seleccionándola de la lista mostrada.
Las fechas mostradas en los campos Desde y Hasta identifican el período tomado
para hacer el cálculo del promedio del Link Budget con el que se trabaja en la
aplicación. Este período puede ser modificado a través de otra interfaz.
Página 80
La gráfica muestra la información del Link Budget de la BTS seleccionada. Está

en función del día de la semana. Haciendo click sobre alguna de las barras se
muestra el valor exacto del Link Budget. Con los botones es posible Guardar,
imprimir, cambiar el tipo de gráfico, etc.
Figura B9. Interfaz de Visualización de Perfiles Link Budget
 Editar: Borra de la base de datos el contenido del Link Budget de la BTS

seleccionada de la lista y realiza el cálculo nuevamente con la data del período
comprendido entre las fechas definidas por el usuario. Es posible editar
también Link Budget por BSC. Con los botones junto a Desde y Hasta se
despliega un calendario para la selección de las fechas y una vez finalizado el
proceso se muestra el mensaje “Perfil Editado!”
Página 81
Figura B10. Interfaz de Edición Perfiles Link Budget
Notificación
Este menú permite configurar la notificación al personal de la empresa según la

fecha, días laborables, fines de semana, días de guardia, etc. y la información
relevante del personal para los efectos del sistema.
 Cargar Guardias: Guarda la configuración definida para el personal

seleccionado de la lista. Esta lista de personal puede ser manipulada a través de
otra interfaz.
Página 82
Figura B11. Interfaz de Edición de Configuración para Notificación
Los botones Desde y Hasta definen el período en que se mantendrá la configuración

establecida para la notificación al personal seleccionado. La sección horas laborables
y horas de guardia detalla la configuración por semana del mes y día.
En el ejemplo se muestra la configuración para notificar de lunes a viernes, todas

las semanas del mes durante las horas laborables, y en horas de guardias o no
laborables no notificar.
Página 83
Es necesario tener bien configurada la notificación del personal puesto que sin esta
información el sistema realizará el análisis correspondiente y los resultados no serán
enviados al personal de la empresa.
 Personal: Permite agregar y eliminar Personal a la Base de datos.
Para Agregar Personal el usuario selecciona la opción en el menú y debe rellenar

los campos mostrados en la siguiente interfaz. El botón Aceptar guarda la
información del Personal y muestra el mensaje “Personal Agregado!”. Se muestra
además la lista del personal existente con los números de teléfono y nombres, y la
lista de los departamentos a los que el sistema notifica.
Figura B12. Interfaz para Agregar Personal a notificar
Página 84
Es necesario que una vez agregado el personal se cargue también la configuración

de guardias deseada, que como se mostró en el punto anterior, permite definir cuando
hacerle la notificación de los resultados del análisis. De no ser así, el personal existe
para el sistema pero por defecto no se le notifica.
Para Eliminar el usuario elige la opción en el menú y selecciona de la lista

mostrada el personal a eliminar, borrándolo así de la base de datos del sistema.
Figura B13. Interfaz para Eliminar Personal de la notificación
Alarmas
Este menú permite Consultar, Agregar y Eliminar de la Base de Datos

implementada las Alarmas que el sistema debe notificar al personal de la empresa.
 Consultar: Muestra la lista de alarmas que están configuradas para la

notificación. Una vez seleccionada alguna se observa la descripción de la alarma,
su rutina recomendada para cancelarla y el o los departamentos a los que debe ser
Página 85
notificada. La ventana Pasos fue diseñada para sintetizar los pasos que pudieran
automatizarse: Bloquear Ranura de tiempo (TimeSlot), Desbloquear Ranura de
tiempo (TimeSlot), Resetear TRX, Resetear BTS y Resetear BCF. Estas rutinas
fueron implementadas pero por políticas de seguridad no pudieron ser ejecutadas
por la aplicación.
 Agregar: Muestra la lista de las alarmas identificadas por el personal de la

empresa como de mayor ocurrencia. Estas alarmas, sus descripciones y rutinas de
atención se guardan en el “Documento Descripción Alarmas BSS y Transmisión”,
el cual fue realizado con la información recolectada de entrevistas con el personal
de O&M. Cada una de estas alarmas u otras, pueden ser almacenadas en el
sistema agregando el número, nombre, departamento a notificar y descripción.
Permite también agregar el orden en que se deben realizar los pasos
automatizados para cancelar la alarma..
Página 86
Figura B15. Interfaz para Agregar nuevas Alarmas a monitorear
 Eliminar: Muestra la lista de alarmas configuradas en el sistema. Una vez

seleccionada alguna se pide confirmación al usuario con el mensaje “Desea
Eliminar la Alarma?”. En caso de Aceptar el sistema elimina de la base de datos
dicha alarma y por tanto no será notificada en caso de activarse en algún equipo
de la red.
Configuración Servidor
 Editar: Muestra la ventana con los parámetros definidos por el usuario para la
ejecución del análisis estadístico (figuras B2 y B3) con la diferencia de que el
botón de Conectar se reemplaza por el de Guardar. Con esta interfaz es posible
editar y almacenar en la base de datos la nueva configuración para la ejecución de
la aplicación.
Página 87
BTS Integradas
Este menú permite hacer la actualización de las BTS que son analizadas por la
aplicación. Para ello se requiere consultar la lista de BTS integradas según
información leída del OSS
 Actualizar: Consulta las BTS Integradas y aquellas estaciones que no sean

consideradas por el sistema para el análisis de sus estadísticas son agregadas a la
base de datos con su respectiva información de BCF, BSC a la que pertenecen,
etc. Al finalizar el proceso de Actualización se muestra el mensaje “Actualización
Realizada!”. A partir de ese momento, cuando la aplicación ejecute el análisis o se
realicen afinaciones de sus perfiles serán consideradas también las nuevas
estaciones integradas a la red.
Figura B16. Interfaz para Actualizar las BST Integradas
Página 88
ANEXO A
MODEM ENFORA SA-GTM
Página 89
Características
Host Interface: RS232- DSUB 9
L x W x H: 2.5 x 2.5 x 0.94 in
Housing: Seamless Aluminum Extrusion
Antenna: SMA Connector
Radio Frequency: 850/900/1800/1900
Sensitivity: -106 dB (Typical)
Transmit Power: Class 4 (2W @850/900 MHz)
Class 1 (1W @1800/1900 MHz)
GSM Functionality
Voice: FR, EFR, HR & AMR
CS Data: Asynchronous,
Transparent and Non-Transparent up to 14.4 KB
GSM SMS: Text, PDU, MO/MT
Cell broadcast
Application Interface
Host Protocols: AT Commands, UDP/API
Internal Protocols: PPP, UDP/API, UDP/PAD, CMUX, TCP/PAD
API Control/Status: AT or UDP
SIM Access
SIM Access: External – 3V with
Página 90
Set de Comandos AT Enfora GSM/GPRS
General Configuration
AT+CSMS Select Message Service

AT+CPMS Preferred Message Storage
AT+CMGF SMS
AT+CSCA Service Center Address
AT+CSMP Set Text Mode Parameters
AT+CSDH Show Text Mode Parameters
AT+CSCB Select Cell Broadcast Message Types
AT+CSAS Save Settings
AT+CRES Restore Settings
Message Receiving and Reading Commands
AT+CNMI New Message Indication to TE

AT+CMGL List Messages
AT+CMGR Read Message
Message Sending and Writing Commands
AT+CMGS Send Message

AT+CMSS Send Message from Storage
AT+CMGW Write Message to Memory
AT+CMGD Delete Message
AT+CMGC Send Command
Página 91

Sistema de Gestion para La Deteccion de Fallas Temprana en La Bts de Red Digitel

Cargado por

Copyright:

Formatos disponibles

Sistema de Gestion para La Deteccion de Fallas Temprana en La Bts de Red Digitel

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Sistema de Gestion para La Deteccion de Fallas Temprana en La Bts de Red Digitel

Cargado por

Copyright:

Formatos disponibles

Sistema de gestión para detección temprana de fallas en las BTS de la Red Digitel

SISTEMA DE GESTIÓN PARA DETECCIÓN TEMPRANA

Considerando el constante crecimiento de la red GSM de la Corporación Digitel y

El trabajo especial de grado contempla el análisis de la información referente al

Palabras Claves: Red GSM, Indicadores de rendimiento, Detección de fallas.

Este trabajo de grado se lo dedico especialmente a mi mamá y a mis hermanos,

Le agradezco a la Universidad Católica Andrés Bello por ser la fuente de los

A los compañeros de Digitel por su disposición a guiarme en las tareas planteadas y

Finalmente le agradezco a Guillermo por ser siempre mi mejor compañía, a mi lado

Dedicatoria y Agradecimientos ..................................................................................... ii

Índice General .............................................................................................................. iii

Índice de Figuras ........................................................................................................... v

Planteamiento del Proyecto ........................................................................................... 2

I.1 Planteamiento del Problema.............................................................................. 2

I.2 Objetivo General. .............................................................................................. 2

I.3 Objetivos Específicos. ....................................................................................... 3

I.4 Justificación. ..................................................................................................... 4

I.5 Limitaciones y Alcance. .................................................................................... 4

Marco Referencial ......................................................................................................... 5

II.1 Estándar GSM y Arquitectura de Red ................................................................... 5

II.1.1 Subsistema de Estaciones Base (BSS) ..................................................... 6

II.1.2. Subsistema de Conmutación y Red (NSS) ............................................... 8

II.1.3 Subsistema de Administración .................................................................. 9

II.2. Canales físicos y lógicos ................................................................................... 11

II.3. Diagramas de Procesos para establecimiento, control y manejo de llamadas ... 14

II.4. Indicadores de Rendimiento Analizados ............................................................ 17

Capítulo III .................................................................................................................. 21

Metodología y Desarrollo ........................................................................................... 21

III.1. Análisis de la Red GSM de Digitel. .................................................................. 21

III.2. Estudio de las mediciones disponibles en el subsistema de radio bases. ........... 22

III.3. Estudio de acciones correctivas y preventivas para la resolución de fallas en los

III.4. Diseño e Implementación del Sistema. ............................................................. 23

IV.1. Diseño del Sistema........................................................................................... 25

IV.1.1. Métodos de Análisis de los Indicadores de Rendimiento ..................... 27

IV.1.1.1. Análisis de los Indicadores de Voz ................................................ 28

IV.1.1.2. Análisis del Link Budget en las Antenas ....................................... 38

IV.1.1.3. Análisis de Sleeping Cells para Datos ........................................... 40

IV.1.2 Establecimiento de la Conexión remota a las BSC ................................ 41

IV.2. Implementación del Sistema. ........................................................................... 43

IV.2.1. Modelo de la Base de Datos ................................................................. 44

IV.2.2. Estructura de la Aplicación ................................................................... 45

IV.2.2.1 Actualización de los Perfiles ........................................................... 46

IV.2.2.2. La detección temprana de fallas ..................................................... 47

IV.2.2.3. El administrador del sistema .......................................................... 48

IV.3. Una corrida de la Detección Temprana de Fallas desde el Administrador del

Conclusiones y Recomendaciones .............................................................................. 58

Referencias Bibliográficas .......................................................................................... 60

Descripción de la Base de Datos del Sistema ............................................................. 62

Interfaces de Usuario del Sistema ............................................................................... 70

MODEM ENFORA SA-GTM ...................................................................................... 89

Figura 1. Subsistemas en GSM ..................................................................................... 6

Figura 2. Subsistema de Estaciones Base .................................................................... 7

Figura 3. Elementos del Subsistema de Conmutación ................................................. 8

Figura 4. Subsistema de Administración ..................................................................... 9

Figura 5. División de las Bandas de Frecuencia ......................................................... 11

Figura 6. Esquema de los Tipos de Canales Lógicos .................................................. 13

Figura 7. Diagrama del Proceso de HandOver entre BTS .......................................... 15

Figura 8. HandOver interno a una BSC entre BTS .................................................... 16

Figura 9. Diseño General del Sistema ......................................................................... 25