Comuniacion TETRA - PC

SOFTWARE DE COMUNICACIÓN ENTRE RADIOS TETRA Y
COMPUTADORES PERSONALES
DARIO FERNANDO CORTES TOBAR

JARDEN DE JESUS VEGA GOMEZ
UNIVERSIDAD AUTONOMA DE OCCIDENTE

FACULTAD DE INGENIERIA
DEPARTAMENTO DE AUTOMATICA Y ELECTRONICA
PROGRAMA DE INGENIERIA ELECTRONICA
SANTIAGO DE CALI
2008
1
SOFTWARE DE COMUNICACIÓN ENTRE RADIOS TETRA Y
COMPUTADORES PERSONALES
DARIO FERNANDO CORTES TOBAR

JARDEN DE JESUS VEGA GOMEZ
PASANTIA PARA OPTAR EL TITULO DE

INGENIERO ELECTRÓNICO
Director:
ZEIDA MARIA SOLARTE
Ingeniero Electrónico
UNIVERSIDAD AUTONOMA DE OCCIDENTE

FACULTAD DE INGENIERIA
DEPARTAMENTO DE AUTOMATICA Y ELECTRONICA
PROGRAMA DE INGENIERIA ELECTRONICA
SANTIAGO DE CALI
2008
2
Nota de aceptación:
Aprobado por el Comité de Grado

en cumplimiento de los requisitos
exigidos por la Universidad
Autónoma de Occidente para optar
al título de Ingeniero Electrónico.
Ing. ZEIDA MARIA SOLARTE

Directora
Ing. FERNANDO CARVAJAL

Jurado
Santiago de Cali, Junio 12 de 2008
3
AGRADECIMIENTOS
Nuestros más sinceros agradecimientos los profesores Ramiro Nogales y Lida

Peña Paz quienes nos han proporcionado invaluable asesoría y apoyo y con sus
consejos han facilitado la culminación de éste proyecto.
4
TABLA DE CONTENIDO
Pág.
GLOSARIO 10
RESUMEN 12
INTRODUCCIÓN 13
1. MARCO TEORICO 14
1.1 SISTEMAS RADIO TRUNKING 14
1.2 EL ESTÁNDAR TETRA 15
1.3 EL SISTEMA NEBULA 17
1.4 ENLACE PC-TERMINAL TETRA 20
1.5 ARQUITECTURA DE SOFTWARE 22
1.5.1 Programación por capas (Niveles) 23
1.6 METODOLOGÍA DE DESARROLLO DE APLICACIONES UML 24
2. COMPONENTES DE LA RED TETRA DE EMCALI 26
3. DESCRIPCION GENERAL DE LA APLICACION 29
3.1 PERSPECTIVA DEL PRODUCTO 29
3.2 FUNCIONES DEL PRODUCTO 29
3.3 CARACTERÍSTICAS DEL USUARIO 29
4. ESPECIFICACIÓN DE REQUERIMIENTOS 30
4.1 REQUERIMIENTOS FUNCIONALES 30
4.2 REQUERIMIENTOS NO FUNCIONALES 30
5
4.3 REQUERIMIENTOS DE DOMINIO 30
5. CASOS DE USO 31
5.1 DIAGRAMA DE CASOS DE USO 31
5.2 LISTA DE CASOS DE USO 32
5.3 ACTORES 32
5.4 DETALLES DE CASOS DE USO 32
5.4.1 Descripción Casos de Uso 32
6. MODELO DE DOMINIO 43
7. DIAGRAMAS DE SECUENCIA PARA DESCRIPCION DE LOS

CASOS DE USO 44
7.1 INICIAR APLICACIÓN 44
7.2 REALIZAR LLAMADA 45
7.3 ENVIAR DATOS 46
7.4 REALIZAR CONSULTA 47
7.5 PERMITIR LLAMADAS 48
7.6 CREAR/ELIMINAR GRUPO 49
7.7 MOVER A GRUPO 50
7.8 HABILITAR SERVICIO 50
8. DIAGRAMAS DE CLASES 51
8.1 PAQUETE INTERFAZ 52
8.2 PAQUETE CONTROL 52
8.3 PAQUETE ENTIDAD 54
6
8.4 CONTROL MAESTRO 55
9. DIAGRAMAS DE SECUENCIA 56
9.1 VOZ 56
9.2 DATOS – CONSULTA 57
9.3 GESTIÓN 58
10. DIAGRAMA DE DESPLIEGUE 59
11. CONCLUSIONES 60
12. RECOMENDACIONES 63
BIBLIOGRAFIA 64
7
LISTA DE FIGURAS
Pág.
Figura 1. Red Trunking 14
Figura 2. Red TETRA 16
Figura 3. Armario SCN NEBULA 18
Figura 4. Estructura red TETRA Teltronic 19
Figura 5. Comunicación con Line Dispatcher 21
Figura 6. Comunicación con Redes Externas 22
Figura 7. Arquitectura de 3 niveles 24
Figura 8. Radios TETRA EMCALI 26
Figura 9. Componentes red TETRA EMCALI 27
Figura 10. Estación Base Repetidora (BSR) 28
Figura 11. Sistema de Gestión (NMS) 28
Figura 12. Diagrama del Servicio 29
Figura 13. Diagrama de Casos de uso 31
Figura 14. Modelo de Dominio 43
Figura 15. Diagrama Inicio de la Aplicación 44
8
Figura 16. Diagrama Realizar Llamada 45
Figura 17. Diagrama Envío de datos 46
Figura 18. Diagrama Realizar Consulta 47
Figura 19. Diagrama Permiso Llamadas 48
Figura 20. Diagrama Creación de grupos 49
Figura 21. Diagrama Gestión de Grupos 50
Figura 22. Diagrama Habilitación del Servicio 50
Figura 23. Diagrama de Clases 51
Figura 24. Patrón Factory Method – Interfaz 52
Figura 25. Patrón Factory Method – Interfaz 53
Figura 26. Patrón Factory Method – Terminales 54
Figura 27. Patrón Bridge – NEBULA 55
Figura 28. Clase Control Maestro 55
Figura 29. Diagrama Secuencia Voz 56
Figura 30. Diagrama Secuencia Datos 57
Figura 31. Diagrama Secuencia Gestión 58
Figura 32. Diagrama de Despliegue 59
9
GLOSARIO
BSR: repetidor estación base.
CNC: controlador del nodo central.
ETSI: instituto europeo para estandarización de las telecomunicaciones (European

Telecomunications Standards Institute)
FULLDUPLEX: Cualidad de los elementos que permiten la entrada y salida de

datos de forma simultánea.
GPRS: servicio general de radio por paquetes (General Packet Radio Service)
GSM: sistema global para las comunicaciones móviles, (Global System for Mobile
communications)
HANDOVER: sistema utilizado en comunicaciones móviles celulares con el

objetivo de transferir el servicio de una estación base a otra cuando la calidad del
enlace es insuficiente.
ISDN: sistema para transmisión telefónica digital (Integrated Services Digital

Network)
IOP: certificados de interoperabilidad.
LINE DISPATCHER: despachador en línea.
LSC: controlador local.
MAM: modulo de alarmas y mantenimiento.
MCCH: canal de control principal (Main Control Channel)
N2A: protocolo interfaz IP Nebula (NEBULA IP Interface Access)
NEBULA: red TETRA de Teltronic.
NGN: red de próxima generación.
NMS: sistema de gestion de red (Network Management System)
10
PABX/PSTN: central de telefonía pública conmutada (Private Automatic Branch
Exchange / Public switched telephone network)
PDCH: canal paquete de datos (Packet Data Channel)
PDP: protocolo paquete de datos (Packet Data Protocol)
ROAMING: itinerancia, concepto utilizado en

comunicaciones inalámbricas relacionado con la capacidad de un dispositivo para
moverse de una zona de cobertura a otra.
SBS: estación base.
SCN: nodo de control del sistema.
SEMIDUPLEX: intercambio de datos entre dos terminales, en la que la transmisión

