Alejandro León Rodríguez

Universidad Central “Marta Abreu” de Las Villas
Facultad de Ingeniería Eléctrica

Departamento de Telecomunicaciones y Electrónica
TRABAJO DE DIPLOMA
Software de Gestión para equipamiento CMTS en

redes DOCSIS 3.0
Autor: Alejandro León Rodríguez
Tutor: Ing. Rolando Evelio Pérez Versón
Santa Clara
2012
"Año 54 de la Revolución"
Universidad Central “Marta Abreu” de Las Villas
TRABAJO DE DIPLOMA
Software de Gestión para equipamiento CMTS en

redes DOCSIS 3.0
Autor: Alejandro León Rodríguez
Tutor: Ing. Rolando Evelio Pérez Versón

e-mail: rpverson@uclv.edu.cu
Consultante: MSc. Hiram del Castillo Sabido
Santa Clara
2012
"Año 54 de la Revolución"
Hago constar que el presente trabajo de diploma fue realizado en la Universidad Central
“Marta Abreu” de Las Villas como parte de la culminación de estudios de la especialidad
de Ingeniería en Telecomunicaciones y Electrónica, autorizando a que el mismo sea
utilizado por la Institución, para los fines que estime conveniente, tanto de forma parcial
como total y que además no podrá ser presentado en eventos, ni publicados sin autorización
de la Universidad.
Firma del Autor
Los abajo firmantes certificamos que el presente trabajo ha sido realizado según acuerdo de
la dirección de nuestro centro y el mismo cumple con los requisitos que debe tener un
trabajo de esta envergadura referido a la temática señalada.
Firma del Autor Firma del Jefe de Departamento

donde se defiende el trabajo
Firma del Responsable de

Información Científico-Técnica
i
PENSAMIENTO
Si quieres mi fidelidad, dame algo bueno que defender.
Yo
ii
DEDICATORIA
A mi abuelo que le prometí que estaría aquí conmigo hoy y sé que es así.
A todos los buenos ingenieros que aspiran a hacer grandes cosas y creen en ello.
iii
AGRADECIMIENTOS
Agradecer primeramente a Armando y a Aragón por hacérmelo tan fácil. A mi tutor por
haber creído en mí y por contribuir a no sentirme tan transparente. A la mejor madre del
mundo por simplemente serlo. A mi padre por lograr enseñarme a ver las cosas
verdaderamente importantes.
A mi abuela que su corazón no cabe en su pecho. A Noemí, Eduardo, Claudia, Javier y

Ocilia por estar siempre e incondicionalmente ahí para mí, por ser auténticos padres,
hermanos y abuela. A mi tía por ser tan buen sostén, a todos mis primos y al resto de mi
familia por hacerme saber que siempre puedo contar con ellos.
A esos negros que verdaderamente han sido los hermanos que nunca tuve, que más que mis
amigos son parte de mi, Celso y Galindo. A Manuel y Danny, que me han soportado
siempre, a Erik que me ha ayudado tanto. A todas las psicólogas que me dejaron entrar, tal
vez por error, a sus vidas y nunca más me dejaron salir. A Leonel, Dayana y Mari que
siempre me acogieron, y a todos mis compañeros de la carrera. A Ana, que es sencillamente
especial. A todos mis amigos.
Agradecer también a todos esos grandes profesores a los que en gran medida les debo el
haber llegado a aquí. A mi patria por darme el orgullo de ser cubano. A Moya y al Sovie
por representar la importancia de lo subjetivo. A todas las cosas malas que me han sucedido
por permitir balancear mi vida con las otras tantas cosas buenas, como esta.
iv
TAREA TÉCNICA
1. Estudio de los dispositivos CMTS y su modo de funcionamiento.
2. Elaboración del sistema de gestión.
3. Creación de la interfaz usuario-sistema.
4. Realización de pruebas en el terreno para ver los resultados del diseño y su

posible aplicación práctica.
5. Puesta a punto del Sistema.
6. Evaluación de la efectividad de la propuesta en el entorno de red.
7. Confección del informe final.
Firma del Autor Firma del Tutor

v
RESUMEN
En Cuba, se cuenta con el equipamiento necesario para brindar los servicios DOCSIS, pero
debido al alto costo del hardware, la inversión en software de gestión es prácticamente
inviable. Este estándar permite el tráfico de datos IP de alta velocidad en redes de cable. En
este trabajo se describe la aplicación creada, CMTS-Manager, software de gestión para
Sistemas de Terminación de Módems de Cable (CMTS) que se basa en el modelo de
gestión FCAPS de la ISO. Para su operación se auxilia del Protocolo Simple de Gestión de
Redes (SNMP) y de bases de datos para la recolección, procesamiento y almacenamiento
de estos. El software ha sido implementado en la cabecera de Telecable Internacional de
Cayo Santa María, proveedor del servicio de televisión por cable de las instalaciones
turísticas de la región, donde ha contribuido al mantenimiento de la disponibilidad del
servicio mediante el monitoreo exhaustivo de la operación de la red y el funcionamiento del
CMTS. Una aplicación de gestión y monitoreo permite influir proactivamente en la calidad
de un servicio de telecomunicaciones, mientras las herramientas de desarrollo de software
posibilitan la creación de aplicaciones a la medida y que respondan a intereses concretos,
sorteando las dificultades que el mercado impone.
vi
ÍNDICE
PENSAMIENTO .....................................................................................................................i
DEDICATORIA .................................................................................................................... ii
AGRADECIMIENTOS ........................................................................................................ iii
TAREA TÉCNICA ................................................................................................................iv
RESUMEN ............................................................................................................................. v
INTRODUCCIÓN .................................................................................................................. 1
Organización del informe ................................................................................................... 3
CAPÍTULO 1. ¿DATOS EN REDES DE TELEVISIÓN?................................................ 4
1.1 Arquitecturas de las redes de Televisión por Cable ................................................ 4
1.2 Redes HFC .............................................................................................................. 6
1.3 Transmisión de datos en redes CATV/HFC ........................................................... 7
1.3.1 Especificación DOCSIS .................................................................................... 8
1.3.1.1 Arquitectura ............................................................................................... 9
1.3.1.2 Características y Funcionamiento General .............................................. 10
Downstream: Desde el CMTS hacia los CMs ...................................................... 11
Upstream: Desde los CMs hacia el CMTS ........................................................... 11
Operación básica del protocolo............................................................................. 12
1.3.1.3 DOCSIS 3.0 ............................................................................................. 13
1.3.1.4 I-CMTS y M-CMTS ................................................................................ 14
1.4 Protocolo Simple de Gestión de Redes (SNMP) .................................................. 15
1.4.1 Gestores y Agentes ......................................................................................... 16
1.4.2 Base de Información de Gestión ..................................................................... 17
vii
1.4.2.1 Estructura de la Información de Gestión ................................................. 17

1.4.2.2 Identificadores de objetos ........................................................................ 18
1.4.3 Protocolo de transporte ................................................................................... 19
1.4.4 Mecanismos del protocolo SNMP .................................................................. 19
1.4.4.1 Formato de los mensajes ......................................................................... 20
1.4.4.2 Los bytes reales ....................................................................................... 21
1.4.5 Versiones ........................................................................................................ 23
1.5 Conclusiones del capítulo ..................................................................................... 23
CAPÍTULO 2. LLEGANDO AL OBJETIVO ................................................................. 24
2.1 El CMTS ............................................................................................................... 24
2.1.1 Hardware ......................................................................................................... 25
2.1.2 Software .......................................................................................................... 28
2.2 Gestión .................................................................................................................. 29
2.2.1 Gestión de Redes ............................................................................................ 29
2.2.1.1 Gestión de Fallas ..................................................................................... 29
2.2.1.2 Gestión de Configuración ........................................................................ 29
2.2.1.3 Gestión de Contabilidad .......................................................................... 30
2.2.1.4 Gestión de Rendimiento .......................................................................... 30
2.2.1.5 Gestión de Seguridad ............................................................................... 30
2.2.2 Gestión en Redes DOCSIS ............................................................................. 30
2.2.2.1 Protocolos de gestión ............................................................................... 32
2.2.2.2 Gestión de un CMTS ............................................................................... 32
2.2.2.3 Principales parámetros de gestión en una red DOCSIS .......................... 34
2.2.2.4 Dimensionamiento y Capacidad .............................................................. 35
2.2.2.5 ¿Cómo implementar un software de Gestión para un CMTS DOCSIS? . 36
2.3 ¿Por qué Delphi? ................................................................................................... 36
2.3.1 Delphi de Delfos ............................................................................................. 37
2.3.2 Delphi de Borland ........................................................................................... 37
2.3.2.1 Programación modular ............................................................................ 38
2.3.2.2 Paquetes y Componentes ......................................................................... 38
viii
2.3.3 Borland Delphi 7 ............................................................................................. 39

2.3.3.1 SNMP en Borland Delphi 7 ..................................................................... 39
2.3.3.2 La librería Synapse .................................................................................. 40
2.3.3.3 Bases de datos.......................................................................................... 40
2.4 CMTS-Manager, el producto ................................................................................ 41
2.4.1 Módulos y Áreas de gestión............................................................................ 42
2.4.1.1 Módulo de Gestión de Fallas ................................................................... 42
2.4.1.2 Módulo de Gestión de Configuración ..................................................... 43
2.4.1.3 Módulo de Gestión de Rendimiento ........................................................ 44
2.4.1.4 Módulo de Gestión de Contabilidad ........................................................ 45
2.4.1.5 Módulo de Gestión de Seguridad ............................................................ 46
2.4.1.6 Otros Módulos ......................................................................................... 47
CAPÍTULO 3. GESTIONANDO CON CMTS-Manager................................................ 48
3.1 Casos de uso.......................................................................................................... 48
3.1.1 Caso de uso 1: Estadísticas de alarmas ........................................................... 49
3.1.2 Caso de uso 2: Configuración de canal de Upstream ..................................... 50
3.1.3 Caso de uso 3: Estado de los Modems de Cable............................................. 52
3.1.4 Caso de uso 4: Mediciones espectrales ........................................................... 53
3.1.5 Caso de uso 5: Disminuir el tráfico de control ............................................... 55
3.1.6 Caso de uso 6: Restablecer una alarma ........................................................... 56
3.2 Qué ha permitido CMTS-Manager ....................................................................... 57
CONCLUSIONES Y RECOMENDACIONES ................................................................... 59
Conclusiones ..................................................................................................................... 59
Recomendaciones ............................................................................................................. 59
ABREVIACIONES Y ACRÓNIMOS ................................................................................. 60
REFERENCIAS BIBLIOGRÁFICAS ................................................................................. 67
ANEXOS .............................................................................................................................. 71
1
INTRODUCCIÓN
La necesidad de ver una imagen televisiva clara, sin ruido ni interferencias apreciables, dio
lugar a la creación de la industria de la televisión por cable cuando la forma más común de
transmisión de televisión era mediante la utilización del espectro electromagnético por aire,
que en Estados Unidos y la mayoría de los países, se remonta a la década de 1940.
Prescindir de sus problemas y limitaciones se hacía a veces muy difícil, pues las señales
podían ser severamente debilitadas o bloqueadas por obstáculos naturales o artificiales.
Surge así el concepto de Community Antenna (CA) o antena comunitaria, cuya idea básica
consistía en utilizar un único punto de recepción y una red de conductores para distribuir
las señales, y que se desarrolló paralelamente en varias ciudades pero se acreditó a Ed
Parsons de Astoria, Oregon, Estados Unidos, como el primero en ponerlo en práctica en
1948.(Pici, 2007)
Entregar una señal audiovisual con calidad superior, aún cuando solo se distribuyese un
solo canal televisivo, satisfacía una necesidad del público por la cual estaban dispuestos a
pagar. De ahí en adelante, se establecería lo que se conoce como Sistema de Televisión de
Antena Comunitaria (CATV), que con la diversificación de sus servicios pasaría a llamarse
también Sistema de Televisión por Cable, manteniendo las mismas siglas. La red de cable
se expandió a tal punto que ya en el 2000 alcanzaba el 80% de las familias en Estados
Unidos, aunque un poco menos eran los que estaban suscritos.(Green, 2002)
La industria del cable, como se le conoce, partiendo de las necesidades de los clientes,
muchas veces necesidades impuestas, fue evolucionando hasta llegar a donde está hoy,
impulsada por la constante competencia de otros servicios que también se expandieron
rápidamente como los servicios de línea de suscriptor digital (DSL). Además de la
INTRODUCCIÓN
2
transmisión de las señales de difusión terrestre, la transmisión de programación generada

localmente y de señales satelitales, comienzan a brindarse servicios bidireccionales,
conocidos como two-way services, y televisión digital a partir de finales de la década de los
noventa, convirtiendo el servicio de cable en una opción muy atractiva.(Pici, 2007)
Como resultado de un proceso de unificación de métodos y conceptos se cuenta hoy con

DOCSIS, estándar no comercial que define los requisitos de la interfaz de comunicaciones
y operaciones para el soporte de transmisión de datos sobre sistemas de cable. Muchos
operadores de televisión por cable lo emplean para proporcionar acceso a Internet sobre una
infraestructura HFC (red híbrida de fibra óptica y coaxial) existente. La versión europea de
DOCSIS se denomina EuroDOCSIS y la principal diferencia es que, en Europa, los canales
de cable tienen un ancho de banda de 8 MHz (PAL), mientras que, en Norte América y
Colombia, es de 6 MHz (NTSC).
La última versión de DOCSIS, DOCSIS 3.0, que data del 2006, aparece implementada en
la gran mayoría del equipamiento actual para estos servicios, permitiendo la puesta en
marcha de redes más complejas, tanto en tamaño como en funcionamiento, pudiendo
alcanzar tasas de transmisión de más de 100 Mbps para un solo usuario.
En sus inicios, las redes DOCSIS se gestionaban a nivel de sistema operativo del
equipamiento. Las facilidades que brindan protocolos como SNMP, y su universalización,
permiten crear una interfaz gráfica y amigable a los operadores en redes complejas. La
gestión de Sistemas de Terminación de Cable Módems (CMTS) se realiza actualmente con
softwares propietarios, por un lado los de los fabricantes, y por otro los producidos por
empresas de software, aunque con menos potencial y más escasez se encuentran algunos de
código abierto o libres. Todos ellos emplean, por especificación, el Protocolo Simple de
Gestión de Redes (SNMP), que se ha convertido en el estándar de gestión de facto para la
industria de las interconexiones. SNMP permite a los fabricantes adicionar funciones
propias de gestión de red; y separa la arquitectura de gestión de la arquitectura de hardware
de los dispositivos, universalizando su utilización. (Miller, 2004)
La realidad de hoy muestra un mercado de softwares de gestión para equipamiento

DOCSIS muy reducido, permitiendo altos precios a los pocos que ofrecen el producto. En
Cuba, se cuenta con el equipamiento básico para comenzar a brindar los servicios DOCSIS
INTRODUCCIÓN
3
3.0 en la infraestructura hotelera de algunos lugares, pero debido al alto costo del hardware,
la inversión en software de gestión es prácticamente inviable. La posibilidad de encontrar
una solución económica y medianamente efectiva existe y puede lograrse, lo que ofrece una
gran salida para el modelo empresarial cubano y la economía del país a través de las
universidades. Se puede además, personalizar el producto, o sea, adaptarlo a las principales
necesidades del operador, de manera que, si bien no ofrece en principio una solución
completa, permitirá iniciar el servicio con cierto nivel de fiabilidad y determinado grado de
rapidez de respuesta ante fallos, lo que sin dudas propiciará el desarrollo y fortalecimiento
del interesado como operador de nuevos servicios que aún no se explotan en el país.
¿Cómo implementar un sistema de gestión para un equipo CMTS comercial que pueda ser
utilizado de forma sencilla por el personal calificado y que asegure la mayoría de las
funciones básicas que esta tarea requiere?
La respuesta a esta interrogante constituye el objetivo fundamental del presente trabajo, que
además pretende estudiar el estándar DOCSIS 3.0 y describir sus principales características,
analizar los protocolos de administración de redes y sus implementaciones en un lenguaje
de programación, elaborar los módulos de gestión y monitoreo del sistema y comprobar los
resultados en un entorno real.
Organización del informe
En el CAPÍTULO 1 se describen las diferentes arquitecturas de redes de cable y los dos

estándares fundamentales implicados, DOCSIS y SNMP. El CAPÍTULO 2 caracteriza el
equipo CMTS sobre el cual se trabajó, las metodologías de gestión que se usan en la
actualidad y la normada por la especificación DOCSIS, el lenguaje de programación
utilizado y la estructura del software realizado. Por su parte el CAPÍTULO 3 expone
brevemente cómo se opera el software y analiza los resultados y la validación, mediante la
comparación con ejemplos prácticos, de la efectividad del método.
Posteriormente aparecen las Conclusiones y Recomendaciones, y las Referencias

Bibliográficas. Se incluyen además los Anexos para complementar la visión que se quiere
dar acerca de los diferentes temas tratados a lo largo del trabajo.
4
CAPÍTULO 1. ¿DATOS EN REDES DE TELEVISIÓN?
El auge de las redes CATV en Cuba comienza durante la apertura económica de la década
del noventa, cuando comienza a desplegarse una infraestructura hotelera con capital
extranjero que demandó estos servicios. Las condiciones económicas del país no habían
permitido, sino hasta ahora, incorporar la tecnología necesaria para la transmisión de datos
sobre estas redes, servicio que desde hace algunos años brindan los grandes operadores de
cable del mundo.
Los servicios bidireccionales requieren que las señales se muevan en dos sentidos: desde el
proveedor hacia el suscriptor, y desde el suscriptor hacia el proveedor. Brindar estos
servicios en las redes de cable implica obligatoriamente modificar en alguna medida las
arquitecturas tradicionales de las redes CATV. Pago por ver (PPV), Servicios a demanda
(XOD), usualmente Video a Demanda (VOD) e IPTV, Voz sobre IP (VoIP) para servicio
de telefonía y Acceso a Internet son ejemplos de estos servicios.
Debido a la novedad que esto representa, se abordarán primeramente las arquitecturas de

las redes de cable para televisión, y siguiendo una línea evolutiva, se llegará hasta los
sistemas actuales. Se tratará además el principal estándar para la transmisión de datos en
redes de cable así como el protocolo definido para la gestión de este tipo de redes. Las
siglas y términos se describen en el acápite Abreviaciones y Acrónimos.
1.1 Arquitecturas de las redes de Televisión por Cable
El lugar donde se encuentran los equipos de recepción de señales, generadores de

