Desarrollo de herramienta de monitoreo de dispositivos IP para la

UNIVERSIDAD SIMÓN BOLÍVAR
Decanato de Estudios Profesionales
Coordinación de Ingeniería Electrónica
DESARROLLO DE HERRAMIENTA DE MONITOREO DE DISPOSITIVOS IP
PARA LA RED WLL DE TELCEL
Por:
Manuel Ferrer P.
Sartenejas, Enero de 2005
2
UNIVERSIDAD SIMÓN BOLÍVAR
Decanato de Estudios Profesionales
Coordinación de Ingeniería Electrónica
DESARROLLO DE HERRAMIENTA DE MONITOREO DE DISPOSITIVOS IP
PARA LA RED WLL DE TELCEL
Por:
Manuel Ferrer P.
Realizado con la Asesoría de:
Prof. Carolina Chang
Ing. David Tirado
PROYECTO DE GRADO
PRESENTADO ANTE LA ILUSTRE UNIVERSIDAD SIMÓN BOLÍVAR COMO
REQUISITO PARCIAL PARA OPTAR AL TÍTULO DE INGENIERO ELECTRÓNICO
Sartenejas, Enero de 2005.
3
UNIVERSIDAD SIMÓN BOLÍVAR
Decanato de Estudios Profesionales
Coordinación de Ingeniería Electrónica
DESARROLLO DE HERRAMIENTA DE MONITOREO DE DISPOSITIVOS IP
PARA LA RED WLL DE TELCEL
Informe final presentado por:
Manuel Ferrer P.
Realizado con la asesoría de:
Prof. Carolina Chang
Ing. David Tirado
RESUMEN
Esta herramienta gráfica fue desarrollada con la finalidad de dar remedio a los
problemas de monitoreo y solución de fallas de la red WLL de TELCEL.
Para la ejecución de tareas de administración de la red, se utilizan comandos
directamente enviados desde el cliente al servidor, aunque también se desarrollaron scripts en
Shell de UNIX que se encuentran dentro del servidor cuyas respuestas son interpretadas por la
aplicación.
Para hacer posible el monitoreo de la red sin afectar el funcionamiento de la misma, se
utilizaron los mecanismos de supervisión del protocolo SNMP (que trabaja a nivel de la última
capa del modelo OSI) y sesiones Telnet directas sobre los dispositivos, que a su vez permiten
una interacción en tiempo real con la red.
Resultó un sistema gráfico que cumple con los requerimientos de ser amigable,
sencillo, compacto y de bajo costo.
PALABRAS CLAVES
Wireless Local Loop (WLL), Administración de redes, Simple Network Management
Protocol (SNMP), Redes Inalámbricas, Cliente Telnet
4
ÍNDICE GENERAL
ÍNDICE GENERAL ........................................................................................................i
ÍNDICE DE FIGURAS .................................................................................................iv
ÍNDICE DE TABLAS ...................................................................................................vi
NOMENCLATURA .....................................................................................................vii
TERMINOLOGÍA ........................................................................................................ix
CAPÍTULO 1: INTRODUCCIÓN .............................................................................11
CAPÍTULO 2: OBJETIVOS.......................................................................................14
2.1. Objetivos principales ............................................................................................14
2.2. Objetivos secundarios...........................................................................................14
CAPÍTULO 3: FUNDAMENTOS TEÓRICOS ........................................................15
3.1. Protocolo Telnet....................................................................................................15
3.1.1. Consideraciones Generales...........................................................................15
3.1.2. El Terminal Virtual de la Red.......................................................................19
3.1.3. Transmisión de datos ....................................................................................20
3.1.4. La impresora y el teclado NVT ....................................................................22
3.1.5. Estructura de órdenes Telnet.........................................................................24
3.1.6. Establecimiento de la conexión ....................................................................25
3.1.7. Asignación de puertos ..................................................................................25
3.2. Wireless Local Loop.............................................................................................26
3.2.1. Evolución de las Redes de acceso WLL.......................................................26
3.2.2. Características...............................................................................................28
3.2.3. Infraestructura:..............................................................................................28
3.2.3.1. Terminales .............................................................................................28
3.2.3.2. Las radio bases WLL .............................................................................28
3.2.4. Tecnologías disponibles de WLL .................................................................29
3.2.4.1. Digital celular .......................................................................................30
3.2.4.2. Celular analógico ..................................................................................31
3.2.4.3. PCS ........................................................................................................31
3.2.4.4. CT-2/DECT............................................................................................31
3.2.4.5. Los Sistemas Propietarios .....................................................................32
3.2.5. Aplicaciones y segmentos de mercado.........................................................32
3.2.6. Arquitecturas y topologías............................................................................33
3.2.7. Red WLL con equipos BreezeAccess (BreezeCom) .....................................35
5
3.2.8. Arquitectura estándar de la base estación (una sola celda) ..........................35
3.2.9. Arquitectura estándar de unidades de subscriptor ........................................36
3.2.10. Arquitectura de la red WLL de TELCEL (múltiples celdas) .....................37
3.3. Protocolo Simple para Gestón de Redes (SNMP)................................................38
CAPÍTULO 4: MARCO ORGANIZACIONAL .......................................................43
4.1. Misión...................................................................................................................43
4.2. Visión ...................................................................................................................43
4.3. Filosofía ................................................................................................................43
4.2 Centro de Control de la Red ..................................................................................44
CAPÍTULO 5: METODOLOGÍA ..............................................................................45
CAPÍTULO 6: DESARROLLO..................................................................................52
6.1. Cónsola de Servicios IP (CSiP) ............................................................................52
6.1.1. Sistema de Archivos .....................................................................................53
6.2. Estructura de las bases de datos............................................................................54
6.2.1. Netwll.mdb ...................................................................................................54
6.2.1.1. Tabla Árbol ............................................................................................54
6.2.1.2. Tabla CELDA ........................................................................................54
6.2.1.3. Tabla AU................................................................................................55
6.2.1.4. Tabla SU ................................................................................................55
6.2.1.5. Tabla GPS..............................................................................................56
6.2.1.6. Tabla MDU ............................................................................................57
6.2.1.7. Tabla Temporal .....................................................................................57
6.2.1.8. Tabla IPCFTemp ...................................................................................58
6.2.1.9. Tabla ShUTemp .....................................................................................59
6.2.1.10. Tabla Puertos.......................................................................................59
6.2.1.11. Otras tablas. .........................................................................................59
6.2.1.12. Consultas .............................................................................................60
6.2.1.12.1. CCF. .............................................................................................60
6.2.1.12.2. SUC2.............................................................................................60
6.2.2. Login.mdb ....................................................................................................61
6.2.2.1. Tabla Password .....................................................................................61
6.2.2.2. Tabla LogFile ........................................................................................62
6.3. Algoritmos de programación de la aplicación......................................................63
6.3.1. Clase CServidor............................................................................................63
6.3.2. Clase CDispIP ..............................................................................................66
6.3.3. Formulario de Inicialización (mForm1) .......................................................71
6.3.4. Mapa de la Red (Form1)...............................................................................72
6
6.3.5. Actualización de BD (Form2) ......................................................................74
6.3.6. Operaciones Masivas (Form8) .....................................................................74
6.4. Perfiles de Usuario ...............................................................................................76
6.5. Consultas SNMP ..................................................................................................77
6.5.1. MIB BreezeCom...........................................................................................77
6.5.2. MIB2.............................................................................................................79
6.6.2. Entorno de Trabajo .......................................................................................80
6.6.2.1. Ventana del Programa...........................................................................80
6.6.2.2. Barra de Herramientas..........................................................................80
6.6.2.3. Menú General ........................................................................................81
6.6.3. Inicio de Sesión ............................................................................................81
6.6.3.1. Inicio de sesión del programa. ..............................................................81
6.6.3.2. Inicio de Sesión HPOVWLL ..................................................................82
6.6.4. Módulo Mapa de Red ...................................................................................83
6.6.4.1. Árbol de la Red .....................................................................................83
6.6.4.2. Submenú de mapa de red.......................................................................85
6.6.4.3. Selector de Pestañas..............................................................................89
6.6.5. Módulo Actualización de BD .......................................................................96
6.6.5.1. Submenú ................................................................................................97
6.6.6. Módulo Operaciones Masivas....................................................................100
CAPÍTULO 7: RESULTADOS Y DISCUSIONES.................................................102
CAPÍTULO 8: CONCLUSIONES Y RECOMENDACIONES.............................111
CAPÍTULO 9: REFERNCIAS BIBLIOGRÁFICAS..............................................116
7
ÍNDICE DE FIGURAS
FIGURA 3.1 – ARQUITECTURA BS BREEZEACCESS .....................................................................36
FIGURA 3.2 – ARQUITECTURA SU BREEZEACCESS.....................................................................37
FIGURA 3.3 – ARQUITECTURA RED WLL TELCEL ....................................................................37
FIGURA 5.1 – DIAGRAMA DEL SISTEMA ......................................................................................46
FIGURA 6.1 – SISTEMA DE ARCHIVOS CSIP ................................................................................53
FIGURA 6.2 – VÍNCULOS CONSULTA CCF ..................................................................................60
FIGURA 6.3 – VÍNCULOS CONSULTA SUC2 ................................................................................61
FIGURA 6.4 – ESQUEMA DE CLASE CSERVIDOR ..........................................................................63
FIGURA 6.5 – DIAGRAMA DE EJECUCIÓN DE COMANDOS.............................................................64
FIGURA 6.6 – DIAGRAMA DE ESTRUCTURA DE LA CLASE CDISPIP..............................................66
FIGURA 6.7 – ESTRUCTURA DEL MENÚ GENERAL ......................................................................72
FIGURA 6.8 – ESTRUCTURA DE ARCHIVO PARA ALMACENAR OPERACIONES ...............................75
FIGURA 6.9 - BARRA DE HERRAMIENTAS....................................................................................80
FIGURA 6.10 - ESTRUCTURA DEL MENÚ GENERAL. .....................................................................81
FIGURA 6.11 - INICIO DE SESIÓN DEL PROGRAMA........................................................................82
FIGURA 6.12 - INICIO DE SESIÓN HPOVWLL.............................................................................82
FIGURA 6.13 - MÓDULO MAPA DE RED ......................................................................................83
FIGURA 6.14 - LEYENDA DE ICONOS DEL ÁRBOL .........................................................................84
FIGURA 6.15 - VENTANA PING ....................................................................................................85
FIGURA 6.16 - VENTANA TELNET ...............................................................................................86
FIGURA 6.17 - VENTANA AGREGAR/CAMBIAR COMENTARIOS. ..................................................87
FIGURA 6.18 - VENTANA ESTADÍSTICAS DE TRÁFICO. ................................................................87
FIGURA 6.19 - VENTANA BUSCAR NODO ....................................................................................89
FIGURA 6.20 - PESTAÑA DETALLES. ...........................................................................................90
FIGURA 6.21 - PESTAÑA SUPERVISIÓN........................................................................................91
FIGURA 6.22 - PESTAÑA ESTADÍSTICAS DE TRÁFICO. .................................................................92
FIGURA 6.23 - PESTAÑA PARÁMETROS IP...................................................................................93
FIGURA 6.24 - ESTADÍSTICAS POR FRECUENCIA .........................................................................94
FIGURA 6.25 - PESTAÑA NETFLOW ............................................................................................95
FIGURA 6.26 - GRÁFICO NETFLOW .............................................................................................95
8
FIGURA 6.27 - MÓDULO ACTUALIZACIÓN DE BD ......................................................................96
FIGURA 6.28 - VENTANA INSERTAR NODO. ................................................................................98
FIGURA 6.29 - EDITAR NODO......................................................................................................98
FIGURA 6.30 – MÓDULO DE OPERACIONES MASIVAS ...............................................................100
FIGURA 7.1 – FALLAS REPORTADAS REGISTRO 1 ......................................................................102
FIGURA 7.2 – DIAGNÓSTICOS Y SOLUCIONES REGISTRO 1 .........................................................103
FIGURA 7.3 – CLASIFICACIÓN DE LLAMADAS DEL
REGISTRO 1.................................................104
FIGURA 7.4 – COMPARACIÓN CANTIDAD DE LLAMADAS ...........................................................105
FIGURA 7.5 – COMPARACIÓN POR CLASIFICACIÓN LLAMADAS .................................................106
FIGURA 7.6 – COMPARACIÓN DE FALLAS REPORTADAS ............................................................107
FIGURA 7.7 – COMPARACIÓN DE DIAGNÓSTICO Y SOLUCIONES.................................................107
FIGURA 7.8 – ANÁLISIS DE CANTIDAD DE LLAMADAS ...............................................................108
FIGURA 7.9 – CANTIDAD DE OPERACIONES POR USUARIO .........................................................109
FIGURA 7.10 – OPERACIONES VS. RU.......................................................................................110
FIGURA 7.11 – HISTOGRAMA DIARIO DE USO DE CSIP..............................................................110
9
ÍNDICE DE TABLAS
TABLA 3.1 - CÓDIGOS USAASCII CON IMPORTANCIA PARA LA IMPRESORA NVT .....................22
TABLA 3.2 – CÓDIGOS USAASCII CON EFECTOS DEFINIDOS EN LA IMPRESORA NVT ...............23
TABLA 3.3 – ÓRDENES TELNET................................................................................................25
TABLA 6.1 – TABLA ÁRBOL........................................................................................................54
TABLA 6.2 – TABLA CELDA......................................................................................................55
TABLA 6.3 – TABLA AU .............................................................................................................55
TABLA 6.4 – TABLA SU..............................................................................................................56
TABLA 6.5 – TABLA GPS............................................................................................................56
TABLA 6.6 – TABLA MDU..........................................................................................................57
TABLA 6.7 – TABLA TEMPORAL .................................................................................................58
TABLA 6.8 – TABLA IPCFTEMP .................................................................................................58
TABLA 6.9 – TABLA SHUTEMP...................................................................................................59
TABLA 6.10– TABLA PUERTOS ...................................................................................................59
TABLA 6.11 – TABLA PASSWORD ...............................................................................................61
TABLA 6.12 – TABLA LOGFILE ...................................................................................................62
TABLA 6.13 – TABLA DE PRIVILEGIOS ........................................................................................76
TABLA 6.14 – TABLA DE CONSULTAS SNMP DE LA MIB DE BREEZECOM .................................79
TABLA 6.15 – TABLA DE CONSULTAS SNMP DE LA MIB2 USADAS EN EL PROGRAMA ...............79
10
NOMENCLATURA
AAA:
Unidad de autenticación, autorización y almacenamiento.
ADO:
ActiveX Data Objects, Objetos de Datos ActiveX
AMPS:
Advanced Mobile Phone System, Sistema de Telefonía Móvil Avanzada.
ARP:
Address Resolution Protocol, Protocolo de Resolución de Direccionamiento.
ASCII:
American Standard Code for Information Interchange, Código Americano
Estándar para el Intercambio de Información.
AU:
Unidad de Autentificación
Bps:
Bits por segundo.
CDMA:
Code Division Multiple Access, Acceso múltiple por división de código.
CCR:
Centro de Control de la Red
CPA:
Servicio de centrales telefónicas privadas.
CT-2:
Cordless Telephony Generation 2, Telefonía Móvil de Segunda generación.
CR:
Carriage Return, caracter de fin de línea
CSIP:
Cónsola de Servicios IP.
DECT:
Telecomunicaciones digitales sin cables
ESSID:
Extended Service Set ID, identificación de servicios extendidos.
FTP:
File Transfer Protocol, Protocolo de Transferencia de Archivos.
GA:
Go Ahead, Continuar
GPS:
Sistema de Posicionamiento Global
GSM:
Sistema Global para Comunicaciones Móviles.
GU:
Unidad GPS.
HPOVWLL: Servidor de Hewlett Packard “Open View” para WLL.
HTTP:
Protocolo de transferencia de HyperText.
IAC:
Interpretar como Orden.
IP:
Protocolo de Internet.
ISDN:
Red de servicios digitales integrados.
LAN:
Local Area Network, Red de Área Local.
LF:
Line Feed, caracter de Nueva Línea.
MDU:
Unidad de Múltiples usuarios
11
MIB:
Management Information Base, Base de Datos de Información de
Administración de la red.
NVT:
Network Virtual Terminal, Terminal Virtual de Red.
PACS:
Sistemas de Comunicación Personales del Acceso.
PCS:
Servicios de Comunicaciones Personales.
PE:
Departamento de Planta Externa.
PMP:
Punto-Multipunto.
PSTN:
Red Conmutada de Telefonía Pública.
RB:
Departamento de Radio Base.
RF:
Radio Frecuencia.
RTx:
Datos Retransmitidos.
RU:
Reinicio de Unidades.
Rx:
Datos Recibidos.
SNMP:
Protocolo Simple de Administración de Redes.
SU:
Unidad de Subscriptor.
TACS:
Sistemas de Comunicaciones del Acceso Total.
TCP/IP:
Protocolo de control de Transferencia / Protocolo de Internet.
TDMA:
Time Division Multiple Access, Acceso múltiple por división de tiempo.
Tx:
Datos Transmitidos.
VI:
Interfaz Virtual.
VPN:
Red Privada Virtual.
VLAN:
Virtual LAN.
UDP:
Protocolo de Datagrama de Usuario.
WAN:
Wide Area Network, Red de Área Ancha.
WLL:
Wireless Local Loop, Accesso de Bucle Local Inalámbrico.
12
TERMINOLOGÍA
BreezeCom:
Modelo de dispositivos WLL de la casa Alvarion. Pueden ser AU, SU,
GU ó MDU.
Checkbox:
Casilla de verificación.
Cisco Secure:
Cuenta de usuario para dispositivos Cisco.
Community Name:
Propiedad de los dispositivos de la red WLL que sirve como contraseña
para administración.
Frames:
Marco de dato.
IP Address:
La dirección numérica de un dispositivo de una red.
ListView:
Objeto de Visual Basic que permite la visualización de elementos en
forma de lista.
Login:
Nombre de usuario.
MAC Address:
La dirección del hardware de un dispositivo de una red.
Password:
Contraseña.
Ping:
Packet Internet Groper. Utilidad básica utilizada para verificar
conectividad, trabaja mandando paquetes a una dirección especificada y
espera la respuesta.
PictureBox:
Objeto de Visual Basic que permite la visualización de imágenes.
Root:
Raíz del árbol de la red.
13
Router:
Dispositivo que determina el próximo punto de red donde se enrutará
los paquetes de datos.
Script:
Líneas de comando ejecutables.
Snmpget:
Comando del protocolo SNMP que permite obtener un valor a una
variable.
Snmpset:
Comando del protocolo SNMP que permite establecer un valor a una
variable.
Switch:
Dispositivo de comunicación de datos.
TabStrip:
Objeto de Visual Basic que permite la visualización de elementos en
forma de pestañas.
Telnet:
Protocolo de conexión entre terminales cuyo principal objetivo es
permitir un método estándar de comunicar terminales y procesos
orientados a terminal.
Timeout:
Tiempo de espera culminado.
Timer:
Temporizador.
TreeView:
Objeto de Visual Basic que permite la visualización de elementos en
forma de árbol.
Uptime:
Tiempo en servicio de un dispositivo.
Winsock:
Objeto de Visual Basic que permite la apertura de puertos para la
comunicación entre terminales.
14
CAPÍTULO 1
INTRODUCCIÓN
La iniciativa de la realización del presente proyecto nace debido a la alta demanda de
soporte de los usuarios de la red WLL (“Wireless Local Loop” ó Internet Banda Ancha de
Telcel). Esta demanda provocaba que los operadores de la central de atención al cliente
(Soporte T-NET ó “411”) tuviesen que delegar la solución de problemas al departamento de
CCR (Centro de Control de la Red), ya que no se poseía una herramienta de monitoreo acorde
para la supervisión de esta red, haciendo mayor la carga de trabajo a este departamento, ya que
el CCR era el encargado de la delegación y de la solución de los problemas de la red
mencionada.
La idea de este proyecto es consecuencia entonces de esta sobrecarga de trabajo en el
CCR, que además de atender estos casos, también se encarga de la gerencia y supervisión de
las redes celulares y de datos (Telefonía Móvil y fija, T-Link, CPA, Timetrack, EDA, entre
otros).
Además de la necesidad de la creación de una herramienta de monitoreo para los
operadores de la central de soporte, era necesario diseñar un sistema que fuese usado en
paralelo por el CCR que permitiese una mejor supervisión y unos mecanismos más eficaces de
solución de fallas de la red WLL.
Anteriormente al diseño de la herramienta, la tarea de revisión y monitoreo consistía en
hacer ping y Telnet a los dispositivos de manera de encontrar la fuente del problema y, de esta
misma manera, atacarlo. Por esto el tiempo de respuesta ante un reclamo de algún cliente no
era el más eficiente.
Por lo tanto era necesaria la creación de una herramienta de monitoreo que fuese lo
suficientemente amigable y lo suficientemente completa para que a través de los operadores de
Soporte T-Net y, en menor medida, de los especialistas de redes del CCR se llegase a una
solución de un problema de la red de manera más rápida y segura, asegurando así el buen
15
funcionamiento de la red, la disminución de la carga de trabajo y una mayor satisfacción del
cliente.
Previo al desarrollo de la aplicación se registraron las llamadas al CCR provenientes de
Soporte T-Net para un posterior estudio del impacto de la herramienta. Este registro, realizado
a los especialistas de redes del CCR, permitió conocer el porcentaje de disminución de
llamadas esperado.
En resumen, el sistema o aplicación puesto en práctica tiene por finalidad proporcionar
una herramienta gráfica que permita la administración y monitoreo de los dispositivos IP de la
Red WLL a través de sesiones Telnet sobre el servidor HP OpenView WLL (HPOVWLL),
servidor que funciona como eje para las operaciones de monitoreo y administración de la red.
Es por ello que el programa es en esencia un cliente Telnet de este servidor. Además con la
implementación de esta herramienta se busca la disminución de la cantidad de llamadas
recibidas por CCR debidas a consultas y fallas en la red.
Los dispositivos monitoreados por la aplicación son routers, presentes en cada una de
las celdas, y unos dispositivos para enlace de voz y datos de la casa BreezeCom de Alvarion
que constan de una unidad de servicio y de una unidad para el suscriptor. Además el programa
es capaz de monitorear otros dispositivos que pudiesen estar presentes en la red como switches
y tarjetas de GPS (Global Positioning System, Sistema de Posicionamiento Global)
Para hacer posible el monitoreo de la red sin afectar el funcionamiento de la misma, se
utilizaron los mecanismos de supervisión del protocolo SNMP, que trabaja a nivel de la última
capa del modelo OSI (Aplicación).
La aplicación de gestión debe ser entonces lo suficientemente versátil como para captar
los cambios frecuentes en este tipo de redes masivas. Es por ello que se construyó una interfaz
modular, dónde, con el paso del tiempo, se pudiese anexar o modificar funciones o
propiedades inherentes al algoritmo de programación. Así mismo las operaciones realizadas
16
directamente sobre la red, se ejecutan a través de Scripts en Shell de Unix sobre el servidor de
gestión, que son fácilmente reemplazables.
Por último se deben resaltar el cumplimiento con los todos requisitos de seguridad
telemática de la empresa.
17
CAPÍTULO 2
OBJETIVOS
Para entender con más claridad el alcance que tiene el proyecto desarrollado, en ésta
sección se presentan los objetivos que se tuvieron previstos. Estos pueden ser desglosados en
objetivos principales, y objetivos específicos que deben ser logrados para cumplir con todos
los requerimientos de la empresa TELCEL.
2.1. Objetivos principales
•
Proporcionar una herramienta gráfica que permita la administración y monitoreo de los
dispositivos IP de la red WLL a través de sesiones Telnet sobre el servidores HPOV.
•
Disminuir la carga de trabajo del Centro de Control de la Red (CCR) a través de la
disminución de la cantidad de llamadas recibidas debidas a consultas y fallas en la red.
•
Reducir el tiempo de atención del cliente optimizando el sistema de respuestas a
problemas en la red.
2.2. Objetivos secundarios
•
Descubrir los dispositivos de la red de manera automática.
•
Crear y actualizar una base de datos de todos los dispositivos de la red.
•
Consultar el estado operativo de los dispositivos.
•
Ofrecer herramientas de diagnóstico y solución de fallas.
•
Realizar configuraciones masivas o individuales de los dispositivos BreezeCom
•
Generar reportes de los nodos de la red.
•
Conocer el tráfico de cada celda.
•
Restringir el acceso a la red mediante la definición de perfiles de usuario.
•
Realizar un diseño modular que permitirá anexar nuevos servicios IP.
18
CAPÍTULO 3
FUNDAMENTOS TEÓRICOS
Para llevar a cabo el desarrollo de la herramienta de monitoreo de dispositivos IP de la
red WLL de TELCEL y cumplir con los objetivos del proyecto, es necesario realizar una
revisión bibliográfica de todos los temas que involucran el desarrollo del mismo. Este capítulo
incluye una reseña de los cambios de la tecnología inalámbrica en los últimos años, pasando
por definiciones específicas de la tecnología WLL, arquitectura de la red inalámbrica de
TELCEL, parámetros del protocolo SNMP y un estudio del protocolo Telnet.
3.1. Protocolo Telnet
Telnet es un protocolo de conexión entre terminales, además proporciona la base para
protocolos posteriores como FTP, HTTP, entre otros.
El propósito del protocolo Telnet es proporcionar un servicio de comunicaciones
orientado a bytes de 8 bit general y bidireccional. El principal objetivo es permitir un método
estándar de comunicar terminales y procesos orientados a terminal. El protocolo puede usarse
también para comunicaciones terminal-terminal ("enlace") y comunicaciones proceso-proceso
(computación distribuida) [1].
3.1.1. Consideraciones Generales
Una conexión Telnet es una conexión TCP usada para transmitir datos con información
de control Telnet intercalada.
El protocolo Telnet se basa en tres ideas principales: en primer lugar, el concepto de un
"Terminal Virtual de Red" (NVT, Network Virtual Terminal) [1]; y en segundo lugar, el
principio de opciones negociadas; y tercera, una visión simétrica de terminales y procesos.
Estos conceptos y principios se enumeran a continuación:
19
1. Cuando se inicia una conexión Telnet, se supone que se inicia y finaliza en un
"Terminal Virtual de Red" o NVT. Un NVT es un dispositivo imaginario que proporciona una
representación intermedia de un terminal. Esto elimina la necesidad para los terminales
"servidor" y "usuario" de guardar información de las características del terminal del otro y de
las convenciones para manejarlo. Ambos construyen un mapa de las características del
dispositivo local para que a través de la red parezca un NVT y ambos pueden suponer que
existe un mapeado similar en el otro extremo. Se pretende que el NVT sea algo intermedio
entre ser muy restringido (que no proporciona a los terminales lo suficiente como para mapear
sus códigos de caracteres locales), y ser demasiado exigente (penalizando a los usuarios con
terminales modestos).
El terminal "cliente" o “usuario” es aquel al que el terminal físico está normalmente
conectado y el terminal "servidor" es el que normalmente proporciona algún servicio. Desde
otro punto de vista, aplicable incluso en comunicación terminal-terminal o proceso-proceso, el
terminal "cliente" es aquel que inicia la comunicación.
2. El principio de opciones negociadas tiene en cuenta el hecho de que muchos
terminales querrán proporcionar servicios adicionales a los disponibles en un NVT y muchos
usuarios tendrán terminales sofisticados y querrán disponer de servicios sofisticados en lugar
de los mínimos. Hay "opciones" independientes del Protocolo Telnet pero estructuradas
dentro de él que se dispondrán y que se podrán usar con la estructura "DO, DON'T, WILL,
WON'T" (tratada posteriormente) que permiten a un usuario y a un servidor ponerse de
acuerdo para usar convenciones más elaboradas (o tal vez sólo diferentes) para sus
conexiones Telnet. Entre esas opciones se podrían incluir el cambio del juego de caracteres, el
modo de eco, entre otros.
La estrategia básica para el uso de opciones es hacer que una parte (o ambas) inicien la
petición de activar alguna opción. El otro lado puede entonces aceptar o rechazar la petición.
Si la petición se acepta, tiene efecto inmediato; si se rechaza, el aspecto asociado de la
conexión queda tal y como se especifica para un NVT. Claramente, una parte siempre puede
20
rehusar activar una opción y nunca debe rehusar desactivar alguna opción ya que ambos lados
deben estar preparados para soportar un NVT.
Se ha diseñado la sintaxis de la negociación de opciones para que si ambas partes
solicitan una opción simultáneamente, cada una de ellas vea la petición de la otra como el
reconocimiento positivo de la suya [1].
3. La simetría de la sintaxis de negociación puede potencialmente llevar a bucles
infinitos de reconocimiento, cada parte viendo las órdenes que llegan no como
reconocimientos, sino como nuevas peticiones para reconocer. Para evitar esto, prevalecen las
siguientes normas:
a. Las partes sólo pueden solicitar un cambio del estado de una opción; por
ejemplo, una parte no puede enviar una "petición" simplemente para anunciar en qué
modo está.
b. Si una parte recibe lo que parece una petición para entrar en algún modo en
el que ya está, la petición no debería reconocerse. No responder esto es esencial para
evitar bucles infinitos en la negociación. Es necesario enviar una respuesta para las
peticiones de cambio de modo incluso si no se ha cambiado el modo.
c. Siempre que una parte envíe una orden de opción a la otra, ya sea una
petición o un reconocimiento, y el uso de la opción va a tener algún efecto en el
procesado de los datos enviados de la primera parte a la segunda, dicha orden se debe
enviar en el punto donde se desee que comience a tener efecto. (Hay que tener en
cuenta que pasará algún tiempo entre la transmisión de una petición y la recepción de
un reconocimiento, que puede ser negativo. Por tanto, un Terminal puede ir
almacenando los datos a enviar después de solicitar una opción, hasta que la petición
se acepte o deniegue, para ocultar al usuario el "periodo de incertidumbre").
21
Es probable que las solicitudes de opción vayan de un lado a otro cuando se inicia la
conexión Telnet, ya que cada parte intenta obtener el mejor servicio posible de la otra. Además
de esto, se pueden usar las opciones para modificar dinámicamente las características de la
conexión para ajustarse a cambios en las condiciones locales. Por ejemplo, el NVT, como se
explica después, usa un mecanismo de transmisión que se ajusta bien a muchas aplicaciones,
como el BASIC, que envían una "línea cada vez", pero se ajusta mal a aplicaciones que, como
el NLS, envían un "carácter cada vez". Un servidor puede optar por la carga extra de
procesador que requiere una disciplina de "carácter cada vez" cuando se ajusta mejor al
proceso local y negociaría la opción apropiada. Sin embargo, en lugar de estar
permanentemente cargado con el trabajo extra que esto requiere, podría volver (es decir,
negociar la vuelta) al NVT cuando no sea necesario el control detallado [1].
Es posible que las peticiones iniciadas por procesos provoquen un bucle de petición
infinito si el proceso responde a un rechazo volviendo a solicitar la opción. Para evitar que
esto suceda, las peticiones rechazadas no se deben repetir hasta que algo cambie.
Operacionalmente, esto puede significar que el proceso está ejecutando un programa
diferente o el usuario ha enviado otra orden o cualquier otra cosa que tenga sentido en el
contexto para un proceso dado y una opción dados. Una buena regla a seguir es que sólo se
debe repetir una petición como resultado de información adicional procedente del otro
extremo de la conexión o cuando se solicite por intervención del usuario a nivel local.
Los diseñadores de opciones no se deberían sentir restringidos por la, en cierto modo,
limitada sintaxis para negociar opciones. El objetivo de la sintaxis simple es hacer fácil tener
opciones ya que es fácil ignorarlas. Si alguna opción en particular requiere una estructura de
negociación más compleja que la posible mediante "DO, DON'T, WILL, WON'T", lo
apropiado es usar "DO, DON'T, WILL, WON'T" para aclarar que ambas partes entienden la
opción y, una vez conseguido esto, se puede usar una sintaxis más compleja. Por ejemplo, una
parte puede enviar una solicitud para alterar (establecer) la longitud de línea. Si se acepta, se
puede usar una sintaxis diferente para negociar la longitud de la línea esa "subnegociación"
puede incluir campos para los valores mínimo, máximo y deseado de longitud de línea. El
22
concepto importante es que esas negociaciones expandidas nunca deberían iniciarse hasta que
una negociación previa (estándar) haya establecido que ambas partes son capaces de
interpretar la sintaxis expandida [1].
En resumen, se envía WILL XXX por cualquier parte para indicar que esa parte desea
(ofrece) iniciar la opción XXX, siendo DO XXX y DON'T XXX los reconocimientos positivo
y negativo respectivamente; de la misma forma, se envía DO XXX para indicar un deseo
(petición) de que la otra parte (es decir, quien recibe el DO) inicie la opción XXX, siendo
WILL XXX y WON'T XXX los reconocimientos positivo y negativo respectivamente. Como
el NVT es lo que queda cuando no se activa ninguna opción, las respuestas DON'T y WON'T
garantizan que la conexión se quede en un estado que ambas partes entienden [1]. De esta
manera, todos los procesos Telnet se pueden implementar de tal forma que ignoren
completamente todas las opciones no soportadas, simplemente devolviendo un rechazo a
cualquier solicitud de opción que no entienda.
En la medida de lo posible, el protocolo Telnet se ha hecho simétrico entre el servidor
y el usuario para que de forma natural se adapte a conexiones usuario-usuario y servidorservidor. Se espera, pero no se requiere en absoluto, que las opciones fomenten la simetría. En
cualquier caso, se acepta explícitamente que la simetría es un principio operativo más que una
regla inamovible.
3.1.2. El Terminal Virtual de la Red
El Terminal Virtual de Red (NVT, Network Virtual Terminal) es un dispositivo
bidireccional de caracteres. El NVT tiene una impresora y un teclado. La impresora responde a
los datos que llegan y el teclado produce los datos de salida que se envían a través de la
conexión Telnet y, si se desea, también a la impresora del NVT. Los "ecos" no deberían
recorrer la red (aunque existen opciones para activar el modo de operación de eco "remoto",
no es obligatorio implementar esta opción). El código usado es USASCII de siete bits en un
campo de ocho bits. Cualquier conversión de códigos u otras consideraciones que surjan son
problemas locales y no afectan al NVT.
23
3.1.3. Transmisión de datos
Aunque una conexión Telnet a través de la red es intrínsecamente bidireccional (fulldúplex), se debe ver al NVT como un dispositivo unidireccional (half-dúplex) operando en
modo línea. A
no ser que se negocien opciones indicando lo contrario, se aplican las
siguientes condiciones por defecto a la transmisión de datos por la conexión Telnet:
1. Los datos se deben acumular en el terminal donde se generan hasta tener una línea
completa de datos o hasta que alguna señal definida localmente indique que debemos
transmitir los datos. Esta señal se puede generar por un proceso o por un usuario. Todo ello
mientras que el espacio de almacenamiento local lo permita.
La motivación de esta regla es el elevado coste, para algunos terminales, de procesar
una interrupción de entrada de datos por red unido a la especificación por defecto del NVT
que dice que los "ecos" no circulan por la red. Por eso es razonable almacenar una cantidad de
datos a medida que se obtienen. Muchos sistemas realizan alguna acción al final de cada línea
de entrada, por eso la transmisión se debería ocurrir al final de cada línea. Por otra parte, un
usuario o proceso puede necesitar o desear enviar datos que no necesariamente terminan en
una nueva línea; por tanto, se le advierte a los programadores de que proporcionen métodos
para indicar localmente que todos los datos almacenados deben transmitirse inmediatamente.
2. Cuando un proceso ha terminado de enviar datos a una impresora NVT y no tiene más
datos que procesar (es decir, cuando un proceso en un extremo de una conexión Telnet no
puede continuar sin datos del otro extremo), el proceso debe transmitir la orden Telnet “Go
Ahead” (Continuar).
Esta regla no pretende requerir que se envíe la orden Telnet GA desde cada terminal en
el extremo de una línea, ya que los servidores no requieren normalmente ninguna señal en
especial (además de fin-de-línea u otros caracteres definidos localmente) para iniciar el
proceso. En cambio, la orden Telnet GA está diseñada para ayudar a que el terminal local de
un cliente interaccione a nivel físico con terminales unidireccionales que disponen de un
24
teclado que se puede bloquear. Una descripción de este tipo de terminal puede ayudar a
explicar el uso correcto de la orden GA [1].
La conexión terminal-terminal está siempre bajo control del usuario o el cliente.
Ninguno puede unilateralmente apoderarse del control cuando lo tiene el otro; en lugar de eso,
quien tenga el control debe liberarlo explícitamente. En la parte del terminal, el hardware está
diseñado para que libere el control cada vez que se termina una línea (es decir, cuando el
usuario pulsa la tecla de nueva línea). Cuando esto ocurre, el cliente (local) al que está
conectado procesa los datos de entrada, decide si se genera salida y si no devuelve el control
al servidor. Si se genera salida, el terminal mantiene el control hasta que ha transmitido todos
los datos.
Las dificultades de usar este tipo de cliente a través de la red deberían ser obvias. El
computador local no es capaz de decidir si mantener el control después de ver la señal “fin de
línea” (EOL) o no; esta decisión sólo puede tomarla el computador remoto que procesa los
datos. Por tanto, la orden Telnet GA proporciona un mecanismo por el cual el computador
remoto (servidor) puede indicar al terminal local (cliente) que es el momento de transferir el
control al usuario del cliente. Debería transmitirse en esos momentos y sólo en esos momentos
es en los que se debe dar al usuario el control del cliente. Teniendo en cuenta que un envío
prematuro de la orden GA puede provocar que se bloquee la salida, ya que el cliente
probablemente pensará que la transmisión de datos está parada y, por tanto, no marcará el final
de línea manualmente.
Lo precedente, por supuesto, no se aplica a la dirección cliente-servidor de la
comunicación. En esta dirección, se pueden enviar GAs en cualquier momento, pero no son
necesarios. También, si la conexión Telnet se usa para comunicación proceso-a-proceso, no se
necesita el envío de GAs en ninguna dirección. Finalmente, para comunicaciones terminal-aterminal, se pueden necesitar GAs en ninguna, una o ambas direcciones. Si un cliente espera
soportar comunicación terminal-a-terminal se sugiere que el servidor provea al usuario con
algún medio para indicar manualmente que es el momento de enviar un GA; no obstante, esto
no es un requisito para un proceso que implemente el protocolo Telnet [1].
25
Se nota que la simetría del modelo Telnet requiere que haya un NVT en cada extremo
de la conexión Telnet, al menos conceptualmente.
3.1.4. La impresora y el teclado NVT
La impresora NVT tiene un ancho de carro y una longitud de página sin especificar y
puede producir representaciones de los 95 caracteres USASCII imprimibles (códigos 32 a
126). De los 33 códigos de control de USASCII (de 0 a 31 y el 127), y los otros 128 códigos
que no están cubiertos (128 a 255), los mostrados en la tabla 3.1 tienen un significado
específico para la impresora NVT.
NOMBRE
NULO(NUL)
CÓDIGO
0
SIGNIFICADO
Ninguna operación.
Avance de
línea (LF)
10
Mueve la impresora a la siguiente
línea conservando la misma
posición horizontal.
Retorno de
carro (CR)
13
Mueve la impresora al margen
izquierdo de la línea actual.
Tabla 3.1 - Códigos USAASCII con importancia para la impresora NVT
Además, los siguientes códigos (tabla 3.2) deberán tener efectos definidos, pero no
requeridos, sobre la impresora NVT. Ningún extremo de una conexión Telnet puede asumir
que el otro lado hará, o ha hecho, ninguna acción particular al recibir o transmitir estos.
26
NOMBRE
CÓDIGO
SIGNIFICADO
Campana (BEL)
7
Produce una indicación audible
o visible que NO desplaza el
cabezal de la impresora.
Retroceso (BS)
8
Mueve el cabezal una posición
hacia el margen izquierdo.
9
Mueve la impresora al siguiente
punto de parada horizontal. No
se especifica cómo cada parte
determina o establece dónde
están esos puntos de parada.
Tabulador horizontal (HT)
Tabulador vertical (VT)
11
Avance de página (FF)
12
Mueve la impresora al siguiente
punto de parada vertical. No se
especifica cómo cada parte
determina o establece dónde
están esos puntos de parada.
Mueve la impresora al principio
de la siguiente página
manteniendo la misma posición
horizontal.
Tabla 3.2 – Códigos USAASCII con efectos definidos en la impresora NVT
El resto de los códigos no hacen que la impresora NVT realice acción alguna.
La secuencia "CR LF", según la definición, hará que el NVT se posicione en el margen
izquierdo de la siguiente línea (tal y como lo haría, por ejemplo, la secuencia "LF CR"). Sin
embargo, muchos sistemas y terminales no tratan el CR y el LF de forma independiente y esto
hará realizar un esfuerzo extra para simular su efecto. (Por ejemplo, algunos terminales no
tienen un CR separado del LF, pero en ellos se puede simular el CR con retrocesos.) Por tanto,
la secuencia "CR LF" se debe tratar como si fuera un carácter de nueva línea y usado cuando
se pretende obtener el resultado de su acción combinada; la secuencia "CR NUL" se usará
cuando lo único que se quiere es un retorno de carro; y se debe evitar el carácter CR en otros
contextos. Esta regla asegura a los sistemas que deben decidir si realizar un función de "nueva
línea" o múltiples retrocesos que el flujo Telnet contiene un carácter después del CR que
permitirá tomar una decisión acertada. Nótese que se requiere "CR LF" o "CR NUL" en ambas
direcciones (en el modo ASCII por defecto), para preservar la simetría del modelo NVT.
Aunque se puede saber en determinadas situaciones (por ejemplo, con las opciones de eco
remoto y continuar en efecto) que no estamos enviando los caracteres a una impresora real, sin
27
embargo, en aras de la consistencia, el protocolo requiere que se inserte un NUL después de
cada CR que no vaya seguido de un LF en el flujo de datos. La conversión de esto es que un
NUL recibido en el flujo de datos después de un CR (en ausencia de opciones que
explícitamente indiquen lo contrario) debería ser eliminado antes de aplicar el conjunto de
caracteres usado localmente por el NVT.
El teclado NVT tiene teclas o combinaciones de teclas o secuencias de teclas para
generar los 128 códigos USASCII. Nótese que aunque muchos de ellos no tienen efecto sobre
la impresora NVT, el teclado NVT es capaz de generarlos todos.
Además de estos códigos, el teclado NVT deberá poder generar los siguientes códigos
adicionales que, excepto en los que se diga lo contrario, tiene significados definidos pero no
requeridos. La asignación de códigos para estos "caracteres" está en la sección de Órdenes
Telnet, porque son, en cierto sentido, genéricos y deberían estar disponibles incluso cuando el
flujo de datos se interpreta como si fuera otro código de caracteres.
3.1.5. Estructura de órdenes Telnet [1]
Todas las órdenes Telnet consisten, al menos, en una secuencia de dos bytes: el
carácter de escape "Interpretar como Orden" (IAC) seguido por el código de orden. Las
órdenes que negocian opciones consisten en secuencias de tres bytes, siendo el tercero el
código para la opción referenciada. Se ha elegido este formato para hacer que si se usa
racionalmente el espacio de datos - mediante negociaciones a partir del NVT básico, por
supuesto - las colisiones de bytes de datos con órdenes se minimicen, requiriendo esas
colisiones la inconveniencia e ineficiencia de "escapar" los bytes de datos. De la forma
indicada, sólo se necesita duplicar el IAC para enviarlo como un dato y los otros 255 códigos
se pueden pasar transparentemente.
Estas son las órdenes Telnet definidas (tabla 3.3). Se debe tener en cuenta que estos
códigos o secuencias de códigos sólo tienen el significado que se indica si van inmediatamente
precedidos por un IAC.
28
NOMBRE
CÓDIGO
SE
NOP
240
241
Marca de datos (DM)
Break
Interrumpir proceso
Interrumpir salida
Estás Ahí
Borrar Caracter
Borrar Línea
Continuar
242
243
244
245
246
247
248
249
SB
250
SIGNIFICADO
Fin de los parámetros de
subnegociación.
No operación.
La parte del flujo de datos de un
Synch. Siempre se debe acompañar
de una notificación urgente de TCP.
Caracter BRK del NVT.
La función IP.
La función AO.
La función AYT.
La función EC.
La función EL.
La señal GA.
Indica que lo que sigue es una
subnegociación de la opción indicada.
WILL (código de opción)
251
WON'T (código de opción)
252
Indica el deseo de iniciar el uso de una
opción o la confirmación de que ya se
está usando.
Denota la negativa a usar o continuar
usando la opción indicada.
253
Es una solicitud para que el otro lado
use una opción o la confirmación de
que se espera que el otro lado la use.
254
255
Pide a la otra parte que deje de usar
una opción o indica que ya no
esperamos que la use más.
Byte de datos 255.
DO (código de opción)
DON'T (código de opción)
IAC
Tabla 3.3 – Órdenes TELNET
3.1.6. Establecimiento de la conexión
La conexión TCP del Telnet se establece entre el puerto U del cliente y el puerto L del
servidor. El servidor espera esas conexiones en un puerto L conocido. Como una conexión
TCP es bidireccional y se identifica por el par de puertos, el servidor puede atender muchas
conexiones simultáneas entre su puerto L y diferentes puertos U de cliente.
3.1.7. Asignación de puertos
Cuando se usa para acceso remoto de usuarios a un terminal (por ejemplo, acceso
desde un terminal remoto) a este protocolo se le asigna el puerto servidor 23 (27 en octal).
Esto es: L = 23.
29
3.2. Wireless Local Loop
Se trata de un medio que provee enlaces locales sin cables. Mediante sistemas de radio
omnidireccional de bajo poder, WLL permite a las operadoras una capacidad de transmisión
mayor a un Megabit por usuario y más de un Gigabit de ancho de banda agregado por área de
cobertura [4].
Tales sistemas están siendo implantados en las economías emergentes, donde aún no
existe acceso a las redes públicas fijas. Los países en desarrollo como China, India, Brasil,
Rusia, Indonesia y Venezuela utilizan la tecnología WLL, como una manera eficiente de
desplegar servicios a millones de suscriptores, evitando los costos de trazar rutas de cable
físico.
También es altamente beneficioso para los operadores que entran en mercados
competitivos, ya que dichas compañías pueden llegar a los usuarios sin tener que pasar por las
redes de los operadores tradicionales.
En economías desarrolladas, los costos de despliegue y mantenimiento de la tecnología
inalámbrica, son relativamente bajos. Esas ventajas hacen de WLL una solución de alta
competencia.
3.2.1. Evolución de las Redes de acceso WLL
La utilización de la radio como técnica de acceso en redes fijas de Telecomunicación
no es una novedad, ya que estas aplicaciones vienen utilizándose desde hace bastante tiempo,
si bien en entornos regulatorios y mercados muy diferentes al actual.
Ya en los primeros años 80, se disponía de sistemas de acceso analógicos de
microondas Punto a Multipunto (PMP). Estos sistemas respondían a la necesidad de extender
los servicios básicos de Telecomunicación a áreas geográficas de difícil cobertura por otros
medios, como los de tipo cableado, que requieren una importante inversión en infraestructura
y obra civil. No obstante, el despliegue de sistemas de acceso radio fue inicialmente bastante
marginal, limitándose a satisfacer parte de los operadores establecidos en régimen de
monopolio [3].
30
En los años 90, y especialmente en la segunda mitad de la década, una serie de factores
han incidido notablemente en la evolución de las redes de acceso radio (en adelante las
denominaremos con el acrónimo inglés WLL, Wireless Local Loop): por un lado, la aparición
de nuevas tecnologías de radio digital, en gran parte motivadas por la explosión de las
comunicaciones móviles; por otro, un gran esfuerzo de estandarización que ha permitido
alcanzar las economías de escala suficientes para bajar drásticamente los precios de elementos
tecnológicamente
muy
complejos;
finalmente,
los
movimientos
desreguladores
y
liberalizadores han hecho surgir la competencia en el bucle local, competencia en la que las
redes WLL pueden jugar un papel importante [3].
Hoy día puede decirse que las redes WLL constituyen una tecnología madura y las
cifras del mercado avalan esta afirmación.
En lo referente a servicios, también se ha producido una evolución significativa en las
capacidades ofrecidas por las redes de acceso radio. En este aspecto podemos distinguir tres
generaciones de redes WLL:
- Primera generación: redes orientadas fundamentalmente a proporcionar telefonía en zonas
rurales.
- Segunda generación: marcada por la incorporación de servicios de datos (VBD-Voice Band
Data) e ISDN (Integrated Services Digital Network).
Se consideran adecuadas para el entorno rural y suburbano con una densidad de
población entre media y baja. Esta generación se encuentra actualmente en fase de madurez
técnica y corresponde a la mayoría de los sistemas en el mercado.
- Tercera generación: adecuada para proporcionar servicios derivados de Internet y
comunicaciones de datos en modo paquete. Están orientadas a entornos urbanos tanto
residenciales como de negocios. Esta es una generación emergente con un potencial de
crecimiento importante a corto y medio plazo.
31
3.2.2. Características
La principal característica de WLL es que proporciona un servicio alternativo a la
telefonía alámbrica.
Para operar WLL, la infraestructura primero debe ser desplegada, es decir, las radio
bases tienen que ser instaladas hasta alcanzar la cobertura geográfica y la capacidad requeridas
por la red. Sólo entonces, el servicio estará disponible para todos los suscriptores potenciales,
dentro del rango de señales de las radio bases.
El servicio individual comenzará con la instalación de la unidad del usuario, la
autorización y la activación.
3.2.3. Infraestructura:
3.2.3.1. Terminales
El suscriptor recibe el servicio telefónico a través de terminales conectados por radio a
una red de estaciones. Los terminales WLL pueden ser microteléfonos que permiten grados
variables de movilidad. Pueden constar de teléfono integrado a un equipo para uso en el
escritorio o pueden ser unidades solas o de varias líneas que se conectan con unos o más
teléfonos estándares [3].
Los terminales se pueden montar dentro de una habitación o al aire libre, ellas pueden
o no incluir baterías de respaldo para el uso durante interrupciones de la línea de potencia. Las
diferencias en diseños de los terminales WLL reflejan el uso de diversas tecnologías de radio.
3.2.3.2. Las radio bases WLL
Las radio bases en un sistema WLL se despliegan para proveer la cobertura geográfica
necesaria. Cada radio base se conecta a la red, bien por cable o por microondas. De esta
manera, un sistema WLL se asemeja a un sistema celular móvil: cada radio base utiliza una
célula o varios sectores de cobertura, manteniendo a los suscriptores dentro del área de
cobertura y proporcionando conexión de retorno a la red principal. El área de cobertura es
32
determinada por la potencia del transmisor, las frecuencias en las cuales la radio base y las
radios terminales del suscriptor funcionan, las características locales asociadas de la
propagación en función de la geografía local y del terreno, y los modelos de radiación de las
antenas de la terminal de la estación base y del suscriptor.
En los sistemas WLL que no permiten movilidad del usuario, algunas reducciones en
el costo pueden ser obtenidas, gracias a la optimización del diseño de la radio base, con el fin
de atender a un suscriptor que se encuentra en una ubicación fija, ya conocida de antemano.
El número de radio bases depende de anticipar el tráfico para el cual se va a utilizar, la
capacidad de sistema, la disponibilidad del sitio, el rango de cobertura que se va a
proporcionar y las características de propagación local, además del ancho de banda a ser usado
por la red WLL.
En general, cuanto mayor es el ancho de banda disponible, mayor es la capacidad para
desplegar la red.
3.2.4. Tecnologías disponibles de WLL
WLL puede ser puesto en ejecución a través de cinco categorías de tecnologías
inalámbricas:
•
Digital celular.
•
Analógico celular.
•
Servicios de Comunicaciones personales (PCS).
•
Telefonía sin cables de segunda generación (CT-2) – Telecomunicaciones digitales sin
cables (Dect).
•
Imprementaciones propietarias.
Cada uno de estas tecnologías tiene una mezcla de fuerzas y debilidades para las
aplicaciones WLL.
33
3.2.4.1. Digital celular
Estos sistemas, que han visto un crecimiento bastante rápido, desplazarán a los analógicos en
muy poco tiempo. Los estándares celulares digitales más importantes son:
•
GSM, sistema global para las comunicaciones móviles.
•
TDMA, acceso múltiple por división de tiempo.
•
e-TDMA, Hughes enhanced TDMA.
•
CDMA, acceso múltiple por división de códigos.
•
GSM domina el mercado celular digital con 71% de suscriptores y está concentrado en
Europa.
Se espera que el sistema celular digital desempeñe un papel importante en proporcionar
WLL, ya que pueden soportar mayor cantidad de suscriptores que los sistemas analógicos, y
también ofrecen funciones que satisfacen mejor la necesidad de emular las capacidades de las
redes cableadas avanzadas. Su desventaja es que no es tan escalable como celular analógico.
Actualmente casi la totalidad de los sistemas WLL instalados utilizan tecnología celular
digital.
Aunque el GSM domina actualmente el mercado celular digital móvil, poco se ha hecho
para usarlo como plataforma WLL. Puesto que la configuración de GSM fue diseñada para
manejar roaming internacional, lleva implícito una gran cantidad de gastos indirectos que lo
hacen poco manejable y costoso para aplicaciones WLL. A pesar de estas limitaciones, es
probable que aparezcan productos GSM WLL.
CDMA parece ser el estándar mejor colocado para aplicaciones WLL. CDMA emplea una
técnica de modulación para separar el espectro, según la cual una amplia gama de la
frecuencia se utiliza para la transmisión y la señal de baja potencia del sistema se separa a
través de frecuencia de banda ancha. Asimismo ofrece mayor capacidad que los otros
estándares digitales (celulares 10 a 15 veces mayor que analógicos), voz relativamente de alta
calidad y un alto nivel de aislamiento [3].
34
3.2.4.2. Celular analógico
El celular analógico posee una amplia disponibilidad, resultado de su participación en
mercados de la alta movilidad. Actualmente existen tres tipos principales de sistemas
analógicos celulares:
•
AMPS, sistema de teléfonía móvil avanzada.
•
NMT, teléfonía móvil (para los países) nórdicos.
•
TACS, sistemas de comunicaciones del acceso total.
Los tres tienen su nicho de participación en el mercado. Como plataforma WLL, el
sistema celular analógico tiene algunas limitaciones con respecto a capacidad y funciones.
Debido a su extenso despliegue, se espera que los sistemas celulares analógicos sean una
plataforma sin hilos importante para WLL, por lo menos en corto plazo [3].
3.2.4.3. PCS
Su propósito es ofrecer a baja movilidad, servicios inalámbricos usando antenas de
baja potencia y microteléfonos ligeros y baratos. PCS es un sistema de comunicaciones para
ciudad, con rango menor que el celular. Tiene una amplia gama de servicios de
telecomunicaciones individualizados que permiten a los usuarios o los dispositivos
comunicarse sin importar dónde se encuentren.
No está claro qué estándar dominará la opción WLL en PCS. Los candidatos son
CMDA, TDMA, GSM, sistemas de comunicación personales del acceso (PACS), omnipoint
CDMA, upbanded CDMA, el sistema japonés PHS, y el teléfono sin hilos digital (DCT-U, en
Estados Unidos). Estos estándares serán utilizados probablemente en combinación para
proporcionar WLL y servicios de la radio de la alta movilidad [3].
3.2.4.4. CT-2/DECT
La telefonía sin hilos fue desarrollada originalmente para proporcionar acceso
inalámbrico dentro de una residencia o de un negocio, entre un teléfono y una estación PBX.
35
Puesto que la estación sigue estando atada por cable a la red telefónica fija, no se considera
WLL.
DECT se considera WLL cuando un operador de red pública proporciona servicio sin
hilos directamente al utilizar esta tecnología.
Aunque DECT no parece satisfacer plenamente las aplicaciones rurales o de baja
densidad, tiene algunas ventajas significativas en áreas de media y alta densidad. La telefonía
sin hilos tiene ventajas en términos de escalabilidad y funcionalidad. Con respecto a
tecnología celular, DECT es capaz de llevar el tráfico a niveles más altos, proporciona mejor
calidad de voz y puede transmitir datos a tasas más altas. La configuración de las microcelda
en DECT permite que sea desplegado en incrementos más pequeños hasta que se logra
emparejar la demanda de suscriptores, con requisitos de capital inicial reducidos [3].
3.2.4.5. Los Sistemas Propietarios
Las puestas en práctica de Sistemas Propietarios WLL abarcan una variedad de
tecnologías y de configuraciones. Estos sistemas se consideran propietarios porque no están
disponibles en redes inalámbricas públicas y son modificadas según los requisitos particulares
de una aplicación específica. Generalmente no proporcionan movilidad. Esto hace que la
tecnología propietaria sea la más eficaz para aplicaciones que no se pueden desarrollar - por
rentabilidad y tiempo - con alternativas cableadas [3].
3.2.5. Aplicaciones y segmentos de mercado
Un factor clave para el éxito de cualquier tecnología emergente lo constituye la
predisposición del mercado para responder a los servicios y capacidades que dicha tecnología
ofrece. Es necesario, por lo tanto analizar las necesidades y expectativas de aquellos
segmentos de mercado donde las redes de acceso radio de banda ancha resultan más
adecuadas.
Podemos distinguir los siguientes segmentos de mercado significativos [7]:
36
•
Residencial básico, caracterizado por un uso predominante de los servicios de voz y de
TV (distribución). Con un uso marginal, aunque creciente, de acceso a Internet, con
velocidades no demasiado elevadas.
•
Residencial alto, realiza un mayor uso de Internet y está dispuesto a pagar por una
mayor velocidad de acceso.
•
Oficina doméstica, también conocido por las siglas inglesas SOHO (Small Office,
Home Office) que responde al perfil típico de teletrabajador o pequeña empresa
familiar. Para este segmento una línea múltiple y conexión permanente a Internet son
aspectos cruciales.
•
Pyme o Pequeña y Mediana Empresa. Este es el segmento de mercado más "goloso" y
al que los nuevos operadores, especialmente los que entran al mercado con tecnologías
radio, dirigirán sus esfuerzos.
•
Grandes empresas, con decenas o miles de empleados y cuyas necesidades de servicios
de comunicación son muy importantes. Normalmente se trata de empresas ubicadas en
diferentes zonas y con una necesidad perentoria de comunicaciones internas y redes
privadas.
3.2.6. Arquitecturas y topologías
Los sistemas WLL deben optimizar el uso de los canales de radio, proporcionando la
mayor capacidad posible al máximo numero de abonados, para un ancho de banda dado. Para
ello utilizan técnicas de acceso múltiple TDM/TDMA o TDMA/TDMA Desde el punto de
vista topológico, presentan un despliegue multicelular que permite el reuso de frecuencia en
cada celda, con estructuras punto a multipunto (PMP) o multipunto a multipunto [3].
Las estructuras punto multipunto se adaptan de modo natural a una colectividad de
usuarios distribuidos geográficamente conectada a las redes troncales a través de un nodo de
acceso. Este nodo controla la red de acceso y las interfaces de conexión hacia las redes
troncales.
Por razones de fiabilidad se necesitan unidades redundantes, que representan un coste
inevitable de abordar desde el primer momento, aun cuando el número de abonados equipados
37
en el sistema sea muy pequeño (situación típica en los primeros meses de despliegue del
producto en el campo).
Las estructuras multipunto, aunque con algunas ventajas sobre las anteriores, presentan
una complejidad que las ha relegado a un segundo plano.
Una de las características más importantes de los sistemas WLL avanzados es la
asignación dinámica de los recursos radio en tiempo real, en función de las interferencias
presentes en cada momento, lo que facilita en gran medida la planificación de la red a lo largo
del ciclo de despliegue del producto.
En resumen, el sistema WLL fijo tiene cuatro usos potenciales: para llevar los servicios
de telefonía a las áreas desatendidas en el mundo; para proveer de servicios avanzados a las
áreas de negocios; para reemplazar los sistemas cableados en las zonas comerciales y
residenciales; y como una alternativa de tecnología de bucle local para mercados nuevos o
liberalizados. WLL está siendo implementado en países en desarrollo que no cuentan con
sistemas de cableados adecuados. De manera que WLL ofrece las ventajas de una instalación
y configuración rápida, lo cual elimina los altos costos asociados al tendido de cables. De
hecho, algunos países en vías de desarrollo utilizan casi exclusivamente, sistemas
inalámbricos y no están invirtiendo en fibra u otras alternativas cableadas. La tecnología WLL
es particularmente atractiva en lugares donde la topología del terreno hace que la instalación
de cables sea problemática. WLL también puede satisfacer la necesidad de expandir el número
de usuarios conectados a la red, rápidamente.
El término Wireless Local Loop, también es usado para referirse a sistemas móviles de
bajo poder. Semejantes sistemas están típicamente basados en microteléfonos de uso dual que
pueden ser operados a través de estaciones bases de la red de la oficina o del hogar para uso de
telefonía inalámbrica y a través de la red pública cuando los usuarios están fuera del alcance
de la estación base matriz. Los costos en infraestructura tienden a ser menores que la de los
sistemas celulares, ya que las estaciones base son más simples; sin embargo, la movilidad de
tales sistemas tiende a ser limitada ya que las celdas son más pequeñas y están restringidas a
un área geográfica específica. Ejemplo de este tipo de sistemas, son el Personal Access
38
Communications System (PACS) y Personal Wireless Telecommunications (PWT), ambos
implementados en los Estados Unidos de Norteamérica; Digital Enhanced Cordless Telephone
(DECT), intensamente utilizado en Europa; Cordless Telephony Generation 2 (CT2) y
CT2Plus, usados en Singapur, Hong Kong, Canadá y algunos países europeos; y el Personal
Handyphone System (PHS), usado principalmente en Japón [3].
3.2.7. Red WLL con equipos BreezeAccess (BreezeCom)
BreezeACCESS provee sistemas de banda ancha para voz y datos, tanto para
aplicaciones privadas como para Wireless Local Loop (WLL) para el caso de Telcel. Además
ofrece una alternativa inalámbrica a las soluciones de banda ancha basadas en infraestructura
de cables, como ISDN, XDSL o Cable Módem. Puede ser usado para comunicación de voz
como para Internet de alta velocidad. El ancho de banda para cada estación es de 3Mbps, con
un total agregado por celda de 72 Mbps y una cobertura con un radio de 15 Km.
El sistema soporta manejo SNMP a través de MIBs (Management Information Base,
véase 3.2) estándar y privado así como Radius para facturación. BreezeACCES provee
conexiones de alta calidad y confiabilidad gracias a su sofisticada tecnología de radio de
Spread Spectrum / Time Diversity. BreezeAccess opera en las bandas de 2,4 GHz, 3,4- 4,0
GHz y 5,7 GHz., teniendo así la posibilidad de operar con a sin línea de vista, lo que lo hace
una alternativa significativamente mas económica y mas rápida de implementar que los
sistemas tradicionales [4].
3.2.8. Arquitectura estándar de la base estación (una sola celda)
La red WLL esta configurada por interfaces punto-multipunto, en donde una celda
(sectorizada) sirve como central de las unidades de usuario (SU), la interfaz de una celda
puede observarse en la figura 3.1. En la misma se puede observar que la central pública se
encuentra conectada vía IP al enrutador de la celda, así como las unidades de autentificación
(AAA), mail, web, entre otras. El switche permite la interacción entre las unidades d sector
39
BreezeCom (AU) y el router. Los AU se encuentran conectados a su vez a través de unidades
RF a las antenas direccionales.
Figura 3.1 – Arquitectura BS BreezeAccess
3.2.9. Arquitectura estándar de unidades de subscriptor
La estructura de las unidades del subscriptor se observa en la figura 3.2. En ésta se
puede observar que los SU soportan las interfaces de datos y de voz sobre IP. Sin embargo en
la plataforma WLL de Telcel no se encuentra implantado el servicio de voz sobre IP. El caso
de los SU compartido por varios usuarios (8 máximo dado que se tiene un máximo de 8
canales de datos) “MDU” corresponden a los dispositivos SU-8D y SU-8D1V.
40
Figura 3.2 – Arquitectura SU BreezeAccess
3.2.10. Arquitectura de la red WLL de TELCEL (múltiples celdas)
De esta manera se puede tener una visión general de la interfaz de múltiples celdas de
la plataforma WLL de Telcel, donde se centralizan los servidores de tarificación y de
autentificación, para administrar las distintas radio bases (Figura 3.3).
Figura 3.3 – Arquitectura red WLL TELCEL
41
3.3. Protocolo Simple para Gestión de Redes (Simple Network Management Protocol,
SNMP)
Con el crecimiento de tamaño y complejidad de las interredes basadas en TCP/IP la
necesidad de la administración de redes comienza a ser muy importante. El espacio de trabajo
de la administración de redes actual para las interredes basadas en TCP/IP consiste en:
1. SMI (RFC 1155) - describe cómo se definen los objetos administrados contenidos en el
MIB.
2. MIB-II (RFC 1213) - describe los objetos administrados contenidos en el MIB.
3. SNMP (RFC 1098) - define el protocolo usado para administrar estos objetos.
El IAB emitió un RFC detallando su recomendación, que adoptó dos enfoques diferentes:
•
A corto plazo debería usarse SNMP.
IAB recomienda que todas las implementaciones IP y TCP sean redes que
puedan administrarse. En el momento actual, esto implica la implementación de
MIB-II Internet (RFC 1213), y al menos el protocolo de administración
recomendado SNMP (RFC 1157).
•
A largo plazo, se podría investigar el uso del protocolo de administración de redes OSI
emergente (CMIP). Esto se conoce como CMIP sobre TCP/IP (CMOT).
SNMP y CMOT usan los mismos conceptos básicos en la descripción y definición de
la administración de la información llamado Estructura e Identificación de Gestión de
Información (SMI) descrito en el RFC 1155 y Base de Información de Gestión (MIB)
descritos en el RFC 1156.
Por lo general, SNMP se utiliza como una aplicación cliente/servidor asincrónica, lo
que significa que tanto el dispositivo administrado como el software servidor SNMP pueden
generar un mensaje para el otro y esperar una respuesta, en caso de que haya que esperar una.
42
Ambos lo empaquetan y manejan el software para red (como el IP) como lo haría
cualquier otro paquete. SNMP utiliza UDP como un protocolo de transporte de mensajes. El
puerto 161 de UDP se utiliza para todos los mensajes, excepto para las trampas, que llegan el
puerto 162 de UDP. Los agentes reciben sus mensajes del administrador a través del puerto
UDP 161 del agente.
SNMP v2 añade algunas nuevas posibilidades a la versión anterior de SNMP, de las
cuales, la más útil para los servidores es la operación get-bulk. Ésta permite que se envíen un
gran número de entradas MIB en un solo mensaje, en vez de requerir múltiples consultas getnext para SNMP v1. Además, SNMP v2 tiene mucho mejor seguridad que SNMP vl, evitando
que los intrusos observen el estado o la condición de los dispositivos administrados. Tanto la
encriptación como la autentificación están soportadas por SNMP v2. SNMP v2 es un
protocolo más complejo y no se usa tan ampliamente como SNMP vl [6].
El SNMP reúne todas las operaciones en el paradigma obtener-almacenar (fetch store
paradigm). Conceptualmente, el SNMP contiene sólo dos comandos que permiten a un
administrador buscar y obtener un valor desde un elemento de datos o almacenar un valor en
un elemento de datos. Todas las otras operaciones se definen como consecuencia de estas dos
operaciones.
La mayor ventaja de usar el paradigma obtener-almacenar es la estabilidad,
simplicidad flexibilidad. El SNMP es especialmente estable ya que sus definiciones se
mantienen fijas aun, cuando nuevos elementos de datos se añadan al MIB y se definan nuevas
operaciones como efectos del almacenamiento de esos elementos.
Desde el punto de vista de los administradores, por supuesto, el SNMP se mantiene
oculto. El usuario de una interfaz para software de administración de red puede expresar
operaciones como comandos imperativos (por ejemplo, arrancar). Así pues, hay una pequeña
diferencia visible entre la forma en que un administrador utiliza SNMP y otros protocolos de
administración de red [2].
A pesar de su extenso uso, SNMP tiene algunas desventajas. La más importante es que
se apoya en UDP. Puesto que UDP no tiene conexiones, no existe contabilidad inherente al
43
enviar los mensajes entre el servidor y el agente. Otro problema es que SNMP proporciona un
solo protocolo para mensajes, por lo que no pueden realizarse los mensajes de filtrado. Esto
incrementa la carga del software receptor. Finalmente, SNMP casi siempre utiliza el sondeo en
cierto grado, lo que ocupa una considerable cantidad de ancho de banda.
Un paquete de software servidor SNMP puede comunicarse con los agentes SNMP y
transferir o solicitar diferentes tipos de información. Generalmente, el servidor solicita las
estadísticas del agente, incluyendo el número de paquetes que se manejan, el estado del
dispositivo, las condiciones especiales que están asociadas con el tipo de dispositivo (como las
indicaciones de que se terminó el papel o la pérdida de la conexión en un módem) y la carga
del procesador.
El servidor también puede enviar instrucciones al agente para modificar las entradas de
su base de datos MIB. El servidor también puede enviar los límites o las condiciones bajo las
cuales el agente SNMP debe generar un mensaje de interrupción para el servidor, como
cuando la carga del CPU alcanza el 90 por ciento.
Las comunicaciones entre el servidor y el agente se llevan a cabo de una forma un
tanto sencilla, aunque tienden a utilizar una notación abstracta para el contenido de sus
mensajes. Por ejemplo, el servidor puede enviar un mensaje what is your current load y recibir
un mensaje del 75%. El agente nunca envía datos hacia el servidor a menos que se genere una
interrupción o se haga una solicitud de sondeo. Esto significa que pueden existir algunos
problemas constantes sin que el servidor SNMP sepa de ellos, simplemente porque no se
realizó un sondeo ni se generó interrupción [2].
3.4. Base de datos de administración (MIB)
La MIB define los objetos de la red operados por el protocolo de administración de
red, y las operaciones que pueden aplicarse a cada objeto. Una variable u objeto MIB se define
especificando la sintaxis, el acceso, el estado y la descripción de la misma. La MIB no incluye
información de administración para aplicaciones como Telnet, FTP o SMTP, debido que es
difícil para las compañías fabricantes instrumentar aplicaciones de este tipo para el MIB.
44
•
Sintaxis: Especifica el tipo de datos de la variable, entero, cadena dirección IP, entre
otros
•
Acceso: Especifica el nivel de permiso como: Leer, leer y escribir, escribir, no
accesible.
•
Estado: Define si la variable es obligatoria u opcional.
•
Descripción: Describe textualmente a la variable.
La MBI-1 define solo 126 objetos de administración, divididos en los siguientes
grupos [2]:
•
Grupo de Sistemas: se usa para registrar información del sistema el cual corre la
familia de protocolos, por ejemplo:
•
-
Compañía fabricante del sistema.
-
Revisión del Software.
-
Tiempo que el sistema ha estado operando.
Grupo de Interfaces: registra la información genérica acerca de cada interfaz de red,
como el número de mensajes erróneos en la entrada y salida, el número de paquetes
transmitidos y recibidos, el número de paquetes de broadcast enviados, MTU del
aparato, entre otros.
•
Grupo de traducción de dirección: comprende las relaciones entre direcciones IP y
direcciones específicas de la red que deben soportar, como la tabla ARP, que relaciona
direcciones IP con direcciones físicas de la red LAN.
•
Grupo IP: almacena información propia de la capa IP, como datagramas transmitidos y
recibidos, conteo de datagramas erróneos, entre otros. También contiene información
de variables de control que permite aplicaciones remotas puedan ajustar el TTL (Time
To Live) de omisión de IP y manipular las tablas de enrutamiento de IP.
•
Grupo TCP: este grupo incluye información propia del protocolo TCP, como
estadísticas del número de segmentos transmitidos y recibidos, información acerca de
conexiones activas como dirección IP, puerto o estado actual.
•
Grupo de ICMP y UDP: igual que el grupo IP y TCP.
•
Grupo EGP: en este grupo se requieren sistemas (enrutadores) que soporten EGP.
45
La MIB -II pretende extender los datos de administración de red empleados en redes
Ethernet y Wan usando enrutadores a una orientación enfocada a múltiples medios de
administración en redes LAN y WAN. Además agrega dos grupos más [2]:
•
Grupo de Transmisión: grupo que soporta múltiples tipos de medios de comunicación,
como cable coaxial, cable UTP, cable de fibra óptica y sistemas TI/EI.
•
Grupo SNMP: incluye estadísticas sobre tráfico de red SNMP.
Cabe señalar que un elemento de red, solo necesita soportar los grupos que tienen sentido
para él.
46
CAPÍTULO 4
MARCO ORGANIZACIONAL
Telcel es una empresa de telecomunicaciones que presta servicios en toda la extensión
del territorio venezolano. Forma parte del grupo internacional Telefónica Móviles, compañía
que gestiona las actividades de telefonía celular del Grupo Telefónica en todo el mundo. Tras
el acuerdo de adquisición de las operaciones de BellSouth en Latinoamérica, es la segunda
mayor multinacional del sector de telefonía móvil a nivel mundial, con unos 72 millones de
clientes gestionados a septiembre de 2004, y la compañía líder del mercado de Latinoamérica,
con más de 50 millones de clientes gestionados en la región. Telefónica Móviles obtuvo un
beneficio neto de 1,607.9 millones de euros en 2003. Telefónica Móviles cotiza en las bolsas
españolas y en el New York Stock Exchange con el código TEM.
4.1. Misión
Ser la empresa líder en servicios de comunicaciones en Venezuela. Satisfaciendo las
necesidades de sus clientes y del mercado, con excelencia en la atención al usuario, calidad en
servicios, modernas tecnologías y un equipo humano altamente motivado y capacitado para
alcanzar la rentabilidad de la compañía, y el desarrollo económico y social del país.
4.2. Visión
Ser la empresa de comunicaciones que logre satisfacer todas las necesidades de sus
clientes y del mercado, con una organización participativa basada en gente excelente, procesos
ágiles y flexibles, lineamientos claros y conocidos, en un ambiente de trabajo confortable, y un
entorno abierto y competitivo.
4.3. Filosofía
Telcel tiene como filosofía estar a la vanguardia con la más avanzada tecnología, a fin
de brindar excelencia y calidad en servicios de telecomunicaciones.
47
Desde que Telcel empezó a operar en Venezuela, han hecho importantes inversiones,
dirigidas a consolidarse como una empresa global de telecomunicaciones, que satisface las
necesidades de sus clientes y se adapte a las realidades de un mercado en continua evolución.
Profundizar su actuación en el ámbito de las telecomunicaciones y contribuir con el
desarrollo del país son las metas que animan la gestión de Telcel.
4.2 Centro de Control de la Red
A fin de garantizar los niveles de operatividad de la red y la continuidad de los
servicios que ofrece en la actualidad, Telcel cuenta con una unidad de monitoreo y gestión
remota tanto de las redes operativas de la empresa, como de las redes que soportan los
productos que ofrece Telcel comercialmente a sus clientes externos. Esta unidad es el Centro
de Control de la Red o CCR, el cual opera las 24 horas del día, los 365 días del año.
Apoyado en un complejo sistema de gestión y monitoreo que correlaciona los sistemas
de gestión propietario de las diferentes tecnologías que conforman la red Telcel, el CCR
detecta las condiciones de malfuncionamiento de cualquier elemento y es responsable de
iniciar y coordinar las acciones de troubleshooting. Estas acciones pueden culminar con la
corrección de la falla con solamente la gestión remota desde el CCR o puede demandar algún
tipo de acción directamente sobre los equipos en cuyo caso se coordina la asistencia de
personal técnico ubicado en las regiones.
El Centro de Control de la Red (CCR) es una dependencia de la vicepresidencia de
Redes en el departamento de Redes e infraestructura.
48
CAPÍTULO 5
METODOLOGÍA
El problema, como se dijo anteriormente, consiste en disminuir la carga de trabajo en
el CCR (Centro de control de la red) diseñando y desarrollando una herramienta gráfica que
permitiese, a niveles de solución de problemas inferiores (Soporte T-Net), dar respuestas
rápidas y solventes a los problemas de la red, todo esto sin comprometer la seguridad que debe
tener ésta.
Para el estudio de posibles soluciones del problema se tomaron registros de las
llamadas, antes y después de la implementación, de manera de medir el impacto que tendría
esta en la carga de trabajo del CCR.
Para le realización del programa se tuvo en cuenta que ésta sería principalmente un
cliente sobre un servidor UNIX (Gestor de la red WLL), sin embargo debía ejecutarse bajo
entorno Windows, ya que todos los gestores de red que se encuentran en el CCR son bajo
entorno Windows (exceptuando el mencionado anteriormente) y sería una pérdida de tiempo
en la solución de un problema el cambiar el sistema operativo. Por ello se decidió, dada la
facilidad de programación y los métodos predefinidos de los objetos con los que puede
construirse un terminal cliente [5], que el lenguaje de programación fuese Visual Basic. Entre
otras opciones se tenían C++, Peral y FoxPro; sin embargo por las razones anteriormente
expuestas y porque Visual Basic provee un entorno de trabajo altamente amigable (que en este
caso es necesario, ya que los usuarios finales no tenían altos conocimientos de redes) se
inclinó la balanza hacia éste.
En cuanto a qué versión del Visual Basic debería usarse, la decisión fue tomada por
disponibilidad del compilador en la empresa, lo que resultó en la versión 6.0 de dicho
lenguaje.
En primer lugar la aplicación establece entonces una conexión al servidor. Tomando en
cuenta las distintas formas de establecer la conexión, se llegó a la conclusión que la mejor
49
opción era diseñar un cliente Telnet. Esto debido a que la simplicidad proporcionada por este
protocolo permite que no se necesiten muchos privilegios dentro de la red. El caso de SSH, en
cambio, necesita permisología especial dentro de la empresa lo que hubiese retrasado
significativamente el desarrollo del proyecto.
Este cliente Telnet establece conexión con el servidor que funciona como puerta de
entrada a la red WLL de Telcel (Figura 5.1), luego, por demanda del usuario, toma variables
de los distintos dispositivos de la red y los muestra. Debe resaltarse que la aplicación no está
periódicamente tomando muestras del estado de la red, sino que únicamente muestra el estado
de uno o varios dispositivos cuando el usuario lo desee. Esto se debe a que el sistema de
atención al cliente funciona de esa manera: por demanda. Además se quiso que los operadores
de soporte T-Net tuviesen limitantes en cuanto a ver el estado instantáneo de la red.
TELNET
Cónsola de
Servicios IP
(CSIP)
Datos
WS CCR
Servidor CCR-Desarrollo
HPOV
TELNET
PING
SNMPGET
SNMPSET
SNMPWALK
Ethernet
CSIP
CSIP
WS Sop. T-NET
RED WLL
WS Planta Externa
Figura 5.1 – Diagrama del sistema
Para la asignación de privilegios se utilizó una base de datos en donde estuviesen
registrados todos los usuarios finales de la aplicación (Operadores de Sop. T-Net, Especialistas
de Red del CCR, Operadores de Planta Externa, etc.), en esta base de datos además de
asignársele a la persona un “Nombre de Usuario” y una clave, se le asigna un número decimal
al registro entre 0 y 5 que define el departamento del usuario, de manera que el programa sea
capaz de reconocer y de aplicar el perfil correspondiente.
50
La administración de los dispositivos se logra gracias a una base de datos en donde se
guarda de manera permanente cada uno de los dispositivos de manera de obtener en la
aplicación una vista total de la red. Para ello se empleó la estructura de árbol para la vista de la
red.
De esta manera, si un dispositivo es instalado, reemplazado o eliminado; es así mismo
insertado, modificado o eliminado de la base de datos.
En un principio se pensó que la base de datos debía ser propietaria de ORACLE, sin
embargo, dada la disponibilidad de los recursos en los servidores ORACLE se tomó la
decisión de hacerla en Access. Access además de proveer una herramienta menos complicada
que ORACLE permite tener suficientes sesiones abiertas como para las que necesitaba la
aplicación (aunque ORACLE es más poderosa en este sentido). Además en cuanto a la
seguridad de esta base de datos, no requería encriptamiento ya que esta se encontraba y se
consultaba desde el mismo disco de red privado de Telcel.
Es por ello y dada la urgencia de disminución de carga de trabajo en el CCR, que la
aplicación fuese utilizada durante gran parte del desarrollo de la misma, por ello se realizó un
método de actualización del programa para que actualizaciones sucesivas y frecuentes del
sistema pudiesen ser tomadas por los usuarios generando el mínimo contratiempo. Esto se
logró mediante el uso de un disco de red disponible en la red interna de Telcel, que a su vez se
encuentra aislada de la red WLL por el servidor UNIX “HPOVWLL”.
En este disco de red es donde se ejecuta directamente la aplicación haciendo más fácil
la instalación y la actualización del programa.
Pueden resumirse los métodos y procedimientos utilizados en el proyecto en las
siguientes etapas:
51
Levantamiento de la Información:
En esta etapa se realizó una inducción al problema, se creó un plan de acción, se
estudiaron los procedimientos anteriores para la solución de problemas. Además en esta etapa
se realizó el primer registro de llamadas.
Se estudiaron las posibles formas de obtener informaciones de los dispositivos sin
alterar su funcionamiento normal. Entre estas se tienen el SSH (Secure Shell) de UNIX que es
un protocolo punto a punto con muchas ventajas, entre ellas el encriptamiento de los datos,
pero que sin embargo no existían instaladas en el servidor HPOVWLL. Es así como se llegó a
la conclusión que la manera más ventajosa era a través del protocolo de última capa SNMP
que es utilizado en este tipo de redes “masivas” por su versatilidad y rapidez, y cuyo agente se
encuentra instalado en el servidor antes nombrado.
Con estas herramientas ya diseñadas se consideraron las posibles soluciones. Se
observaron distintos gestores SNMP comerciales como el SolarWinds y se estudiaron las MIB
de gestión SNMP de los dispositivos de la red WLL en busca de las variables a utilizar.
En esta etapa se procedió a la elección del lenguaje de programación a diseñar, que al
final fue Visual Basic dadas las razones anteriormente expuestas.
Diseño de la Aplicación:
Luego del estudio del problema y de la creación de un plan de acción se procedió a la
definición de los alcances, limitaciones, recursos necesarios y de los métodos de ejecución del
proyecto, además de diseñar la interfaz de usuario.
Entre las limitaciones más resaltantes se encontraba la incapacidad que tendría la
herramienta para manejar alarmas o traps de SNMP ya que éstas son sólo manejadas por el
gestor de red HPOVWLL y no son reflejadas hacia otras redes.
52
Otro aspecto sobresaliente corresponde a la posible adición de nuevas redes IP que son
administradas por el CCR, es por ello que se diseñó un sistema modular que permitiese la
aceptación de nuevos módulos en forma de objetos. De ahí que se construyeran objetos para
definir los dispositivos que se administrarían de buenas a primeras.
En cuanto al plan de implantación, como la herramienta tenía carácter de urgencia para
los operadores de CCR, se debía contar con recursos muy específicos como un disco de red
desde donde se permitiera la ejecución de la aplicación y que hiciera fácil la actualización de
la misma de manera que se pusiera en práctica durante la etapa de desarrollo. Entre otros
recursos utilizados se tienen las cuentas de usuario que tiene el programa en el servidor de
WLL.
Para hacer fácil la administración de los dispositivos se creó una base de datos que
contuviera cada uno de éstos. Esta base de datos, que no existía anteriormente, se creó
mediante el desarrollo de una pequeña aplicación, que luego fue anexada modularmente a la
aplicación final, que descubre los dispositivos de la red mediante el uso de consultas SNMP a
los dispositivos que se tenían registrados en las tablas ARP de los routers de cada celdas.
En esta etapa se diseñaron los perfiles de usuario de la aplicación. Se tomaron en
cuenta las distintas preocupaciones en materia de seguridad telemática que tenían los
departamentos involucrados. De esta manera se adjudicaron las operaciones críticas
(Configuración de los dispositivos y el reset de los dispositivos) a los niveles más altos de
solución de problemas.
Desarrollo de la aplicación:
Como se dijo anteriormente la aplicación fue diseñada en Visual Basic 6.0. Este
lenguaje, de manera sencilla, permite establecer una sesión TCP hacia el puerto que se halla
configurado mediante el objeto Winsock [5]. Este objeto se configuró al puerto 23 (puerto de
Telnet)
y se dirigió hacia el servidor Telnet del HPOVWLL. Sin embargo esto no fue
53
suficiente, ya que, como se expuso en la revisión bibliográfica, el protocolo Telnet necesita
configurar una serie de opciones que se tramitan iniciando la comunicación.
Así se comenzó el desarrollo de la aplicación, configurando un terminal cliente Telnet,
que se logró mediante un objeto. Luego se continuó con el desarrollo de las bases de datos que
contendrían la información de cada uno de los dispositivos de la red y de cada uno de los
usuarios y sus perfiles en la aplicación.
Además se desarrolló el objeto que estaría asociado a los dispositivos de la red WLL.
En este objeto se utilizaron para la mayoría de los métodos las consultas SNMP para las
operaciones sobre los dispositivos.
Para una mejor visión sobre la red, ésta se organizó en forma de árbol dónde cada nodo
corresponde con un dispositivo. Sin embargo el nodo raíz y los nodos inmediatamente
siguientes (hijos), son únicamente para organizar los dispositivos en regiones. Por lo tanto los
SU estarían organizados por AU, los AU por celdas y las celdas por regiones. Así el nodo
padre de un AU es necesariamente una celda.
Documentación de la aplicación:
En esta etapa se desarrollaron dos manuales: el manual de usuario y el manual técnico.
En el primero se daba una breve introducción al entorno de trabajo, mientras que en el técnico
se da una explicación completa de los algoritmos de programación.
Implantación:
Durante la implantación de la aplicación se trabajó, en mayor medida, en el
departamento de atención al cliente. Allí se hicieron los procesos de instalación y se entrenó al
personal en el uso del programa.
54
Además se realizaron dos presentaciones al departamento de Radio Base, ya que estos
serían los encargados del mantenimiento de la base de datos.
Mantenimiento:
Se contó con una ventana de mantenimiento de una semana, de manera de resolver
problemas inherentes a la aplicación, haciendo más robusta la ejecución de ésta.
55
CAPÍTULO 6
DESARROLLO
Esta herramienta gráfica fue desarrollada con la finalidad de dar remedio a los
problemas de monitoreo y solución de fallas de la red WLL de TELCEL.
CSiP fue diseñada para monitorear la red a través del servidor UNIX HPOVWLL por
motivos de seguridad de la red. Es por ello que funciona como cliente Telnet de dicho
servidor, lo que constituye su mayor fortaleza pero también su mayor debilidad.
Para la ejecución de tareas de administración de la red, se utilizan comandos
directamente enviados desde el cliente al servidor, aunque también se desarrollaron Scripts en
Shell de UNIX que se encuentran dentro del servidor cuyas respuestas son interpretadas por la
aplicación.
Los dispositivos monitoreados por la aplicación son routers Cisco, presentes en cada
una de las celdas, y dispositivos para enlace de voz y datos de la casa BreezeCom de Alvarion,
los cuales constan de una unidad de servicio (AU) y de una unidad para el suscriptor (SU).
Además el programa es capaz de monitorear otros dispositivos que pudiesen estar presentes en
la red como switch y tarjetas de GPS.
Para hacer posible el monitoreo de la red sin afectar el funcionamiento de la misma, se
utilizaron los mecanismos de supervisión del protocolo SNMP y sesiones Telnet directas
sobre los dispositivos. Las consultas SNMP se hacen, en su mayoría, a través de la MIB
(Management Information Base) de los dispositivos BreezeCom.
6.1. Cónsola de Servicios IP (CSiP)
Se basa en un programa modular realizado en Visual Basic 6.0, utilizando múltiples
formularios con los controles comúnmente utilizados para el manejo de variables. El mismo
trabaja con bases de datos de Microsoft Access 2000,
anteriormente.
por las razones expuestas
56
La aplicación fue diseñada para que funcionara como cliente Telnet del servidor
HPOVWLL, por ende se utiliza el control Winsock con sus propiedades y métodos para
realizar la conexión a éste.
Para el buen funcionamiento de CSiP se debe asegurar un mínimo de memoria de
64Mb RAM con un procesador Pentium de 233 MHz , espacio mínimo de 10Mb libres de
Disco, acceso al servidor HPOVWLL y acceso al disco de red desde el cual se ejecuta la
aplicación.
6.1.1. Sistema de Archivos
Como muestra la figura 6.1 la aplicación consta de archivos en el directorio raíz del
programa entre los que destaca el archivo CSiP.exe y la base de datos Netwll.mdb. También
debe haber una carpeta “Data” en donde se almacenarán algunos archivos con variables
dinámicas del programa y la base de datos login.mdb.
Figura 6.1 – Sistema de Archivos CSiP
Opcionalmente se crea un directorio “Setup” con los archivos de instalación del
programa y un instructivo de instalación.
57
6.2. Estructura de las bases de datos
A continuación se dará una breve explicación del diseño de las bases de datos de los
dispositivos y de los usuarios y perfiles de la aplicación.
6.2.1. Netwll.mdb
Esta base de datos contiene toda la información necesaria de los dispositivos que
conforman la red, así como la estructura en que deben ser ordenados.
6.2.1.1. Tabla Árbol
Esta tabla se utiliza para definir el root en el árbol donde se refleja el mapa de la red.
Además contiene la información sobre las regiones en las que se divide. Contiene un campo el
cual sirve para que todos los usuarios conozcan un comentario en específico sobre la región o
sobre la red en general. Este campo es leído por la función dbVisor para mostrar a través del
programa alguna información adicional sobre el dispositivo (tabla 6.1).
Campo
Nombre
Padre
Comentarios
Tipo
Texto
Texto
Texto
Descripción
Nombre
Nombre del Nodo Padre
Comentarios sobre el
dispositivo.
Tabla 6.1 – Tabla Árbol
6.2.1.2. Tabla CELDA
Contiene la información de las celdas de cada región. El campo Región permite
conocer el nodo padre del dispositivo, y de esta manera es fácilmente ubicado dentro del árbol
de la red (tabla 6.2).
58
Campo
IP Add
Nombre
Región
Administrador
Comentarios
Tipo
Texto
Texto
Texto
Descripción
Dirección IP
Nombre de la Celda
Región a la que pertenece la
Celda
Texto
Nombre del administrador de la
Celda
Texto
Comentarios sobre la Celda
Tabla 6.2 – Tabla CELDA
6.2.1.3. Tabla AU
Contiene los datos de todas las unidades de acceso o Access Units (AU) de la
red. En este caso el campo Celda funciona como indicador del nodo padre. En el caso
de que se trate de una extensión de otra unidad (AU conectado en serie con un SU de
manera de llegar a sitios lejanos), en el campo Celda es colocada la dirección IP de la
unidad de acceso que funciona como “padre” y es establecido el campo Ext a
Verdadero (tabla 6.3).
Campo
IP Add
Nombre
MAC Add
Sector
Celda
Last Reset
Comentarios
Ext
Community
Name
Tipo
Texto
Texto
Texto
Número
Texto
Descripción
Dirección IP
Nombre
MAC Address
Número de sector al que pertenece
Dirección IP de la Celda a la que
pertenece
Texto
Fecha y Hora del último Reset del
dispositivo
Texto
Comentarios sobre el dispositivo
Booleano
Indica si es un AU extendido
Texto
Contraseña de administración del
dispositivo
Tabla 6.3 – Tabla AU
6.2.1.4. Tabla SU
Contiene los datos de todas las unidades de subscriptor o Suscriber Units (SU)
de la red. En este caso el campo Celda y el campo Sector funcionan como indicadores
del nodo padre. En el caso de que se trate de una unidad configurada como Best AU
59
(No tienen asociados un AU en particular, sino que se adjudican al que reciban con
mayor potencia), en el campo BestAU es establecido a Verdadero y el campo Sector a
Null (tabla 6.4).
Campo
Login Name
IP Add
MAC Add
Celda
Sector
Cliente
ESSID
Last Ping
Tipo
Texto
Texto
Texto
Texto
Número
Texto
Texto
Texto
Best AU
Booleano
Last Reset
Comentarios
E-mail
Community
Name
Fecha
Texto
Texto
Texto
Texto
Descripción
Nombre de usuario al que corresponde la unidad
Dirección IP
MAC Address
Dirección IP de la Celda a la que pertenece
Número de sector al que pertenece
Nombre completo del Cliente
ESSID (Extended Service Set ID) del dispositivo
Fecha de la última vez que se le hizo ping al
dispositivo
Indica si el dispositivo esta configurado para Best
AU
Fecha y Hora del último Reset del dispositivo
Comentarios sobre el dispositivo
Indica si es un AU extendido
Contraseña de administración del dispositivo
Fecha/Hora
Fecha y Hora de la última actualización de los
datos del dispositivo
Tabla 6.4 – Tabla SU
6.2.1.5. Tabla GPS
Contiene los datos de todas las unidades de GPS o GPS Units (GU) de la red. En este
caso el campo Celda funciona como indicador del nodo padre (tabla 6.5).
Campo
Nombre
IP Add
MAC Add
Celda
Last Reset
Community
Name
Tipo
Texto
Texto
Texto
Texto
Texto
Texto
Descripción
Nombre
Dirección IP
MAC Address
Dirección IP de la Celda a la que pertenece
Fecha y Hora del último Reset del dispositivo
Contraseña de administración del dispositivo
Tabla 6.5 – Tabla GPS
60
6.2.1.6. Tabla MDU
Contiene los datos de todas los switch que soporten múltiples subscriptores para un
solo Suscriber Unit. En este caso el campo SU IP funciona como indicador del nodo padre. En
el caso de que este campo esté vacío, es decir, que no ha sido ubicado a un SU; el programa lo
ubica por defecto en la celda especificada en el campo Celda (tabla 6.6).
Además es a través del MAC Address que este dispositivo puede ser ubicado.
Campo
IP Add
MAC Add
SU IP
Celda
Sector
Community
Name
Tipo
Texto
Texto
Texto
Descripción
Dirección IP
MAC Address
Dirección IP del SU al que
pertenece el switch
Texto
Dirección IP de la Celda a la que
pertenece
Número
Número de sector al que pertenece
Texto
Contraseña de administración del
dispositivo
Tabla 6.6 – Tabla MDU
6.2.1.7. Tabla Temporal
Esta tabla es el resultado de la consulta que importa la información de las bases de
datos del departamento de Tráfico (CCF) que contiene la información del tráfico cursado en
los últimos días y de los dispositivos a través de los que cursa. A partir de esta tabla se
resuelve, si existiera o no alguna coincidencia en la tabla SU y/o si fuese eventualmente una
actualización más reciente del dispositivo, si el dispositivo puede ser agregado o modificado
en la base de datos local del programa (tabla 6.7). La estructura de esta tabla es semejante a la
tabla SU para facilitar la programación de funciones de modificado y de agregado. Sin
embargo debe tomarse en cuenta que algunos campos en la tabla SU (Community Name, entre
otros) no tendrán equivalente en esta tabla ya que la información no es extraíble de las tablas
de Tráfico. Es por ello que al momento de importar la base de datos de Tráfico es posible que
existan algunas inconsistencias en las tablas que utiliza directamente el programa.
61
Es importante señalar que a pesar de que las bases de datos de SU de tráfico se
actualizan en términos de horas, estas bases de datos no presentan una orientación directa
hacia el programa, es decir, no están diseñadas para ser utilizadas por el sistema.
Campo
Login Name
IP Add
MAC Add
Celda
Sector
Fecha
Tipo
Texto
Descripción
Nombre de usuario al que
corresponde la unidad
Texto
Dirección IP
Texto
MAC Address
Texto
Dirección IP de la Celda a
la que pertenece
Número
Número de sector al que
pertenece
Fecha/Hora
Fecha y Hora de la última
actualización de los datos
del dispositivo
Tabla 6.7 – Tabla Temporal
6.2.1.8. Tabla IPCFTemp
Esta tabla contiene los datos temporales obtenidos con el comando sh ip cache flow
sobre un router de la red cuando es requerido por el usuario del programa. Los datos de esta
tabla son eliminados antes de ejecuta la función por lo que no acumula los registros de este
comando (tabla 6.8).
Campo
Vi
IP Fuente
Int Destino
IP Destino
Tipo
Texto
Texto
Texto
Texto
Protocolo
Puerto Fuente
Puerto Destino
Paquetes
Texto
Texto
Texto
Texto
Descripción
Virtual Interface del Usuario
Dirección IP Fuente del flujo de datos
Interfase Destino
Dirección IP Destino del flujo de
datos
Protocolo del flujo
Puerto Fuente del Flujo
Puerto Destino del Flujo
Cantidad de Paquetes enviados
Tabla 6.8 – Tabla IPCFTemp
62
6.2.1.9. Tabla ShUTemp
La tabla ShUTemp contiene los registros de cada uno de los usuarios que tienen sesión
abierta en el router así como su interfaz virtual asignada. Por medio de esta tabla se obtiene
una relación entre el Usuario, la dirección IP del SU, la Vi y la IP asignada en el pool de
direcciones IP del router. De esta manera cuando se analiza el flujo de datos en el programa se
conocerá a qué SU corresponde determinado flujo.
Esta tabla se llena durante el mismo momento que se llena la tabla IPCFTemp (tabla
6.9).
Campo
Vi
Usuario
Tipo
Descripción
Texto
Virtual Interface del usuario
Texto
Nombre de usuario
Tabla 6.9 – Tabla ShUTemp
6.2.1.10. Tabla Puertos
Esta tabla funciona como referencia a los puertos utilizados por los usuarios y
obtenidos por la aplicación con el comando sh ip cache flow. Estos puertos son obtenidos en
base hexagesimal y por medio de esta tabla se les otorga un nombre alfabético predefinido.
Por ejemplo el puerto 80 (50 hex) se le puede asignar el nombre “HTTP” de manera de ser
localizable dentro de la tabla vista dentro de la aplicación (tabla 6.10).
Campo
Puerto
Name
Tipo
Texto
Texto
Descripción
Número de puerto
Nombre del servicio
predeterminado para el
puerto
Tabla 6.10– Tabla Puertos
6.2.1.11. Otras tablas.
Las otras tablas (Mac - IP, MAC_PC_SU, TRAFICO_LUGAR y Usuarios) son
vínculos a las tablas de registros de dispositivos de Tráfico. A partir de estas tablas y a través
63
de la consulta SUC2 se logra la tabla Temporal que permita la función “Importar BD” y de
esta manera agregar o modificar dispositivos a la base de datos del programa.
6.2.1.12. Consultas
6.2.1.12.1. CCF: Esta consulta permite obtener las relaciones Vi –
Usuario en el comando sh ip cache flow estableciendo de esta manera un
vínculo muy importante para la ubicación de los dispositivos registrados en las
tablas del router. En la siguiente figura (Figura 6.2) se observan las relaciones
utilizadas para el diseño de esta consulta.
Figura 6.2 – Vínculos Consulta CCF
6.2.1.12.2. SUC2: Esta consulta permite la importación de la base de
datos de tráfico, obtiene las relaciones entre las distintas tablas vinculadas y
crea una nueva tabla con el nombre Temporal. Los vínculos se observan a
continuación (Figura 6.3).
64
Figura 6.3 – Vínculos Consulta SUC2
6.2.2. Login.mdb
Esta base de datos contiene toda la información sobre los Usuarios del sistema así
como las operaciones que han realizado dentro del programa. Ésta base de datos permite la
identificación del usuario, consta de 2 tablas. Está protegida por contraseña y sólo podrá tener
privilegios de lectura y escritura el administrador del sistema.
6.2.2.1. Tabla Password
Contiene todos y cada uno de los usuarios del programa, define el perfil del usuario de
manera que el programa asigne los correspondientes privilegios (tabla 6.11). No posee ningún
mecanismo de encriptamiento ya que la base de datos, además de estar protegida por
contraseña, se encuentra en un disco de red al que sólo puede acceder la aplicación.
Campo
Nombre
Username
Password
Extensión
Perfil
Tipo
Texto
Texto
Texto
Texto
Texto
Descripción
Nombre Completo
Login Name
Contraseña de acceso
Teléfono
Define los privilegios dentro
del programa.
0. Administrador
1. CCR
2. Soporte T-Net
3. Planta Externa
4. Radio Base
5. Supervisor Sop. T-Net
Tabla 6.11 – Tabla Password
65
6.2.2.2. Tabla LogFile
Funciona como bitácora o historial de la aplicación. Registra las operaciones realizadas
a través de la aplicación, así como el usuario que la ejecutó y el dispositivo al que se le aplicó
(tabla 6.12).
Campo
Fecha
Hora
Usuario
Operación
Tipo
Fecha/Hora
Fecha/Hora
Texto
Texto
IP Add
Texto
Descripción
Día de la operación (dd/mm/aaaa)
Hora de la operación (hh:mm:ss a.m./p.m.)
Usuario que realiza la operación
Operación realizada. Ésta puede ser:
• RESET UNIT
• Ver Asociaciones
• Ver Usuarios Conectados
• Ver IP Local Pool
• Consulta
• Ver Estadísticas de Tráfico
• NetFlow
• Supervisión (Site Survey)
• Descubrir SU, entre otros.
Define los privilegios dentro del programa.
0. Administrador
1. CCR
2. Soporte T-Net
3. Planta Externa
4. Radio Base
5. Supervisor Sop. T-Net
Tabla 6.12 – Tabla LogFile
El sistema debe estar en continua conexión con la base de datos, ya que las
actualizaciones de lotes se realizan de manera inmediata. En caso de perder la conexión con
las mismas aparece un mensaje y se cierra la aplicación.
La base de datos netwll.mdb debe encontrarse en el mismo directorio que el archivo
ejecutable de la aplicación. La base de datos login.mdb debe estar dentro de la carpeta “Data”
que se encuentre en el mismo directorio que el archivo ejecutable de la aplicación.
66
6.3. Algoritmos de programación de la aplicación.
En esta sección se hace referencia a los objetos, como las clases y los formularios
principales que fueron diseñados y desarrollados.
6.3.1. Clase CServidor
Esta clase es la que permite la conexión al servidor HPOVWLL vía Telnet. Contiene
todos los métodos que posee el objeto Winsock que se le introduzca a través de la propiedad
Sesión. Se puede observar en la figura 6.4 un esquema de la estructura de esta clase.
Figura 6.4 – Esquema de clase CServidor
Si se tiene un terminal Telnet debe establecerse las propiedades que describen esta
sesión, estas son: Omitir y Telnet. Si la sesión sostenida por el objeto Winsock es una sesión
Telnet, se debe establecer la propiedad Telnet a Verdadero. La propiedad Omitir permite
tener un terminal con comunicación unidireccional es decir, si la propiedad Omitir se
encuentra establecida a Verdadero la sesión no tomara en cuenta los comandos tecleados
desde el cliente, de lo contrario se contará con una sesión bidireccional. Estas propiedades se
encuentran establecidas a Falso predeterminadamente.
Las otras propiedades buffer y Buffer2 son las variables que almacenan los datos
enviados del servidor al cliente. La propiedad buffer almacena cada vez que llega algún dato
67
sin importar el tamaño ni si el comando es finalizado. En cambio Buffer2 acumula todos los
datos de buffer hasta que el comando haya finalizado, es decir, contiene la respuesta del
servidor a un comando del cliente por completo.
En cuanto a los métodos, Constructor únicamente establece el nombre del constructor
del servidor y su dirección IP. Mediante el método Conectar se establece la conexión con el
servidor a través de un puerto especificado como entrada a esta función.
El método SendData envía al servidor los datos que se hayan especificado como
entrada a esta función.
En cuanto a los eventos producidos por esta clase, ambos se refieren a las propiedades
buffer y Buffer2 respectivamente. El evento BufferLleno se dispara cada vez que se recibe
alguna información y se almacena en buffer. El evento InPrompt se emite cuando el cursor de
la sesión, luego de haber mandado a ejecutar algún comando en el servidor, se encuentra
localizado en el prompt del mismo, es decir, cuando está lleno Buffer2.
Figura 6.5 – Diagrama de ejecución de comandos
68
En el diagrama anterior (Figura 6.5) puede observarse el algoritmo de ejecución y
respuesta para el que se encuentra diseñada esta clase. Inicialmente es enviado el comando que
se quiere ejecutar, luego se espera, mediante un Timer periódico, la respuesta del servidor, si
ésta es por partes, es decir, si el caracter GA se intercala entre líneas la propiedad buffer toma
cada una de las respuestas; mientras que Buffer2 las almacena todas en orden. Puede
observarse el momento en que son emitidos los eventos, y la manera en que son almacenados
los datos en las propiedades de clase buffer y Buffer2.
Un ejemplo puede ser el método Reset_Unit de la clase CDispIP. Inicialmente al
invocar al método se envía la consulta SNMP correspondiente, que en este caso es snmpset cComunityString IP -t3 1.3.6.1.4.1.710.3.3.10.1.0 integer 1, luego se espera que el dispositivo
responda con un mensaje de reinicio satisfactorio (se logra este tiempo muerto a través del
timer, y se almacena a través de buffer y Buffer2).
69
6.3.2. Clase CDispIP
En esta clase se encuentran todas las funciones que pueden ser aplicables sobre los
dispositivos de la red WLL (Figura 6.6). Esta clase se desarrolló con la finalidad de que
funcionase sobre cualquier dispositivo IP de la red WLL, para de esta manera, en el caso de
anexar una nueva red al sistema de supervisión, bastara con anexar una nueva clase. Esta clase
cuenta con los métodos necesarios para lograr la supervisión de la red y es capaz de consultar
parámetros más importantes de la configuración de los dispositivos
Figura 6.6 – Diagrama de estructura de la clase CDispIP
Las propiedades Tipo, IP, name y Nodo corresponden al tipo (Router, AU, SU, GU ó
MDU), dirección IP, nombre y nodo dentro del control treeview [5] del dispositivo a consultar
respectivamente.
70
Además se le otorga a la clase una conexión a la base de datos de los dispositivos a
través de cn. Las cadenas de caracteres RoutLogin y RoutPass corresponden al nombre de
usuario y a la contraseña indicados por el usuario para tener acceso a los routers.
Como las operaciones se hacen desde el servidor, es necesario facilitarle a la clase el
terminal Telnet en cuya sesión realizará las operaciones, de esta manera la propiedad Session
corresponde al objeto CServidor donde se quiere que construya las secuencias de comando.
Esta clase está compuesta por 18 métodos que corresponden a las posibles operaciones
sobre cada uno de los distintos dispositivos de la red WLL.
-
SU_Disc: se basa en un mecanismo de búsqueda de dispositivos, en este caso
SU y MDU, que no se encuentren en la base de datos pero que formen parte de
la red. Esta operación debe hacerse sobre los routers ya que lo que hace es, de
manera resumida, buscar dentro de las tablas ARP de los routers registros de
dispositivos que no aparezcan en la base de datos (script en el servidor. Ver
p06.sh). Luego al obtener una lista de las direcciones IP de estos dispositivos,
hace una consulta SNMP apoyada en la MIB de BreezeCom demandando el
ESSID del dispositivo. Esta consulta se realiza utilizando los Community
Strings proporcionados por el usuario a través de unas cajas de texto ubicadas
en el formulario de Actualización de BD (ver Form2). Si el dispositivo
contesta esta consulta, es ubicado a través de esta variable dentro de la red y
se le consultan otras variables, de lo contrario no es añadido dentro de la base
de datos y se continúa con los demás dispositivos. Si el dispositivo no es
BreezeCom, se descarta la posibilidad de que sea un SU y por lo tanto debe
ser un switch de un MDU (sin embargo se realiza una consulta de una variable
de mib2 que confirma si es un switch).
Cuando se consulta una variable MIB correspondiente a BreezeCom a
un switch de otro proveedor, éste contesta con la siguiente cadena de
caracteres: “no MIB objects contained under subtree”. En el caso de que no
71
exista ningún dispositivo en la dirección consultada no se produce respuesta
alguna y se produce un timeout.
-
Descubrir_SU: es otro mecanismo para descubrir dispositivos en la red. Es
similar al anterior solo que este realiza un barrido de ping sobre las posibles
direcciones IP dada las máscaras de subred para cada router. Luego que una
dirección IP le contesta la petición de ping realiza las operaciones de consulta
SNMP al igual que en SU_Disc.
-
Locate_MDU: en los anteriores métodos es posible que se descubran los
switchs de los MDU, y dado que éstos no pueden ser ubicados, se diseña un
método que los ubique dentro de la red. Locate_MDU toma la información de
las tablas de los MAC Address asociados dentro de cada sector o AU y, a
través de la información que ésta proporciona, saber a qué SU corresponde
este switch y, de esta manera ubicarlo en la red.
-
Get_Client: realiza una consulta SNMP demandando la variable que
corresponde al nombre que tiene el SU. Devuelve una cadena de caracteres.
-
GetMACadd: realiza una consulta SNMP demandando la variable que
corresponde al MAC Address que tiene el SU, MDU, AU o Router. Devuelve
una cadena de caracteres.
-
GetESSID: realiza una consulta SNMP demandando la variable que
corresponde al ESSID que tiene el SU. Devuelve una cadena de caracteres.
-
DepuraBD: realiza una actualización automática de la base de datos, captando
los cambios realizados en la red, tomando tres variables determinantes de cada
dispositivo: el ESSID (ubicación en la red), MAC Address (dispositivo físico)
y el nombre del cliente. Esto se logra a través de los métodos GetESSID,
GetMACadd y Get_Client. Se ejecuta en la totalidad de los SU de la red
72
-
Get_Users: esta consulta se realiza a través de un script en el HPOVWLL
(p04.sh) que realiza una sesión Telnet sobre el router y ejecuta el comando sh
user. De esta manera se conocen el nombre de usuario de cada uno de los
subscriptores con una sesión abierta en el router. Con el nombre de usuario,
este método ubica el nodo correspondiente en el árbol del form1 y cambia el
icono al estado “conectado”.
-
CrrntAss: esta consulta se realiza sobre los AU y toma instantáneamente la
tabla de MAC Address asociados a esta unidad. Con esta MAC se ubica el
nodo correspondiente y se cambia el icono al estado “asociado”.
Predeterminadamente se cambian en un principio todos los íconos al estado
“no asociado”, de tal manera que al conocer cuáles dispositivos están
asociados queden como “no asociados” aquellos que no aparezcan en las
tablas MAC del AU.
-
Ping: toma como entrada la dirección IP del dispositivo. Inicia el formulario
de ping, de manera de graficar los tiempos de respuesta del dispositivo sobre
el que se ejecutó el comando.
-
InitTelnetSession: toma como entrada la dirección IP del dispositivo. Inicia el
formulario Telnet, de manera de establecer una interfaz gráfica para un
terminal Telnet al dispositivo.
-
Reset_Unit: establece la variable SNMP de reiniciado del dispositivo a
verdadero.
-
Consulta: toma las variables Uptime, Associated SU, Hopping Shift, Software
Versión y VLAN ID.
73
-
GetPHStats: toma la tabla de estadísticas por frecuencia que funciona como
una variable SNMP.
-
getperSUStats: toma la tabla de supervisión de cada SU asociado al AU
consultado, que funciona como una variable SNMP.
-
GetTrffcStats: toma las variables de errores wireless y de tráfico ethernet del
dispositivo.
-
GetIPLocalPool: toma las estadísticas de las direcciones IP asignadas y
asignables de cada router a través de un script en el servidor HPOVWLL
(p02.sh) que ejecuta el comando sh ip local pool.
-
GetIPParams: ejecuta un script en el servidor HPOVWLL (p05.sh) que lleva
a cabo los comando sh user, sh vpdn y sh ip vrf de manera de relacionar sus
respuestas y mostrarlas en una tabla (ver Form1)
Para la mayoría de las consultas realizadas por esta clase, es necesario proveer un
temporizador cuya instancia se encuentre contenida en el formulario desde donde se llama al
comando, de manera de generar el tiempo de espera por respuesta o delay.
El evento TVRefresh sirve como bandera para la actualización del árbol de la red una
vez que se realiza un cambio en la base de datos.
El caso del evento Desbloqueo es similar al de TVRefresh ya que sirve como bandera
para la habilitación o bloqueo de opciones debido a que el sistema se encuentre o no
realizando una operación en el momento. Esto se hace para evitar colisión de operaciones en la
sesión Telnet.
74
6.3.3. Formulario de Inicialización (mForm1)
Formulario MDI en donde se define el menú de opciones generales del programa. En
este formulario se encuentra, entre otras cosas, el Temporizador de Actualización y el control
de las bases de datos ADO.
-
Temporizador de Actualización: se encarga de revisar la existencia de un
archivo (act3838.txt) que permite, al ser eliminado, que se inicie el método
Timer_Timer que muestra un mensaje que cierra el programa permitiendo la
actualización de la aplicación. El período de éste temporizador está
preestablecido a 5 seg.
-
Control de base de datos ADO: le indica al programa que debe cargar el
control para bases de datos ADO msado.ocx.
-
Barra de Herramientas: toma las opciones generales del programa (véase
Menú General) y, dependiendo del caso, las opciones de ejecución de
operaciones sobre el dispositivo seleccionado
-
Menú General: está compuesto por las distintas opciones, pantallas y
comandos ejecutables en las distintas instancias del programa. Su estructura
se ilustra en la siguiente figura (figura 6.7)
75
Archivo
Iniciar Sesión
Cerrar Sesión
Salir
Edición
Buscar en Árbol
Ver
Mapa de la Red
Actualización de BD
Operaciones Masivas
Opciones
Cuenta CS
Importar BD
Ayuda
Acerca de CSiP
Manual de Usuario
Figura 6.7 – Estructura del Menú General
-
Listas de imágenes: Contiene los distintos íconos usados en la barra de
Herramientas, íconos de formularios e íconos de logotipos
6.3.4. Mapa de la Red (Form1)
Básicamente es el formulario principal del programa. Está compuesto principalmente
por un control Treeview donde se muestra el mapa de la red WLL y un control TabStrip [5]
donde se encuentran las distintas opciones y funciones que ofrece la aplicación. Para mostrar
la selección del TabStrip se utilizaron controles PictureBox cuyo índice coincide con el índice
de la pestaña del TabStrip menos uno. De esta manera cuando se pasa de una pestaña a otra en
realidad se está pasando de un PictureBox a otro. Para ello se aprovecha el método
76
TabStrip_Click. Cada uno de estos PictureBox contiene a su vez distintos controles que hacen
posible la interacción sistema-usuario, estos controles se describirán a continuación:
-
Pestaña Detalles: Consta de varios controles Label o Etiquetas donde se
muestra mediante el método dbVisor inherente al formulario, la información
del dispositivo almacenada en la base de datos. Además es posible realizar
consultas de distintas variables con el método Consulta de la clase DispIP.
-
Pestaña Supervisión: Este PictureBox contiene un control ListView [5] y
varios Label donde se muestran los resultados del método getperSUstats.
-
Pestaña Estadísticas de Tráfico: Muestra, a través de dos controles MSChart
y varios Label los resultados del método GetTrffcStats.
-
Pestaña Parámetros IP: Muestra los resultados del método GetIPParams
mediante dos Listview.
-
Pestaña Estadística por Frecuencia: Muestra los resultados del método
GetPHStats mediante un control Listview.
-
Pestaña Netflow: Muestra los resultados del comando sh ip cache flor
(p08.sh) mediante un control Datagrid. Además permite graficar los
resultados mediante el Formulario Gráfica Netflow y filtrar por las distintas
variables de la tabla.
-
Pestaña Sesión: Muestra la sesión Telnet del Form1. Esta pestaña sólo será
visible por el administrador de la aplicación.
Cada una de estas pestañas contiene un control ProgressBar que muestra el progreso de
la operación. Así mismo tiene un control CommandButton que determina el momento en el
que se da inicio a la operación.
77
El llenado del árbol de la red se hace a través del método TreeFill que completa el árbol
de la raíz a las hojas (SU y/o MDU). Los casos especiales (Extenders y sus SU, y Best AU) son
dejados de último en el procedimiento de llenado de manera de evitar errores y tener un
algoritmo sencillo.
6.3.5. Actualización de BD (Form2)
Este formulario constituye la única forma de modificar la base de datos dentro del
programa. En él se encuentra una ventana al terminal Telnet, un visor de base de datos
exactamente igual al del Form1 y un árbol de red, que en este caso no funciona como visor de
estado de los dispositivos.
Seleccionando los distintos dispositivos se tendrán opciones desplegadas en el
submenú que permitirán la inserción, modificación y eliminación de los dispositivos.
Para agregar dispositivos se pueden usar los métodos automáticos de descubrimiento
de dispositivos, o agregar manualmente mediante el Formulario de Agregado de Nodos. Sin
embargo para agregar manualmente es necesario que el dispositivo pueda ser consultado.
En el submenú se tienen las opciones correspondientes a los métodos DepuraBD,
SU_Disc, Descubrir_SU, Locate_MDU y GetESSID de la clase CDispIP. Además se
encuentran vínculos al Formulario de Inserción de Nodos, Formulario de Modificación de
Nodos y al método Del_Node que es el encargado de eliminar los nodos del árbol y de la base
de datos.
6.3.6. Operaciones Masivas (Form8)
Permite hacer configuraciones a varios dispositivos a la vez. Estas configuraciones se
hacen a través de los comandos snmpget y snmpset desde el servidor.
78
Se tienen además diversos controles de texto que constituyen la entrada de las variables
necesarias para la ejecución de los comandos. Es posible guardar el contenido de estos cuadros
de texto de manera de utilizar posteriormente la misma operación con los mismos o con
distintos dispositivos. Es por ello que se tiene un control listbox que muestra el contenido del
archivo CMQ.txt en dónde se almacenan las operaciones guardadas.
s
t r ie
Re
rt
Po
Va
lo r
de
lp
ar
ám
e tr
o
El formato en el que se guardan las operaciones es el que se muestra en la figura 6.8.
g
T ip
od
eP
ar á
me
V e tr o
rs i
on
T
T ip
im
e
od
ou
ec
t
on
su
lt a
t r in
MI
BS
No
mb
re
de
la
co
ns
u lt
a
Software Version;1.3.6.1.4.1.710.3.3.13.3;1;1;3;4;2;5;1
Figura 6.8 – Estructura de archivo para almacenar operaciones
Además es posible, basándose en scripts preconcebidos, actualizar la versión del
software en los dispositivos BreezeCom.
El árbol mostrado en este formulario contiene checkboxes que permiten elegir los
dispositivos a los que se realizarán las operaciones.
79
6.4. Perfiles de Usuario
La siguiente tabla (Tabla 6.13) se observan los perfiles de usuario (0-5) y las
operaciones que pueden realizar. Se observa que existe un perfil de Supervisor de Soporte (5)
que tiene los mismos privilegios que el operador de Sop. T-Net (2) exceptuando que tiene la
potestad de reiniciar las unidades, sin embargo hasta el momento no se ha puesto en práctica.
Tabla 6.13 – Tabla de Privilegios
80
6.5. Consultas SNMP
En las siguientes tablas se observan las variables de la MIB que fueron utilizadas en la
aplicación.
6.5.1. MIB BreezeCom
La tabla 6.14 muestra las variables propietarias de la MIB de BreezeCom que fueron
utilizadas en las consultas SNMP en los dispositivos AU, GU, SU y MDU. Además se puede
observar a que función o método pertenecen dentro del programa.
Nombre
brzaccResetUnit
brzaccUnitName
brzaccUnitStatus
Identificador de Variable
1.3.5.3.4.1.710.3.3.10.1.0
1.3.5.3.4.1.710.3.3.10.3
1.3.5.3.4.1.710.3.3.13.15
Descripción
Aplicable a todos los
dispositivos
BreezeCom.
Reinicia la unidad y
aplica los cambios
realizados
Aplicable a todos los
dispositivos
BreezeCom.
Una
cadena
de
caracteres de hasta 32
caracteres ASCII
Aplicable únicamente
a GU.
Función en la
que se utiliza
Reset_Unit
GetClient
DepuraBD
Get_Users
El estado de la antena
GPS.
brzaccCurrentNumOfAssociations
brzaccSoftwareVersion
brzaccUnitMacAddress
1.3.5.3.4.1.710.3.3.13.16
1.3.5.3.4.1.710.3.3.13.3
1.3.5.3.4.1.710.3.3.13.6
Aplicable sólo a AU.
(Lectura)
El
número
de
unidades
subscriptoras
asociadas en ese
instante con el AU
Aplicable a todos los
dispositivos
BreezeCom.
La versión que se
está ejecutando del
software.
Aplicable a todos los
dispositivos
getperSUstats
Consulta
Consulta
GetMACadd
DepuraBD
81
BreezeCom.
brzaccVlanID
1.3.5.3.4.1.710.3.3.5.3.1
MAC Address de la
unidad.
Aplicable sólo a SU.
Consulta
VLAN ID para el
etiquetado de marcos.
brzaccManagementVID
brzaccVlanIdForwarding
brzaccESSID
brzaccNumberOfHoppingFrequencies
brzaccHopingShift
perHopStatisticsTable
brzaccEthCounters
1.3.5.3.4.1.710.3.3.5.3.5
Aplicable a SU, AU y
GU.
Consulta
1.3.5.3.4.1.710.3.3.5.3.7.2.1.2
VLAN ID para el
etiquetado de marcos
de administración y
de VOZ
Aplicable a SU y AU.
1.3.5.3.4.1.710.3.3.6.1
La lista de VLAN
ID’s en la tabla de
VLAN ID
Aplicable a SU y AU.
1.3.5.3.4.1.710.3.3.6.20
El Extended Service
Set ID (ESSID) usado
para
prevenir
el
crecimiento
de
sistemas colocados.
Aplicable a SU y AU.
1.3.5.3.4.1.710.3.3.6.8
El Número de saltos
de frecuencia usados
en el AU.
Aplicable a SU y AU.
Consulta
1.3.5.3.4.1.710.3.3.8.1
Define el patrón de
saltos de frecuencia
diferente al básico
(Hopping Shift=0)
Aplicable a SU y AU.
GetPHStats
1.3.5.3.4.1.710.3.3.8.2.2
Estadísticas
acumuladas desde el
último reinicio del
promedio de RSSI
por frecuencia para
todos los saltos de
frecuencia
de
la
secuencia
Aplicable a SU y AU.
GetTrffcStats
El número total de
frames enviados y
recibidos
por
el
puerto ethernet de la
unidad
Consulta
DepuraBD
SU_Disc
DescubrirSU
GetESSID
GetPHStats
82
brzaccTotalTxFramesToWireless
brzaccTotalRxFramesFromWireless
brzaccTotalRetransmittedFrames
brzaccTotalTxErrors
1.3.5.3.4.1.710.3.3.8.2.3.1
Aplicable a SU y AU.
1.3.5.3.4.1.710.3.3.8.2.3.2
El total de frames
enviados
vía
inalámbrica
Aplicable a SU y AU.
1.3.5.3.4.1.710.3.3.8.2.3.15
El total de frames
recibidos
vía
inalámbrica
Aplicable a SU y AU.
1.3.5.3.4.1.710.3.3.8.2.3.19
El total de frames
retransmitidos
vía
inalámbrica
Aplicable a SU y AU.
El total de frames no
enviados dado un
error.
Gráfico
Estadísticas de
Tráfico.
Gráfico
Estadísticas de
Tráfico.
Gráfico
Estadísticas de
Tráfico.
Gráfico
Estadísticas de
Tráfico.
Tabla 6.14 – Tabla de consultas SNMP de la MIB de BreezeCom usadas en el programa
6.5.2. MIB2
Al igual que con la MIB de BreezeCom se utilizaron variables inherentes a todos los
dispositivos IP, estas variables pertenecen a la MIB2 (Tabla 6.15).
Nombre
Numero de
Variable
Descripción
Función en
la que se
utiliza
sysUpTime
1.3.5.3.2.1.1.3
El tiempo (en cientos de segundos) Consulta
desde
que
la
porción
de
administración del sistema fue
reiniciada.
sysServices
1.3.5.3.2.1.1.7
Un valor que indica el tipo de DescubrirSU
servicio que presta la entidad SU_Disc
primaria de la unidad
ifPhysAddress
1.3.5.3.2.1.2.2.1.6
La dirección de interfaz del DescubrirSU
protocolo
que
se
encuentra SU_Disc
inmediatamente debajo de la capa GetMACadd
de Red en el snack de protocolos.
Tabla 6.15 – Tabla de consultas SNMP de la MIB2 usadas en el programa
83
6.6.2. Entorno de Trabajo
6.6.2.1. Ventana del Programa.
Al iniciar la aplicación aparece una ventana que constituye el entorno de trabajo y en la
cual se contienen todas las opciones y operaciones posibles. Se pueden identificar una barra de
herramientas y un menú general
6.6.2.2. Barra de Herramientas.
La barra de herramientas se puede observar en la Figura 6.9.
1
3
2
5
4
9
7
6
8
10
Figura 6.9 - Barra de Herramientas
1.- Inicio de sesión.
2.- Cerrar sesión.
3.- Refrescar árbol.
4.- Buscar en árbol.
5.- Configurar cuenta Cisco Secure.
6.- Ping a dispositivo.
7.- Telnet a dispositivo.
8.- Cambiar comentarios de dispositivo.
9.- Generar reporte sobre dispositivo.
10.- Reiniciar la unidad seleccionada.
84
6.6.2.3. Menú General
El menú General tiene la estructura que se muestra en la Figura 6.10.
Archivo
Iniciar Sesión
Cerrar Sesión
Salir
Edición
Buscar en Árbol
Ver
Mapa de la Red
Actualización de BD
Operaciones Masivas
Opciones
Cuenta CS
Importar BD
Ayuda
Acerca de CSiP
Manual de Usuario
Figura 6.10 - Estructura del menú general.
6.6.3. Inicio de Sesión
6.6.3.1. Inicio de sesión del programa.
Al iniciar la sesión del programa aparece una ventana donde se debe introducir
el nombre de usuario y la contraseña asignadas para la aplicación. Este nombre de
usuario y contraseña son establecidos por el administrador del sistema.
Todas las operaciones realizadas bajo la sesión del usuario son registradas bajo
el nombre de usuario suministrado al programa. En la figura 6.11 puede observarse la
ventana de inicio de sesión del programa.
85
Figura 6.11 - Inicio de sesión del programa.
6.6.3.2. Inicio de Sesión HPOVWLL
Luego de registrarse en el sistema es necesario que se le suministre al programa el
nombre de usuario y contraseña para inicio de sesión en el servidor UNIX HPOVWLL (figura
6.12).
Esto quiere decir que las operaciones que se realicen en la red serán registradas por el
servidor con el nombre de usuario que se suministre.
Figura 6.12 - Inicio de sesión HPOVWLL
86
6.6.4. Módulo Mapa de Red
La interfaz gráfica del módulo de mapa de red puede observarse a continuación en la
Figura 6.13.
Figura 6.13 - Módulo Mapa de Red
6.6.4.1. Árbol de la Red
El árbol de la red constituye la estructura organizativa a través de la cual se muestra la
totalidad de la red. En el caso de la red WLL esta estructura esta previamente dividida en
regiones, que a su vez contienen las celdas.
87
La estructura de árbol permite tener una visión general de la red y muestra el estado de
algunos dispositivos de la red según sean consultados. Los iconos de los nodos corresponden
al tipo de dispositivo que representan, así mismo se denota con cambios de color los estados
de los dispositivos. En la Figura 6.14 se puede observar una leyenda de estos íconos.
Figura 6.14 - Leyenda de iconos del árbol
Para poder observar el estado de los SU es necesario hacer dos consultas: la primera se
conoce haciendo doble-click sobre el sector o AU que corresponda de manera de conocer los
dispositivos asociados y los no asociados; la segunda corresponde a un doble-click pero esta
vez sobre la celda o router para saber cuales usuarios están conectados.
En el caso de la tarjeta GPS, una vez consultada la celda, esta puede adoptar tres
estados:
•
Activa y sincronizada (Verde)
•
Activa (Amarillo)
•
Inactiva (Rojo)
En algunos casos se colocará un asterisco (*) a un lado de un dispositivo que se
encuentre asociado a un sector que no corresponde al sector donde estaba registrado. De esta
manera son fácilmente localizables incongruencias entre la red y la base de datos.
En el caso de un MDU el usuario, que entre los múltiples usuarios, esté conectado,
aparecerá a un lado del icono del switch correspondiente.
88
6.6.4.2. Submenú de mapa de red.
Este submenú contiene las distintas operaciones que se pueden realizar sobre los
distintos dispositivos. Estas opciones cambian dependiendo del dispositivo seleccionado y se
muestran a continuación:
- Ping:
Abre la ventana de ping graficando los tiempos de respuesta del dispositivo
seleccionado. Además muestra estadísticas de estos tiempos como el tiempo mínimo (Min),
tiempo máximo (Max), tiempo promedio (Avg.) y el porcentaje de paquetes perdidos (%PP)
como se muestra en la Figura 6.15.
Figura 6.15 - Ventana Ping
Además es posible copiar al portapapeles la gráfica de ping haciendo click en el menú
de ventana sobre la opción Copiar.
- Telnet:
Abre la ventana de terminal Telnet (figura 6.16), en esta ventana se tiene una sesión
abierta sobre el dispositivo seleccionado. En el caso de los AU y los SU esta sesión es iniciada
automáticamente utilizando el Community String almacenado para dicho dispositivo. Para los
89
routers es necesario configurar la Cuenta Cisco Secure para un ingreso automático, de lo
contrario la sesión deberá iniciarse manualmente.
Figura 6.16 - Ventana Telnet
La sesión Telnet permite guardar un archivo log o historial de las operaciones
realizadas con dicha ventana.
- Cambiar Comentarios:
Los comentarios de los dispositivos se pueden ver en la pestaña Detalles en el módulo
Mapa de red. Estos comentarios sirven como nota informativa acerca de algún problema en el
dispositivo. La opción en el submenú permite cambiar el contenido de esta nota.
Una vez agregado algún texto al comentario, automáticamente se cambia el
encabezado de éste a la última fecha de actualización de la nota.
Cuando un dispositivo contiene alguna nota esta aparecerá intermitentemente cuando
otro usuario seleccione el dispositivo correspondiente.
La nota puede tener un máximo de 90 caracteres. En la Figura 6.17 se puede observar
la ventana de actualización de comentarios.
90
Figura 6.17 - Ventana Agregar/Cambiar Comentarios.
- Ver Estadísticas de Tráfico:
Abre la ventana de estadísticas de tráfico graficando los frames por segundo de
transmisión, recepción, retransmisión y de error, vistos desde el dispositivo seleccionado.
Esta ventana permite observar de manera instantánea el comportamiento de un
dispositivo BreezeCom (AU ó SU). Es por ello que no es posible aplicar este tipo de consultas
a routers u otros dispositivos de la red (figura 6.18).
Figura 6.18 - Ventana Estadísticas de Tráfico.
91
Además es posible copiar al portapapeles la gráfica haciendo click en el menú de
ventana sobre la opción Copiar.
- Generar Reportes:
A través de esta función se puede obtener un informe detallado y exportable de algún
nodo de la red. Existen dos tipos de reporte que se describirán a continuación.
- Inventario desde Nodo Actual:
Genera un informe de todos los dispositivos hijos del nodo seleccionado. En este
informe se crea un inventario general indicando el número de SU, AU, MDU, etc. que se
encuentren registrados como hijos del dispositivo seleccionado. Además se compone un
reporte detallado de cuáles son estos nodos.
- Estado Actual de los Dispositivos:
Genera un informe que indica el estado de todos los dispositivos hijos del nodo
seleccionado. En este informe se crea un inventario general indicando el número de SU que se
encuentran conectados, asociados, no asociados y sin consultar. Además se compone un
reporte detallado de cuáles son estos nodos. Es importante haber consultado la mayor cantidad
de dispositivos posibles para que el informe sea lo más detallado que se pueda.
- Buscar en Actualización de BD:
Abre la ventana de búsqueda de dispositivos, que permite ubicar en el árbol de la red
algún dispositivo por su nombre de usuario, MAC Address, Dirección IP o nombre de cliente.
Una vez ubicado es seleccionado en el árbol (figura 6.19).
92
Figura 6.19 - Ventana Buscar Nodo
- Reset Unit
Esta opción permite reiniciar remotamente el dispositivo. Es aplicable únicamente a los
dispositivos BreezeCom (AU, SU y GU).
6.6.4.3. Selector de Pestañas
Contiene diversas herramientas para el monitoreo de la red. A través de estas
herramientas es posible la interacción con la red. El contenido de cada pestaña se explica a
continuación:
- Detalles:
En esta pestaña se tiene una visión general del dispositivo. Allí se encuentra toda la
información almacenada, en base de datos, del dispositivo seleccionado en el árbol. Además es
posible consultar en línea variables importantes del mismo.
Estas variables varían dependiendo del tipo de dispositivo de red seleccionado. Para los
routers es posible observar las estadísticas del pool de direcciones IP asignables a los usuarios,
y en el caso de los dispositivos BreezeCom, dependiendo sean AU o SU, se puede ver el
Hopping Shift, Software Version, VLAN ID y el Uptime. Para realizar esta consulta sobre un
93
dispositivo éste se debe seleccionar y se debe pulsar sobre el botón “Actualizar”.Una vista de
la ventana detalles puede observarse en la Figura 6.20.
Figura 6.20 - Pestaña Detalles.
- Supervisión:
Esta pestaña funciona únicamente para Sectores (AU). Permite observar las estadísticas
de tráfico de cada SU que se encuentre asociado a dicho sector (Figura 6.21). Es importante
señalar que los SU listados en esta tabla pueden no estar registrados en la base de datos de la
aplicación.
94
Estas estadísticas corresponden a contadores propios de cada dispositivo y se refieren a
la cuenta acumulada desde la última vez que se llevaron a cero. Por ello resulta conveniente
llevar a cero los contadores antes de iniciar una medición, ya que esto resulta en una medición
del momento más precisa.
Además se muestran las estadísticas generales de marcos transmitidos (Tx Frames) y
retransmitidos (RTx Frames).
Figura 6.21 - Pestaña Supervisión.
95
- Estadísticas de Tráfico:
Contiene consultas para recibir la información del tráfico ethernet de los dispositivos
BreezeCom así como las estadísticas de frames erróneos de transmisión al medio inalámbrico.
Además grafica estos datos (Figura 6.22).
Las graficas se pueden copiar al portapapeles haciendo click con el botón derecho del
ratón sobre cada una de ellas.
Figura 6.22 - Pestaña Estadísticas de Tráfico.
Los errores de transmisión se refieren a los frames que al transmitirlos que fueron
abortados, que no se recibió acuse de recibo, retrasados por distintas razones, etc. Los rubros
que aparecen en esta tabla se refieren a las razones por la que el frame pudo ser erróneo, estas
son:
•
H/W : Error por causa de hardware en el modem del dispositivo.
•
ABR: La transmisión fue abortada por errores internos del dispositivo.
96
•
CSL: Error por Carrier Sense Level. Si el nivel de potencia de señal del dispositivo
receptor es menor al de la sensibilidad del equipo, el sistema cancela al transmisión
del frame.
•
ACKTOUT (Acknowledge Timeout): no fue acusado el recibo del frame enviado
dentro de un tiempo preestablecido.
•
FAIL: Timeout interno del modem.
•
RTS : fue enviado el RTS pero no se recibe el CTS (Colisión RTS).
•
ACKCRC: Hubo un error de CRC en el acuse de recibo.
•
EOD (End of Dwell): No hubo tiempo suficiente de transmitir el marco.
- Parámetros IP:
Contiene las tablas de los usuarios conectados al router consultado. Así mismo muestra
la cantidad de usuarios por plan (figura 6.23). Puede que algunos de estos usuarios no se
encuentren registrados en la base de datos, ya que esta tabla responde a consultas directas
sobre el router.
Figura 6.23 - Pestaña Parámetros IP
97
- Estadísticas por Frecuencia:
Desde aquí se puede extraer información y estadísticas de tráfico por cada una de las
bandas de frecuencia a las que trabajan los dispositivos BreezeCom. Estos datos pueden ser
graficados, seleccionando los datos que se deseen (Figura 6.24).
Figura 6.24 - Estadísticas por Frecuencia
- NetFlow:
En esta pestaña se pueden consultar las tablas de flujo de datos de los routers Cisco
que tengan habilitada la consulta (Figura 6.25). Es posible graficar los datos seleccionando los
que interesan graficar.
98
Figura 6.25 - Pestaña NetFlow
Un ejemplo de una gráfica de flujo de datos se puede observar en la Figura 6.26. En
este caso se graficaron el número de paquetes por cada protocolo (TCP/UDP) para el usuario
bufmjs.
Figura 6.26 - Gráfico NetFlow
99
Es posible cambiar el tipo de gráfico a torta, líneas, etc. Además puede copiarse en el
portapapeles desde el menú de ventana.
- Sesión:
Esta pestaña muestra la sesión Telnet en donde se llevan a cabo las operaciones
realizadas por la aplicación.
6.6.5. Módulo Actualización de BD
En este módulo se puede modificar la base de datos del programa. Pueden agregarse,
editar y eliminar nodos (figura 6.27).
Figura 6.27 - Módulo Actualización de BD
100
Contiene un visor de base de datos que muestra información del dispositivo
seleccionado. Además se puede observar la totalidad de la sesión Telnet mediante un terminal
que muestra todas las operaciones y con el que se puede interactuar con el servidor.
El árbol de la red tiene la misma estructura que en el módulo de mapa de red, sin
embargo no cuenta con los indicadores de estado ya que en este módulo no es necesario hacer
este tipo de consultas.
En esta pantalla se encuentran dos cuadros de texto (Posibles Community Strings)
donde se deben especificar las contraseñas con las que se ejecutarán las operaciones de los
dispositivos desconocidos.
En el cuadro SU’s Encontrados se listarán los dispositivos que hayan sido añadidos por
los procedimientos automáticos de la aplicación (Descubrir SU) en la sesión actual.
6.6.5.1. Submenú
El submenú del módulo de Actualización de BD se desplegará, al igual que en el caso
del módulo anterior, al hacer click con el botón derecho del ratón sobre algún nodo.
- Ping:
(Véase 6.6.4.2)
- Insertar Nodo:
Aparece la ventana de Insertar Nodo que se observa en la Figura 6.28.
En esta ventana deben establecerse todos los valores de las variables requeridas
para añadir un nodo. El tipo de nodo a insertar dependerá directamente del
nodo padre, es por ello que al seleccionar una celda por ejemplo, sólo
podremos añadir posibles nodos hijos (SU con configuración BestAU, AU,
GPS).
101
Debe tenerse en cuenta que algunos rubros del formulario deben ser
obtenidos directamente del dispositivo haciendo click a los botones de consulta.
Si el dispositivo no responde este no podrá ser agregado.
Figura 6.28 - Ventana Insertar Nodo.
- Editar Nodo:
Aparece la ventana de Editar Nodo que se observa en la Figura 6.29. En
esta ventana deben establecerse todos los valores de las variables requeridas
para modificar un nodo. En un primer momento aparecerán los datos
almacenados y, luego de ser modificados, se debe hacer clic sobre el botón
“Aceptar”.
Figura 6.29 - Editar Nodo
102
- Eliminar Nodo:
Elimina el dispositivo seleccionado de la base de datos. Es equivalente a
pulsar el botón “Supr” o “Del”.
- Descubrir SU:
Consulta inherente a routers. Hace un barrido sobre los dispositivos que
se encuentren en la tabla ARP del router seleccionado. Los dispositivos que
contesten a las consultas SNMP preestablecidas son añadidos a la base de datos
y paralelamente son agregados a la lista de dispositivos descubiertos en la
sesión (SU’s Descubiertos).
- Get ESSID:
Obtiene el ESSID del dispositivo seleccionado. Si es ejecutado desde un
sector o una celda, obtendrá el ESSID de cada uno de los SU contenidos en ella.
- Ubicar MDU’s:
Relaciona los MDU que no han sido ubicados con un SU. Se basa en
sesiones Telnet sobre los distintos sectores de la celda seleccionada, de manera
que, por medio de la tabla de MAC Address, se pueda establecer la dirección IP
del SU para cada switch que no ha sido ubicado.
- Depurar BD:
Consulta todos y cada uno de los dispositivos hijos del nodo
seleccionado de manera de eliminar incongruencias en la base de datos. Por
ejemplo, ubica en el sector real un dispositivo que haya sido movido de sector.
103
6.6.6. Módulo Operaciones Masivas
El módulo de Operaciones Masivas (MOM) es una herramienta sencilla para la
configuración y consulta sobre varios dispositivos de la red. Pueden configurarse cualquier
variable SNMP propietaria del sistema. Además es posible, con el uso de scripts
preestablecidos en el servidor, realizar actualizaciones del software de los dispositivos
BreezeCom. En la figura 6.30 se observa el MOM.
Figura 6.30 – Módulo de Operaciones Masivas
En primer lugar, si se desea hacer una nueva operación, se debe hacer doble-click
sobre <Nueva Operación> en la lista de operaciones guardada (De igual manera si se quiere
utilizar alguna operación guardada basta con hacer double-click sobre la misma). Luego deben
seleccionarse los dispositivos sobre los que se quiere realizar la operación en el árbol de
selección.
104
Se debe especificar la variable en el caso de que la operación no sea de Actualización
de Firmware. Luego de establecer todas las variables y parámetros de la operación se debe
hacer click en el menú sobre “Ejecutar”. En el terminal Telnet se observará todo el progreso de
la operación masiva.
Por último se debe destacar que la operación puede ser cancelada o detenida en
cualquier momento a conveniencia del usuario. Así mismo, la nueva operación puede ser
almacenada en la lista por medio del botón “Guardar”
105
CAPÍTULO 7
DISCUSIÓN Y RESULTADOS
Antes del desarrollo del desarrollo del sistema se tenía en el CCR una gran carga de
trabajo debido a la gran cantidad de quejas que eran escaladas a este ente a causa de problemas
de la red WLL. Anteriormente, según el estudio realizado, se recibían un promedio de 110
llamadas semanales al CCR por problemas de la red WLL.
En este estudio se analizaron las causas de estas llamadas así como los respectivos
diagnósticos y soluciones aplicadas a cada una de ellas.
En la figura 7.1 se pueden observar las causas de estas llamadas tomadas del primer
registro de llamadas (registro 1).
Fallas Reportadas
160
156
141
140
N° de Llamadas
120
100
80
60
40
22
9
20
7
3
0
No Conecta
Lentitud
No Navega
Supervisión
Consulta
3%
7%
Señal Intermitente
2%
1%
45%
42%
Figura 7.1 – Fallas reportadas registro 1
Estos registros corresponden a un total de 338 llamadas tomadas los días hábiles
comprendidos entre el 3/8/04 y el 23/08/04. Nótese que un 45% de las llamadas, que
constituyen el mayor porcentaje, pertenecían al rubro de clientes que se quejaban de que no
106
podían conectarse a la red. Se tenía además un no menospreciable porcentaje de 42% de
usuarios que se quejaban por lentitud de la red.
Es importante resaltar que aunque los problemas de la red son diversos, existía una
muy pequeña gama de fallas reportadas que fueron definidas y tipificadas en el desarrollo del
proyecto.
Las soluciones encontradas para estas llamadas se pueden observar en la figura 7.2.
Diagnóstico y Soluciones
160
141
140
N° de Llamadas
120
100
70
80
60
60
40
21
20
23
15
4
3
1
1%
7%
0
RU
PE
RB
No se Aplicó Información Falla Celda
Correctivo
Alto Tráfico
RTX
RC
4%
1%
42%
21%
6%
18%
Figura 7.2 – Diagnósticos y soluciones registro 1
Fue entonces que se descubrió que la mayoría de los problemas correspondían a cierta
sobrecarga de flujo que existía en la red, ya que en mayor medida la solución consistía en el
reinicio de las unidades (RU). Los problemas que se consideraban “físicos” como cambios de
equipos, problemas de interfaz aérea, entre otros eran escalados al departamento de Planta
Externa (PE) y al departamento de Radio Base (RB). Sin embargo estos problemas “físicos”
no poseen ninguna correlación numérica con llamadas en otros días comunes en el CCR,
debido a que en un determinado instante se pueden dar más llamadas a causa de estos
problemas que en otro momento debido a que existieron mayores fallas en las celdas. Nótese
107
que en tan solo un 1% de las llamadas se diagnosticaba que el problema era responsabilidad
del cliente (RC).
De esta manera, el análisis de estos datos arrojó una clasificación de las llamadas en
llamadas evitables totales y llamadas no evitables totales. Sin embargo, considerando que el
único departamento que reinicia unidades es el CCR, el Reinicio de Unidades (RU) formaba
parte de las llamadas no evitables, siendo éste el grueso de las llamadas registradas. De ahí que
se tenga que tomar la decisión, en pro de una mayor disminución de llamadas, de que se diera
un reinicio de unidades condicional a otros agentes de la solución de fallas de WLL.
Es por ello que para el presente estudio se dividieron las llamadas no evitables totales,
en llamadas no evitables y llamadas RU, estas últimas pudiendo formar parte de las evitables
totales en un futuro, dependiendo de las decisiones que se tomaran. En la figura 7.3 se observa
entonces la clasificación de las 338 llamadas registradas.
100%
24
90%
% de LLamadas
80%
141
70%
60%
50%
40%
30%
173
20%
10%
0%
No Evitable
Reset Unit
Evitable
Figura 7.3 – Clasificación de llamadas del registro 1
108
Así se tenía un 51,18% de llamadas evitables, que serían erradicadas con el uso de la
aplicación; un 41,72% de llamadas donde se aplica (RU) que serían eventualmente evitables y
un poco más de 17% que no podrían ser evitables.
Luego del desarrollo de la aplicación, basado precisamente en las herramientas
específicas para los problemas ya descritos, se logró de manera directa una reducción del
51,.47% a tan sólo dos semanas de la implementación de la aplicación. Esto se observó en un
registro posterior donde se obtuvieron, durante el mismo período de tiempo que el primer
registro, un total de 174 llamadas (a diferencia de las 338 del registro anterior). Actualmente y
al igual que durante las semanas en que se realizó el registro, el reinicio de unidades todavía se
encuentra a cargo del CCR, es por ello que no pudo eliminarse el 41,72% de llamadas
restantes que se pensó se podían eliminar delegando el RU a otros departamentos.
En la figura 7.4 se observa la comparación de la cantidad de llamadas recibidas antes
del uso de la aplicación y después.
Cantidad de Llamadas
Cantidad de Llamadas
350
300
250
200
338
150
174
100
50
0
Antes de CSiP
Después de CSiP
Figura 7.4 – Comparación cantidad de llamadas
109
De esta manera se observa la disminución del 51,47% en la cantidad de llamadas
recibidas por el CCR debidas a problemas en la red WLL durante 15 días hábiles. En la
siguiente gráfica (Figura 7.5) se observa la comparación entre las distintas clasificaciones de
las llamadas antes y después del uso del programa.
Se observa la clara disminución, que era esperada, en el rubro de llamadas evitables.
Además se puede observar una notable disminución en la cantidad de reinicio de unidades, lo
que puede indicar que antes pudiesen haber habido cierta cantidad de llamadas en las que se
daba un falso diagnóstico o un diagnóstico errado.
Antes de CSIP
Gráfica Com parativa
Después
180
173
160
141
- 29 %
Cantidad de Llamadas
140
120
100
100
- 68 %
80
55
60
40
24
19
20
0
Evitable
Reset Unit
No Evitable
Evitabilidad
Figura 7.5 – Comparación por clasificación llamadas
Esta reducción de llamadas se debe, según el registro, a las llamadas donde el usuario
se queja de que no puede conectarse. Es importante resaltar que estas llamadas eran, en su
mayoría, reportadas a los departamentos técnicos para el reemplazo de las unidades del
subscriptor (SU). Se nota entonces que esas llamadas eran hechas directamente desde el centro
de atención al cliente a los distintos departamentos técnicos.
110
La figura 7.6 muestra el ligero aumento en algunos tópicos, como en el de consulta.
Estas llamadas se refieren a consultas técnicas de los operadores de atención al cliente a los
especialistas de red del CCR. Se puede pensar que estas llamadas son producto a la poca
experiencia que han tenido con la aplicación los operadores de soporte.
FallaReportada
Antes deCSiP
Después deCSiP
156
160
141
140
120
99
- 29 %
100
80
60
40
30
- 80 %
27
22
16
20
9
- 27 %
0
No Conect a
Lent itud
No Navega
Supervisión
+ 74 %
7
1
- 88 %
Consult a
3
0
Señal Int ermit ente
Figura 7.6 – Comparación de fallas reportadas
En el siguiente gráfico (Figura 7.7) se observa claramente todo lo anteriormente
expuesto, ya que se nota la disminución total de las llamadas escaladas a Planta Externa.
Diagnósticos y Soluciones
Antes de CSiP
Después de CSiP
160
140
141
Nº de Llamadas
120
- 29 %
100
100
80
74
60
60
40
21
20
RU
PE
49
- 23 %
16
23
- 82 %
15
4
0
0
- 33 %
- 100 %
RB
- 100 %
0
No se Aplicó Información Alto Tráfico
Correctivo
1
RTX
0
0
3
Clear Arp
Figura 7.7 – Comparación de diagnóstico y soluciones
3
RC
1
111
La columna “Clear Arp” se debe a un problema poco frecuente que no ha sido
identificado en la red y que surgió durante el desarrollo del proyecto, donde al parecer se
inhibe el equipo del sector y se deben limpiar las tablas Arp de los routers. Esta falla no
permite que los dispositivos sean supervisados. Además desencadena alarmas en el sistema de
gestión de la red haciendo imposible un buen monitoreo de ésta. Actualmente se está
estudiando el caso y analizando las posibles soluciones, sin embargo a efectos de la aplicación
basta con limpiar las tablas ARP de los routers que es una operación muy sencilla.
Los resultados obtenidos son entonces satisfactorios ya que cumplen los objetivos, sin
embargo debe acotarse que todavía no se alcanzó la disminución total de las llamadas
evitables. En la Figura 7.8 puede observarse los valores de llamadas anteriores al programa,
los posteriores, los esperados y los que pudiesen tenerse si se delega el reinicio de unidades a
otros departamentos.
No Evitable
Resultados
Reset Unit
Evitable
350
No Evitable 24
300
250
Reset Unit
141
200
No Evitable 19
150
100
Evitable
173
Reset Unit
100
Evitable
55
50
No Evitable 19
Reset Unit
100
No Evitable 19
0
Antes CSIp
Despues CSIp
Esperado
Delegando RU
Figura 7.8 – Análisis de cantidad de llamadas: antes (registro 1), después (registro 2),
esperadas y esperadas delegando RU
112
En las siguientes figuras se observan los datos obtenidos del archivo Log o bitácora del
programa. Con ellas se percibe que el uso del programa no es únicamente para el reinicio de
unidades. En la figura 7.9 se observa la cantidad de operaciones realizadas por cada usuario de
la aplicación en el término de una semana.
Operaciones por Usuario
3000
Cantidad de Operaciones
2500
2000
1500
2686
1000
1143
500
54
0
CCR
Sop T-Net
D. Tirado
82
M. Ferrer
13
P. Externa
Figura 7.9 – Cantidad de operaciones por usuario
Es posible saber, mediante la bitácora, qué funciones se ejecutaron por los distintos
departamentos. En la figura 7.10 puede observarse que el reinicio de unidades no ocupa sino
sólo el 4% del total de los comandos ejecutados, lo que muestra la capacidad de supervisión
que posee el programa, ya que los operadores están conociendo, mediante las demás
funciones, el estado de la red sin incidir directamente sobre la misma.
113
Operaciones en Detalle
0%
1%
0%
0%
2%
1%
3%
4%
21%
4%
9%
18%
11%
12%
Ver Asociaciones
Supervisión (Site Survey)
Estadísticas de Tráfico
Ver Usuarios Conectados
Ping
Telnet
RESET UNIT
Errores Wireless & Tráfico Ethernet
Parámetros IP
Ver IP Local Pool
Consulta
Estadísticas por Frecuencia
Cambiar Comentarios
Reporte
Descubrir SU
14%
Figura 7.10 – Operaciones vs. RU
Por último la gráfica de la figura 7.11 muestra la cantidad de comando utilizados por
cada día de la semana.
Histograma de uso de CSiP (8/11/04 - 14/11/04)
40
35
Cantidad de Operaciones
30
25
20
15
10
5
0
Lunes
Martes
Miércoles
Jueves
Viernes
Sábado
Figura 7.11 – Histograma diario de uso de CSiP
Domingo
114
CAPÍTULO 8
CONCLUSIÓN Y RECOMENDACIONES
En resumen se diseñó, desarrolló y se puso en práctica una herramienta gráfica para el
monitoreo y administración de la red WLL de Telcel. Esta aplicación logró una reducción del
51,47% de las llamadas que se hacían desde la central de atención al cliente (411) hacia el
CCR por quejas de usuarios por problemas de la red. Así mismo se espera que con algunas
decisiones que se tomen a futuro se pueda reducir, en mayor medida, la carga de trabajo del
CCR en cuanto a la red WLL.
La estructura modular de la aplicación permite que sean añadidas otras redes de
dispositivos IP de Telcel. Es posible insertar dispositivos de las redes CPA, T-Link y
Timetrack. Esta versatilidad proporciona una herramienta que trasciende la solución de fallas
y lograría eventualmente una integración de la administración y gestión de algunas redes de
datos de Telcel.
Sin embargo, debido a las limitaciones de seguridad de la red, es necesario que el
sistema sea atendido por diversos entes. Principalmente el programa basa su funcionamiento
en que la base de datos de los dispositivos se acerque a la realidad de la red. Tomando en
cuenta que estas redes de servicios de datos cambian de tamaño y topología en períodos cortos
de tiempo, es extremadamente importante que los datos sean actualizados con frecuencia.
En un principio estos datos están a cargo de personal de Planta Externa, sin embargo es
necesario crear mecanismos automáticos de actualización de las bases de datos que reúnan
ciertos requisitos del sistema que logren esta actualización sin la intervención de ningún ente.
Como se dijo anteriormente, las llamadas recibidas por el CCR debido a problemas en
la red WLL se redujeron en un 51,47%, sin embargo la adjudicación del reinicio de las
unidades a otros departamentos aligeraría de forma notable la carga de trabajo restante. Para
tal fin se diseñó un perfil de usuario que, de manera restringida, tuviese privilegios de
115
supervisón y que pudiese reiniciar unidades. El perfil de “Supervisor de Soporte T-Net” (5)
permite tales bondades.
Se debe entonces tomar una decisión en cuanto a este respecto para profundizar el
alcance del presente proyecto, ya que, aunque fue implantado el perfil, actualmente no se
encuentra adjudicado a ninguna persona.
Además se logró un mecanismo efectivo para la actualización del programa de manera
directa, ya que éste se ejecuta desde un disco de red, que reduce el tiempo y la complejidad de
reemplazo de la aplicación.
Con la herramienta se consiguió una interacción muy positiva en los distintos
departamentos que componen la red de supervisión de WLL. Y con ello se logró un registro
que no existía hasta el momento de los dispositivos de la red.
Gracias a la herramienta, los usuarios que llaman al centro de atención al cliente 411
por problemas de la red WLL, son atendidos con una mayor rapidez y eficacia.
El futuro de la red WLL es incierto, la inclusión de nuevas redes inalámbricas para
prestar servicios de Internet y de voz sobre IP con nuevas tecnologías ya se avecinan en los
próximos años, si es que hasta el momento no han sido implantadas. Hoy ya se tienen
tecnologías como G-Tran (3G) y la red EDA de Ericsson. Sin embargo el desarrollo de este
proyecto provee una solución temporal a los problemas de supervisión de la red WLL y, por
su flexibilidad, permite la inclusión de nuevas redes IP.
116
CAPÍTULO 9
REFERENCIAS BIBLIOGRÁFICAS
[1]
POSTEL, J. y REYNODS, J.; “Request for Comments 854”, ISI 1983.
[2]
Cisco Systems Inc., “User Guide for Resource Manager Essentials”, Software Release
3.4, 2002.
[3]
SCHWARTZ, Sorin M. “WLL Fundamentals” 2002.
[4]
SCHWARTZ, Sorin M. “Frequency Hopping Spread Spectrum (FHSS) vs. Direct
Sequence Spread Spectrum (DSSS) in the Broadband Wireless Access and WLAN Arenas”
(ver.6 - Feb 10, 2001)
[5]
BALENA, Francesco. “Programming Microsoft Visual Basic 6.0”. Microsoft Press
1999.
[6]
TANENBAUM, A, “Redes de Computadoras”, Prentice Hall Hispanoamericana,
Naucalpan de Juárez, (1997)
[7]
Intranet Corporativa de Telcel.