se lleva a cabo de manera alternativa, es decir, mientras un terminal está
transmitiendo el otro solo puede recibir y viceversa.
SIN: interfaz nodo-estacion base.
SMS: servicio de mensajes cortos (Short Message Service)
SYNC: tarjeta de sincronización.
TEA: algoritmo ligero de encriptamiento (Tiny Encription Algorithm)
TETRA: radio trunking terrestre (Terrestrial Trunken Radio)
UML: lenguaje unificado de modelado.
VOIP: telefonía sobre protocolo de internet (Voice on Internet Protocol)
WIMAX: interoperabilidad mundial para acceso por microondas, (Worldwide

Interoperability for Microwave Access)
11
RESUMEN
Afrontando los nuevos retos en el mercado de las telecomunicaciones, EMCALI

E.I.C.E., E.S.P compró a la empresa china Zte una Red de Próxima Generación
(NGN) la cual es capaz de proveer los servicios tradicionales de
telecomunicaciones y hacer uso de múltiples tecnologías de banda ancha y de
transporte con capacidades de calidad del servicio y donde las funciones
relacionadas con el servicio son independientes de las tecnologías relacionadas
con el transporte. En pocas palabras, la NGN es capaz de unificar en una sola
estación de gestión y control toda la variedad de servicios en telecomunicaciones
que ofrece EMCALI como son telefonía análoga y digital, Internet conmutado,
banda ancha y WiMax, pero también es capaz de gestionar nuevos servicios como
la televisión digital, telefonía inalámbrica GSM y la telecomunicación usando el
estándar TETRA. Pensando en esos nuevos servicios, EMCALI compró una
plataforma TETRA representada en radios portátiles y radios móviles y toda la
infraestructura para establecer esta comunicación; estos radios pueden
comunicarse entre sí y son monitoreados y gestionados a través de una NMS
(Network Management System), pero ésta NMS es única, además de costosa, por
lo que una empresa que compre el servicio de Radios TETRA a EMCALI no podrá
hacer monitoreo de sus terminales de radio.
Dado que no existe un sistema para que quienes compren el servicio TETRA a
EMCALI puedan comunicarse con los radios desde un computador personal
ubicado en una oficina o un hogar y que funcione como estación de control, se
planteó el proyecto de realizar las especificaciones que permitan la
implementación de un software para efectuar la comunicación de voz y de datos
entre computadores personales y los radios TETRA.
Como trabajo de grado para optar por el título de Ingeniero Electrónico se realizó
una pasantía en EMCALI E.I.C.E., E.S.P desarrollando dicho proyecto y en éste
documento se describe tanto la estructura de la red TETRA como la especificación
de los requerimientos que cumplan con las necesidades de EMCALI y a partir de
ellos se realizo la descripción de los casos de uso que enmarcarán el
funcionamiento y alcance de la aplicación. Se usó lenguaje Unificado de Modelado
UML para estructurar el desarrollo del aplicativo y poder garantizar su
escalabilidad puesto que el proyecto está pensado para ser implementado en un
lenguaje de programación orientado a objetos.
12
INTRODUCCIÓN
En un mundo cada vez más pequeño y próximo gracias a las telecomunicaciones,

pero a la vez más dependiente de ellas y más vulnerable a alguna falla de las
mismas, se hace indispensable contar con sistemas de telecomunicaciones
robustos, que soporten fallas inherentes al uso, condiciones atmosféricas o
catástrofes naturales. Es con base en esos requerimientos se ha desarrollado el
sistema TETRA (Terrestrial Trunken Radio), el cual garantiza una comunicación
confiable entre sus terminales a pesar de un fallo severo de las centrales.
EMCALI E.I.C.E., E.S.P ha adquirido una plataforma con ésta tecnología para la
prestación del servicio entre usuarios corporativos, los cuáles deberían poder
comunicar voz o datos entre los terminales de su flota y/o computadores
personales, así como algunas funciones de gestión, monitoreo y registro para que
sus usuarios puedan contar con una pequeña central de control o “line dispatcher”
desde un PC.
El presente documento describe de manera rápida la estructura de la red TETRA

adquirida por EMCALI, el proceso mediante el cual se realiza una comunicación
de terminales TETRA, y las especificaciones con las cuales se desarrollará el
aplicativo que cumpla con los requerimientos de EMCALI para dicha red y los
usuarios que adquieran el servicio, esto sujeto a la adquisición por parte de
EMCALI del protocolo de comunicaciones N2A (NEBULA IP Interface Access),
protocolo propiedad de Teltronic, y a través del cual se logra la comunicación IP.
13
1. MARCO TEÓRICO
1.1 SISTEMAS RADIO TRUNKING
Los Sistemas Radio Trunking son sistemas de radiocomunicaciones móviles para

aplicaciones privadas, formando grupos y subgrupos de usuarios, con las
siguientes características principales:
• Estructura de red celular (independientes de las redes públicas de telefonía

móvil).
• Los usuarios comparten los recursos del sistema de forma automática y
organizada.
• Cuando se requiere, por el tipo de servicio, es posible el establecimiento de
canales prioritarios de emergencia que predominarían sobre el resto de
comunicaciones del grupo.
Figura 1. Red Trunking
Fuente: Trunking Digital TETRA [en línea]. Zaragoza: Teltronic, 2007. [Consultado 06 de octubre de
2007]. Disponible en Internet: http://www.teltronic.es/soluciones.aspx?Area_ID=20&NodI_Id=355
Son sistemas que han ido estandarizando las diferentes interfaces desde su
introducción en el año 1997. En la actualidad se está produciendo un proceso de
estandarización con los sistemas digitales.
A su vez, el trunking es un sistema de radio en el que todas las comunicaciones
14
van precedidas de un código de llamada similar a una telefónica; si nuestro equipo
la recibe y no es el destinatario la emite de nuevo, actuando como repetidor, y si
es el destinatario se establece un circuito para asegurar la comunicación. Por lo
tanto sólo oímos las comunicaciones destinadas a nosotros. Dependiendo del
servicio instalado se puede implementar conexión a la red de telefonía pública.
El proceso de estandarizado con los sistemas digitales de trunking a dado como

resultado un estándar llamado TETRA el cual conserva las características de los
sistemas trunking pero adicionalmente permite otras alternativas de mejor
rendimiento y optimización de recursos.
1.2 EL ESTÁNDAR TETRA
TETRA (Terrestral Trunked Radio) es un estándar elaborado por el ETSI

(European telecomunications Standards institute) que ha reunido propuestas de
operadores de redes, administraciones nacionales, fabricantes de equipos y
usuarios de servicios móviles para establecer una norma abierta para las
comunicaciones digitales troncales.
Los certificados de interoperabilidad (IOP) aseguran que distintos fabricantes de

infraestructura y terminales pueden operar juntos en cualquier red TETRA sin
problemas.
La aplicación de este estándar está orientada a soluciones altamente

especializadas en el ámbito profesional, donde características como fiabilidad y
costos son un requerimiento importante, se observa en sectores críticos como lo
son servicios de emergencias (policía, bomberos, ambulancias) y para transmisión
de datos.
Tetra presenta grandes ventajas con respecto a otros sistemas digitales como
GSM que hacen que Tetra se presente como una muy buena opción para las
telecomunicaciones inalámbricas. Las principales ventajas son:
• Utilización de una banda de frecuencias mucho más baja, lo que supone un

menor necesidad de equipos repetidores para dar cobertura a una misma zona
geográfica.
• Puede trabajar en modo terminal a terminal, en caso de fallo en las

comunicaciones.
15
• Es un sistema digital más moderno que GSM por lo que la calidad de audio es
superior al implementar sistemas más modernos de compresión de voz.
• Las capacidades de transmisión de datos están definidas en el propio estándar

inicial y sólo son comparables al actual estándar GPRS.
• Mejor aprovechamiento del canal, ya que permite comunicaciones semi-duplex

como la radio convencional o full-duplex como el teléfono en casos necesarios,
utilizando los canales no ocupados.
• Menor grado de saturación, ya que el propio estándar garantiza una capacidad

por defecto superior al doble de los canales convencionales en uso. Además
dispone de comunicaciones priorizadas, por lo que en caso de saturación se
garantizan la disponibilidad de estas comunicaciones prioritarias.
• Permite comunicaciones uno a muchos lo que mejora la gestión de grupos en

caso de comunicaciones para coordinación de emergencias.
• Dispone de terminales específicos para cada necesidad. Así dispone de