programación local, donde se procesa y se conforma el paquete de canales así como donde
se gestionan los servicios adicionales que se ofrecen se denomina cabecera, o headend.
5
Las señales de los canales generados y recibidos, en banda base, se aplican a moduladores
para llevarlas a las frecuencias (o canales) deseadas. Luego se combinan y se inyectan en la
red de cable coaxial desplegada hasta los suscriptores. La calidad en estas redes se mide a
partir de las intermodulaciones de segundo orden (CSO), las de tercer orden llamado triple
batido (CTB) y las intermodulaciones cruzadas (XMOD). Por su naturaleza, el cable
coaxial atenúa las señales en cierta medida para cierta frecuencia. Para compensar estas
pérdidas, se emplean amplificadores con filtros de ecualización, que se encargan de
mantener el nivel de señal con la distancia y con la frecuencia(Cable Europe Labs, 2009).
Esta estructura y procedimientos se describen la Figura 1.1.
Figura 1.1. Arquitectura básica de una red de Televisión por Cable (CATV).
Los sistemas actuales cubren el rango de 54 MHz hasta 1 GHz, pues la atenuación del cable
coaxial por encima de esta frecuencia se hace muy grande, aunque la mayoría se detienen
en 750 MHz. Los sistemas de cable fueron concebidos para difusión de televisión,
requiriendo solamente una transmisión unidireccional. Sin embargo servicios como Internet
y Pay-per-View necesitan una comunicación en dos sentidos, razón por la cual los
operadores han tenido que actualizar sus redes con las nuevas arquitecturas.
Emplear el cable coaxial como medio de transmisión, para aprovechar la red desplegada,
requiere separar en frecuencia las diferentes señales que lo utilizarán. Así, se separa una
banda para la comunicación en sentido contrario, o como se le conoce, upstream o canal de
subida, de la banda descendente o downstream, donde se ubican los canales convencionales
de televisión. Las señales de subida se transmiten en frecuencias por debajo de los 50 MHz,
6
para no solaparse con los otros servicios. Esta banda es especialmente sensible al ruido, y
se necesitan eficientes equipos para lograr la comunicación.(Green, 2002)
Los nuevos amplificadores, que ahora tienen que amplificar en los dos sentidos, separan las
señales de bajada y subida en frecuencia, la amplifican, la vuelven a componer y la
entregan, y se conocen como amplificadores bidireccionales. La comunicación se establece
entre equipos terminales en la cabecera y en el extremo del suscriptor, de manera similar a
la mostrada en la figura 1.2.
Figura 1.2. Arquitectura de una red de cable bidireccional.
1.2 Redes HFC
La transmisión bidireccional en redes de sólo coaxial (all-coaxial cable networks)

experimentó grandes pérdidas de señal y eran muy propensas al ruido en las conexiones,
especialmente en el canal de retorno. En la década de los noventa aparecen las Redes
Híbridas de Fibra y Coaxial (HFC), como una modificación en el sistema de transmisión
para aumentar el alcance, reducir el ruido y las distorsiones, incrementar la fiabilidad,
disminuir gastos de mantenimiento y proveer medios económicos para actualizar las redes
existentes, creando además una vía para interconectar las cabeceras.
Las redes HFC aprovechan la significativamente menor atenuación que sufren las señales al
ser transportadas sobre sistemas de fibra óptica (Pici, 2007). Las señales eléctricas se
insertan en un conversor óptico-eléctrico que las entrega para el transporte ópticamente
moduladas. Usualmente, la fibra óptica conecta la cabecera con nodos ópticos distribuidos
7
en una región, donde se recuperan nuevamente las señales eléctricas y se distribuyen por
cable coaxial hasta los consumidores. Esto permite aislar el ruido hasta los nodos y
disminuir las pérdidas de señal del sistema, permitiendo construir redes más grandes
(Tooley and Bowman, 2010), que ofrecen un escenario ideal para la transmisión
bidireccional al minimizar el trayecto de la señal de retorno como señal eléctrica,
alcanzando tasas de transmisión más altas en ambos sentidos. Una red HFC se conforma
básicamente como lo muestra la figura siguiente.
Figura 1.3. Topología de una red HFC.
Las redes HFC son únicas en cuanto a:
1. Soportan la operación en dos sentidos sobre el mismo cable.

2. Son asimétricas. Debido a su origen en sistemas de difusión de televisión se cuenta
con más ancho de banda para downstream que para upstream.
3. Emplean transporte común para múltiples servicios, MPEG2, que carga tanto
paquetes de datos como señales de televisión digital.(Tooley and Bowman, 2010)
1.3 Transmisión de datos en redes CATV/HFC
Durante los años noventa, la industria del cable desarrolló un gran número de esquemas
para soportar la transmisión de datos en redes CATV/HFC, por lo que varios estándares
emergieron en calidad de competidores.
8
IEEE 802.14: En 1994 este grupo de trabajo desarrolló una capa MAC para
soportar ATMe IP sobre redes HFC. El canal de subida era TDMA con un tamaño
de ranura de 8 bytes.
Multimedia Cable Network System’s (MCNS) DOCSIS: En respuesta a la
competencia de DSL, varios Operadores de Servicios Múltiples (MSOs) crearon el
MCNS para definir un sistema estándar para proveer servicios y datos sobre
infraestructuras CATV. En 1997 lanzaron la versión 1.0 de DOCSIS. El canal de
subida utilizaba TDMA con un tamaño de ranura configurable, y fue rápidamente
aprobado por la industria.
DAVIC/DVB: La organización europea Digital Audio Visual Council (DAVIC)
produjo el DAVIC 1.2 y el muy similar Digital Video Broadcast Return Channel
for Cable (DVB-RCC), ambos estándares para cable módems, que definieron las
capas Física (PHY) y MAC para comunicaciones bidireccionales sobre redes
CATV/HFC. Posteriormente la industria europea se movió hacia EuroDOCSIS,
lógicamente por motivos económicos.(Shah et al., 2006)
De aquí en adelante se tratará a las redes CATV/HFC como redes HFC, pues es
prácticamente absoluta su aplicación en el mundo.
1.3.1 Especificación DOCSIS
DOCSIS® es una marca registrada de CableLabs® (Cable Television Laboratories, Inc.),

consorcio de investigación y desarrollo sin ánimos de lucro integrado por Arris, BigBand,
Broadcom, Cisco Systems, Harmonic, Intel, Motorola y Texas Instruments; y marcó la
entrada de los MSOs en el mercado de la banda ancha o broadband.(Volpe, 2009)
Es además un estándar no comercial que dicta los requerimientos de una interfaz de

comunicaciones para soportar el tráfico de datos IP en sistemas de cable, permitiendo
transferencias de datos de alta velocidad en redes HFC, y con el objetivo adicional de crear
interoperabilidad entre equipos desarrollados por diferentes fabricantes (Ramos et al.,
2011). Se describe en un grupo de especificaciones y reportes técnicos que exponen cómo
deben operar los dispositivos y sus interfaces en capa Física (PHY), Control de Acceso al
Medio (MAC) e Internet (IP). La versión europea de DOCSIS se llama EuroDOCSIS, y la
principal diferencia es que en Europa los canales de cable tienen un ancho de banda de 8
9
MHz, mientras que en Norte América es de 6 MHz. La primera versión de la especificación

(DOCSIS 1.0) vio la luz en marzo de 1997, y tuvo una gran revisión (DOCSIS 1.1) en abril
de 1999, que fundamentalmente adicionó algún soporte de calidad de servicio (QoS). La
versión 2.0 (DOCSIS 2.0) se lanzó en diciembre de 2001, con una mejora en las
velocidades de subida. Posteriormente en agosto de 2006, aparece DOCSIS 3.0, para
proveer mayores velocidades tanto en subida como en bajada, así como dar soporte a IP
versión 6. El apoyo de la industria a DOCSIS ha hecho del despliegue de las redes HFC un
líder en servicios de banda ancha en el principal mercado del mundo, el estadounidense,
manteniendo a su favor el 50% de las acciones del sector.(Tooley and Bowman, 2010)
En el Anexo I se listan las especificaciones que definen la última versión del estándar.
1.3.1.1 Arquitectura
Implementar DOCSIS implica la puesta en funcionamiento de un equipo denominado

Sistema de Terminación de Cable Módems (CMTS) en la cabecera, que controla los
puertos de envío y recepción de datos hacia la red de cable. Asimismo, en el extremo del
cliente debe colocarse un dispositivo que se conoce como Módem de Cable (CM).
Figura 1.4. Arquitectura de una red HFC con DOCSIS.
Tal como se muestra en la figura 1.4, el CMTS básicamente conecta Internet y la red
interna del proveedor (Back Office Network) con la red HFC, reenviando paquetes entre
esos dos grandes dominios y entre los canales de subida y bajada dentro la propia red de
cable.(Cable Television Laboratories, 2010)
Para dar soporte a la red DOCSIS, deben emplearse según especificaciones, dos sistemas
fundamentales: el Sistema de Provisionamiento (Provisioning System) y el Sistema de
Gestión de Red (NMS).
10
El Sistema de Provisionamiento se conforma de un conjunto de aplicaciones que

intervienen en la puesta en operación de los CMs. Este grupo de aplicaciones incluye:
Servidores DHCP: proveen información de configuración inicial como la dirección

IP de los CMs y otras direcciones.
Servidor de Archivos de Configuración (TFTP): permite que los CMs descarguen
sus archivos de configuración cuando arrancan.
Servidor de Descarga de Software: permite actualizar los softwares de los
fabricantes en el equipamiento.
Servidor de Protocolo de Tiempo: proporciona la referencia de tiempo para la red.
Servidor de Revocación de Certificados: provee estados de certificados.
De manera similar, el Sistema de Gestión de la Red se compone de programas de aplicación

que intervienen en la administración y monitoreo de los recursos, como son:
Gestor SNMP: permite al operador configurar y monitorear el equipamiento,

típicamente los CMs y el CMTS.
Servidor Syslog: recolecta mensajes acerca de la operación de los dispositivos.
Servidor de IPDR: permite al operador obtener estadísticas de manera general y
eficiente respecto al uso de la transmisión de datos.
1.3.1.2 Características y Funcionamiento General
DOCSIS funciona principalmente entre las capas 1 y 2 del modelo OSI de la ISO,
conocidas también como Capa Física (PHY) y Capa de Control de Acceso al Medio
(MAC).En términos simples, las redes DOCSIS son redes IP sobre HFC, donde los
paquetes IP son codificados y transportados como señales de televisión digital que
coexisten con otros servicios también transportados por la red.
El espectro total es dividido en una parte para el upstream desde 5 MHz hasta 42 MHz (en
algunos sistemas hasta 85 MHz, conocida como banda extendida de upstream), y la parte
para el downstream a partir de los 108 MHz hasta la capacidad de la red. Así DOCSIS
especifica un camino asimétrico de datos con flujos de bajada y subida en dos frecuencias
separadas. Las portadoras de bajada y subida proveen dos canales compartidos para todos
los CMs.
11
Downstream: Desde el CMTS hacia los CMs
La banda de downstream se comparte con los demás servicios que brinda la red. El ancho
de banda para cada canal descendente puede ser de 6 MHz ó de 8 MHz para cumplir con las
normas de los canales de difusión de televisión en Norteamérica y Europa. Los formatos de
modulación que pueden ser empleados son: 64-QAM y 256-QAM, y en la tabla 1.1 se
muestras las diferentes tasas que pueden alcanzarse. (Cable Television Laboratories, 2010)
Tabla 1.1. Velocidades para los canales de bajada de 6 MHz.

Tipo de Modulación Tasa de Modulación Bits por símbolo Velocidad de Transferencia
64-QAM 5.056941 Msym/s 6 30.34 Mbps
256-QAM 5.360537 Msym/s 8 42.88 Mbps
Los paquetes enviados por el canal de bajada se separan en tramas MPEG de 188 bytes, con
4 bytes de encabezado y 184 bytes de carga útil. Aún cuando a todos los CMs llegan todas
las tramas, normalmente se configuran para recibir solamente las que están direccionadas a
su dirección MAC o a la dirección de difusión. (Shah et al., 2006)
En el sentido descendente, DOCSIS emplea un sistema primero-que-llega primero-que-se-

atiende para el reenvío de paquetes, así los paquetes que arriban de Internet se reenvían
inmediatamente como paquetes DOCSIS y se modulan en un canal downstream de RF para
la transmisión.(Tooley and Bowman, 2010)
Upstream: Desde los CMs hacia el CMTS
Las características de esta banda (ruido y distorsión) hacen que se necesiten mecanismos
robustos, como modulaciones eficientes, para la transmisión de datos. A diferencia de la
banda de downstream, en la que sólo hay un transmisor, en esta banda hay muchos
transmisores y un solo receptor, por lo que la utilización del medio de transmisión deber ser
cuidadosamente organizada y repartida entre todos los CMs. Por todo esto se conforman los
CMTS con más puertos de subida que de bajada, permitiendo segmentar más la red en el
sentido ascendente y lograr mejores niveles de señal.
En la banda de upstream, DOCSIS emplea dos esquemas básicos de acceso al medio: modo
FDMA/TDMA, descrito como TDMA, y modo FDMA/TDMA/S-CDMA descrito como
modo S-CDMA, permitiendo seis tasas de modulación y múltiples formatos para esta. Con
FDMA se divide la banda en múltiples canales de frecuencias. TDMA responde a la
12
naturaleza de ráfaga de las transmisiones de subida y permite compartir un canal de RF de

subida entre varios cable módems a través de la asignación dinámica de ranuras de tiempo.
S-CDMA da la posibilidad de que varios CMs transmitan simultáneamente en el mismo
canal de RF y sobre la misma ranura de tiempo TDMA, separados por diferentes códigos
ortogonales. (Cable Television Laboratories, 2010)
Los tipos de modulación establecidos para los moduladores/demoduladores de upstream

son: QPSK, 8-QAM, 16-QAM, 32-QAM, 64-QAM y 128-QAM. El CMTS reserva el
ancho de banda de upstream basado en peticiones de los CMs y las políticas de calidad de
servicio. El canal de subida se divide en ranuras de tiempo multiplexadas, llamadas “mini-
slots”, de una duración de 6.25 µs, y la oportunidad para transmitir en ellas es administrada
por el CMTS, que las identifica mediante referencias de tiempo y que son utilizadas por los
CMs según mecanismos de contención. La influencia de la distancia en el retardo implica
una compensación de tiempo (offset) en las referencias de los CMs para que identifiquen
con suficiente precisión la posición de los mini-slots. (Cable Television Laboratories, 2010)
Operación básica del protocolo
La configuración elemental de una red DOCSIS se muestra en la siguiente figura.
Figura 1.5. Componentes básicos de una Red DOCSIS.
Básicamente, para que funcione la red DOCSIS se debe tener en funcionamiento el CMTS,
un servidor DHCP y uno TFTP, para que los CMs puedan registrarse. Normalmente se
emplea un DHCP de dos niveles o rangos: uno para la operación de los cable módems a
nivel de servicio, y otro para los equipos de premisas del cliente (CPE). (Carcamo, 2009)
Cuando un cable módem se conecta a la red coaxial, y se enciende, comienza a rastrear un

canal descendente buscando en toda la banda una transmisión 64-QAM ó 256-QAM, que
contenga información válida acerca de un canal de subida, para poder establecer una
13
comunicación bidireccional. Si efectivamente lo encuentra y lo retiene, comienza lo que se

conoce como Ranging. El ranging es un proceso que consta de dos etapas, la primera es el
Ranging Inicial, en la que se configura el menor nivel de potencia que garantiza la
comunicación. Después pasa a un nuevo estado conocido como Ranging de Mantenimiento
(Station Maintenance Ranging), en el que el cable módem recibirá instrucciones desde el
CMTS para hacer ajustes en cuanto a frecuencias de transmisión, amplitud, timing offset y
pre-ecualización. El Ranging de Mantenimiento de Estaciones ocurrirá al menos una vez
cada 30 segundos para cada cable módem, realizando ajustes de forma continua y para que
el CMTS conozca que los módems se encuentran en línea.(Volpe, 2009)
De esta manera, el CMTS periódicamente envía tramas de gestión y otra clase de mensajes
denominados mensajes MAP, para que los CMs puedan identificar futuras ranuras TDMA
para el upstream. Inmediatamente al contar con ancho de banda para transmitir, el CM
obtiene su IP y otras direcciones importantes mediante DHCP y descarga el archivo de
configuración del servidor TFTP, con los parámetros que necesita para el acceso a la red,
velocidades, QoS y otras configuraciones. Si las pruebas de validez son satisfactorias, se
concluye el proceso con el Registro del CM en la red y se le asigna un Identificador de
Servicio (SID).Una vez registrado el CM, se permite a los suscriptores transmitir tráfico IP.
(Downey, 2006)
1.3.1.3 DOCSIS 3.0
DOCSIS 3.0 consiste en una serie de especificaciones (ver Anexo I) que define la tercera
generación de la transmisión de datos de alta velocidad sobre sistemas de cable. Fue
expedida en la primera semana de agosto de 2006 y representa la gran evolución del
estándar. La flexibilidad en la implementación de sus nuevas características y la
escalabilidad de los equipos de terminación lo hacen muy atractivo(Vecima Networks,
2008). La principal característica que aporta la versión 3.0 de DOCSIS es el Channel
Bonding, que permite agrupar varios canales físicos para formar un gran canal lógico y
aumentar el ancho de banda, tanto en subida como en bajada, para cada suscriptor. Además
cuenta con:
Mayores rangos de direccionamiento IP con IPv6
Soporte mejorado para Multicast (multidifusión)
14
Técnicas de encriptación más robustas con AES y MMH

Sistemas de gestión de más capacidad con mediciones más profundas.
Razón canales upstream a canales downstream más flexible (U:D) (Ader and
Cloonan, 2007)
Las especificaciones DOCSIS 3.0 no limitan la cantidad de canales que se pueden unir para
el channel bonding. En la práctica los factores que lo limitan pueden describirse como:
cantidad de canales de 6 MHz u 8 MHz libres, y equipamiento que soporte mayores grupos
de canales puenteados. Pocos fabricantes pueden ofrecer soluciones económicas de
equipamiento que puedan puentear más de 4 canales debido al alto costo marginal y a la
baja demanda.(Tooley and Bowman, 2010)
1.3.1.4 I-CMTS y M-CMTS
Durante la evolución de DOCSIS 3.0, se fueron desarrollando diferentes modos para