terminales portátiles (equiparables a teléfonos móviles), terminales móviles
(destinados a vehículos) y terminales para bases.
Figura 2. Red TETRA
16
Pero así como Tetra tiene sus ventajas sobre GSM hay algunos inconvenientes
que hacen que los usuarios duden un poco sobre el desempeño de Tetra. Los
principales inconvenientes frente a GSM son:
• Requiere una menor densidad de usuarios que los servicios de GSM debido al
tipo de modulación realizada.
• Los terminales tienen un precio mucho mayor al estar dirigido a sectores

diferentes y no disponer de un mercado masivo de clientes.
•
• Las transferencias de datos son más lentas (max 19 Kbps), aunque se está
mejorando en versiones más modernas de esta tecnología.
• Debido a la baja modulación de frecuencia, los terminales pueden interferir con

dispositivos electrónicos sensibles, como marcapasos o desfibriladores.
1.3 EL SISTEMA NEBULA
NEBULA es el sistema de gestión de la red TETRA adquirido por EMCALI y

desarrollado por el proveedor de la red, Teltronic, y basado en arquitectura
Ethernet/IP. Su capacidad de conmutación es muy flexible y tiene un gran nivel de
escalabilidad, pudiendo alcanzar niveles muy altos de redundancia. El sistema
cuenta con portadoras que permiten soportar hasta 32 portadoras por Estación
Base (SBS), los Gateways telefónicos pueden también estar localizados en las
SBS proporcionando así interconexión telefónica distribuida. Una tarjeta SYNC
interna proporciona la sincronización necesaria para un sistema
∗
multiemplazamiento (con handover y roaming). Adicionalmente se puede usar
GPS como una señal de sincronización alternativa.
NEBULA emplea el protocolo N2A (Network IP Interface Access) para su

funcionamiento con redes Ethernet/IP, éste protocolo permite tanto integrar
aplicaciones de voz y datos (modo paquete o modo circuito) como realizar gestión
de datos (telemetría).
Los servicios básicos ofrecidos por NEBULA son:
Gestión de movilidad:
∗
Teltronic define multiemplazamiento como un sistema de varias radio bases conectadas entre si
17
• Registro / De-registro
• Re selección de célula (handover)
Seguridad clase 3
• Autenticación (del terminal y mutua)

• Cifrado interface aire con claves dinámicas.
• Algoritmos de cifrado TEA1, TEA2 yTEA3 (Tiny Encription Algorithm)
• Habilitación / Inhabilitación remota
• Cifrado extremo a extremo, incluyendo Gateway telefónico
Servicios de voz
• Llamadas individuales/Grupo, semiduplex/dúplex, PABX/PSTN

• Normal/prioridad/emergencia
• Gestión múltiple de grupos
Servicio de datos
• Mensajes de estado, individuales o de grupo

• Mensajes de estado simultáneos en una llamada de voz
• Datos modo circuito y modo paquete
Figura 3. Armario SCN NEBULA
18
Servicios suplementarios
• Asignación dinámica de grupo

• Entrada tardía
• Identificación de llamante y de hablante
• Llamada prioritaria
• Bloqueo de llamadas entrantes o salientes
Gateways
• Teléfono PABX/PSTN
• SMS a GSM
• VoIP
• Gateway de mantenimiento remoto
Figura 4. Estructura red TETRA Teltronic
Fuente: NMS [CD-ROM]. Zaragoza: Teltronic, 2007. Requerimientos del Sistema.
Terminología NEBULA:
• BSR: Base Estación Repetidora.

• CNC: Nodo Central de Control.
• Gateway-ISDN: Gateway para conectar a PABX o PSTN con formato ISDN.
• LSC: Controlador Local.
• N2A: NIIA, NEBULA IP Interface Access.
• SBS: Estación Base.
• SCN: Nodo de Control y Conmutación.
19
1.4 ENLACE PC-TERMINAL TETRA
El sistema NEBULA proporciona un servicio de transporte IP para dar soporte a

aplicaciones de datos basadas en el protocolo TCP/IP.
Antes de poder intercambiar datagramas IP con otros terminales, y con elementos
externos, el terminal necesita tener asociado un conjunto de parámetros
denominado "Contexto PDP (Packet Data Protocol)", entre los que se encuentra
una dirección IP con que identificarse como origen o destinatario de los envíos. La
dirección IP es estática y está grabada en la configuración del terminal. En el
momento de la negociación de parámetros, la infraestructura acepta o rechaza la
dirección IP propuesta por el terminal.
Para que un usuario o “Line Dispatcher” de origen a una comunicación con uno o
más terminales TETRA se debe tener la configuración:
En los terminales:
• Activación / desactivación del servicio PDP.

• Negociación de dirección IP: estática o dinámica.
• En caso de dirección estática: valor de la dirección IP.
En el sistema, por abonado:
• Permiso de utilización del servicio PDP.

• Dirección IP asociada al abonado. No es necesario configurarla, la
infraestructura genera una dirección IP automáticamente basándose en el número
de abonado (ISSI).
En el sistema, a nivel general:
• Servicio PDP disponible / no disponible.

• Conexión IP al exterior de la infraestructura: presencia de Gateway PDP en el
SCN.
• Conexión IP al exterior de la infraestructura: dirección IP del router / firewall que
media entre la infraestructura y el exterior.
Un terminal con contexto PDP activo puede seguir operando normalmente en la

red, establecer llamadas, cambiar de célula, recibir mensajes, etc. Además, será
avisado por la infraestructura cuando haya datos disponibles destinados a su
20
dirección IP, y podrá a su vez solicitar a la infraestructura el envío de datagramas
hacia otras direcciones.
Para recibir o enviar datagramas, el terminal pasa a un canal dedicado a este
servicio, denominado PDCH ("Packet Data Channel"). Cuando la transmisión ha
finalizado, el terminal vuelve al canal de control principal (“MCCH”).
Al ser el Cliente Line Dispatcher∗ un tipo de elemento externo al armario, es

obligatorio disponer un Firewall/Router, en lugar de conectarlos directamente por
Ethernet al switch del SCN, entre el SCN y los Clientes Line Dispatcher.
Figura 5. Comunicación con Line Dispatcher
Fuente: NMS [CD-ROM]. Zaragoza: Teltronic, 2007. Requerimientos del Sistema
Cada usuario LINE DISPATCHER tendrá asociado un nombre de usuario

(unívoco), una contraseña, un alias (varios usuarios pueden tener el mismo alias)
y un número de abonado TETRA (unívoco). El Line Dispatcher se comportará
∗
Line Dispatcher es el usuario de la aplicación con privilegios para realizar gestión
21
como un nuevo terminal introducido en la red Tetra con un identificador Tetra
especial.
Para cada usuario LINE DISPATCHER se configura la lista de flotas, los cuales
permiten que automáticamente se abran los audios del equipo cliente Line
Dispatcher.
Cuando un usuario Line Dispatcher comienza su sesión de trabajo, introduce su
nombre de usuario y su contraseña para identificarse y autenticarse ("registro").
Esta información viaja hasta el CNC, de modo que a partir de ese momento se
pueden cursar llamadas en el sistema que tenga como origen o destino ese
número de abonado, y dichas llamadas se dirigirán automáticamente a ese
puesto.
Figura 6. Comunicación con Redes Externas
Fuente: NMS [CD-ROM]. Zaragoza: Teltronic, 2007. Requerimientos del Sistema
Cuando el usuario de la aplicación lanza una petición de comunicación hacia

terminal TETRA identificándolo con su número de abonado, el sistema NEBULA
asocia ese número con la dirección IP correspondiente y se inicia el proceso de
autenticación mutuo entre el sistema y el terminal. Una vez verificada la identidad
se da paso a la comunicación descrita en la figura 6, en donde se transmite la
información vía Ethernet/IP hasta la Estación Base Repetidora (BSR) donde es
cifrada y transmitida por aire hasta el o los terminales.
22
1.5 ARQUITECTURA DE SOFTWARE
Paul Clements en su obra “Software architecture: An executive overview” [24]