conformar un CMTS que implementara el estándar completamente, lo que trajo como
resultado dos arquitecturas fundamentales de CMTSs: Modulares e Integrados.
CMTS Integrado (I-CMTS)
Es un CMTS donde todos los componentes necesarios para la operación de DOCSIS 3.0 se
encuentran dentro del mismo chasis. El primer fabricante de CMTSs Integrados en ganar la
calificación DOCSIS 3.0 completa fue CASA Systems, Inc. proveyendo un CMTS DOCSIS
3.0 y eQAM en una plataforma de 1RU de 19 pulgadas. Los beneficios de esta arquitectura
radican en su facilidad de despliegue, bajo costo y menos puntos de fallo en cableado e
interfaces. Cuenta además con algunas debilidades, como la baja densidad y dificultades
para la sincronización con fuentes de tiempo externas utilizadas por otro equipamiento.
CMTS Modular (M-CMTS)
Esta arquitectura, expuesta en la figura 1.6, se basa en un Núcleo CMTS que implementa
las interfaces de upstream y las del lado de red (NSI) mostrada como WAN Ethernet. Este
núcleo tuneliza el contenido de los canales descendentes a uno o más eQAMs, a través de
una Interfaz Física Externa de Downstream (DEPI), que conforma el grupo de canales para
el channel bonding. El núcleo y los eQAMs se sincronizan a través de un servidor de
tiempo por la Interfaz de Temporización DOCSIS (DTI). Este modelo difiere del integrado
15
en su escalabilidad y en el tratamiento al canal descendente, a expensas de la separación de

sus componentes. (Cable Television Laboratories, 2011)
Figura 1.6. Arquitectura M-CMTS
La modularidad de esta arquitectura es muy ventajosa en grandes sistemas donde se hace

importante el costo por ancho de banda, aún cuando genera nuevo cableado vulnerable y
expuestoa fallos potenciales.(Volpe, 2010)
De cualquier manera, e independientemente de la arquitectura del CMTS, DOCSIS 3.0

define un estándar para la gestión de este equipo conocido como SNMP y ampliamente
difundido como herramienta de administración de redes, que es empleado por el Gestor
SNMP dentro del Sistema de Gestión de Red para el intercambio de información de gestión
con el equipamiento de la red HFC, y cuyos detalles se abordan en el siguiente epígrafe.
1.4 Protocolo Simple de Gestión de Redes (SNMP)
SNMP, o Protocolo Simple de Gestión de Redes, define un protocolo sencillo que permite
obtener y modificar valores de variables específicas de sistemas, definidas en su
arquitectura como objetos (Parziale et al., 2006). SNMP emplea un modelo
gestor/agente/subagente, integrado por un Gestor (NMS), un Sistema Gestionado, una
Base de Datos de Información de Gestión y un Protocolo de Red (Miller, 2004). SNMP
es en este caso el protocolo de red, y se utiliza en dos servicios fundamentales:
Monitoreo: encuesta las redes para valorar su funcionamiento, uso general y capacidad,
determinación de problemas y análisis gráficos y estadísticos. Adicionalmente,
incorpora componentes para la notificación de alertas a los administradores.
16
Gestión: permite cambiar parámetros dinámicamente dentro del funcionamiento de la

red, responder de manera rápida ante problemas y realizar pruebas en tiempo
real de cómo un cambio afecta la red.(Parziale et al., 2006)
Estas rutinas son muy importantes en el mantenimiento de las redes. En el caso de las redes
HFC, se dedicarían, por ejemplo, al chequeo del estado de los elementos de la red y a la
configuración de la modulación y frecuencia de los canales de transmisión o recepción.
1.4.1 Gestores y Agentes
Figura 1.6. Relación entre el Gestor y el Agente.
El Gestor es básicamente un software, que generalmente incluye una interfaz gráfica de

usuario, que corre uno o más procesos que se comunican con los agentes en la red, y que
posee toda la inteligencia de gestión para simplificar el impacto de los agentes en los
dispositivos gestionados. Los procesos de gestión recolectan, analizan, procesan y
modifican los valores de los objetos en los agentes.
Un agente, por otro lado, se implementa en el dispositivo o sistema gestionado, y mantiene

una base de datos local de los objetos que describen su estado, historia, e inciden en su
funcionamiento. Operan enviando notificaciones sobre eventos y respondiendo peticiones
de los gestores (Hilmersson, 2006). Su interacción con el gestor se muestra gráficamente en
la figura 1.6, que en una red DOCSIS se hablaría del software de gestión como el NMS y el
CMTS, por ejemplo, como el agente.
SNMP v1 y v2 emplean lo que se conoce como comunidad (community) para establecer la

comunicación entre agentes y gestores. Un agente se configura con tres nombres de
comunidades: uno para sólo-lectura (read-only), uno para lectura-escritura (read-write), y
uno para notificaciones (trap). Los nombres de comunidad son básicamente contraseñas, y
los tipos de comunidad representan los privilegios de la conexión sobre los objetos.
17
1.4.2 Base de Información de Gestión
La Base de Información de Gestión (MIB) define un conjunto de objetos que pueden ser
monitoreados y administrados con SNMP. Se asocia tanto con el sistema que gestiona
como con el gestionado, para que ambos conozcan los objetos a los que se tiene acceso.
Una MIB tiene una organización definida que se denomina Estructura de la Información de
Gestión (SMI), con una estructura de árbol que comienza en una raíz y con las ramas que
organizan los objetos o variables en categorías lógicas, representando los objetos finales
como las hojas de las ramas como se muestra en la figura 1.8 (Miller, 2004). Una MIB
define un nombre textual para los objetos y explica su función y estructura.(Mauro and
Schmidt, 2005)
Existen MIBs que deben implementarse obligatoriamente en todos los agentes. Tal es el
caso de la MIB-II, definida en la RFC 1213 (McCloghrie and Rose, 1991) y actualizada por
la RFC 4022 (Raghunarayan, 2005), RFC 4113 (Fenner and Flick, 2005) y RFC 4293
(Routhier, 2006), que define variables para, entre otras cosas, estadísticas de interfaces e
información de sistema, cuyo objetivo principal es brindar información general de gestión
TCP/IP.Además, a los fabricantes se les permite definir sus propias MIBs para sus equipos,
las que se conocen como MIBs propietarias.(Mauro and Schmidt, 2005)
1.4.2.1 Estructura de la Información de Gestión

Figura 1.7. MIB y SMI.
La figura 1.7 muestra la relación entre la MIB y la SMI, o

sea, los objetos dentro de una MIB se definen según la
SMI. Actualmente se emplea la SMIv2 (versión 2)
definida en la RFC 2578 (McCloghrie et al., 1999).
SMIv2 define cómo los objetos administrados son
descritos y cómo pueden acceder a ellos los protocolos.
Para esto utiliza un subconjunto de la Notación Sintáctica
Abstracta 1 (ASN.1), un lenguaje de descripción de datos. La SMI dice cómo se definen los
objetos mientras que la MIB es la definición de los propios objetos. SMI soporta tres tipos
diferentes de definiciones de estructuras: Módulos, Objetos y Notificaciones. Los Módulos
18
son estructuras que encapsulan Objetos y Notificaciones. Estas definiciones no sólo

describen la sintaxis de los objetos, sino también su semántica.(Hilmersson, 2006)
1.4.2.2 Identificadores de objetos
Un objeto administrado además de descrito debe ser identificado. Esto se hace empleando
el identificador de objeto (OID) de ASN.1, que consiste en una serie de números enteros
separados por puntos (.) donde cada número representa la jerarquía a la que pertenece el
objeto en la estructura de árbol donde se agrupa.(Stevens, 2001)
Al inicio del árbol se encuentra la raíz sin

nombre donde comienzan los OIDs. Los
nodos además de numerados son nombrados
también. Acuerdos entre diferentes
organizaciones han determinado la
organización de los nodos principales. La
figura 1.8 muestra un sub-árbol con objetos
SMI.
Figura 1.8. Sub-árbol del Árbol de Objetos SMI.
En el cuarto nivel, donde se situó el nodo del Departamento de Defensa de los EUA (DoD),
la comunidad de Internet asumió el 1 (o sea, el OID 1.3.6.1), descrito por la IAB con la
RFC 1155 (Rose and McCloghrie, 1990), cuyo sub-árbol emplea el 2 para la identificación
de objetos con propósitos de gestión y el 4 para objetos de uso privado, donde se colocan
las MIBs propietarias de los fabricantes, entre otros. (Parziale et al., 2006)
Cada MIB define sus módulos y objetos, los que se adjuntan a este gran árbol. Así el objeto
sysDescr, por ejemplo, declarado en la MIB-II (RFC 1213) pertenece al grupo system, que
pertenece a mib-2 que es un hijo del nodo mgmt, y así sucesivamente. Por tanto, su OID se
conformaría con la cadena de números: 1.3.6.1.2.1.1.1.0, donde el cero al final significa que
es el valor de la instancia del objeto en el agente. También se identifica por
iso.org.dod.internet.mgmt.mib-2.system.sysDescr. La notación decimal expresa cómo se
representa el objeto internamente dentro de un agente, mientras el nombre textual solo se
utiliza para facilitar actividades humanas. (Mauro and Schmidt, 2005)
19
Para SNMP solo es importante el sub-árbol 1.3.6.1, administrado por la IANA mediante el
documento de Números Asignados según la RFC 1700 (Reynolds and Postel, 1994).
Una de las MIBs estándares importantes en redes DOCSIS es DOCS-IF, para la gestión de
las interfaces DOCSIS, que se subordina a la MIB-II, específicamente su identificador es
1.3.6.1.2.1.10.127, equivalente a iso.org.dod.internet.mgmt.mib-2.transmission.docsif.
Igualmente de las propietarias están las de CableLabs, donde CLAB-DEF es la más
significativa y cuyo OID es 1.3.6.1.4.1.4491.2.1, expresado textualmente como
iso.org.dod.internet.private.enterprises.cableLabs.clabProject.clabProjDocsis.
1.4.3 Protocolo de transporte
SNMP se comunica principalmente sobre UDP, definido en la RFC 768 (Postel, 1980) y
escogido sobre TCP por ser no orientado a la conexión, ya que en redes sobrecargadas
puede tener mejores oportunidades de alcanzar el destino debido a su naturaleza simple y
ligera de encabezados (Hilmersson, 2006). A nivel de protocolo no hay reconocimiento de
datagramas perdidos, por lo que la aplicación SNMP deberá determinar las pérdidas y
realizar las retransmisiones si son necesarias. De cualquier forma no hay restricciones para
emplear otro protocolo de transporte.(Mauro and Schmidt, 2005)
1.4.4 Mecanismos del protocolo SNMP
El Gestor SNMP, conocido como NMS, es responsable de hacer las peticiones al agente,
que pueden ser para obtener el valor de un objeto MIB, o para modificar el valor de dicho
objeto. Además escucha también las notificaciones o alertas, conocidas por traps,
generadas por las entidades SNMP de la red. La Unidad de Datos de Protocolo (PDU) es el
formato de los mensajes que se utilizan en la comunicación entre agentes y NMSs. SNMP
cuenta con cinco tipos básicos de mensajes:
GetRequest
GetNextRequest
SetRequest
GetResponse
Trap
20
Para obtener el valor de un objeto en un agente, el NMS envía una petición GetRequest
especificando el OID del objeto, y el agente responde con un mensaje GetResponse con el
valor del objeto o con la especificación de un error ocurrido. El mensaje GetNextRequest se
emplea fundamentalmente en el recorrido de tablas, y funciona similar a GetRequest, pero
el agente responde el valor del objeto cuyo OID es el próximo inmediato al OID del objeto
que se envió en la petición.
Para modificar un valor, el NMS envía una petición SetRequest con el OID del objeto y el
valor a asignarle, y el agente responde con un mensaje GetResponse con la notificación de
si ocurrió error o no. Contrariamente los PDU tipo Traps son alertas que envían los agentes
ante cambios de estado y sin petición alguna por el NMS.
1.4.4.1 Formato de los mensajes
Los mensajes SNMP se encapsulan generalmente en datagramas UDP, dentro de paquetes

IP en las tramas de red, como aparece en la figura 1.9.
Figura 1.9. Mensaje SNMP dentro de la trama de red.
Los mensajes SNMP se dividen en encabezado y PDU. El encabezado especifica la versión

empleada de SNMP y las credenciales de autenticación. La PDU contiene información
concerniente al tipo de mensaje y los valores de los objetos encuestados. Los mensajes
GetRequest, GetNextRequest, SetRequest y GetResponse tienen un formato de PDU común
(figura 1.10), mientras los mensajes Trap difieren (figura 1.11).(Miller, 2004)
Figura 1.10. PDU para los mensajes GetRequest, GetNextRequest, SetRequest y

GetResponse.
21
Figura 1.11. PDU para los mensajes Trap.
En la figura 1.10, el campo Tipo PDU contiene un valor en dependencia del tipo de
mensaje: GetRequest (0), GetNextRequest (1), GetResponse (2), SetRequest (3) y Trap (4).
El campo Identificador de Petición lleva un número que relaciona la petición del NMS con
la repuesta del agente. Los campos de error portan información acerca de los resultados de
las operaciones en el agente respecto a la petición realizada. Los contenedores de variables
transportan los OIDs y los valores de los objetos implicados.
En cambio, las PDU de las notificaciones, como se aprecia en la figura 1.11, siguen otro
formato excepto el campo Tipo PDU. Enterprise indica el OID del fabricante del
dispositivo y el campo Dirección Agente simplemente la dirección IP de la entidad SNMP
que la genera. Las alertas se pueden originar por trampas genéricas normadas o por
específicas (incorporadas por los fabricantes); esta información se transporta en los campos
Tipo Trap Genérico y Tipo Trap Específico. El Sello de Tiempo lleva una marca del
momento en que se originó la notificación, mientras los contenedores llevan información
acerca de los objetos involucrados en la alerta. (Miller, 2004)
1.4.4.2 Los bytes reales
ASN se divide en dos partes: gramática formal y reglas de codificación. Las reglas de
codificación, conocidas como Reglas de Codificación Básicas (BER), se encargan de
construir los datos binarios y están especificadas en ISO 8825 (Miller, 2004). La estructura
de codificación empleada para la transferencia a nivel de bit se llama codificación Tipo
Longitud Valor (TLV). La idea básica consiste en que para cada campo a transmitir se
determine el tipo de valor, o sea, el tipo ASN, la longitud en bytes que se necesitará para la
transmisión del valor del campo y el valor propiamente dispuesto como una cadena de
22
bytes. Esto es especialmente útil si se tiene en cuenta que los valores MIB
tienden especialmente a ser enteros de varios tamaños y cadenas de
caracteres. (Binkley, 2005)
Todos los mensajes SNMP son convertidos o serializados de la notación

ASN.1 a datos binarios empleando la codificación BER. Existen varios
métodos de codificación, aunque SNMP se enmarca en el más simple,
conocido como Primitivo. El campo Tipo ocupa un byte que es dividido en
dos bits para denotar la clase (class), uno para P/C, y cinco para la etiqueta
que identifica el tipo de valor. Algunos Tipos ASN.1 y sus etiquetas son: (2)
número entero, (4) cadena de caracteres, (5) null, (6) OID, (16) secuencia.
Igualmente el campo longitud ocupa un byte mientras la cantidad de bytes
en el campo valor sea menor que 127, de lo contrario se extiende marcando
el bit más significativo como 1 para informar que el próximo byte también
pertenece al campo longitud.
Figura 1.12. Trama capturada de SNMP
En la figura 1.12 se muestra una trama capturada, en la que se puede

apreciar cómo se apilan los protocolos. El encabezado de red (Ethernet II)
muestra la MAC destino, la MAC fuente y el tipo de protocolo que carga, en
este caso IP (0x0800). El encabezado IP muestra que es versión 4 y que
carga un datagrama UDP (0x11), y las direcciones IP son: fuente
10.12.57.23 (0x0a 0c 39 17) y destino 10.12.57.254 (0x0a 0c 39 fe). UDP
tiene como puerto fuente 2539 (0x09eb) y destino 161 (0x00a1), la longitud
del datagrama completo es 48 (0x30) y el chequeo de redundancia cíclica
(0x399c). Dado que el puerto de destino es 161, la carga del datagrama es
SNMP, y la codificación puede apreciarse con detalle en la figura 1.13.
Aclarar que el tipo secuencia (16) no se muestra como 0x10 en ningún caso
porque el nibble superior está afectado además por otros bits.
Figura 1.13. Codificación de nivel de byte de un mensaje SNMP

GetRequest. (Lateral)
23
1.4.5 Versiones
La IETF es responsable por la definición de protocolos estándares que gobiernan el tráfico

IP, incluyendo SNMP. Esta organización publica Peticiones para Comentarios (RFC), que
son especificaciones para muchos protocolos en el mundo IP. SNMP ha desarrollado tres
versiones (Mauro and Schmidt, 2005):
SNMP versión 1 (SNMPv1): versión inicial del protocolo. Se define en la RFC

1157 (Case et al., 1990) y se basa en comunidades, contraseñas de texto plano que
permite a las aplicaciones SNMP ganar acceso a la información de gestión de los
dispositivos. Aunque es histórica, es la primera implementación de SNMP que
soportan muchos fabricantes.
SNMP versión 2 (SNMPv2): al igual que su predecesora se basa en comunidades.
Esta versión se llama técnicamente SNMPv2c. Está definida en las RFC 3416
(Presuhn et al., 2002c), RFC 3417 (Presuhn et al., 2002b) y RFC 3418 (Presuhn et
al., 2002a). Incorpora algunos tipos de PDU nuevos como GetBulkRequest,
InformRequest, Notification y Report.
SNMP versión 3 (SNMPv3): última versión de SNMP. Su mayor contribución a la
gestión de redes es la seguridad. Proporciona soporte para una fuerte autenticación y
comunicación privada entre entidades gestionadas. En 2002 se convirtió en estándar
y está definido en las RFC 3410 (Case et al., 2002b), RFC 3411 (Harrington et al.,
2002), RFC 3412 (Case et al., 2002a), RFC 3413 (Levi et al., 2002), RFC 3414
(Blumenthal and Wijnen, 2002), RFC 3415 (Wijnen et al., 2002), RFC 3416, RFC
3417, RFC 3418 y RFC 2576 (Frye et al., 2000).
1.5 Conclusiones del capítulo
El protocolo DOCSIS permite transformar las redes de cable o HFC en tecnologías de

transmisión de datos que logran brindar servicios de banda ancha de una manera muy
económica. Para sustentar competentemente estos servicios, el operador debe desplegar un
eficiente sistema de gestión para su red, donde SNMP da la posibilitad de hacerlo mediante
una aplicación informática hecha a la medida, que facilite sustancialmente dicho proceso.
(Cable Television Laboratories, 2008c, Cable Television Laboratories, 2008b, Cable Television Laboratories, 2008d)
24
CAPÍTULO 2. LLEGANDO AL OBJETIVO
El presente trabajo se realizó sobre un CMTS genérico

propiedad de Telecable Internacional, proveedor de
servicios de cable perteneciente a la corporación cubana
CIMEX. A continuación se describen brevemente sus principales características tanto de
software como de hardware.
Los nuevos CMTS genéricos ofrecen una nueva categoría de dispositivos terminales para
redes de cable basados en tecnologías disruptivas1 para aprovechar las oportunidades
crecientes en el mercado de los servicios IP de banda ancha, y son conocidos como
Sistemas de Terminación de Cable Módems (CMTS) de próxima generación (next-
generation), que ofrecen, además, soluciones para difusión de video IP (Summit Partners,
2010). Para la gestión de dicho equipo, se confeccionó un software utilizando la
herramienta de programación Borland Delphi 7, cuya descripción general y sus
características también se abordan más adelante.
2.1 El CMTS
El CMTS empleado, que se muestra en la figura 2.1, es una nueva clase de dispositivo
terminal que combina un Edge-QAM para video MPEG y un CMTS DOCSIS de tercera
generación en una misma plataforma de una unidad de rack (1RU), implementando las
mejores características DOCSIS 3.0 en el mercado. Cuenta con una completa separación de
1
Tecnología disruptiva: término de corte financiero usualmente análogo a Innovación disruptiva, se refiere a
una innovación que ayuda a romper un mercado existente para crear uno nuevo mediante un producto o
servicio que el mercado no espera.
25
la capacidad de bajada y la de subida, pudiéndose agregar canales en cualquier sentido de

manera totalmente independiente. La gran densidad de canales, la capacidad revolucionara
de ancho de banda DOCSIS, y el costo por bit del este CMTS permite ofrecer servicios IP
de banda ancha de una manera muy económica y brinda la mayor capacidad de channel
bonding en bajada (16) y en subida (8) para CMTSs de su tipo.(CMTS Systems, 2011)
Figura 2.1. CMTS

Puede contar hasta con 48 canales QAM de downstream (3 módulos x 16 canales). Soporta
tráfico DOCSIS y MPEG/DVB, muy importante para aprovechar los recursos espectrales
de la red HFC, permitiendo compartir estos recursos dinámicamente. Permite hasta 30
Mbps de ancho de banda por canal de subida, que unido al esquema de cancelación de
ruido por ingress que implementa, da la posibilidad de utilizar menos canales de upstream
y desplegar razones D:U más simétricas.
2.1.1 Hardware
Consiste en un sistema base con cuatro slots, o ranuras, para módulos de interfaces de RF
(módulos downstream o upstream), 4 puertos GbE SFP y conmutación capa 2/capa 3
incorporada. Existen tres versiones de módulos de downstream, de 4, 8 ó 16 canales QAM,
todos con cuatro puertos de salida. Cada módulo de upstream puede tener 4 u 8 puertos,
pudiendo tener 1 o 2 canales por puerto. Cada canal físico, de dowstream o de upstream,
posee una portadora con una frecuencia central en el espectro de la red. En el caso del
upstream, la informción no fluye directamente por los canales físicos, sino por canales
lógicos identificados que cada canal físico posee.
La plataforma soporta cualquier combinación de módulos de downstream y upstream. El

módulo DOCSIS QAM (DQM) es una unidad de downstream DOCSIS que incluye
26
procesamiento de paquetes DOCSIS, QoS y conversión de capa PHY y MAC de DOCSIS y

de RF. El módulo de Control y Upstream DOCSIS (DCU) es una unidad que incluye el
procesamiento de paquetes DOCSIS, operaciones de capa MAC de DOCSIS y receptores
en modo ráfaga. Configuraciones típicas de canales pueden ser 32DSx32US para una razón
de 1:1 y 16DSx32US para una razón de 1:2. En la configuración mínima, el CMTS puede
tener un módulo DQM04 (4 canales QAM) y un módulo DCU04 (4 canales de recepción).
La figura 2.2 y la tabla 2.1 muestran detalles sobre el panel frontal del CMTS.
Figura 2.2. Panel Frontal del CMTS.
Tabla 2.1. Conectores del panel frontal.

Etiqueta del conector Función
Conector de AC Suministro de energía
RS-232 <serial> Puerto de consola serial para la administración del sistema
Puerto del Sistema de Gestión de Red (NMS), conector RJ-45, provee
10/100 BT <eth0>
enlace Fast Ethernet directo para tráfico de gestión fuera-de-banda.
T1 Sincronización de reloj para DOCSIS.
Puertos Gigabit Ethernet (GbE) 1, 2, 3 y 4. Acepta/Transmite corrientes de
GbE <gige0..3> video con transporte MPEG2 de un servidor VoD o desde/para redes IP.
Cada puerto utiliza un módulo SFP (Small Form-factor Pluggable) estándar.
Nota: Entre < > se coloca el identificador del puerto.
En el panel trasero se encuentran los conectores de cable coaxial de los módulos de subida
y bajada, como se muestran en la figura 2.3. (CMTS Systems, 2007)
Figura 2.3. Panel Trasero del CMTS.

27
Los módulos se numeran según el slot que ocupan, así de izquierda a derecha comienzan
por 0 y terminan en 3. Los puertos se numeran, en los módulos de 4 puertos, de izquierda a
derecha comenzando por 0 y terminando en 3; y en los de 8 conectores, de 0 a 7
comenzando de izquierda a derecha primero en la fila inferior y luego de izquierda a
derecha en la fila superior. Otros detalles se muestran en la tabla 2.2.
Tabla 2.2. Conectores del panel trasero.

Etiqueta del conector Función
Interfaz para cable coaxial de la salida de RF de downstream.
Salida QAM/RF Conector F de 75Ω. Se numeran con un formato <módulo>/<puerto>.
Los canales se numeran <módulo>/<puerto>/<canal>.
Interfaz para cable coaxial de las entradas de los receptores de ráfaga
de upstream. Conector F de 75Ω. Se numeran con un formato
Entrada Rx/RF
<módulo>/<puerto>. Los canales se numeran
<módulo>/<puerto>.<canal físico>/<canal lógico>.
Otras características y especificaciones técnicas se pueden consultar en el Anexo III.
El esquema básico de un CMTS de este tipo se muestra en la figura 2.4. El CMTS en

cuestión cuenta con una capacidad de conmutación de 12 x 2 Gbps. El Switch Fabric es lo
que se conoce como Estructura de Conmutación, sistema que se encarga del redireccionado
y reenvío de paquetes.
Figura 2.4. Diagrama básico del CMTS.
El CMTS de Telecable Internacional en la cabecera de Cayo Santa María, y objeto del

presente trabajo, cuenta un módulo DQM04 (4 canales downstream 0/0/0, 0/1/0, 0/2/0 y
0/3/0), y un módulo DCU04 (4 canales upstream 1/0.0/0, 1/1.0/0, 1/2.0/0 y 1/3.0/0). Se
encuentra enlazado al proveedor de servicio de internet, ETECSA, a través de una fibra
óptica conectada a un puerto GbE. El puerto 10/100 BaseT está conectado a un conmutador
(switch) al que se conectan otros equipos para conformar la red de servicio.
28
Posee un microprocesador Broadcom BCM1250, que integra dos núcleos SiByte SB1,
implementación de alto rendimiento de la arquitectura MIPS64, en un sistema en un chip
(SoC) que incluye 512KB de caché nivel 2 y un controlador DDR que maneja hasta 2 GB,
controlado por un sistema operativo basado en Linux. (MIPS Technologies Inc., 2009)
2.1.2 Software
El CMTS se configura y administra por software mediante la Interfaz de Línea de

Comandos (CLI) estándar de la industria, a la que se puede acceder por puerto serie RS232
o por Telnet a través de la interfaz de gestión; y permite el uso de SNMP para la
configuración y la gestión remotas, implementando las MIBs estándar de DOCSIS y de la
IETF. Una CLI se utiliza cuándo los sistemas no disponen de suficientes recursos para
soportar una GUI. Un programa que implementa tal interfaz se denomina Intérprete de
Línea de Comandos o shell (shell se usa comúnmente para describir CLIs, pero en principio
puede ser cualquier programa que constituya la interfaz de usuario, aún cuando sea gráfica).
La CLI mostrará un prompt (conjunto de caracteres que indican la disposición a aceptar

comandos, por ejemplo CMTS>), aceptará una línea de comandos terminada por el carácter
Enter y luego ejecutará el comando especificado y mostrará los resultados o mensajes de
error. El conjunto de comandos se divide en subconjuntos que ocupan una posición en una
jerarquía. La posición dentro de la jerarquía y las opciones disponibles son referidas como
modo (mode). Emplea además un sistema de usuarios caracterizados por sus privilegios,
definidos por un número de 1 a 15 donde 15 es el nivel más alto. La disponibilidad de los
comandos está determinada entonces por el modo y el privilegio del usuario.
Características operacionales como información de los CMs, administración espectral,

reporte de uso de recursos de CPU y memoria, administración con privilegios de usuario
están disponibles, así como balanceo de carga para canales puenteados. Cuenta también con
características IP como relay de DHCP y la opción 82, múltiples servidores de DHCP,
proxy ARP, IGMP v2 y v3 y listas de control de acceso (ACL). Funciona como un
enrutador de capa 3, soportando protocolos de enrutamiento dinámicos y estáticos, como
puenteo de capa 2, VLAN, RIP, BGP, OSPF, IS-IS, y PIM-SM. (CMTS Systems, 2010)
29
2.2 Gestión
La gestión es un concepto general, y se basa en el auxilio de herramientas y técnicas para

ayudar a los seres humanos en la administración de los procesos y los recursos de
determinado sistema.
2.2.1 Gestión de Redes
Cuando lo que se gestiona es una Red, entonces se administran sus dispositivos y sistemas.
La Organización Internacional para la Estandarización, ISO, creó un modelo para la gestión
de redes denominado FCAPS que comprende varias áreas conceptuales identificadas por
sus siglas. Estas son: Gestión de Fallas (Fault Management), Gestión de Configuración
(Configuration Management), Gestión de Contabilidad (Accounting Management), Gestión
de Rendimiento (Performance Management) y Gestión de Seguridad (Security
Management). (Mauro and Schmidt, 2005)
Es aquí precisamente donde SNMP juega un papel protagónico, pues se ha convertido en el

lenguaje estándar para el intercambio de información de gestión, siendo implementado en
prácticamente todo el equipamiento para redes de todo tipo. Ser capaz de aplicar los
conceptos de la Gestión de Redes es tan importante como aprender SNMP. Algunas
cuestiones importantes en el despliegue de los sistemas de gestión aparecen en el Anexo
IV. (Mauro and Schmidt, 2005)
2.2.1.1 Gestión de Fallas
El objetivo es identificar, aislar, resolver y registrar fallas del sistema. Dicta los siguientes
pasos para la resolución de fallas:
1. Aislar el problema empleando herramientas para determinar síntomas.

2. Resolver el problema.
3. Registrar el proceso utilizado para detectar y resolver el problema.
2.2.1.2 Gestión de Configuración
Su objetivo es monitorear la red y controlar la configuración de los sistemas involucrados

de manera que puedan seguirse y administrar los elementos de software y hardware que
operan en la red.
30
2.2.1.3 Gestión de Contabilidad
Consiste en minimizar problemas en la red dividiendo los recursos de acuerdo a su

capacidad. Asegura su utilización justa por todos los grupos que tienen acceso.
2.2.1.4 Gestión de Rendimiento
Se encarga de medir y reportar aspectos relacionados con el rendimiento del sistema o red.
Los pasos involucrados en esta tarea son:
1. Recolección de la información de rendimiento.

2. Niveles de línea base se estiman basados en el análisis de los datos recopilados.
3. Se establecen umbrales de rendimiento. Cuando son excedidos indican un problema
que requiere atención.
2.2.1.5 Gestión de Seguridad
Tiene un objetivo doble. Primero, controlar el acceso a los recursos de la red, y segundo,
detectar y prevenir ataques que comprometan el funcionamiento de la red. Los ataques
contra las redes pueden llevar a la suspensión del servicio, y aún peor, otorgar acceso a
sistemas vitales dentro de estas.
La gestión de seguridad abarca además la seguridad física, como el acceso físico a los
dispositivos y sistemas de vigilancia, para asegurar que sólo el personal autorizado tenga
acceso a los sistemas vulnerables. Hoy en día la gestión de seguridad se lleva a cabo
mediante el uso de herramientas diseñadas específicamente para este propósito, e incluye:
Cortafuegos (Firewalls)
Sistemas de Detección de Intrusión (IDS)
Sistemas de Prevención de Intrusión (IPS)
Sistemas Antivirus
Sistemas de Cumplimiento y Administración de Políticas
2.2.2 Gestión en Redes DOCSIS
Los requerimientos para la gestión en redes DOCSIS se definen en la Especificación de la

Interfaz del Sistema de Soporte de Operaciones. Según (Cable Television Laboratories,
31
2008a) la gestión de las redes DOCSIS se realiza de acuerdo a las cinco categorías
conceptuales desarrolladas como parte de la recomendación ITU-T M.3400, que se refiere
al modelo FCAPS. En DOCSIS 3.0 los requerimientos de gestión acentúan la necesidad de
mantenimiento proactivo, análisis de tráfico y dimensionamiento de los servicios, para
minimizar las condiciones de fallas críticas.
Para las redes de este tipo, los elementos de red son los CMs y el CMTS. La tabla 2.3
resume las características de gestión DOCSIS y el área funcional de gestión a la que se
subordina.
Tabla 2.3. Áreas funcionales FCAPS en DOCSIS 3.0

Área Elemento
Característica Descripción
Funcional de Red
Múltiples canales de
Configurar puertos físicos que soportan
downstream y upstream Configuración CMTS
múltiples transmisores/receptores.
por puerto
Establecer arreglos flexibles de canales US/DS
Topología de Planta Configuración CMTS para la configuración del puenteo de canales
para reflejar la topología de la planta HFC.
Registro detallado de condiciones asociadas al
registro y estado de los CMs que pudiesen
Diagnóstico mejorado Fallas CMTS
indicar problemas que afectan la disponibilidad
del servicio.
Se implementa IPDR para la transmisión de
Recolección Mejorada de
Rendimiento CMTS información de estado de los CMs con menos
Datos de Rendimiento
impacto en los recursos del CMTS.
Provee información acerca del ingress de
Monitoreo Mejorado de
Rendimiento CMTS banda estrecha y la distorsión que afectan la
Calidad de Señal
calidad de las señales de RF.
Facturación basada en
Contabilidad CMTS Especificación de SAMIS.
uso
Configuración,
Fallas, CM
Seguridad Mejorada Características de Seguridad de DOCSIS 3.0.
Rendimiento, CMTS
Seguridad
Configuración,
CM
IPv6 Fallas, Soporte de IPv6.
CMTS
Rendimiento
Configuración,
CM Establecimiento de grupos de canales para
Puenteo de Canales Fallas,
CMTS realizar el puenteo US/DS.
Rendimiento
Configuración,
CM Nuevas capacidades de multidifusión como
Multidifusión IP Fallas,
CMTS SSM, IGMP v3, MLD v1 y v2.
Rendimiento
La gestión de fallas se centra mayormente en un registro extendido de los eventos

detallados ocurridos y en las herramientas de diagnóstico que permiten la detección de la
operación inestable de los CMs, ejemplo: repetición de intentos de registro. La gestión de
configuración tiene que ver con adicionar, inicializar, mantener y actualizar los elementos
32
de la red. Monitorea el estado de configuración cuando la red está operativa y hace cambios
en respuesta a alguna función de gestión. Determina la interacción entre el CMTS y los
CMs mediante el archivo de configuración de los CMs y a través de mensajes MAC,
operando así con dos tipos de parámetros fundamentales: recursos físicos y objetos lógicos.
Por su parte para la gestión de contabilidad se define una Especificación de Interfaz de
Gestión de Contabilidad del Suscriptor (SAMIS) que garantiza este proceso de una manera
uniforme y consistente, y utiliza el protocolo IPDR/SP para la transmisión eficiente y
confiable de la información de contabilidad.
La gestión de rendimiento se dedica a la recolección de métricas de rendimiento, análisis de

estas y al establecimiento de umbrales y límites de tasas, para la determinación de la salud
de la red y el cumplimiento de los acuerdos de nivel de servicio, como la información de
estado de los CMs, estadísticas de QoS y monitoreo de calidad de señal. Finalmente la
gestión de seguridad se encarga tanto de la identificación y autorización de usuarios y
equipos que intenten acceder a la red como de la seguridad de la información.
2.2.2.1 Protocolos de gestión
DOCSIS define SNMP v1, v2c y v3 como el protocolo de comunicación a emplear para la
gestión de la red, que se basa en encuestas e incluye notificaciones para informar fallas.
Asimismo no lo considera adecuado a largo plazo para obtener la creciente y más detallada
información que brinda el CMTS. Un protocolo de streaming desarrollado por la
organización IPDR se introdujo para ofrecer un mecanismo eficiente para la transferencia
de estadísticas voluminosas de un CMTS mediante una corriente continua orientada a la
conexión (TCP). Inicialmente se utilizaba solamente para la gestión de contabilidad, pero
DOCSIS 3.0 lo extiende a otras áreas de gestión como rendimiento y monitoreo para ganar
en reducción de recursos computacionales necesarios en el CMTS en comparación con
SNMP.
2.2.2.2 Gestión de un CMTS
Para gestionar un Sistema de Terminación de Cable Módems se deben utilizar, según

especificación, un Gestor SNMP, un Servidor Syslog y un Recolector IPDR, aunque no son
imprescindibles para el funcionamiento de este y de la red. En el CMTS en cuestión, como
33
en muchos otros, la guía de software del fabricante permite configurar y monitorear el

CMTS a través de la CLI del sistema operativo embebido, siendo esta la manera más
rudimentaria de gestión.
De cualquier forma, para respaldar el protocolo fundamental de gestión de DOCSIS,

SNMP, el CMTS incluye las MIBs estándar de la IETF y otras específicas para redes HFC
en general, y DOCSIS en particular. Estas se listan en la tabla 2.4.
Tabla 2.4. MIBs establecidas en DOCSIS 3.0 para un CMTS