define la arquitectura de software como una vista del sistema que incluye los
componentes principales del mismo, la conducta de esos componentes según se
la percibe desde el resto del sistema y las formas en que los componentes
interactúan y se coordinan para alcanzar la misión del sistema. La vista
arquitectónica es una vista abstracta, aportando el más alto nivel de comprensión
y la supresión o diferimiento del detalle inherente a la mayor parte de las
abstracciones.
La AS se refiere a la estructura a grandes rasgos del sistema, estructura
consistente en componentes y relaciones entre ellos, constituye un puente entre el
requerimiento y el código. La arquitectura de software define, de manera
abstracta, los componentes que llevan a cabo alguna tarea de computación, sus
interfaces y la comunicación ente ellos.
Cada paradigma de desarrollo exige diferente número y tipo de vistas o modelos

para describir una arquitectura. No obstante, existen al menos tres vistas
absolutamente fundamentales en cualquier arquitectura:
• La visión estática: describe qué componentes tiene la arquitectura.

• La visión funcional: describe qué hace cada componente.
• La visión dinámica: describe cómo se comportan los componentes a lo largo del
tiempo y cómo interactúan entre sí.
Las arquitecturas más comunes son:
• Monolítica.
• Cliente-servidor.
• Arquitectura de tres niveles.
• Pipeline.
• Entre pares.
• Orientada a servicios.
• Máquinas virtuales.
23
1.5.1 Programación por capas (Niveles). Su objetivo principal es la separación
de la lógica de negocios de la lógica de diseño, esto se logra separando la capa
de datos de la capa de presentación al usuario.
Figura 7. Arquitectura de 3 niveles
Fuente: CLEMENTS Paul; NORTHROP L. Software architecture: An executive overview. Madrid:

Prentice-Hall, 2005. p.49
• Capa de presentación: es la que ve el usuario, presenta el sistema al usuario, le

comunica la información y captura la información del usuario dando un mínimo de
proceso (realiza un filtrado previo para comprobar que no hay errores de formato).
Esta capa se comunica únicamente con la capa de negocio.
•
• Capa de negocio: es donde residen los programas que se ejecutan, se reciben
las peticiones del usuario y se envían las respuestas tras el proceso. Se denomina
capa de negocio pues es aquí donde se establecen todas las reglas que deben
cumplirse. Esta capa se comunica con la capa de presentación, para recibir las
solicitudes y presentar los resultados, y con la capa de datos, para solicitar al
gestor de base de datos para almacenar o recuperar datos de él.
•
• Capa de datos: es donde residen los datos y es la encargada de acceder a los
datos. Está formada por uno o más gestores de bases de datos que realizan todo
el almacenamiento de datos, reciben solicitudes de almacenamiento o
recuperación de información desde la capa de negocio.
24
1.6 METODOLOGÍA DE DESARROLLO DE APLICACIONES UML
Lenguaje Unificado de Modelado UML es un lenguaje de modelado cuyo

vocabulario y sintaxis están ideados para la representación conceptual y física de
un sistema. Sus modelos son precisos, no ambiguos, completos y pueden ser
trasladados directamente a una gran variedad de lenguajes de programación,
como Java, C++ o Visual Basic, pero también a tablas de bases de datos
relacionales y orientados a objetos. Es posible generar código a partir de un
modelo UML (ingeniería directa) y también puede construirse un modelo a partir
de la implementación (ingeniería inversa), aunque en las dos situaciones debe
intervenir un mayor o menor grado de supervisión por parte del programador, en
función de lo buenas que sean las herramientas empleadas.
Como todo lenguaje, UML incluye una gama de símbolos válidos (vocabulario) y
las reglas para combinarlos apropiadamente; permite generar diferentes modelos
para la representación de un sistema. Las reglas del UML indican básicamente
cómo crear estos modelos, el momento y orden apropiados deberán ser
establecidos por el método de desarrollo que se elija.
Una de las principales intenciones de los autores de UML era mantener el

lenguaje simple, no obstante, fueron incorporadas características que se pueden
considerar poderosas y avanzadas, proporcionando a los usuarios un lenguaje
muy útil. Entre las características incluidas en UML se encuentran:
• Mecanismos de extensibilidad (estereotipos, valores etiquetados y

restricciones).
• Hilos y procesos.
• Distribución y concurrencia.
• Patrones / colaboraciones.
• Diagramas de actividad (para el modelamiento de procesos del negocio).
• Refinamiento (para manejar relaciones entre niveles de abstracción).
• Interfaces y componentes.
• Lenguaje de restricciones.
25
2. COMPONENTES DE LA RED TETRA DE EMCALI
EMCALI ha realizado una gran inversión para adquirir de manos de la empresa