Referencia Descripción Módulo MIB MIB
DOCSIS Interface Extension 2 DOCS-IFEXT2-MIB
CableLabs Topology CLAB-TOPO-MIB
DOCSIS Diagnostic Log DOCS-DIAG-MIB
DOCSIS Interface 3 DOCS-IF3-MIB
DOCSIS Multicast DOCS-MCAST-MIB
Borradores y Otros DOCSIS Multicast Authorization DOCS-MCAST-AUTH-MIB
DOCSIS Quality of Service 3 DOCS-QOS3-MIB
DOCSIS Security DOCS-SEC-MIB
DOCSIS Subscriber Management 3 DOCS-SUBMGT3-MIB
DOCSIS Load Balancing 3 DOCS-LOADBAL3-MIB
DOCSIS DRF DOCS-DRF-MIB
RFC 2786 Diffie-Helman USM Key SNMP-USM-DH-OBJECTS-MIB
RFC 2790 Host Resources HOST-RESOURCES-MIB
RFC 2863 Interfaces Group IF-MIB
RFC 2933 Internet Group Management Protocol IGMP-STD-MIB
RFC 3083 DOCSIS Baseline Privacy DOCS-BPI-MIB
RFC 3410 SNMP-FRAMEWORK-MIB
RFC 3411 SNMP-MPD-MIB
RFC 3412 SNMPNOTIFICATION-MIB
RFC 3413 SNMP-TARGET-MIB
RFC 3414 SNMP-USERBASED-SM-MIB
RFC 3415 SNMP-VIEW-BASED-ACM-MIB
RFC 3584 SNMPCOMMUNITY-MIB
IETF RFCs RFC 3418 SNMPv2 SNMPv2-MIB
RFC 3433 Entity Sensor ENTITY-SENSOR-MIB
RFC 3635 Ethernet Interface EtherLike-MIB
RFC 4022 Transmission Control Protocol TCP-MIB
RFC 4113 User Datagram Protocol UDP-MIB
RFC 4131 DOCSIS Baseline Privacy Plus DOCS-IETF-BPI2-MIB
RFC 4133 Entity ENTITY-MIB
RFC 4188 Bridge BRIDGE-MIB
RFC 4293 Internet Protocol IP-MIB
RFC 4546 DOCSIS RF DOCS-IF-MIB
RFC 4639 DOCSIS Device DOCS-CABLE-DEVICE-MIB
RFC 5519 Multicast Group Membership Discovery MGMD-STD-MIB
En este trabajo se emplea SNMP pues es el que más se implementa en las herramientas de
diseño de aplicaciones, y es el que más nivel de desarrollo y fiabilidad tiene en estos
equipos. De cualquier forma se recomienda el estudio y análisis de IPDR/SP por las
prometedoras capacidades que parece brindar.
34
2.2.2.3 Principales parámetros de gestión en una red DOCSIS
La gestión de una red DOCSIS puede abarcar tanto como se desee pues se sustenta sobre
una gran cantidad de parámetros, protocolos y recursos. Muchas veces no se hace factible
gestionar todo lo que es realmente posible, por lo que se define un subgrupo de objetos
gestionables a los que se les da mayor relevancia.
Interfaces
Contempla todas las interfaces del equipamiento. Las más importantes son las del CMTS,
que incluyen las interfaces Ethernet, Gigabit Ethernet y las de RF, siendo estas últimas las
fundamentales, pues establecen el comportamiento espectral de la interfaz. Sus parámetros
más importantes son:
Frecuencia central
Ancho de banda del canal
Potencia de Transmisión
Tipo de Modulación
Utilización
Calidad de Señal
La calidad de señal es crucial en canales compartidos que sufren interferencia y ruido. Tal
es el caso de los canales upstream, que son muy sensibles a estas agresiones por sus
características de banda de frecuencias y técnicas de acceso al medio. El estado de la
comunicación se monitorea atendiendo a parámetros y comportamientos que pueden
localizar fallas en caso de existir. Estos parámetros son esencialmente:
Tasa de pérdida de paquetes

Control de los temporizadores T1, T2, T3, T4 y T5.2
Niveles de ruido en el espectro de operación
2
T1: el CM no recibe un UCD en cinco intervalos de UCD.
T2: el CM no recibe un permiso de transmisión MAP de difusión en cinco intervalos de ranging.
T3: el CM no recibe un RNG-RSP del CMTS 200ms después de enviar un RNG-REQ.
T4: el CM no recibe un permiso de transmisión MAP en 30s.
T5: el CMTS no recibe una respuesta de Cambio de Canal de Upstream en 2s.
35
Niveles de microreflexiones
Cable Módems
Al ser uno de los dos dispositivos terminales principales, es objetivo del servicio
mantenerlos en operación y disponibles. De ahí que sea muy importante supervisarlos
constantemente y mantener cierto control sobre ellos. Los CMs aportan información útil en
el diagnóstico del canal de comunicaciones, que es utilizada por el CMTS y el supervisor
para el ajuste de otros parámetros.
Parámetros que brindan los CMs:
Potencia de transmisión
SNR
Información de estado de operación
Contadores de control
Corrección de errores en paquetes
Tráfico
2.2.2.4 Dimensionamiento y Capacidad
Las limitantes en el despliegue de redes DOCSIS están dadas por las características
intrínsecas de cada sentido de la transmisión. Así, se recomienda tener en cuenta dos
números importantes:
Máxima cantidad de CMs por downstream: dictado por las velocidades de

descarga de peor caso que el cliente quiere tolerar para el pico de la hora activa.
(Usualmente por debajo de 1000)
Máxima cantidad de CMs por receptor upstream: dictado por el ruido en el canal
de retorno, SNR y control del nivel de colisiones. (Usualmente por debajo de 200)
Se recomienda fuertemente al proveedor que la cantidad de CMs por puerto de upstream se

mantenga razonable. Un canal DOCSIS de upstream es un canal de comunicación de
acceso múltiple por tiempo basado en contenciones alineadas, y no es deseable que el nivel
de contención en un canal sea tan alto que cause excesiva multiplicidad de colisiones que
además causen efectos de clipping en los láseres de la red HFC, y grandes retardos y
36
tiempos de recuperación para los CMs. De cualquier forma cada servicio es diferente y el
proveedor debe determinar, basándose en técnicas de ingeniería de tráfico y en
características propias de su red, el número apropiado de CMs que puede conectar a cada
módulo, aclarándose siempre que determinar el número apropiado de CMs por
upstream/downstream se vuelve más subjetivo a medida que se tienen en cuenta mayor
cantidad de factores.
2.2.2.5 ¿Cómo implementar un software de Gestión para un CMTS DOCSIS?
La implementación de cualquier software, demanda primeramente, una plataforma de

desarrollo de aplicaciones, o más simplemente, un lenguaje de programación que permita
crear una aplicación. Dado que la gestión del equipamiento DOCSIS, por especificación,
define a SNMP como protocolo de gestión, debe desarrollarse un software que sea capaz de
comunicarse con la red a través de este protocolo, por lo que la plataforma de desarrollo
debe ser capaz de interactuar de esta forma.
Ya que la idea es aligerar lo más posible las operaciones en el agente, el núcleo de la

inteligencia en la gestión de un CMTS debe moverse a dicha aplicación, y de ahí la
importancia de la misma. El software de gestión deberá cumplir entonces dos objetivos
fundamentales: uno, ser capaz de obtener información del agente, procesarla, analizarla e
interactuar con este con el objetivo de lograr la mayor eficiencia posible en la prestación
del servicio, y el otro, ofrecer una interfaz más amigable que logre una administración del
equipo tan robusta como sea posible así como procedimientos fáciles para realizar la tarea.
2.3 ¿Por qué Delphi?
Delphi es un entorno de desarrollo de software diseñado para la programación de propósito

general con énfasis en la programación visual y basado en el lenguaje Pascal. Cuenta con
un potente Ambiente de Desarrollo Integrado (IDE) formado por un editor de formularios
(que permite el desarrollo visual al estilo Windows de manera muy sencilla), un potente
editor de textos que resalta la sintaxis del código fuente, una cargada paleta con gran
cantidad de componentes de todo tipo y un robusto depurador integrado.
Adiciona muchas características para realizar fácilmente aquellas tareas que

tradicionalmente tomaban mucho tiempo, permitiendo al programador concentrarse más en
37
lo que quiere hacer y menos en cómo hacerlo, haciéndolo más fácil para aquellos cuya
razón de estudio no es la programación. El estudio del lenguaje en la enseñanza previa
unido a la simplicidad de Delphi lo hace propicio para su participación en entornos
académicos, especialmente en el desarrollo de aplicaciones para la resolución inmediata de
problemas. Entonces ¿por qué Delphi?:
Conocimiento previo del lenguaje.

Calidad del ambiente de desarrollo visual.
Rapidez del compilador vs. la eficiencia del código compilado.
Potencia del lenguaje de programación vs. su complejidad.
Flexibilidad y escalabilidad de la arquitectura de bases de datos.(Teixeira and
Pacheco, 2002)
2.3.1 Delphi de Delfos
El nombre Delphi hace referencia al oráculo de Delfos. Borland3 eligió ese nombre para
resaltar su principal mejora con respecto a su antecesor (Turbo Pascal), que sería su
conectividad con bases de datos Oracle (oráculo, en inglés).
2.3.2 Delphi de Borland
Fue producido comercialmente por la empresa estadounidense Borland Software

Corporation, posteriormente por CodeGear, escición de Borland con objetivos financieros,
quien a su vez fue adquirida en mayo de 2008 por Embarcadero Technologies, una empresa
del grupo Thoma Cressey Bravo, en una suma que ronda los 30 millones de dólares. En sus
diferentes variantes, permite producir archivos ejecutables para Windows, GNU/Linux y la
plataforma .NET. (Embarcadero Technologies, 2010)
Fue la primera herramienta de desarrollo para Windows que combinó un ambiente de

desarrollo visual, un compilador optimizado de código nativo y un motor de acceso a bases
de datos escalable, definiendo así la frase: Rapid Application Development (RAD). El
corazón de Delphi es el lenguaje Delphi Pascal, basado en Object Pascal (o Pascal
orientado a objetos), y tiene todo el poder de un lenguaje moderno orientado a objetos y la
3
de la Compañía Borland International, después Borland Software Corporation.
38
elegancia y simplicidad de Pascal. Pascal se convirtió en un estándar ISO en 1983 con

Turbo Pascal de Borland International escrito por Anders Hejlsberg. (Lischner, 2000)
Delphi cuenta con clases y objetos, manipulación de excepciones, programación multihilos

(multithreaded programming), programación modular, enlace estático y dinámico,
automatización OLE, entre otros. Es un lenguaje de programación modular, y el módulo
básico se denomina Unit.
2.3.2.1 Programación modular
Las Units son los módulos de código fuente individuales que conforman un programa de
Pascal, comúnmente archivos .pas. Es el lugar donde se agrupan funciones y
procedimientos que pueden ser llamados desde el programa principal. Para compilar y
enlazar un programa, se necesita un archivo de fuente de programa y cualquier número de
units adicionales en forma de fuente u objeto.
Algunas units representan formularios o forms, término de Delphi para nombrar una
ventana que se puede editar con su constructor gráfico, cuya descripción se almacena en un
archivo .dfm que contiene información sobre su aparencia, contenido, propiedades y la unit
asociada.(Lischner, 2000)
2.3.2.2 Paquetes y Componentes
Los paquetes en Delphi permiten colocar porciones de un programa en módulos separados,

los cuales pueden ser compartidos entre múltiples aplicaciones. Véase entonces un paquete
como una colección de units almacenadas en un módulo, conocido como Biblioteca de
Paquete o .bpl. De esta forma la aplicación puede después enlazarse con esas units
empaquetadas en tiempo de ejecución disminuyendo el tamaño de los .exe
generados.(Teixeira and Pacheco, 2002)
Los paquetes son también utilizados para cargar componentes, formularios personalizados
y otras units de tiempo de diseño. Los componentes son básicamente objetos que se utilizan
para realizar determinadas operaciones dentro de un programa y cuyos procedimientos,
funciones y propiedades se almacenan en una unit. Las units de estos componentes
igualmente se enlazan estáticamente incluyéndolas en el .exe o dinámicamente enlazando al
paquete que las contiene.(Lischner, 2000)
39
2.3.3 Borland Delphi 7
Borland Delphi 7 realizó mejoras para soportar nuevas tecnologías, como Windows XP,
pero más importante aún, agregó nuevas e interesantes herramientas de terceros: Motor de
reportes RAVE, tecnología de desarrollo para aplicaciones web IntraWeb y el ambiente de
diseño ModelMaker, así como soporte para aplicaciones .NET. Finalmente abrió el camino
a un nuevo mundo proveyendo el primer compilador de Borland para el lenguaje
Delphi/Pascal que no apunta a procesadores Intel.
Figura 2.5. Borland Delphi 7 y su IDE.
La aplicación objeto del presente trabajo se desarrolló en Borland Delphi 7 como se

muestra en la figura 2.5, aprovechando sus características como potente herramienta de
desarrollo rápido de aplicaciones y los componentes para SNMP que se obtuvieron.
2.3.3.1 SNMP en Borland Delphi 7
En la instalación básica de Borland Delphi 7 se incluye un paquete de componentes

conocidos como Indy, que provee objetos para operaciones con varios protocolos de red,
entre ellos SNMP. Estos componentes son conocidos en Internet como los
“indocumentados Indy”, cuyo Indy SNMP, además, reportó algunos fallos en la lectura de
tablas en pruebas realizadas. En sitios de publicación de componentes de código abierto
para Delphi, se encontró un componente para SNMP incluido en una biblioteca
denominada Synapse. Este incluye procedimientos básicos para la lectura y escritura de
objetos SNMP, así como funciones de conversión y tratamiento de los valores obtenidos.
40
Posee además un procedimiento para la lectura de tablas que mostró gran fiabilidad. Por
tales razones se escogió dicho componente para la interacción con el CMTS en la obtención
y modificación de valores de los objetos MIB.
A pesar de no ser un componente visual, brinda muchas facilidades para su uso, pues
implementa todas las funciones SNMPv1 en una unit de la que simplemente se invocan las
funciones y procedimientos tales como peticiones GetRequest y GetNextRequest y
devuelve directamente el resultado de la petición en una variable.
2.3.3.2 La librería Synapse
La librería Synapse debe su nombre a Synchronous Socket Library y es el resultado de un

proyecto conocido como Ararat Synapse. Provee clases y funciones que simplifican
marcadamente la programación de aplicaciones de comunicaciones de red utilizando
Winsock. Ofrece abiertamente todos los códigos y tiene derechos de copia reservados a
nombre de Lukas Gebauer de República Checa, desarrollador inicial del código original,
que permiten la redistribución de estos con o sin modificación siempre que no se utilice su
nombre o los modificadores para endorsar o promover productos derivados de la aplicación
de estos componentes.(Gebauer, 2002)
La última versión es la Release nº 39 con fecha 9/10/2009 y se encuentra en

http://www.synapse.ararat.cz/doku.php, que es la empleada en este trabajo. El paquete
incluye ejemplos así como código fuente para operar con los siguientes protocolos: DNS,
FTP, TFTP, HTTP, IMAP, NTP, ICMP, POP3, SYSLOG, SMTP, SNMP y SNTP.
Implementa completamente la versión 1 de SNMP, y parcialmente la v2c y la 3.
2.3.3.3 Bases de datos
Trabajar con información implica inevitablemente operar con bases de datos, no por ley
sino por utilidad. Almacenar y procesar información son actividades que facilitan el trabajo
en labores complejas, y la gestión no está fuera de ello. Delphi incluye más de 40
componentes para bases de datos y provee un ambiente de programación visual que incluye
Módulos de Datos (Data Modules), contenedor diseñado para colocar componentes de base
de datos y compartirlos entre múltiples formularios. Entre estos grupos de componentes se
41
destaca ADO (ActiveX Data Objects), que ofrece un esquema simple para la conexión y el
acceso a datos de gran variedad de tipos de bases de datos. (Pablo, 2002)
Con componentes tan simples como Tablas y Consultas SQL, realiza operaciones
complejas de una manera sencilla, permitiendo enlazar grandes conjuntos de información y
mostrar resultados de relaciones que no se obtienen directamente de la fuente. Tal es el caso
de la información que brinda un CMTS sobre los CMs conectados y la que pueden ofrecer
los propios CMs, que mediante SNMP tendrían naturaleza independiente, pero que pueden
agruparse y mostrarse como un gran conjunto coherente de datos. Por estas razones se
escogió el modelo ADO para operar con las bases de datos de CMTS-Manager, el software
producido en el presente trabajo, que se detallará a continuación.
2.4 CMTS-Manager, el producto
Figura 2.6. Splash de CMTS-Manager.
CMTS-Manager es el nombre del software elaborado en el presente trabajo y opera en tres

direcciones fundamentales: la primera, la utilización de SNMP como protocolo de
comunicación para el intercambio de datos con el CMTS, la segunda, el empleo de bases de
datos para el almacenamiento y procesado de datos, y la tercera, el auxilio de mecanismos
de análisis y relacionales para la realización de las diferentes áreas de gestión.
Básicamente funciona como un intérprete que se auxilia de mecanismos que permiten

transformar los datos en información útil y manejable, de manera que el operador del
sistema pueda decidir cómo actuar y que el resultado se aproxime tanto como sea posible a
lo esperado. La figura 2.6 muestra el splash de CMTS-Manager, que aparece en pantalla al
ejecutar la aplicación. La figura 2.7 describe la arquitectura general del software.
42
Figura 2.7. Arquitectura de CMTS-Manager.
CMTS-Manager está diseñado para que se esté ejecutando permanentemente, en aras de

satisfacer la necesidad de una gestión proactiva, por lo que se ha dotado de determinada
autonomía referida esencialmente al manejo dinámico de la memoria del sistema y a la
puesta a punto de las bases de datos que permanecen abiertas durante su ejecución.
2.4.1 Módulos y Áreas de gestión
El software opera en las cinco áreas de gestión contempladas en el modelo ISO FCAPS,
concentrando el mayor esfuerzo en la gestión de Fallas, Configuración y Rendimiento. Para
realizar estas actividades, CMTS-Manager cuenta con una serie de módulos que se dedican
a cada una de dichas áreas, descritos a continuación mediante el Lenguaje de Modelado
Unificado (UML), ampliamente difundido para promover la comunicación precisa y
efectiva acerca de la naturaleza de los sistemas en todos sus aspectos.(Chonoles and
Schardt, 2003)
2.4.1.1 Módulo de Gestión de Fallas
El módulo de Gestión de Fallas se encarga del reporte detallado y en tiempo real de las
notificaciones recibidas por el CMTS, las cuales se archivan por etiquetas de tiempo,
permitiendo la confección de reportes históricos. Cuenta con un subsistema de alarmas para
el chequeo de objetos SNMP, con el fin de dar seguimiento a parámetros de interés en el
tiempo, y permite el manejo de la Flap-List, lista implementada en CMTSs DOCSIS para
las estadísticas de aquellos módems que más incurren en determinados fallos. Para ello se
auxilia de temporizadores que chuequean, cada cierto intervalo de tiempo, los objetos
43
correspondientes. En la figura 2.8 se muestra el diagrama UML correspondiente a este

módulo.
Figura 2.8. Diagrama UML para la Gestión de Fallas.
El diagrama anterior se manifiesta en:
Ventana Principal
Ventana Alarmas
Ventana Logs
Ventana Flap-List
2.4.1.2 Módulo de Gestión de Configuración
El módulo de Gestión de Configuración por su parte administra los parámetros de las

interfaces de downstream y upstream, como son frecuencia central, ancho de banda del
canal, y tipo de modulación por citar los principales. Opera también con parámetros
específicos de CMTSs como la configuración de los servidores de provisionamiento y los
intervalos de mensajes de sincronismo y control, donde estos últimos son propios de cada
interfaz MAC del CMTS. La figura 2.9 muestra el esquema de este módulo.
44
Figura 2.9. Diagrama UML para la Gestión de Configuración.
Ventana Canales Downstream/Upstream
Ventana Interfaces
Ventana Interfaces MAC
Ventana Parámetros del CMTS
2.4.1.3 Módulo de Gestión de Rendimiento
El módulo de Gestión de Rendimiento agrupa las operaciones de monitoreo. Aquí se

consulta el estado de los CMs conectados al CMTS, atendiendo tanto a la información que
lleva el CMTS de los mismos como a la que portan estos que no se almacena en el CMTS.
También provee información sobre la operación de todas las interfaces de RF, haciendo un
seguimiento de su utilización y de las características del tráfico que cursan.
Posee además un pequeño subsistema de mediciones de niveles de ruido en el canal de

retorno que puede habilitarse o no, y que almacena estos valores de modo que pueden
realizarse análisis sobre el comportamiento de estos niveles en el tiempo. Finalmente
permite la obtención de algunos otros parámetros como las microreflexiones, que ofrece
una buena idea, por ejemplo, de las condiciones de acople de impedancias en que se
encuentra la red. La figura 2.10 representa este módulo en el lenguaje de modelado UML.
45
Figura 2.10. Diagrama UML para la Gestión de Rendimiento.
Ventana Estado de los CMs
Ventana Calidad de Señal
Ventana Utilización de Canales
Ventana Monitoreo del CMTS
2.4.1.4 Módulo de Gestión de Contabilidad
El módulo de Gestión de Contabilidad básicamente se encarga de reportar la Gestión de

Rendimiento en el tiempo. Esto es, que guarda evidencias del funcionamiento de algunos
dispositivos a medida que se van leyendo sus parámetros por las operaciones de Gestión de
Rendimiento. De esta forma, la Gestión de Contabilidad que se implementa en la aplicación
objeto es, esencialmente, un mecanismo de consultas a la información almacenada en las
bases de datos.
Se incorpora además a esta área de gestión la información de Topología de la Red, que no

es más que un inventario de los dispositivos conectados al CMTS que refleja la ubicación
de estos en la región que cubre la red HFC. Así, solamente la parte de Topología necesita
interactuar directamente con las funciones SNMP. El diagrama UML para esta área de
gestión se muestra en la figura 2.11.
46
Figura 2.11. Diagrama UML para la Gestión de Contabilidad.

Ventana Histórico de los CMs
Ventana Histórico de Niveles de Ruido
Ventana Histórico de Utilización de Canales
Ventana Topología de la Red
2.4.1.5 Módulo de Gestión de Seguridad
Finalmente el módulo de Gestión de Seguridad se ha implementado con un mínimo de

funciones, pues sólo administra el acceso al Sistema de Gestión de Red. Esto se refiere a
que sólo contempla el control de los usuarios que acceden a las operaciones de gestión
dentro de la aplicación, así como sus privilegios y el registro detallado de la operaciones
más importantes que realizan mientras están autenticados, por lo que la Gestión de
Seguridad se subordina directamente a la Opciones de Configuraciones de CMTS-Manager.
El diagrama UML para esta área de gestión se muestra en la figura 2.12.
Figura 2.12. Diagrama UML para la Gestión de Seguridad.

Ventana Trazas de Operaciones
Ventana Opciones de Configuraciones
o Pestaña: Control de Acceso
47
2.4.1.6 Otros Módulos
CMTS-Manager también cuenta con otros módulos a fin de facilitar otras actividades
relativamente independientes de la gestión, pero no menos importantes. Tal es el caso del
Módulo de Ayuda, que implementa básicamente la Guía de Usuario de la aplicación, donde
se recoge detalladamente la función de cada elemento del programa. Constituye además
material de consulta valioso para ayudar en las labores de gestión con SNMP, incorporando
una descripción completa de los objetos de las MIBs estándares para aprovechar la
flexibilidad que brindan algunas operaciones, y algunas informaciones acerca de las labores
de gestión en general.
También se incorpora un Módulo de Obtención de OIDs que permite comunicarse via

SNMP con cualquier host, implementando operaciones de lectura y escritura, y soporte
para la lectura de tablas. Este módulo permite interactuar con cualquier objeto
implementado en la MIB del agente host por la simple introducción de su OID, lo que
permite explorar y encuestar otros datos que la aplicación en esta primera versión no
abarca, o simplemente recorrer las MIBs de otros dispositivos conectados a la red.
Partiendo de las características generales de un CMTS y conociendo sobre qué se puede

operar y cómo hacerlo, es posible a partir de herramientas de desarrollo de aplicaciones
crear un software que responda a las operaciones básicas de gestión para redes DOCSIS, las
cuales, al dividirse en categorías con funciones específicas definidas según el estándar ISO
FCAPS, facilitan la confección de dicho programa mediante su división en Módulos que
agrupan tareas comunes.
Para generar la información útil, cada módulo emplea un grupo de tablas de bases de datos
en las que se recolectan los datos que ofrecen los dispositivos. De esta forma el
desarrollador tiene la libertad de decidir cómo y con qué relacionar y/o analizar esos datos
para obtener simplemente la información necesaria en la atención a determinado proceso de
determinada área de gestión, aportando elementos para incurrir en alguna acción específica,
que igualmente, permite realizar la aplicación.
48
CAPÍTULO 3. GESTIONANDO CON CMTS-Manager
La gestión no es un proceso que se lleva a cabo por los módulos de la aplicación. La

gestión la realiza un operador que se auxilia de la aplicación de gestión para organizar y
controlar la operación de la red.
Realizar actividades de gestión DOCSIS demanda un fuerte conocimiento previo de la

operación de este protocolo. Así la inteligencia real en la administración del CMTS como
núcleo de la red recae sobre el sujeto, mientras las funciones de transformación, análisis,
procesado, almacenamiento y modificación de datos e información son realizadas por el
objeto, en este caso CMTS-Manager, aunque bajo ciertas condiciones se pudiera dotar al
software a cierta inteligencia para actuar ante determinados cambios.
De esta manera la gestión con esta aplicación se puede describir mediante casos de uso.
Exponer todos los casos de uso para el programa es prácticamente imposible, por lo que se
tratará un caso para cada tipo de gestión representando situaciones reales típicas que se han
enfrentado.
3.1 Casos de uso
Los casos de uso no son más que operaciones que puede realizar un actor, en este caso el
operador de la red, y que se definen por un propósito y una serie de condiciones iniciales. A
continuación se muestra una selección breve de algunas de las actividades comunes a las
que se enfrenta un operador de una red de cable DOCSIS que CMTS-Manager pretende
auxiliar.
49
3.1.1 Caso de uso 1: Estadísticas de alarmas
Varias irregularidades se aprecian en la ocurrencia de determinadas alarmas, por lo que el

operador necesita conocer con qué frecuencia ocurren, en aras de determinar si son hechos
aislados o forman parte de un problema mayor.
Obtener estas estadísticas es tarea fácil mediante la ventana de estadísticas de alarmas del
subsistema de gestión de alarmas. Sea la alarma A la encargada del chequeo de la cantidad
de módems de cable en estado de ranging, que tiene un primer umbral en 5 y un segundo
umbral en 10, el chequeo de la alarma se realiza como muestra la figura 3.1:
Figura 3.1. Menú Fallas  Alarmas  Estadísticas de Alarmas.
Luego se selecciona la alarma A y se añade a la lista de la consulta, se selecciona la fecha

que se quiere consultar y se Ejecuta la consulta. Inmediatamente se muestra en el cuadro
Resumen las ocurrencias de la misma, y en el cuadro Detalles las especificidades de las
ocurrencias. Asimismo se muestra a la derecha las gráficas de estos datos. Este
procedimiento se describe en la figura 3.2.
50
Figura 3.2. Estadísticas para alarma A.
3.1.2 Caso de uso 2: Configuración de canal de Upstream
Se presenta un problema con un canal de upstream, que después de cierto análisis, se

determina que se debe a la presencia excesiva de ruido en el canal que opera. El operador
desea entonces cambiarlo de frecuencia.
Sea el canal 1/0 de upstream del CMTS el canal en cuestión con frecuencia central en 11.4
MHz, se desea moverlo a 17.8 MHz. Para esto se procede como se aprecia en la figura
siguiente:
51
Figura 3.3. Menú Configuración  Canales Downstream/Upstream <Ctrl+D> 

Pestaña Upstream.
Se selecciona el canal, se da click en Editar, se escribe el nuevo valor de frecuencia en Hz,

17800000 en este caso y se procede a Aceptar el cambio. De realizarse físicamente el
cambio, la nueva frecuencia aparecerá en la tabla.
Figura 3.4. Cambio de frecuencia en el canal US 1/0.

52
3.1.3 Caso de uso 3: Estado de los Modems de Cable
El operador desea observar el estado de los CMs conectados al CMTS y observar algunos
parámetros de rutina. Además está interesado en un CM que varias veces se ha atascado en
un estado conocido como RNG-RSP Completado [init(r1)], que muchas veces se resuelve
con un RESET. Siguiendo los siguientes pasos, como se muestra en la figura 3.5, se llega al
estado de los CMs:
Figura 3.5. Menú Rendimiento  Estado de los CMs <Ctrl+M>.
Se da click en el botón Obtener Datos y casualmente el mismo CM se encuentra

nuevamente en ese estado, en el que había reincidido una semana atrás. De esta forma se
selecciona dicho CM, y se le propicia un RESET en el botón cuyo ícono tiene un cero en un
cuadro rojo.
Pasado un tiempo se actualiza el estado mediante el botón Obtener Datos y se aprecia que
el CM ya se encuentra operacional.
53
Figura 3.6. Estado de los CMs.
3.1.4 Caso de uso 4: Mediciones espectrales
Es objetivo de la supervisión chequear el estado de los canales de upstream dada la

sensibilidad que presentan ante el ruido y la interferencia. Para esto se incluye el monitoreo
en tiempo real de las mediciones efectuadas por el CMTS a todos los canales de upstream
en 10 frecuencias. En un caso donde el operador desee observar las mediciones de los
niveles de ruido en los canales de retorno, como aparece en la figura siguiente, simplemente
deberá ir a:
54
Figura 3.7. Menú Rendimiento  Calidad de señal <Ctrl+S>.
A la derecha se muestran los controles de habilitación del muestreo. A la izquierda se van

observando las mediciones, y en la parte inferior se aprecian controles de consulta, que
basado en el lenguaje SQL permite encuestar los datos para la obtención de información
útil para, principalmente, el mantenimiento de la red. Así, por ejemplo, se pudiese solicitar
el promedio de nivel de ruido para el canal de upstream 1/2 en cada frecuencia dos días
atrás. Esto se logra según la imagen:
Figura 3.8. Consulta a las mediciones de los niveles de ruido en los canales US.
55
3.1.5 Caso de uso 5: Disminuir el tráfico de control
En el chequeo del tráfico en la red, sobresale, dado además por la baja presencia de otros
servicios, el tráfico de control DOCSIS. A modo de experimento, se desea comprobar la
influencia de la disminución de los mensajes UCD que se envían desde el CMTS hacia la
red, que según especificaciones es importante para el ingreso o la recuperación de los CMs
fuera de servicio. Dado que el control sobre este tipo de mensajes se establece mediante el
parámetro intervalo de mensajes UCD, se desea disminuir tanto como sea posible la
emisión de estos mensajes. Para esto se procede como se muestra en la figura 3.9:
Figura 3.9. Menú Configuración  Interfaces MAC.
Aquí se muestra una ventana con las interfaces MAC del CMTS, que son interfaces en las
que se agrupan canales de US y DS. Se procede a leer del CMTS la configuración actual a
través del botón Obtener, luego se prosigue a Modificar, se aumenta al máximo el intervalo
de estos mensajes, que sería 2000, y se hace click en Aplicar. Esta secuencia se muestra a
continuación.
56
Figura 3.10. Modificación del intervalo de mensajes UCD.
Inmediatamente el CMTS pasa a difundir los mensajes UCD cada 2 segundos,

disminuyendo considerablemente la presencia de estos circulando por la red, que no son
particularmente necesarios cuando la mayoría de los CM se encuentran operacionales.
3.1.6 Caso de uso 6: Restablecer una alarma
Es una de las operaciones más sencillas. Consiste en atender la alarma cuyo indicador en la
ventana principal, en el panel de alarmas en la parte inferior derecha, está en rojo.
Figura 3.11. Ventana principal con una indicación de alarma.

57
Cuando el operador finalmente resuelve el problema, o quiere estar pendiente nuevamente

ante la ocurrencia de la alarma, simplemente con un click derecho sobre el indicador este
pasa a su estado normal, en verde. Esto emite igualmente un reporte de alarma restablecida
en el panel de alarmas, para archivar su ocurrencia en una base histórica.
Figura 3.12. Procedimiento de restablecimiento de una alarma.
3.2 Qué ha permitido CMTS-Manager
Primeramente, y muy importante en los servicios de comunicaciones, CMTS-Manager ha

contribuido al mantenimiento de la disponibilidad del servicio, donde el factor tiempo para
la resolución de fallas es crucial, máxime cuando, de no realizar el chequeo de las alarmas
por software no hay evidencias físicas del estado de la comunicación.
La interfaz gráfica amigable permite realizar actividades de administración y

mantenimiento del CMTS y la red de cable de una forma sencilla, a través de un esquema
de bases de datos que permite la modificación de valores mientras los va visualizando,
totalmente diferente a lo que permite la CLI.
Realiza además un monitoreo exhaustivo de la operación de la red y el funcionamiento del

CMTS, fundamental en la previsión y evasión de fallas mediante el chequeo de objetos de
estado y tendencias de parámetros.
58
La recolección de estadísticas de operación ofrece al operador la posibilidad de evaluar la

red en determinado momento, e incluso, determinar patrones de comportamiento en largos
períodos de tiempo, lo que permite además estimar la respuesta de la red a determinados
cambios estacionales.
Puede apreciarse de esta forma la necesidad que puede tener un software de este tipo, pero
existe un aspecto importante que no se puede obviar cuando se trata de implementar uno de
ellos, el costo.
CMTS-Manager se concentra en amenizar la interacción con el CMTS en la realización de

las actividades de gestión. Cuenta con una barra de menús donde se llega rápidamente a las
facilidades que implementa en cada área de gestión y los paneles de la ventana principal
permiten ir observando los mensajes que el CMTS envía durante su operación. Se destaca
por la recolección de estadísticas de operación de los dispositivos, permitiendo al operador
encuestar estos grandes volúmenes de datos para obtener información valiosa en la
administración de la red DOCSIS.
De esta manera queda muy claro que sí es necesario un software de Gestión cuando se
necesita optimizar estas labores, especialmente cuando una GUI da la posibilidad de
obtener información y realizar modificaciones en las configuraciones de forma fácil y sobre
todo rápida, de una manera eficiente y efectiva.
59
CONCLUSIONES Y RECOMENDACIONES
Conclusiones
El estudio del estándar DOCSIS permite conocer una alternativa para la diversificación de
los servicios de telecomunicaciones, y lograr además competitividad y grandes ahorros.
Con el aumento de la complejidad de las redes se hace más necesario la gestión y
administración eficiente de los recursos, más cuando los protocolos de gestión de redes han
demostrado su capacidad en el mundo IP, y sus limitantes han llevado al desarrollo de
nuevos protocolos, como IPDR/SP. Una aplicación especializada en la gestión y el
monitoreo permite influir proactivamente en la calidad y disponibilidad de un servicio de
telecomunicaciones, y puede decirse que las herramientas de desarrollo de software dan la
posibilidad de crear aplicaciones a la medida y que respondan a intereses concretos
sorteando las dificultades que el mercado impone. CMTS-Manager provee de una
herramienta importante al proveedor de servicios de cable que lo utilice, contribuyendo, en
Cuba, al desarrollo tecnológico de servicios tan importantes para la estimulación del
turismo, incorporando nuevas facilidades que son indispensables hoy en día para ganarse
un lugar de preferencia entre los destinos turísticos competentes.
Recomendaciones
Se recomienda el desarrollo de la aplicación para incorporar otras actividades de gestión

igualmente importantes que no se han implementado. Asimismo se recomienda el estudio
nuevos protocolos de gestión como IPDR/SP para valorar la sustitución de SNMP y la
puesta en explotación del software en otros ambientes para determinar su capacidad de
generalización y puntos de vulnerabilidad no cubiertos.
60
ABREVIACIONES Y ACRÓNIMOS
ACL Access Control List – Lista de Control de Acceso
ADO ActiveX Data Objects – Objetos de Datos ActiveX
AES Advanced Encryption System
All-coaxial cable networks Redes completamente de coaxial
ARP Address Resolution Protocol – Protocolo de Resolución de Direcciones
ASN.1 Abstract Syntax Notation – Notación Sintáctica Abstracta
ATM Asynchronous Transfer Mode – Modo de Transferencia Asincrónico
BER Basic Encoding Rules – Reglas de Codificación Básica
BGP Border Gateway Protocol – Protocolo de Pasarela de Borde
Broadband Servicios de Banda ancha
CATV Community Antenna TeleVision System, Cable TeleVision System –

Sistema de Televisión por Cable
Channel bonding Puenteo de Canales
CLI Command Line Interface – Interfaz de Línea de Comandos
CM Cable Modem – Módem de Cable
CMTS Cable Modem Termination System – Sistema de Terminación de

Módems de Cable
CPE Customer Premises Equipment – Equipo de Premisas del Cliente

61
CSO Composite Second Order distorsion – Distorsión Compuesta de

Segundo Orden, también conocido como Batido de Segundo Orden
CTB Composite Triple Beat – Distorsión Compuesta de Tercer Orden,

también conocido como Triple Batido Compuesto
CWDM Coarse Wavelength Division Multiplexing – Multiplexado por División

en Longitudes de Onda Ligeras
DAVIC Digital Audio Visual Council - Consejo de Audio y Video Digital
DCU DOCSIS Control and Upstream Module – Módulo de Upstream y