española Teltronic una plataforma TETRA, incluyendo tanto la infraestructura para
realizar la comunicación como terminales finales de usuario; éstos terminales
incluyen radios móviles, para vehículos y de mesa.
Figura 8. Radios TETRA EMCALI
Fuente: Trunking MPT-1327 [en línea]. Zaragoza: Teltronic, 2007. [Consultado 06 de octubre de
La infraestructura que permite la comunicación NEBULA está conformada por:
26
• 1 SCN (Nodo de Control del sistema)
Este SCN se encarga de todos los procesos que hacen factible la comunicación
TETRA e incluye los Firewalls, Gateways, Controladores de Nodo, Servidores de
Gestión y el módulo de alarmas y mantenimiento.
Figura 9. Componentes red TETRA EMCALI
• 7 SBS (Estación Base)

Ubicada cada una en una central de telecomunicaciones de EMCALI en la ciudad,
se encarga de encriptar la información y transmitirla desde la SCN hasta las
antenas ampliando la cobertura.
• BSR (Estación Base Repetidora) en cada SBS

Son tarjetas ubicadas dentro de la SBS y son las encargadas de transmitir la
comunicación vía aire entre el sistema y los terminales.
27
Figura 10. Estación Base Repetidora (BSR)
• 1 NMS (Sistema de Manejo de la Red)

Es el software mediante el cual EMCALI realiza toda la gestión de la red, esto
incluye activar terminales, asignar grupos, fijar parámetros de configuración,
activar/desactivar servicio, monitoreo, entre otros.
Figura 11. Sistema de Gestión (NMS)
28
3. DESCRIPCION GENERAL DE LA APLICACION
3.1 PERSPECTIVA DEL PRODUCTO
El software que se desarrollará con base en éstas especificaciones permitirá a los

usuarios corporativos que adquieran el servicio TETRA hacer seguimiento a sus
terminales, comunicarse con ellos desde un PC y realizar gestión sobre los
mismos.
3.2 FUNCIONES DEL PRODUCTO
• Permitir comunicación de voz y datos entre computadores personales y radios

TETRA.
• Permitir gestión básica (Activar, permitir llamadas, crear grupos) sobre los
terminales TETRA.
• Llevar un registro histórico de las comunicaciones realizadas desde y hacia
cada una de las terminales TETRA.
3.3 CARACTERÍSTICAS DEL USUARIO DE LA APLICACIÓN
El usuario de la aplicación que se desarrollará debe contar con una conexión a

internet, ya sea banda ancha o internet conmutado, un computador con al menos
512 MB de memoria RAM, un procesador con velocidad superior a 750 MHz con
sistema operativo Windows XP y dispositivos multimedia (tarjeta de sonido,
parlantes y micrófono) y solo debe poseer conocimientos elementales sobre el uso
del sistema operativo Windows XP.
Figura 12. Diagrama del Servicio
29
4. ESPECIFICACIÓN DE REQUERIMIENTOS
4.1 REQUERIMIENTOS FUNCIONALES
• El software debe permitir la comunicación de voz modo fullduplex, semiduplex

y datos entre un PC y un terminal TETRA.
• El software debe permitir realizar una autenticación del usuario para poder
acceder a la comunicación.
• El software debe permitir, cuando se poseen los privilegios, gestionar (Agregar,
eliminar, autorizar, monitorear) las flotas existentes.
• El software debe permitir la comunicación con un usuario individual o con todos
los miembros de una flota de manera simultánea.
• El software debe permitir llevar un registro histórico de las llamadas realizadas
desde y hacia los terminales TETRA.
4.2 REQUERIMIENTOS NO FUNCIONALES
• Los usuarios del software deben disponer una conexión a internet provista por
su ISP.
• El software será desarrollado sobre plataforma JAVA, servidor Apache y
software libre como MySQL.
• Capacidad de transmisión de datos de 7.8 Kbps.
4.3 REQUERIMIENTOS DE DOMINIO
• El protocolo usado para la comunicación entre la red TETRA y los PC´s es N2A,
protocolo exclusivo de Teltronic.
• La comunicación se realizará entre un PC y la red TETRA a través los
dispositivos multimedios del PC (Tarjeta de sonido, parlantes y micrófono).
• Mediante la interfaz gráfica se permitirá al usuario realizar gestión de su flota de
terminales con servicios como activación y desactivación de los mismos, entre
otros.
30
5. CASOS DE USO
5.1 DIAGRAMA DE CASOS DE USO
Figura 13. Diagrama de Casos de uso
31
5.2 LISTA DE CASOS DE USO
• Iniciar_Aplicación CU_1
• Realizar_Llamada CU_2
• Llamar_Teléfono_Fijo CU_3
• Llamar_TETRA CU_4
• Llamar_Grupo CU_5
• Llamar_Individual CU_6
• Enviar_Datos CU_7
• Enviar_Datos_Cortos (SMS) CU_8
• Enviar_Archivo_Datos CU_9
• Realizar_Consulta CU_10
• Consultar_Llamadas_Entrantes CU_11
• Consultar_Llamadas_Salientes CU_12
• Realizar_Gestión CU_13
• Permitir_Llamadas CU_14
• Crear/Eliminar_Grupo CU_15
• Mover_A_Grupo CU_16
• Habilitar_Servicio CU_17
5.3 ACTORES
• Line Dispatcher: Persona encargada de manejar el software y configurar cada

uno de los terminales tetra que estén registrados para comunicarse con estos.
•
• Usuario Oficina: Todas las personas que se pueden comunicar con un terminal
Tetra desde un PC pero no tiene acceso a la configuración.
•
• SCN NEBULA: Nodo de Control del sistema. Se encarga de todos los procesos
que hacen factible la comunicación TETRA.
5.4 DETALLES DE CASOS DE USO
5.4.1 Descripción Casos de Uso
Nombre: Iniciar_Aplicación
Identificación: CU_1
Actor Participante: Usuario oficina, Line Dispatcher, SCN NEBULA.
32
Precondiciones:
El usuario oficina o el line dispatcher deben conocer el nombre de usuario y la
contraseña.
El computador donde está la aplicación debe estar conectado a internet.
Flujo de eventos
• El usuario oficina o el line dispatcher ejecuta la aplicación.

• El sistema despliega la pantalla de presentación y solicita el nombre de usuario
y la contraseña.
• El usuario oficina o el line dispatcher ingresa el nombre de usuario y la
contraseña.
• El sistema compara los datos introducidos con su archivo de claves.
• El sistema establece comunicación con el SCN NEBULA.
• La aplicación despliega el menú principal.
• La aplicación accede a la base de datos de NEBULA y consulta los terminales
activos.
Caminos alternos
• Si el usuario oficina o el line dispatcher ingresan un nombre o contraseña no

valida, el sistema muestra un mensaje de error en pantalla y solicita nuevamente
su ingreso.
Nombre: Realizar_Llamada
Actor Participante: Usuario oficina.
Precondiciones:
El equipo del usuario oficina debe estar conectado a internet.
El usuario oficina debe de estar registrado.
Flujo de eventos
• El usuario oficina selecciona la opción realizar llamada del menú principal.

• El sistema solicita al usuario oficina que seleccione el tipo de llamada a fijo o
terminal tetra.
• El usuario oficina selecciona el tipo de llamada a realizar:
- Llamar a fijo, pasar a CU_3

- Llamar a TETRA, pasar a CU_4
33
Caminos alternos
• Si el usuario oficina desea cancelar la acción puede regresar al menú principal.
extends: Llamar teléfono fijo.

Actor Participante: Usuario oficina, SCN NEBULA.
Precondiciones:
El usuario oficina debe escoger la opción llamar a teléfono fijo en CU_2.
El usuario oficina debe conocer el número del teléfono fijo.
Flujo de eventos
• El sistema solicita el número del teléfono fijo.

• El usuario oficina digita el número del teléfono fijo.
• El usuario oficina inicia la llamada.
• El sistema establece la comunicación entre el usuario oficina y el SCN
NEBULA.
• EL usuario oficina finaliza la llamada.
Caminos alternos
• Si el usuario oficina ingresa un número de teléfono fijo no valido, el sistema

muestra un mensaje en pantalla y solicita nuevamente su ingreso.
• Si el sistema no puede establecer la comunicación, se realizan tres intentos de
forma automática y si no se consigue establecer la comunicación se cancela la
operación.
extends: Llamar TETRA.

Actor Participante: Usuario oficina, Usuario terminal.
Precondiciones:
El usuario oficina debe haber escogido la opción llamar a TETRA en CU_2.
El terminal tetra debe tener el servicio habilitado.
Flujo de eventos
34
• El sistema solicita al usuario oficina que seleccione si la llamada es individual o
de grupo.
• El usuario escoge el tipo de llamada a realizar:
- Llamada a grupo, pasar a CU_5

- Llamada individual, pasar a CU_6
Caminos alternos
extends: Llamar_Grupo
Actor Participante: Usuario oficina, Usuario terminal, SCN NEBULA
Precondiciones:
El usuario oficina debe haber escogido la opción llamar a grupo en CU_4.
Los terminales tetra deben tener el servicio habilitado.
Los terminales tetra deben estar habilitados para recibir llamadas.
Flujo de eventos
• El sistema despliega las flotas de terminales tetra activas.

• El usuario oficina escoge la flota tetra con quien desea hablar.
NEBULA.
Caminos alternos

operación.
extends: Llamar Individual

Actor Participante: Usuario oficina, Usuario terminal, SCN NEBULA.
35
Precondiciones
El usuario oficina debe haber escogido la opción llamar individual en CU_4.
El terminal tetra debe estar habilitado para recibir llamadas.
El usuario oficina debe conocer el número del terminal TETRA.
Flujo de eventos
• El sistema muestra los terminales activos.

• El usuario oficina digita el número del terminal tetra o lo escoge de la lista de
terminales activos.
NEBULA.
Caminos alternos
• Si el usuario oficina ingresa un número de terminal tetra no valido, el sistema

operación.
Nombre: Enviar_Datos
Actor Participante: Usuario oficina, Usuario terminal.
Precondiciones
Flujo de eventos
• El usuario oficina selecciona la opción comunicación de datos del menú

principal.
• El sistema solicita al usuario oficina que seleccione el tipo de mensajes cortos o
enviar archivo de datos.
• El usuario oficina elige la opción deseada:
- Enviar datos cortos (SMS), pasar a CU_8

- Enviar archivo de datos, pasar a CU_9
36
Caminos alternos
extends: Enviar Datos Cortos (SMS)

Actor Participante: Usuario oficina, Usuario terminal, SCN NEBULA.
Precondiciones
El usuario oficina debe escoger la opción enviar datos cortos en CU_7.
El terminal tetra debe estar habilitado para recibir datos.
Flujo de eventos
• El sistema solicita al usuario oficina que seleccione el tipo de terminal de mesa

ó móvil.
• El usuario oficina selecciona el tipo de terminal.
• El sistema solicita el número del terminal.
• El usuario oficina digita el número del terminal tetra o escoge el grupo a quien
desea enviar el mensaje.
• El usuario oficina escribe el mensaje en la ventana correspondiente de la
aplicación.
• El usuario oficina inicia el envío del mensaje.
• El sistema envía los datos vía IP hacia el SCN NEBULA.
• El sistema muestra una confirmación de envío del mensaje.
Caminos alternos
• Si el usuario oficina ingresa un número de terminal tetra no valido, el sistema

• Si el sistema no puede establecer la comunicación de manera inmediata, el
mensaje se guarda en el servidor de datos y reintenta enviarlo después.
extends: Enviar Archivo de Datos

Actor Participante: Usuario oficina, Usuario terminal, SCN NEBULA
37
Precondiciones
El usuario oficina debe escoger la opción enviar archivo de datos en CU_7.
El terminal tetra debe estar habilitado para recibir datos.
Flujo de eventos
• El usuario oficina selecciona el tipo de terminal.

• El sistema solicita el número del terminal.
• El usuario oficina digita el número del terminal tetra o escoge el grupo a quien
desea enviar el archivo.
• El usuario oficina escoge el archivo que desea enviar.
• El usuario oficina inicia el envío del mensaje.
• El sistema envía el archivo vía IP hacia el SCN NEBULA.
Caminos alternos
• Si el usuario oficina ingresa un número de terminal tetra no válido, el sistema

• Si el sistema no puede enviar el archivo, se muestra un mensaje de falla.
Poscondiciones
En el terminal Tetra no se pueden visualizar los archivos enviados por lo que es
necesario descargarlos a un PC o una PDA.
Nombre: Realizar_Consulta
Actor Participante: Usuario oficina.
Precondiciones
Flujo de eventos
• El usuario oficina selecciona la opción Realizar consulta del menú principal.

• El sistema muestra todos los terminales y sus respectivos grupos.
• El usuario oficina selecciona el terminal a consultar.
• El sistema ofrece las opciones de consultar llamadas entrantes o salientes.
• El usuario oficina elige la opción deseada.
38
- Consultar llamadas entrantes, pasar a CU_11
- Consultar llamadas salientes, pasar a CU_12
Caminos Alternos
extends: Consultar llamadas entrantes

Precondiciones
El usuario oficina debe haber escogido consultar llamadas entrantes en CU_10.
Flujo de eventos
• El sistema se comunica con el SCN NEBULA y consulta la base de datos.

• El sistema despliega en pantalla el registro histórico de las llamadas entrantes
para ese terminal.
Caminos Alternos
No existen caminos alternos.
Poscondiciones
El histórico se despliega en un archivo de texto plano que puede ser almacenado
e impreso.
extends: Consultar llamadas salientes

Precondiciones
El usuario oficina debe haber escogido la opción consultar llamadas salientes en
CU_10.
Flujo de eventos
• El sistema se comunica con el SCN NEBULA y consulta la base de datos.
39
• El sistema despliega en pantalla el registro histórico de las llamadas salientes
para ese terminal.
Caminos Alternos
Poscondiciones
El histórico se despliega en un archivo de texto plano que puede ser almacenado
e impreso.
Nombre: Realizar_Gestión
Actor Participante: Line Dispatcher.
Precondiciones
El equipo del line dispatcher debe estar conectado a internet.
El line dispatcher debe de estar registrado.
Los terminales tetra deben estas registrados en el sistema.
El line dispatcher debe conocer el número del terminal a gestionar.
Flujo de eventos
• El line dispatcher selecciona la opción realizar gestión del menú principal.

• El sistema muestra todos los terminales y sus respectivos grupos.
• El line dispatcher selecciona el terminal a gestionar.
• El sistema despliega las opciones para la gestión de terminales.
• El usuario oficina elige la opción deseada.
- Permitir Llamadas, pasar a CU_14

- Crear/Eliminar grupo, pasar a CU_15
- Mover a grupo, pasar a CU_16
- Habilitar servicio, pasar a CU_17
Caminos Alternos
uses: Permitir llamadas

Actor Participante: Line Dispatcher, SCN NEBULA.
40
Precondiciones
El line dispatcher debe haber escogido permitir llamadas en CU_13.
Flujo de eventos
• El line dispatcher selecciona la opción permitir llamadas a teléfono fijo y/o

terminal tetra.
• El line dispatcher graba los cambios.
• Los cambios son enviados al SCN NEBULA.
Caminos Alternos
Poscondiciones
Queda almacenado el cambio de configuración en el terminal Tetra y en el registro
histórico de actividades.
uses: Crear/Eliminar Grupo

Precondiciones
El line dispatcher debe haber escogido crear/eliminar grupo en CU_13.
Flujo de eventos
• El sistema solicita el nombre para el nuevo grupo a crear.

• El sistema solicita confirmación de eliminación del grupo escogido.
Caminos Alternos
Poscondiciones
Queda almacenado el cambio de configuración en el sistema.
uses: Mover a grupo

41
Precondiciones
El line dispatcher debe haber escogido mover a grupo en CU_13.
Flujo de eventos
• El line dispatcher selecciona a qué grupo mover el terminal.

Caminos Alternos
Poscondiciones
Quedan almacenados los cambios en la configuración en el registro del sistema.
uses: Habilitar servicio.

Precondiciones:
El line dispatcher debe haber escogido habilitar servicio en CU_13.
Flujo de eventos
• El sistema muestra el terminal como habilitado.

• El line dispatcher selecciona la opción deshabilitar servicio.
Caminos Alternos
Poscondiciones
Queda almacenado en el registro la configuración del terminal.
42
6. MODELO DE DOMINIO
Figura 14. Modelo de Dominio
43
7. DIAGRAMAS DE SECUENCIA
PARA DESCRIPCION DE LOS CASOS DE USO
7.1 INICIAR APLICACIÓN
Figura 15. Diagrama Inicio de la Aplicación
44
7.2 REALIZAR LLAMADA
Figura 16. Diagrama Realizar Llamada
45
7.3 ENVIAR DATOS
Figura 17. Diagrama Envío de datos
46
7.4 REALIZAR CONSULTA
Figura 18. Diagrama Realizar Consulta
47
7.5 PERMITIR LLAMADA
Figura 19. Diagrama Permiso Llamadas
48
7.6 CREAR/ELIMINAR GRUPO
Figura 20. Diagrama Creación de grupos
49
7.7 MOVER A GRUPO
Figura 21. Diagrama Gestión de Grupos
7.8 HABILITAR SERVICIO
Figura 22. Diagrama Habilitación del Servicio
50
8. DIAGRAMAS DE CLASES
Figura 23. Diagrama de Clases
51
8.1 PAQUETE INTERFAZ
El patrón de diseño Factory Method consiste en utilizar una clase constructora

abstracta con unos cuantos métodos definidos y otro(s) abstracto(s): el dedicado a
la construcción de objetos de un subtipo de un tipo determinado. Es una
simplificación del Abstract Factory, en la que la clase abstracta tiene métodos
concretos que usan algunos de los abstractos; según usemos una u otra hija de
esta clase abstracta, tendremos uno u otro comportamiento.
Figura 24. Patrón Factory Method – Interfaz
8.2 PAQUETE CONTROL
El control se ha dividido en dos paquetes: Uno para manejar el perfil de usuarios

usando el patrón Abstract Factory y otro para manejar las operaciones sobre los
terminales con el patrón Factory Method.
El patrón Abstract Factory ofrece una interfaz para la creación de familias de

productos relacionados o dependientes sin especificar las clases concretas a las
que pertenecen.
52
La estructura típica de éste patrón es: 1. La definición de interfaces para la familia
de productos genéricos (ej: ventana, menú, botón...) 2. Implementación de las
interfaces de los productos para cada una de las distintas familias concretas.
Figura 25. Patrón Factory Method – Interfaz
53
Figura 26. Patrón Factory Method – Terminales
8.3 PAQUETE ENTIDAD
El patrón Bridge es una técnica usada en programación para desacoplar una

abstracción de su implementación, de manera que ambas puedan ser modificadas
independientemente sin necesidad de alterar por ello la otra.
54
Figura 27. Patrón Bridge – NEBULA
8.4 CONTROL MAESTRO
Figura 28. Clase Control Maestro
55
9. DIAGRAMAS DE SECUENCIA
9.1 VOZ
Figura 29. Diagrama Secuencia Voz
56
9.2 DATOS – CONSULTA
Figura 30. Diagrama Secuencia Datos
57
9.3 GESTIÓN
Figura 31. Diagrama Secuencia Gestión
58
10. DIAGRAMA DE DESPLIEGUE
Figura 32. Diagrama de Despliegue
Requisitos Mínimos Computador Personal:

• Procesador Pentium III 750 MHz
• 512 MB memoria RAM
• Periféricos Multimedia (Parlantes, micrófono)
• Conexión a Internet 56 Kbps
Componentes SCN NEBULA

• Controlador del Nodo Central (CNC)
• Servidor NMS (Sistema Administrador de Red)
• Módulo de Alarmas y Mantenimiento (MAM)
• Interfaz con BSR
• Gateway VoIP
• Gateway Telefonía
• Gateway SMS GSM
• Gateway de Mantenimiento Remoto
59
11. CONCLUSIONES
Durante el proceso de desarrollo de éste proyecto y una vez finalizado el mismo,

los desarrolladores hemos podido obtener las siguientes conclusiones:
La red TETRA adquirida por EMCALI E.I.C.E. E.S.P. ofrece una opción para
telecomunicaciones inalámbricas de alta calidad y confiabilidad basada en el
sistema trunking, con tecnología de punta que permite la interoperabilidad con
otras redes de telecomunicaciones tales como PABX, GSM e IP, lo que posiciona
a EMCALI como pionera de ésta tecnología en el suroccidente de Colombia.
La característica primordial de TETRA, que la diferencia y se convierte en su

principal ventaja sobre el Trunking tradicional es el hecho de que el estándar
TETRA es completamente digital, permitiendo además de la comunicación de voz,
comunicación de datos y la gestión de los terminales a través de una red IP, así
como la consulta del tráfico y monitoreo de la red. Esto es importante puesto que
gracias a su compatibilidad con IP, la red TETRA puede interactuar con todas las
plataformas integradas en la red multiservicios de EMCALI y su gestión no está
anclada al centro de gestión de Colón, sino que puede ser monitoreada y
modificada desde cualquier punto con acceso a internet.
TETRA en un estándar abierto pero para que el sistema NEBULA pueda

comunicarse con redes externas usando el protocolo IP -como en el caso de la
aplicación que se desarrollará basada en éste documento- es necesario contar
con el protocolo N2A (NEBULA IP Interface Access) ya que solamente a través de
ese protocolo se logra la interacción entre NEBULA y redes IP. Este protocolo,
propiedad del proveedor de la red TETRA, Teltronic, es el único medio por el cual
se puede realizar la interoperabilidad entre NEBULA y redes externas que deseen
comunicarse usando el protocolo IP, por lo que es imperativo que EMCALI
adquiera el protocolo N2A si desea implementar la aplicación que se detalla en
éste documento.
Dado que no se tiene un conocimiento detallado del protocolo N2A, las

especificaciones para la implementación de la aplicación que se presentan en éste
documento pueden estar sujetas a modificaciones en cuanto a los métodos para
lograr la comunicación se refiere. En las especificaciones presentadas en éste
documento no se puede hacer énfasis en los métodos para realizar la
comunicación de voz o de datos entre un PC y un terminal TETRA puesto que al
no tener acceso el protocolo N2A no se conoce el formato de la trama y no se
puede precisar los comandos para realizar la comunicación.
60
En éste documento se presenta una completa descripción del diseño, casos de
uso, diagramas de clase y de secuencia, así como las clases y métodos
necesarios para lograr una fácil implementación de la aplicación una vez se
adquiera por parte de EMCALI el protocolo N2A. Las especificaciones presentadas
en éste documento permitirán desarrollar una aplicación software que cumpla con
los requerimientos técnicos y de diseño planteados por EMCALI pero también
permitirá agregarle nuevas funciones o modificar las existentes al realizarse un
diseño “modular”.
Se logró adquirir un conocimiento detallado de la estructura y funcionamiento de la

red TETRA adquirida por EMCALI, lo cual permitió no solo desarrollar el proyecto
original de las especificaciones para la aplicación software, sino que permitió tener
las herramientas para contribuir con otros aspectos de la red TETRA como
gestión, mantenimiento, ampliación de cobertura y capacitaciones entre otros.
El empleo de UML como lenguaje para el diseño de software permitió plasmar las
funciones y métodos que emplearemos en el desarrollo de la aplicación de una
manera estandarizada, de modo que la persona que implemente la aplicación
conozca de manera precisa el diseño de la misma, así como sus clases, métodos
y relaciones. Durante el tiempo que duró la pasantía se conoció a fondo la red
TETRA y se entendió su funcionamiento, pero fue gracias a UML que se pudo
moldear la aplicación y expresar en un lenguaje formal las ideas de modo que los
conocimientos adquiridos sobre la red se puedan convertir en las especificaciones
que darán origen a la aplicación solicitada por EMCALI.
Debido a la posibilidad de realizar gestión del la red TETRA a través de una red
IP, se hace necesario contar con dos tipos de usuarios para que de ese modo los
usuarios que deseen comunicarse con un terminal TETRA no puedan modificar la
estructura de la red y sólo quienes tengan privilegios de line dispatcher tendrán
acceso a la opción de gestión protegiendo de ésta manera la integridad de la red
TETRA.
Una vez establecidos los requerimientos del proyecto, el primer paso para trabajar
con UML es definir los casos de uso, puesto que es gracias a ese diagrama que
enmarcamos el alcance de nuestro diseño, incluyendo lo que queremos que haga
el sistema y quienes van a realizar cada acción.
Dando cumplimiento a los requerimientos funcionales del proyecto, la aplicación

está pensada para ser implementada usando lenguaje Java, lo que permite la
herencia de código, esto significa que la programación se puede dividir en bloques
-cada bloque representa a un caso de uso- y los métodos incluidos en cada bloque
pueden ser utilizados por otros bloques que cumplan con las mismas o con
funciones similares, permitiendo además de la no duplicación de métodos, la
posibilidad de agregar o modificar de manera sencilla alguno de estos bloques.
61
Los patrones de diseño se utilizaron debido a que brindan solución a problemas
ya conocidos en el desarrollo de sistemas software y evitan la reiteración en la
búsqueda de soluciones a problemas puntuales que se presentan en la mayoría
de los desarrollos, en el caso de éste proyecto, el uso de una interfaz de usuario,
una base de datos, comunicación con otra plataforma, que son funcionalidades
primordiales para el software.
Al existir una serie de patrones estandarizados y conocidos por la comunidad de

desarrolladores de software se hace importante el uso de estos en el desarrollo,
ya que mediante la implementación de estos se hace mucho más comprensible el
diseño. En el caso puntual del proyecto fue de gran importancia para facilitar la
interpretación de los diagramas de Clases y lo que se pretendía con ellos.
La implementación de patrones de diseño permite que el sistema de software sea

escalable, característica que es muy importante teniendo en cuenta que TETRA es
un estándar relativamente nuevo y las compañías que lo ofrecen tratar de
incorporar nuevas funcionalidades dentro de las plataformas ya existentes.
A pesar de que UML es un lenguaje que no está oficialmente estandarizado, el

proceso descrito por la mayoría de los autores es muy similar y su apoyo en
diagramas para describir los procedimientos resulta de gran utilidad para trasladar
las ideas a lenguaje de programación, especialmente para quienes no tienen la
experiencia de los ingenieros informáticos.
El desarrollo de ésta pasantía ha sido una actividad sumamente enriquecedora,

puesto que se ha logrado poner en práctica los conocimientos adquiridos durante
la carrera en una empresa prestigiosa en el campo de las telecomunicaciones y se
ha desarrollado un proyecto beneficioso para dicha empresa, logrando de ésta
manera que relacionemos los conocimientos teóricos con la realidad vivida en las
empresas y dejando en la misma una buena imagen de los estudiantes y de la
universidad.
Los objetivos planteados al inicio del proyecto se han cumplido satisfactoriamente,

por ello se puede concluir que el proceso de pasantía ha sido beneficioso al
máximo para todos los entes involucrados, tanto para la institución educativa cuya
visión ha sido cumplida y su imagen reforzada, los alumnos que han recibido
ilustración sobre los procesos industriales, como para la empresa por haber
obtenido los servicios y aportes de los pasantes.
62
12. RECOMENDACIONES
Recomendamos a EMCALI E.I.C.E. E.S.P. desarrollar un proyecto de

documentación de sus redes de telecomunicaciones, tanto TETRA como ISDN,
GSM, GPRS y Wi-Max para que gracias a esa documentación se tenga un registro
completo de los componentes de cada una de éstas redes pero también se
desarrolle un protocolo para la atención de eventos como alarmas, fallos,
mantenimiento y copias de seguridad.
A todos los entes involucrados en la figura de Pasantía (Universidad, empresas y

estudiantes) recomendamos seguir ofreciendo y optando por esta oportunidad de
relacionar a los estudiantes con la infraestructura y la metodología empleada por
la industria en la región, ya que esta opción de trabajo de grado permite no solo
que los estudiantes lleven a la práctica los conocimientos recibidos en el aula de
clase sino que también permite a las empresas nutrirse de los conocimientos y
ansias de aprender de los estudiantes mientras observan el desempeño de
posibles candidatos a ocupar cargos dentro de la empresa.
63
BIBLIOGRAFIA
ARREGUI, Miguel. Tutorial de UML. Barcelona: Universitat Jaume I, Castellón,

2004. 245 p
CLEMENTS Paul; NORTHROP L. Software architecture: An executive overview.

Madrid: Prentice-Hall, 2005. 453 p
First TETRA Release 2 standards approved [en línea]. Londres: ETSI, 2001.
[Consultado 16 de febrero de 2008]. Disponible en Internet:
http://portal.etsi.org/tetra
Guide ETSI Standards [en línea]. Londres: MoU, 2005. [Consultado 16 de febrero
de 2008]. Disponible en Internet:
http://www.tetramou.com/tetramou.aspx?&id=1201
Latest TETRA Direct Mode Operation standards published [en línea]. Londres:
ETSI, 2002. [Consultado 06 de octubre de 2007]. Disponible en Internet:
New version of TETRA General Network design approved [en línea]. Londres:
ETSI, 2002. [Consultado 06 de octubre de 2007]. Disponible en Internet:
NMS [CD-ROM]. Zaragoza: Teltronic, 2007. Requerimientos del Sistema EMCALI

E.I.C.E., E.S.P.
Radiocomunicaciones TETRA [en línea]. Berlín: EADS, 2005. [Consultado 16 de

febrero de 2008]. Disponible en Internet:
http://www.eads.com/1024/es/businet/defence/dcs/solutions/pmr/products_service
s/tetra_radio_communications/tetra_radio_communications.html
Rise of the Asian TETRA industry [en línea]: TETRA Experience 2006 China.
Conference and exhibition at the Hotel New Century Beijing. Londres: MoU, 2006.
[Consultado 06 de octubre de 2007]. Disponible en Internet:
http://www.tetramou.com/uploadedFiles/Files/Presentations/CHINA06SRT.ppt
STELTING Sthephen. Patrones de Diseño Aplicados a Java. Mexico: Prentice-

Hall, 2003. 360 p
TANENBAUM, Andrew. Redes de computadoras. 3 ed. México: Prentice-Hall,

1997. 425 p
64
Technology Benefits [en línea]. Londres: MoU, 2005. [Consultado 16 de febrero de
2008]. Disponible en Internet: http://www.tetramou.com/tetramou.aspx?&id=2552
Terrestrial Trunked Radio (TETRA) [en línea]: Final draft ETSI EN 300 392-1
V1.2.0. 2002-09. Londres: ETSI, 2002. [Consultado 06 de octubre de 2007].
Disponible en Internet: http://portal.etsi.org/tb/status/status.asp
TETRA [en línea]. Londres: ETSI, 2001. [Consultado 06 de octubre de 2007].

Disponible en Internet: http://www.etsi.org/etsi_radar/cooking/cooking_a.html
TETRA Interoperability [en línea]: The TETRA Association Board held a

conference in Belgrade. Serbia: MoU, 2007. [Consultado 16 de febrero de 2008].
Disponible en Internet:
http://www.tetramou.com/uploadedFiles/Files/Presentations/Belgrade07_Interoper
ability.pdf
TETRA Release 1 [en línea]. Londres: MoU, 2005. [Consultado 16 de febrero de

TETRA Standard [en línea]. Londres: MoU, 2005. [Consultado 16 de febrero de

The new frontier of the TETRA access network [en línea]: TETRA Experience 2006
China. Conference and exhibition at the Hotel New Century Beijing. Londres: MoU,
2006. [Consultado 06 de octubre de 2007]. Disponible en Internet:
http://www.tetramou.com/uploadedFiles/Files/Presentations/CHINA06Basile.ppt
Trunking Digital TETRA [en línea]. Zaragoza: Teltronic, 2007. [Consultado 06 de

octubre de 2007]. Disponible en Internet:
http://www.teltronic.es/soluciones.aspx?Area_ID=20&NodI_Id=355
Trunking MPT-1327 [en línea]. Zaragoza: Teltronic, 2007. [Consultado 06 de

octubre de 2007]. Disponible en Internet:
http://www.teltronic.es/soluciones.aspx?Area_ID=20&NodI_Id=356
Understanding TETRA Security [en línea]: The TETRA Association Board held a
conference in Belgrade. Serbia: MoU, 2007. [Consultado 16 de febrero de 2008].
Disponible en Internet:
http://www.tetramou.com/uploadedFiles/File/Presentation/Belgrade07_Security.pdf
Unified Modeling Language Specification, versión 1.5 [en línea]. New York. 2003.
[Consultado 22 de abril de 2008]. Disponible en Internet:
http://www.omg.org/technology/documents/formal/uml.htm
65

Comuniacion TETRA - PC

Cargado por

Copyright:

Formatos disponibles

Comuniacion TETRA - PC

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

Comuniacion TETRA - PC

Cargado por

Copyright:

Formatos disponibles

SOFTWARE DE COMUNICACIÓN ENTRE RADIOS TETRA Y

DARIO FERNANDO CORTES TOBAR

UNIVERSIDAD AUTONOMA DE OCCIDENTE

DARIO FERNANDO CORTES TOBAR

PASANTIA PARA OPTAR EL TITULO DE

UNIVERSIDAD AUTONOMA DE OCCIDENTE

Aprobado por el Comité de Grado

Ing. ZEIDA MARIA SOLARTE

Ing. FERNANDO CARVAJAL

Santiago de Cali, Junio 12 de 2008

Nuestros más sinceros agradecimientos los profesores Ramiro Nogales y Lida

1.1 SISTEMAS RADIO TRUNKING 14

1.2 EL ESTÁNDAR TETRA 15

1.3 EL SISTEMA NEBULA 17

1.4 ENLACE PC-TERMINAL TETRA 20

1.5 ARQUITECTURA DE SOFTWARE 22

1.5.1 Programación por capas (Niveles) 23

1.6 METODOLOGÍA DE DESARROLLO DE APLICACIONES UML 24

2. COMPONENTES DE LA RED TETRA DE EMCALI 26

3. DESCRIPCION GENERAL DE LA APLICACION 29

3.1 PERSPECTIVA DEL PRODUCTO 29

3.2 FUNCIONES DEL PRODUCTO 29

3.3 CARACTERÍSTICAS DEL USUARIO 29

4.1 REQUERIMIENTOS FUNCIONALES 30

4.2 REQUERIMIENTOS NO FUNCIONALES 30

5.1 DIAGRAMA DE CASOS DE USO 31

5.2 LISTA DE CASOS DE USO 32

5.4 DETALLES DE CASOS DE USO 32

5.4.1 Descripción Casos de Uso 32

7. DIAGRAMAS DE SECUENCIA PARA DESCRIPCION DE LOS

7.1 INICIAR APLICACIÓN 44

7.2 REALIZAR LLAMADA 45

7.3 ENVIAR DATOS 46

7.4 REALIZAR CONSULTA 47

7.5 PERMITIR LLAMADAS 48

7.6 CREAR/ELIMINAR GRUPO 49

7.7 MOVER A GRUPO 50

7.8 HABILITAR SERVICIO 50

8.1 PAQUETE INTERFAZ 52

8.2 PAQUETE CONTROL 52

8.3 PAQUETE ENTIDAD 54

9.2 DATOS – CONSULTA 57

10. DIAGRAMA DE DESPLIEGUE 59

Figura 1. Red Trunking 14

Figura 2. Red TETRA 16

Figura 3. Armario SCN NEBULA 18

Figura 4. Estructura red TETRA Teltronic 19

Figura 5. Comunicación con Line Dispatcher 21

Figura 6. Comunicación con Redes Externas 22

Figura 7. Arquitectura de 3 niveles 24

Figura 8. Radios TETRA EMCALI 26

Figura 9. Componentes red TETRA EMCALI 27

Figura 10. Estación Base Repetidora (BSR) 28

Figura 11. Sistema de Gestión (NMS) 28

Figura 12. Diagrama del Servicio 29

Figura 13. Diagrama de Casos de uso 31

Figura 14. Modelo de Dominio 43

Figura 15. Diagrama Inicio de la Aplicación 44

Figura 17. Diagrama Envío de datos 46

Figura 18. Diagrama Realizar Consulta 47