Control DOCSIS
DDR Double Data Rate – Doble Tasa de Transferencia de Datos
DEPI Downstream External Physical Interface – Interfaz Física de

Downstream Externo
DHCP Dynamic Host Configuration Protocol – Protocolo Dínamico de

Configuración de Host
Dirección MAC Dirección Física de una Tarjeta de Interfaz a la Red
DOCSIS Data Over Cable Service Interface Specification – Especificación de la

Interfaz de Servicio para Datos sobre Cable
Downstream Canal descendente, canal de descarga, canal de bajada
DQM DOCSIS QAM Module – Módulo QAM DOCSIS
DS Downstream
DSL Digital Subscriber Line – Línea de Suscriptor Digital
DTI DOCSIS Timing Interface – Interfaz de Temporización DOCSIS
DVB Digital Video Broadcasting – Difusión de Vídeo Digital (Norma)
DVB-RCC Digital Video Broadcasting-Return Channel for Cable – Difusión de

Video Digital con Canal de Retorno para Cable
edge QAM Modulador QAM de borde
EuroDOCSIS Versión de DOCSIS para Europa

62
FDMA Frequency Division Multiple Access – Acceso Múltiple por División de

Frecuencias
GbE Gigabit Ethernet
GUI Graphic User Interface – Interfaz Gráfica de Usuario
Headend Cabecera
HFC Hybrid Fiber Coax Networks – Redes Híbridas de Fibra y Coaxial
IAB Internet Activities Board – Junta de Actividades de Internet
IANA Internet Assigned Numbers Authority – Autoridad de Números

Asignados para Internet
IDE Integrated Development Environment – Ambiente de Desarrollo

Integrado
IDS Intrusion Detection Systems. – Sistemas de Detección de Intrusión
IETF Internet Engineering Task Force – Fuerza de Tareas para la Ingeniería

de Internet
Ingress Señales no deseadas que ingresan al sistema de cable a través de cables

poco apantallados o mediante otros dispositivos conectados a la red de
cable.
IP Internet Protocol – Protocolo de Internet
IPDR/SP IP Detail Record Streaming Protocol – Protocolo de Streaming para

Registros Detallados del Protocolo de Internet
IPS Intrusion Prevention Systems – Sistemas de Prevención de Intrusión
IPTV Internet Protocol Television – Televisión IP
IPv4 Internet Protocol version 4 – Protocolo de Internet versión 4
IPv6 Internet Protocol version 6 – Protocolo de Internet versión 6
IS-IS Intermediate System to Intermediate System Routing Protocol –

Protocolo de Enrutamiento Sistema Intermedio a Sistema Intermedio
63
ISO International Organization for Standarization – Organización

Internacional para la Estandarización
MAC Media Access Control Layer – Capa de Control de Acceso al Medio
MAP Media Access Protocol – Protocolo de Acceso al Medio
MCNS Multimedia Cable Network System – Sistema de Red Multimedia de

Cable
MIB Management Information Base – Base de Información de Gestión
MIPS Microprocessor without Interlocked Pipeline Stages – Microprocesador

sin Etapas de Pipeline Entrelazadas
MMH Multilinear Modular Hashing – Hashing Modular Multilínea
MPEG Motion Pictures Expert Group – Grupo de Expertos para Imágenes en

Movimiento
MSO Multiple Service Operators – Operadores de Múltiples Servicios (video,

voz y datos)
NMS Network Management System – Sistema de Gestión de Red
NSI Network Side Interface – Interfaz del Lado de la Red
NTSC National Television System Comitee – Comité del Sistema Nacional de

Televisión. Es la norma de televisión de Norteamérica.
OID Object Identifier – Identificador de Objeto
OLE Object Linking and Embedding – Incrustación y Enlazado de Objetos,

nombre de un sistema de objetos distribuido y un protocolo desarrollado
por Microsoft
OSI Open Systems Interconnection Reference Model – Modelo de

Referencia para la Interconexión de Sistemas Abiertos
OSPF Open Shortest Path First Protocol – Protocolo de Camino más Corto
PAL Phase Alternation Line – Línea de Alternación de Fase. Es la norma de

televisión de Europa.
64
PAT En tramas MPEG, Program Association Table – Tabla de Asociación

de Programas
PCR En tramas MPEG, Program Clock Reference – Referencia de Reloj de

Programas
PDU Protocol Data Unit – Unidad de Datos de Protocolo
PHY Physical Layer – Capa Física
PID En tramas MPEG, Packet IDentifier – Identificador de Paquete
PIM-SM Protocol Independent Multicast in Sparse Mode – Multidifusión

Independiente del Protocolo en Modo Esparcido
PMT En tramas MPEG, Program Multiplex Table – Tabla de Multiplexado

de Programas
PPV Pay per View – Servicios de Pago por Ver
PSI En tramas MPEG, Program Specific Information – Información

Específica de Programa
QAM Quadrature Amplitude Modulation – Modulación por Amplitud en

Cuadratura
QoS Quality of Service – Calidad de Servicio
QPSK Quadrature Phase Shift Keying – Desplazamiento de Fase en

Cuadratura
RAD Rapid Application Development – Desarrollo Rápido de Aplicaciones
RFC RequestForComments – Petición para Comentarios
RIP Routing Information Protocol – Protocolo de Información de

Enrutamiento
RU Rack Unit – Unidad de Rack
SAMIS Subscriber Accounting Management Interface Specification –

Especificación de la Interfaz de Gestión de Contabilidad del Suscriptor
65
S-CDMA Synchronous Code Division Multiple Access – Acceso Múltiple por

División de Código Sincrónico
SFP Small Form-Factor Pluggable
SID Service IDentifier – Identificador de Servicio
SMI Structure of Management Information – Estructura de la Información de

Gestión
SNMP Simple Network Management Protocol – Protocolo Simple de Gestión

de Redes
SNR Signal to Noise Ratio – Razón Señal a Ruido
SoC System-on-a-Chip – Sistema en un chip
TCM Trellis Code Modulation – Modulación con Codificación de Trellis
TCP Transmission Control Protocol – Protocolo de Control de la

Transmisión
TDMA Time Division Multiple Access – Acceso Múltiple por División de

Tiempo
TFTP Trivial File Transfer Protocol – Protocolo Trivial de Transferencia de

Archivos
timing offset correción de tiempo
TLV Type Length Value Codification – Codificación Tipo Longitud Valor
ToD Time of Day Protocol – Protocolo de Tiempo
two-way services Servicios bidireccionales de datos
U:D Razón canales Upstream a canales Downstream
UCD Upstream Channel Descriptor – Descriptor de Canal Upstream
UDP User Datagram Protocol – Protocolo de Datagrama de Usuario
UML Unified Modeling Language – Lenguaje de Modelado Unificado
Upstream Canal ascendente, canal de subida, canal de retorno

66
US Upstream
VCL Visual Component Library – Biblioteca de Componentes Visuales
VLAN Virtual Local Area Network – Red Virtual de Área Local
VOD Video on Demand – Video a Demanda
VoIP Voice over Internet Protocol – Voz sobre IP
XMOD Cross Modulation Distorsion – Distorsión de Modulación Cruzada
XOD Services on Demand – Servicios a Demanda

67
REFERENCIAS BIBLIOGRÁFICAS
ADER, J. & CLOONAN, T. 2007. Thomas Wiesel Partners DOCSIS® 3.0 Tutorial. ARRIS
Group, Inc.
BINKLEY, J. 2005. SNMP SMI Structure of Management Information. Network
Mgmt/Sec.
BLUMENTHAL, U. & WIJNEN, B. 2002. User-based Security Model (USM) for version
3 of the Simple Network Management Protocol (SNMPv3). RFC 3414. Internet
Engineering Task Force.
CABLE EUROPE LABS 2009. Overview of Architecture, Technical Features and Services
of Integrated Broadband and Cable TV Networks. Cable Network Handbook.
Bruselas, Bélgica: Cable Europe®.
CABLE TELEVISION LABORATORIES, I. 2008a. DOCSIS 3.0 OSSI Configuration
Management. Data-Over-Cable Service Interface Specifications ed. USA.
CABLE TELEVISION LABORATORIES, I. 2008b. DOCSIS Timing Interface
Specification. Data Over Cable Service Interface Specifications DOCSIS 3.0 ed.
USA.
CABLE TELEVISION LABORATORIES, I. 2008c. Downstream External PHY Interface
Specification. Data Over Cable Service Interface Specifications DOCSIS 3.0 ed.
USA.
CABLE TELEVISION LABORATORIES, I. 2008d. Downstream Radio Frequency
Interface Specification. Data Over Cable Service Interface Specifications DOCSIS
3.0 ed. USA.
CABLE TELEVISION LABORATORIES, I. 2010. Physical Layer Specification. Data
Over Cable Service Interface Specifications DOCSIS 3.0 ed. USA.
CABLE TELEVISION LABORATORIES, I. 2011. MAC and Upper Layer Protocols
Interface Specification. Data Over Cable Service Interface Specifications DOCSIS
3.0 ed. USA.
CARCAMO, C. 2009. Instalación CMTS. www.tripleplay.mx/support/instalacion-cmts.pdf.
CASE, J., FEDOR, M., SCHOFFSTALL, M. & DAVIN, J. 1990. A Simple Network
Management Protocol (SNMP). RFC 1157. Internet Engineering Task Force.
68
CASE, J., HARRINGTON, D., PRESUHN, R. & WIJNEN, B. 2002a. Message Processing
and Dispatching for the Simple Network Management Protocol (SNMP). RFC
3412. Internet Engineering Task Force.
CASE, J., MUNDY, R., PARTAIN, D. & STEWART, B. 2002b. Introduction and
Applicability Statements for Internet Standard Management Framework. RFC 3410.
Internet Engineering Task Force.
CHONOLES, M. J. & SCHARDT, J. A. 2003. UML 2 for Dummies. New York, USA:
Wiley Publishing, Inc.
CMTS SYSTEMS 2011. CMTS datasheet.
CMTS SYSTEMS, I. 2007. CMTS Hardware Guide.
CMTS SYSTEMS, I. 2010. CMTS Software Configuration Guide.
DOWNEY, J. J. 2006. DOCSIS 3.0 Overview. Cisco Systems, Inc.
EMBARCADERO TECHNOLOGIES 2010. Borland Delphi - Embarcadero Delphi.,
http://es.wikipedia.org/w/index.php?title=Borland_Delphi&redirect=no.
FENNER, B. & FLICK, J. 2005. Management Information Base for the User Datagram
Protocol (UDP). RFC 4113. Internet Engineering Task Force.
FRYE, R., LEVI, D., ROUTHIER, S. & WIJNEN, B. 2000. Coexistence between Version
1, Version 2, and Version 3 of the Internet-standard Network Management
Framework. RFC 2576. Internet Engineering Task Force.
GEBAUER, L. 2002. Synchronous Socket Library SYNAPSE License.
GREEN, J. H. 2002. Access Technologies: DSL and Cable. Executive Briefings in Key
Technologies. USA: McGraw-Hill Companies, Inc.
HARRINGTON, D., PRESUHN, R. & WIJNEN, B. 2002. An Architecture for Describing
Simple Network Management Protocol (SNMP) Management Frameworks. RFC
HILMERSSON, C. 2006. Network investigation using SNMP. Master, Universidad de
Umea.
LEVI, D., MEYER, P. & STEWART, B. 2002. Simple Network Management Protocol
(SNMP) Applications. RFC 3413. Internet Engineering Task Force.
LISCHNER, R. 2000. Delphi in a Nutshell. A Desktop Quick Reference., USA, O'Reilly &
Associates, Inc.
MAURO, D. & SCHMIDT, K. 2005. Essential SNMP. 2da ed. USA: O'Reilly.
MCCLOGHRIE, K., PERKINS, D. & SCHOENWAELDER, J. 1999. Structure of
Management Information Version 2 (SMIv2). RFC 2578. Internet Engineering Task
Force.
MCCLOGHRIE, K. & ROSE, M. 1991. Management Information Base for Network
Management of TCP/IP-based internets: MIB-II. RFC 1213. Internet Engineering
Task Force.
69
MILLER, M. A. 2004. Managing Internetworks with SNMP. 2da ed. USA: IDG Books
Worldwide, Inc.
MIPS TECHNOLOGIES INC. 2009. MIPS64 Architecture.
http://www.mips.com/products/architectures/mips64/.
PABLO, Z. 2002. Using ADO from Delphi. Access Database from Delphi.
PARZIALE, L., BRITT, D. T., DAVIS, C., FORRESTER, J., LIU, W., MATTHEWS, C.
& ROSSELOT, N. 2006. RedBooks. TCP/IP Tutorial and Technical Overview. 8va
ed. New York, USA: International Bussines Machines Corporation.
PICI, L. G. 2007. Introduction to Cable Television. USA.
POSTEL, J. 1980. User Datagram Protocol. RFC 768. Internet Engineering Task Force.
PRESUHN, R., CASE, J., MCCLOGHRIE, K., ROSE, M. & WALDBUSSER, S. 2002a.
Management Information Base (MIB) for the Simple Network Management
Protocol (SNMP). RFC 3418. Internet Engineering Task Force.
PRESUHN, R., CASE, J., MCCLOGHRIE, K., ROSE, M. & WALDBUSSER, S. 2002b.
Transport Mappings for the Simple Network Management Protocol (SNMP). RFC
PRESUHN, R., CASE, J., MCCLOGHRIE, K., ROSE, M. & WALDBUSSER, S. 2002c.
Version 2 of the Protocol Operations for the Simple Network Management Protocol
(SNMP). RFC 3416. Internet Engineering Task Force.
RAGHUNARAYAN, R. 2005. Management Information Base for the Transmission
Control Protocol (TCP). RFC 4022. Internet Engineering Task Force.
RAMOS, E., RODRÍGUEZ, A. & SANTA, I. 2011. HFC DOCSIS.
REYNOLDS, J. & POSTEL, J. 1994. Assigned Numbers. RFC 1700. Internet Engineering
Task Force.
ROSE, M. & MCCLOGHRIE, K. 1990. Structure and Identification of Management
Information for TCP/IP-based Internets. RFC 1155. Internet Engineering Task
Force.
ROUTHIER, S. 2006. Management Information Base for the Internet Protocol (IP). RFC
SHAH, N., KOUVATSOS, D., MARTIN, J. & MOSER, S. 2006. A Tutorial on DOCSIS:
Protocol and Performance Models. University of Bradford, UK & Clemson
University, USA.
STEVENS, W. R. 2001. TCP/IP Illustrated. 5ta ed. Tucson, Arizona, USA: Addison
Wesley.
SUMMIT PARTNERS 2010. Summit Partners Makes Growth Equity Investment in CMTS
Systems. Summit Partners News & Perspectives.
TEIXEIRA, S. & PACHECO, X. 2002. Borland® Delphi 6 Developer's Guide, USA, Sams
Publishing.
70
TOOLEY, M. & BOWMAN, D. 2010. An overview of the DOCSIS (Cable Internet)

Platform. Sandvine® Intelligent Broadband Networks, 6-12.
VECIMA NETWORKS 2008. M-CMTS & DOCSIS 3.0 Standards Overview. Vecima
Networks.
VOLPE, B. 2009. DOCSIS Tutorial Series. bradyvolpe.com.
VOLPE, B. 2010. CMTS Architecture: I-CMTS vs. M-CMTS. bradyvolpe.com, Junio 21,
2010.
WIJNEN, B., PRESUHN, R. & MCCLOGHRIE, K. 2002. View-based Access Control
Model (VACM) for the Simple Network Management Protocol (SNMP). RFC
71
ANEXOS
Anexo I Especificaciones DOCSIS 3.0
Todas las especificaciones de la serie DOCSIS 3.0 se encuentran publicadas en

http://www.cablemodem.com.
Tabla I.1. Especificaciones de DOCSIS 3.0

Nombre Descripción
CM-SP-PHYv3.0 Physical Layer Specification
CM-SP-MULPIv3.0 Media Access Control (MAC) and Upper Layer Protocols Interface
Specification
CM-SP-OSSIv3.0 Operations Support System Interface Specification
CM-SP-SECv3.0 Security Specification
CM-SP-CMCIv3.0 Cable Modem CPE Interface Specification
Tabla I.2. Especificaciones relacionadas con DOCSIS 3.0

Nombre Descripción
CM-SP-eDOCSIS eDOCSIS™ Specification
CM-SP-CMCI Cable Modem CPE Interface Specification
CM-SP-DRFI Downstream Radio Frequency Interface Specification
CM-SP-DTI DOCSIS Timing Interface Specification
CM-SP-DEPI Downstream External PHY Interface Specification
CM-SP-DSG DOCSIS Set-Top Gateway Interface Specification
CM-SP-ERMI Edge Resource Manager Interface Specification
CM-SP-M-OSSI M-CMTS Operations Support System Interface Specification
CM-SP-L2VPN Layer 2 Virtual Private Networks Specification
CM-SP-TEI TDM Emulation Interfaces Specification
ANEXOS
72
Anexo II Modelos de Referencia OSI de la ISO y TCP/IP
Modelo de Referencia OSI
Figura II.5. Modelo de Referencia OSI.
El Modelo de Referencia OSI (Open Systems Interconnect) ISO 7498 define un modelo de
comunicaciones de datos de siete capas con el transporte físico en la capa más baja y los
protocolos de aplicación en la cima. Este modelo es ampliamente aceptado como la base para la
comprensión de cómo la pila de protocolos de una red debe operar y como herramienta de
referencia en la comparación de las implementaciones de redes.
Cada capa proporciona un conjunto de funciones a la capa superior y, en cambio, recae en las
funciones proporcionadas por la capa inferior. Aunque los mensajes pueden solo pasar
verticalmente a través de la pila de capa a capa, desde un punto de vista lógico, cada capa se
comunica directamente con su par en otros nodos.
Las siete capas son:
Aplicación: Aplicaciones de red como emulación de terminales y transferencia de

ficheros.
Presentación: Formato y representación (sintaxis) de los datos y encriptación.
Sesión: Control de la comunicación, establecimiento y mantenimiento de sesiones.

ANEXOS
73
Transporte: Provisión de entrega punto-a-punto confiable y no confiable y control de flujo.
Red: Maneja las conexiones y entrega de paquetes incluyendo enrutamiento.
Enlace de datos: Entramado de unidades de información, sincronización y chequeo de errores.
Física: Transmisión de bits en el hardware físico. Tiene que ver con las características
procesales, funcionales, eléctricas y mecánicas para acceder al medio físico.
En contraste a TCP/IP, OSI comenzó de cero y definió estándares, adhiriéndose fuertemente a su

propio modelo, empleando un proceso formal sin requerimiento de implementaciones. Los
protocolos de interconexión (IP) utilizan un acercamiento ingenieril menos formal, donde
cualquiera puede proponer y comentar en Peticiones para Comentarios conocidas como RFC, y
requieren implementaciones para validar la factibilidad. Los protocolos OSI se desarrollaron
lentamente, y debido a que correr la pila completa de protocolos necesita muchos recursos, no
han sido ampliamente implementados, especialmente en el mercado de las computadoras
pequeñas y de escritorio. Mientras tanto TCP/IP e Internet se fueron desarrollando rápidamente,
con una tasa de despliegue muy grande.
Modelo TCP/IP
Figura II.2. Modelo TCP/IP. (hacer la figura similar a la anterior OSI)
TCP/IP es igualmente un modelo por capas, pero en cambio sólo posee cuatro. Estas incluyen:
Aplicación: Proporcionada por el programa que utiliza TCP/IP para la comunicación. Una
aplicación es un proceso del usuario que coopera con otro proceso usualmente
un host diferente. Ejemplo: Telnet y FTP (File Transfer Protocol ó Protoco de
ANEXOS
74
Transferencia de Ficheros). La interfaz entre las capas de Transporte y

Aplicación es definida por números de puertos y sockets.
Transporte: Provee transferencia de datos punto-a-punto mediante la entrega de datos de

una aplicación a su par remoto. Soporta múltiples aplicaciones
simultáneamente. El protocolo de transporte más utilizado es TCP
(Transmisión Control Protocol ó Protocolo de Control de la Transmisión),
que es orientado a la conexión y permite entrega de datos confiable, supresión
de información duplicada, control de la congestión y control de flujo. Otro
protocolo es el Protocolo de Datagrama de Usuario (UDP – User Datagram
Protocol) que en cambio no es orientado a la conexión y brinda servicio no
confiable y de mejor esfuerzo, utilizado usualmente por aplicaciones que
necesitan mecanismos de transporte rápido y pueden tolerar la pérdida de
alguna información.
Interconexión: También conocida como Capa de Internet o Capa de Red, proporciona la

imagen de una “red virtual” de Internet. Separa los niveles superiores de la
arquitectura de red física debajo de estos. El Protocolo de Internet (IP –
Internet Protocol) es el más importante en esta capa, y no provee
confiabilidad, control de flujo ni recuperación de errores, funciones que se
deben proporcionar a niveles superiores. IP ofrece una función de
enrutamiento que intenta entregar los mensajes transmitidos a su destino. El
mensaje IP en una red se conoce como datagrama, y es la unidad básica de
información en redes TCP/IP. Otros protocolos de Interconexión son ICMP,
IGMP, ARP y RARP.
Interfaz a la red: También llamada Capa de Enlace, es la interfaz al hardware de red. Puede o
no proveer entrega confiable y puede ser orientada a paquetes o corrientes.
TCP/IP no especifica ningún protocolo para esta capa, pero puede utilizar casi
cualquier interfaz disponible lo que muestra su flexibilidad. Ejemplos: IEEE
802.2, X.25 (confiable), ATM y otros.
ANEXOS
75
Las especificaciones TCP/IP no describen o estandarizan ningún protocolo de red en sí, sólo
estandarizan la forma de acceder a ellos desde la capa de interconexión.
Figura II.3. Modelo detallado de la arquitectura TCP/IP.
La siguiente figura ilustra las arquitecturas TCP/IP y OSI, mostrando a grandes rasgos la
correspondencia de funcionalidades de las dos. La figura también sugiere medios comunes de la
implementación de varias capas. (Parziale et al., 2006)
Figura II.4. Arquitecturas de TCP/IP y OSI y algunas implementaciones.

ANEXOS
76
Anexo III Especificaciones técnicas del CMTS.
Tabla III.1. Características clave.

Características Descripción
Chasis 1-RU (unidad de rack), de rack estándar de 19 pulgadas.
4 x GbE Tráfico máximo Ethernet: 4 x 1000 Mbps
8 – 48 moduladores QAM Modo QAM:
Anexo A: 8 MHz
Anexo B: 6 MHz
Anexo C: 6 MHz
Constelaciones QAM:
Anexo A: 64, 128, 256
Anexo B: 64, 256
Anexo C: 64, 128, 256
8 – 32 receptores de ráfagas de Cada receptor puede ser configurado con muchos canales lógicos
upstream de upstream
16 – 32 puertos de RF Cada puerto QAM porta cuatro canales QAM.
Cada puerto de upstream porta varios canales lógicos.
Conector: F
Cable recomendado: 75 Ohm RG-6
LEDs del panel frontal Estado del sistema, estado del puerto de gestión, estado GbE,
estado de canal QAM y estado de canal upstream.
LEDS del panel trasero Estado de los puertos de RF.
1 Fast Ethernet Tráfico máximo Ethernet: 100 Mbps
Conector: RJ45
1 RS-232 Tasa serial máxima: 115 kbps
Conector: D-Sub 9
Tabla III.2. Especificaciones técnicas básicas.

Características Valor
Físicas
Dimensiones Alto: 1.75” / 44.4 mm
Ancho: 19” / 482 mm
Profundidad: 23.5” / 597 mm
Estándar de montaje 1 RU de 19”
Peso 30 lbs / 13 kg. (Completamente cargado)
Eléctricas
Alimentación AC Voltaje: 100 – 240 VAC
Frecuencia: 50 – 60 Hz
Corriente: 5 A máx. a 100 VAC
Conector: IEC 320 conector estándar, 10 A máx.
Alimentación DC 370 W típico
Voltaje: -40 a -60 VDC
Corriente: 10 A máx.
ANEXOS
77
Ambientales
Temperatura Operación: 0 a 50 ºC
Almacenamiento: -40 a 70 ºC
Humedad relativa Operación: 5 a 95%
Almacenamiento: 5 a 95%
Altura Operación: del nivel del mar a 2000 m
Almacenamiento: del nivel del mar a 4800 m
Tabla III.3. LEDs del panel frontal.

LED Color Estado Descripción
Sistema Verde Encendido El chasis está encendido y operacional.
Apagado El chasis está apagado o fue incapaz de encender
normalmente.
Módulo 0 – 3 Bi-color Verde No se ha detectado condición de error en el módulo de
aplicación correspondiente.
Amarillo Se ha detectado una condición de error en el módulo de
aplicación correspondiente.
Apagado No hay módulo de aplicación correspondiente instalado.
Enlace Verde Encendido El enlace 10/100BT-TX FE está operativo.
Fast Ethernet Apagado El enlace 10/100BT-TX FE está caído.
Actividad Verde Encendido Hay actividad en el enlace 10/100BT-TX FE.
Fast Ethernet Apagado No hay actividad en el enlace 10/100BT-TX FE.
Enlace Verde Encendido Indicador de estado del enlace GbE.
GbE 0 – 3 Apagado Puerto GbE correspondiente no está conectado.
Actividad Verde Encendido Indicador de actividad del enlace GbE.
GbE 0 – 3 Apagado No se detecta actividad en el puerto GbE correspondiente.
Tabla III.4. LEDs QAM RF del panel trasero.

LED Color Estado Descripción
RF 0 – 3 Bi-color Verde Salida de RF alimentada y habilitada.
Amarillo Salida de RF alimentada pero deshabilitada.
Apagado Salida de RF muerta.
Aterramiento
La versión alimentada con AC se aterra mediante el conductor de tierra en el cordón de

alimentación. La versión alimentada con DC proporciona una conexión de tierra separada en la
parte frontal del chasis.
Tabla III.5. Especificaciones técnicas.

Características Descripción
Sistema Capacidad de conmutación: 12 x 2 Gbps.
Conmutación MPEG de cualquier puerto a cualquier puerto.
Gestión mediante SNMP y CLI.
ANEXOS
78
Ranuras de interfaces: 4.
Módulos de downstream: 1 – 3.
Módulos de upstream: 1 – 3.
DOCSIS DOCSIS 3.0 Downstream channel bonding: hasta 16 canales.
DOCSIS 3.0 Upstream channel bonding: hasta 8 canales.
Firmware actualizable a encriptación AES e IPv6.
Soporte completo de DOCSIS 1.1 y DOCSIS 2.0.
Balance de carga.
Gestión espectral.
IP Relay de DHCP y opción 82.
Múltiples servidores DHCP.
Proxy ARP.
Enrutamiento de subredes IP.
Enrutamiento IP estático.
Snooping de IGMP. IGMP v2 y v3.
Múltiples rutas predefinidas.
Lista de control de acceso.
Procesamiento de Remultiplexación MPEG
tramas MPEG Conversión Unicast a Multicast.
Extracción y regeneración de PAT y PMT.
Remapeo y filtrado de PID.
Supresión de jitter PCR y remarcado.
Generación e inserción de tabla SI.
DVB Simulcrypt.
Encriptación basada en sesiones.
Gestión Puerto serie RS-232 (DB9)
Puerto de Gestión 10/100 BaseT
Interfaz de Línea de Comandos (CLI).
Telnet
SNMP v1, v2c y v3.
MIBs estándares de DOCSIS & IETF.
IPDR
Registro de eventos Syslog.
Notificación por correo electrónico.
Reporte de utilización de recursos.
Interfaces GbE Cuatro puertos de cobre o fibra SFP.
Módulos QAM de Número de puertos: 4.
Downstream Número de canales: 4, 8 ó 16.
(DQM) Constelaciones QAM: 64, 128 & 256 QAM.
Conector: F, 75 Ohm.
Rango de Frecuencias: 48 – 999 MHz.
Tamaño del paso de frecuencia: 5 kHz
Ancho del canal: 6 u 8 MHz.
Potencia máx. salida: 61 dBmV @ 1-ch por puerto
56 dBmV @ 2-ch por puerto
52 dBmV @ 4-ch por puerto.
ANEXOS
79
Tamaño del paso de potencia: 0.1 dB.

Estabilidad de salida: ±0.3dB.
Pérdidas de retorno: 48 – 870 MHz, 14 dB
870 – 1002 MHz, 10 dB
Tasas de datos: Anexo A 36 Mbps @ 64 QAM
51 Mbps @ 256 QAM
Anexo B/C 27 Mbps @ 64 QAM.
Módulos de Control y Número de puertos: 4 u 8.
Upstream DOCSIS Número de canales por puerto: 1 ó 2.
(DCU) Modulación: QPSK, 8, 16, 32 & 64 QAM.
Tasa de datos por canal: 0.32 a 30.72 Mbps.
Rango de frecuencia: 5 a 42 MHz (DOCSIS)
5 a 65 MHz (EuroDOCSIS).
Conector: F, 75 Ohm.
Rango de potencia de entrada: -4 a 26 dBmV.
Conformidad ANSI/UL 60950-1 - UL Standard for Safety for Information Technology
Regulatoria Equipment Safety.
CAN/CSA C22.2 No. 60950-1 - Standard for Safety for Information
Technology Equipment Safety.
EN60950-1.
EN-55022, class A.
EN-55024.
FCC part 15, subpart B, class A.
ANEXOS
80
Anexo IV Aplicación de los Conceptos de la Gestión de Redes.
Para aplicar los conceptos de la gestión de redes se deben tener en cuenta algunos casos
para los cuales esta actividad deben tener un impacto apreciable. Estos son:
IV.1. Rentabilidad.
El esfuerzo de la gestión de redes involucra resolver problemas en el negocio al que se

subordina mediante una implementación de algún tipo. Un caso de este tipo se desarrolla
para entender el impacto de implementar algún tipo de tarea o función y la idea básica es
reducir costos e incrementar efectividad. Si la implementación no trae ahorros para la
compañía en la provisión de servicios más efectivos, prácticamente no hay necesidad de
implementar la solución dada.
IV.2. Niveles de Actividad.
Antes de administrar un servicio específico o dispositivo, se deben entender los cuatro

niveles posibles de actividad y decidir el apropiado:
Inactivo: No se realiza monitoreo, y si se recibe una alarma pudiera ignorarse.
Reactivo: No se realiza monitoreo, pero se reacciona ante la ocurrencia de un problema.
Interactivo: Se monitorean componentes pero se tienen que resolver los problemas

interactivamente para eliminar las alarmas colaterales y aislar la causa del
problema.
Proactivo: Se monitorean componentes, y el sistema proporciona alarmas de causas para

el problema en cuestión e inicia procesos de restauración automáticos siempre
que sea posible para minimizar el impacto en la prestación servicio.
IV.3. Reporte de Análisis de Tendencia.
La habilidad de monitorear un servicio o sistema proactivamente comienza con el análisis

de tendencia. En general, el objetivo de este tipo de análisis es identificar cuándo sistemas,
servicios, o redes están comenzando a alcanzar su máxima capacidad, con suficiente
antelación para hacer algo al respecto antes de que se convierta en un problema real para
los usuarios. Ejemplo: puede descubrir que se necesita añadir memoria al servidor de base
ANEXOS
81
de datos. Hacerlo antes de que se convierta en un problema puede ayudar a los usuarios a
evitar la frustración y posiblemente a mantenerlo a usted empleado.
IV.4. Reporte de Tiempos de Respuesta.
Estos reportes miden cómo varios aspectos de la red, incluyendo sistemas, se encuentran
funcionando en cuanto a sensibilidad.
IV.5. Correlación de Alarmas.
La correlación de alarmas trata con agrupar varias alertas y eventos en una única alerta o en
varios eventos que describen el problema real. Otro nombre para esto es Análisis de Causa
Fundamental. La idea es simple, pero tiende a dificultarse en la práctica. Por ejemplo,
cuando un servidor en su red se cae, y usted administra todos los dispositivos hasta el
servidor, pudiera obtener una serie de alertas incluyendo las de servidor caído, el switch
caído, o el router, dependiendo de dónde el fallo real se encuentra. Dígase que el router es
el verdadero problema, solo necesitaría saber que el router está caído. La clave en esta
situación es correlacionar el estado del servidor, el switch y el router en una alarma de
mayor nivel que indique que la raíz del problema es el router.
La alarma de mayor nivel puede obtenerse del análisis de todas las entidades y sus posibles
alarmas debido a la ocurrencia del fallo real. Enmascarar todas estas alarmas con una
alarma de mayor nivel, a menos que sea de interés observarlas todas, podría contribuir a la
eficiencia del personal de trabajo ante la solución de problemas. Notificar el
restablecimiento de las alarmas es también importante. Esta noción de transición de malo a
bueno ayuda a los operadores a conocer que algo está operacional nuevamente,
contribuyendo también al análisis de tendencia, ya que por ejemplo si un dispositivo está
constantemente inestable se querría investigar por qué.
IV.6. Resolución de Problemas.
Mensajes escuetos como “Router caído” no ayudan mucho. La clave está en tratar de
recopilar la suficiente información de alarmas y objetos de estado para proporcionar al
operador suficientes detalles para que pueda detectar y resolver el problema efectivamente.
(Mauro and Schmidt, 2005)

Alejandro León Rodríguez

Cargado por

Copyright:

Formatos disponibles

Alejandro León Rodríguez

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Alejandro León Rodríguez

Cargado por

Copyright:

Formatos disponibles

Universidad Central “Marta Abreu” de Las Villas

Facultad de Ingeniería Eléctrica

Software de Gestión para equipamiento CMTS en

Autor: Alejandro León Rodríguez

Tutor: Ing. Rolando Evelio Pérez Versón

Software de Gestión para equipamiento CMTS en

Autor: Alejandro León Rodríguez

Tutor: Ing. Rolando Evelio Pérez Versón

Consultante: MSc. Hiram del Castillo Sabido

Firma del Autor

Firma del Autor Firma del Jefe de Departamento

Firma del Responsable de

Si quieres mi fidelidad, dame algo bueno que defender.

A mi abuela que su corazón no cabe en su pecho. A Noemí, Eduardo, Claudia, Javier y

1. Estudio de los dispositivos CMTS y su modo de funcionamiento.

2. Elaboración del sistema de gestión.

3. Creación de la interfaz usuario-sistema.

4. Realización de pruebas en el terreno para ver los resultados del diseño y su

5. Puesta a punto del Sistema.

6. Evaluación de la efectividad de la propuesta en el entorno de red.

7. Confección del informe final.

Firma del Autor Firma del Tutor

1.4.2.1 Estructura de la Información de Gestión ................................................. 17

2.3.3 Borland Delphi 7 ............................................................................................. 39

transmisión de las señales de difusión terrestre, la transmisión de programación generada

Como resultado de un proceso de unificación de métodos y conceptos se cuenta hoy con

La realidad de hoy muestra un mercado de softwares de gestión para equipamiento

Organización del informe

En el CAPÍTULO 1 se describen las diferentes arquitecturas de redes de cable y los dos

Posteriormente aparecen las Conclusiones y Recomendaciones, y las Referencias

CAPÍTULO 1. ¿DATOS EN REDES DE TELEVISIÓN?

Debido a la novedad que esto representa, se abordarán primeramente las arquitecturas de

1.1 Arquitecturas de las redes de Televisión por Cable

El lugar donde se encuentran los equipos de recepción de señales, generadores de

Figura 1.2. Arquitectura de una red de cable bidireccional.

1.2 Redes HFC

La transmisión bidireccional en redes de sólo coaxial (all-coaxial cable networks)

Figura 1.3. Topología de una red HFC.

Las redes HFC son únicas en cuanto a:

1. Soportan la operación en dos sentidos sobre el mismo cable.

1.3 Transmisión de datos en redes CATV/HFC

1.3.1 Especificación DOCSIS

DOCSIS® es una marca registrada de CableLabs® (Cable Television Laboratories, Inc.),

Es además un estándar no comercial que dicta los requerimientos de una interfaz de

MHz, mientras que en Norte América es de 6 MHz. La primera versión de la especificación

Implementar DOCSIS implica la puesta en funcionamiento de un equipo denominado

Figura 1.4. Arquitectura de una red HFC con DOCSIS.

El Sistema de Provisionamiento se conforma de un conjunto de aplicaciones que

Servidores DHCP: proveen información de configuración inicial como la dirección

De manera similar, el Sistema de Gestión de la Red se compone de programas de aplicación

Gestor SNMP: permite al operador configurar y monitorear el equipamiento,

1.3.1.2 Características y Funcionamiento General

Downstream: Desde el CMTS hacia los CMs

Tabla 1.1. Velocidades para los canales de bajada de 6 MHz.

En el sentido descendente, DOCSIS emplea un sistema primero-que-llega primero-que-se-

Upstream: Desde los CMs hacia el CMTS

naturaleza de ráfaga de las transmisiones de subida y permite compartir un canal de RF de

Los tipos de modulación establecidos para los moduladores/demoduladores de upstream

Operación básica del protocolo

La configuración elemental de una red DOCSIS se muestra en la siguiente figura.