Analizador de Protocolo de La Interfaz A Del Sistema GSM

Universidad ORT Uruguay
Facultad de Ingeniería
Analizador de protocolos de
la interfaz A del sistema
GSM
Entregado como requisito para la obtención del título de
Ingeniera en Telecomunicaciones
Patricia Gutiérrez - 111996

Alejandra Mar - 67906
Tutor: Ing. Fernando Fontán
2003
Agradecimientos:
Al Ing. Fernando Fontán, por ser nuestro tutor, orientarnos y ayudarnos a percibir
todos los detalles involucrados en el proyecto.
Al Ing. Alejandro Paz, por proponer la idea de la utilidad de un analizador de la

Interfaz A.
Al Ing. Andrés Álvarez, por aportar sus conocimientos sobre análisis de mensajes
ISUP.
Al Ing. Andrés Antoniuk y la Ing. Inés Kereki por aportar ideas desde su
conocimiento del lenguaje de programación Java.
A Martín Vázquez, que nos indicó como hacer el Programa de Instalación.
2
Abstract
El presente trabajo contiene el planteamiento y la resolución de un analizador de

protocolo para la interfaz A, del Sistema Global de Comunicación Móvil GSM, así
como un estudio profundo del sistema y en particular de la interfaz A y su sistema
de señalización.
El trabajo está organizado en 11 capítulos y 5 apéndices. El capítulo 1 define el

proyecto, estableciendo objetivos y alcances. El capítulo 2 define GSM, interfaz A
y la unidad de señalización analizada. El capítulo 3 contiene la especificación de
los requisitos y los casos de uso del sistema. El capítulo 4 explica porque se han
elegido para el proyecto los lenguajes JAVA y XML. El capítulo 5 plantea el
análisis de riesgos que se estimó para el proyecto. Los capítulos 6 y 7 contienen el
análisis y diseño del sistema y los diagramas de clase. El capítulo 8 muestra
pruebas del software para cada caso de uso. El capítulo 9 contiene el manual de
usuario. El capítulo 10 presenta un análisis de un modelo de analizador on-line. El
capítulo 11 reúne distintas consideraciones del proyecto y decisiones que se
tomaron.
El apéndice A describe el sistema GSM, su arquitectura y servicios. El apéndice B

describe la interfaz A y su sistema de señalización. El apéndice C contiene el
estudio de la pila de protocolos de la interfaz. El apéndice D contiene diagrama de
clases y el diseño de clases. El apéndice E contiene la documentación de la s
clases.
3
Índice
Agradecimientos:...................................................................................................... 2
Abstract ............................................................................................................................ 3
1.1- Introducción .......................................................................................................... 10
1.2- Objetivo ................................................................................................................ 11
1.3- Definición ............................................................................................................. 11
1.4- Alcance ................................................................................................................. 11
1.5- Analizador “off-line” versus “on-line” ................................................................. 13
1.6- Aplicaciones de los analizadores de protocolos de señalización .............................. 14
2.1- GSM (Global System for Mobile Comunication) ..................................................... 16
2.1.1- Servicios y facilidades del sistema ......................................................................... 16
2.1.2- Arquitectura del sistema GSM ........................................................................... 16
2.2- Interfaz A................................................................................................................... 17
2.2.1- Estructura de la interfaz .................................................................................... 17
2.2.2- Clases de mensajes de señalización de la interfaz.............................................. 18
2.2.3- Unidades de señalización ................................................................................... 18
Capítulo 3 - Especificación de Requerimientos .............................. 20
3.1- Propósitos Generales ................................................................................................. 20
3.2- Metas ......................................................................................................................... 20
3.3- Requerimientos específicos ....................................................................................... 21
3.2.1- Requerimientos funcionales ............................................................................... 21
3.3.2- Requerimientos no funcionales .......................................................................... 21
3.3.3- Atributos del software ........................................................................................ 22
3.4- Características del usuario ......................................................................................... 23
3.5- Diagrama de los casos de uso .................................................................................... 23
3.6- Casos de Uso ............................................................................................................. 24
3.6.1- Obtener análisis de mensajes.............................................................................. 24
3.6.2- Buscar un mensaje ocurrido en un tiempo específico ........................................ 24
3.6.3- Obtener mensajes con una característica en común ........................................... 25
3.6.4- Generar un archivo con el análisis detallado de mensajes ................................. 26
Referencias para éste capítulo .......................................................................................... 26
Capítulo 4- Elección del lenguaje de programación .................... 27
4.1- JAVA......................................................................................................................... 27
4.2- XML .......................................................................................................................... 28
4.2.1- APIs de Java para XML ..................................................................................... 29
Capítulo 5- Estimación del Riesgo ........................................................... 30
5.1- Identificación de los riesgos ...................................................................................... 30
5.2 - Análisis de los riesgos .............................................................................................. 30
5.3- Análisis de las acciones tomadas .............................................................................. 31
5.4 - Proyección del Riesgo .............................................................................................. 32
5.5- Evaluación del riesgo ................................................................................................ 33
4
Capítulo 6 - Análisis ............................................................................................ 40
6.1- Dominio del problema............................................................................................... 40
6.2- Identificación de clases ............................................................................................. 43
6.3- Modelo de clases ....................................................................................................... 44
Capítulo 7- Diseño del sistema .................................................................... 48
7.1- Diseño de los subsistemas ......................................................................................... 48
7.2- El subsistema de dominio.......................................................................................... 49
7.2.1- Diagrama de Clases ............................................................................................ 49
7.2.2- Descripción detallada ......................................................................................... 51
7.3- El subsistema de vista de la aplicación ..................................................................... 57
7.3.1- Diagrama de clases ............................................................................................. 57
7.4- Implementación ......................................................................................................... 58
Capítulo 8 – Pruebas del software ............................................................. 60
8.1- Visualizar análisis de mensaje................................................................................... 60
8.2- Obtención de mensajes con una característica en común ......................................... 61
8.3- Búsqueda de mensajes en un tiempo específico........................................................ 62
8.4- Generación de un archivo con la descripción detallada de un conjunto de mensajes62
Capítulo 9- Manual de usuario ..................................................................... 65
9.1- Instalar el programa ................................................................................................... 65
9.2- Procedimientos de Uso .............................................................................................. 65
9.2.1- Análisis de un archivo ........................................................................................ 66
9.2.2- Búsqueda de un mensaje por tiempo .................................................................. 66
9.2.3- Filtrado de mensajes ........................................................................................... 66
9.3- Agregar Mensajes en los archivos XML ................................................................... 67
9.3.1- Mensajes de MTP3 ............................................................................................. 67
9.3.2- Mensajes de SCCP ............................................................................................. 68
9.3.3- Parámetros de SCCP .......................................................................................... 69
Agregar o modificar un campo de un parámetro: ........................................................ 70
9.3.4- Mensajes de Testeo y Mantenimiento ................................................................ 71
9.3.5- Mensajes BSSMAP ............................................................................................ 72
Capítulo 10- Análisis del modelo Online............................................. 76
10.1 - Arquitectura ON-LINE .......................................................................................... 76
10.1.1- Hardware adicional .......................................................................................... 76
10.2 - Arquitectura general básica .................................................................................... 77
10.3- Resolución del Análisis ........................................................................................... 78
10.3.1- Obtención de datos ........................................................................................... 79
Capítulo 11- Sobre el proyecto .................................................................... 82
11.1- Vida del proyecto .................................................................................................... 82
11.2- Especificaciones GSM e ITU-T .............................................................................. 83
11.3- Archivos XML ........................................................................................................ 84
5
11.4- Etapa previa ............................................................................................................. 86
11.5- Lectura de archivos ................................................................................................. 86
Bibliografía ................................................................................................................. 88
Apéndice A ................................................................................................................. 91
A.1 - GSM Sistema Mundial de Telecomunicaciones
Móviles .......................................................................................................................... 91
A.1.1- GSM ...................................................................................................................... 91
A.1.2- Servicios y Facilidades del Sistema ...................................................................... 91
A.1.2.1- Teleservicios ................................................................................................... 91
A.1.2.2- Servicios portadores ....................................................................................... 92
A.1.2.3- Servicios suplementarios ................................................................................ 92
A.1.3- Arquitectura de la red GSM .................................................................................. 92
A.1.3.1- La Estación Móvil (MS) ................................................................................. 93
A.1.3.2- El Subsistema de Estación Base (BSS) .......................................................... 94
A.1.3.3- Central de Conmutación Móvil (MSC) .......................................................... 94
A.1.3.4- El Registro de Localización de Abonado (HLR) ........................................... 94
A.1.3.5- El Centro de Autenticación (AuC) ................................................................. 95
A.1.3.6- El Registro de Localización de Visitantes (VLR) .......................................... 95
A.1.3.7- Registro de Llamada de Grupo (GCR) ........................................................... 95
A.1.3.8- Central de Operación y Mantenimiento (OMC)............................................. 95
A.1.3.9- Definición de interfaces: ................................................................................ 96
A.1.4- Algunos aspectos fundamentales del sistema ...................................................... 100
A.1.4.1- Control de potencia: ..................................................................................... 100
A.1.4.2- Salto en Frecuencia: ..................................................................................... 100
A.1.4.3- Traspaso de Frecuencia: ............................................................................... 101
A.1.4.4- Recepción discontinua.................................................................................. 101
A.1.4.5- Autenticación................................................................................................ 102
A.1.4.6- Encriptado .................................................................................................... 102
A.1.4.7- Itinerancia ..................................................................................................... 102
Apéndice B................................................................................................................ 104
B.1- Interfaz A y su Sistema de Señalización................................. 104
B.1.1- Interfaz A ............................................................................................................. 104
B.1.1.1- Objetivos de especificación de la interfaz A ................................................ 105
B.1.1.2- Características de la interfaz A ..................................................................... 105
B.1.1.3- División funcional entre BSS y MSC ........................................................... 105
B.1.1.4- Integración del transcodificador/adaptador de velocidad ............................. 109
B.1.1.5- Multiplexación de canales de control común y dedicados ........................... 110
B.1.1.6- Clases de mensajes de señalización .............................................................. 110
B.1.1.7- Soporte de servicios distinto a los de voz ..................................................... 110
B.1.1.8- Estructura de la interfaz ................................................................................ 111
B.1.2- Sistema de señalización ....................................................................................... 111
B.1.2.1- Sistema de señalización Nº 7 ........................................................................ 112
Referencias para éste apéndice ....................................................................................... 117
6
Apéndice C................................................................................................................ 119
C.1 - Capa física (MTP1) ............................................................................... 119
C.1.1- Enlace de datos de señalización........................................................................... 119
C.1.1.1- Velocidad de bits para la señalización .......................................................... 121
C.1.1.2- Características en lo relativo a los errores y a la disponibilidad .................. 121
C.1.1.3- Puntos de especificación del interfaz ........................................................... 121
C.1.1.4- Enlace de datos de señalización digital (derivado del trayecto digital a 2048
kbps) ........................................................................................................................... 122
Referencias para éste apéndice ........................................................................................... 122
C.2 – Enlace de señalización (MTP2) .................................................. 124
C.2.1- Delimitación y alineamiento de las unidades de señalización ............................. 125
C.2.2- Detección de errores ............................................................................................ 125
C.2.3- Corrección de errores .......................................................................................... 126
C.2.4- Alineamiento inicial ............................................................................................ 126
C.2.5- Supervisión de errores en el enlace de señalización ............................................ 127
C.2.6- Funciones de control del estado del enlace ......................................................... 127
C.2.7- Control del flujo .................................................................................................. 127
C.2.8- Formato básico de la unidad de señalización ...................................................... 128
C.2.8.1- Funciones y códigos de los campos de la unidad de señalización ............... 129
C.3 – Red de señalización (MTP3) ......................................................... 132
C.3.1- Introducción ......................................................................................................... 132
C.3.2- Manejo de mensajes de señalización ................................................................... 132
C.3.2.1 Etiqueta de ruteo ............................................................................................ 135
C.3.2.2- Función de ruteo de mensaje ........................................................................ 136
C.3.2.3- Funciones de discriminación y distribución de mensaje .............................. 138
C.3.3- Gestión de la red de señalización ........................................................................ 140
C.3.3.1- Estado del enlace de señalización ................................................................. 141
C.3.3.2- Estado de las rutas de señalización ............................................................... 142
C.3.3.3- Estado de los puntos de señalización ............................................................ 142
C.3.3.4- Congestión de una red de señalización ......................................................... 142
C.3.4 Características generales de los formatos de la unidad de señal del mensaje ....... 143
C.3.4.1- Octeto de información de servicio ................................................................ 143
C.3.4.2- Etiqueta ......................................................................................................... 144
C.3.5- Formatos y códigos de mensajes de gestión de red ............................................. 145
C.3.5.1- Etiqueta ......................................................................................................... 145
C.3.5.2- Código de cabecera (H0) .............................................................................. 145
C.4 – Testeo y Mantenimiento ................................................................... 155
C.4.1- Testeo .................................................................................................................. 155
C.4.1.1- Testeo de enlace de dato de señalización ..................................................... 155
C.4.1.2- Testeo de enlace de señalización .................................................................. 156
C.4.2- Localización de falla............................................................................................ 157
C.4.3- Monitoreo de la red de señalización .................................................................... 157
7
C.4.4- Formatos y códigos de mensajes de testeo y mantenimiento .............................. 157
Código de cabecera H0 ............................................................................................... 157
Mensajes de testeo del enlace ..................................................................................... 158
C.5 – SCCP ......................................................................................................................... 160
C.5.1- Servicios provistos por la SCCP.......................................................................... 160
C.5.1.1- Servicios con conexión ................................................................................. 161
C.5.1.2- Servicios no orientados a conexión .............................................................. 163
C.5.2- Funciones proporcionadas por la SCCP .............................................................. 164
C.5.2.1- Funciones del servicio con conexión ............................................................ 164
C.5.2.2- Funciones del servicio sin conexión ............................................................. 165
C.5.2.3- Funciones de gestión .................................................................................... 165
C.5.2.4- Funciones de encaminamiento y traducción ................................................. 166
C.5.3- Definición y funciones de los mensajes de la SCCP ........................................... 167
C.5.3.1- Confirmación de conexión (CC): ................................................................. 167
C.5.3.2- Petición de conexión (CR, connection request): .......................................... 167
C.5.3.3- Conexión rechazada (CREF, connection refused):....................................... 167
C.5.3.4- Forma de datos 1 (DT1, data form 1): .......................................................... 168
C.5.3.5- Prueba de inactividad (IT, inactivity test): ................................................... 168
C.5.3.6- Liberado (RLSD, released): .......................................................................... 168
C.5.3.7- Liberación completa (RLC, release complete): ............................................ 168
C.5.3.8- Subsistema autorizado (SSA, subsystem-allowed): ...................................... 169
C.5.3.9- Subsistema prohibido (SSP, subsystem-prohibited): .................................... 169
C.5.3.10- Prueba de estado de subsistema (SST, subsystem-status-test): .................. 169
C.5.3.11- Dato unidad (UDT, unitdata): .................................................................... 169
C.5.3.12- Dato unidad ampliado (XUDT, extended unitdata): .................................. 169
C.5.3.13- Servicio de dato unidad ampliado (XUDTS, extended unitdata service): . 170
C.5.3.14- Subsistema congestionado (SSC, subsystem congested): ........................... 170
C.5.3.15- Dato unidad largo (LUDT, long unitdata): ................................................ 170
C.5.3.16- Servicio de dato unidad largo (LUDTS, long unitdata service): ................ 170
C.5.4- Parámetros de mensajes del SCCP ...................................................................... 171
C.5.4.1- Parámetros a tener en cuenta ........................................................................ 171
C.5.5- Formato de los mensajes del SCCP ..................................................................... 176
C.5.5.1- Principios del formato .................................................................................. 176
C.5.5.2- Código de tipo de mensaje ........................................................................... 178
C.5.5.3- Parte fija obligatoria ..................................................................................... 178
C.5.5.4- Parte variable obligatoria .............................................................................. 179
C.5.5.5- Parte opcional ............................................................................................... 179
C.5.7- Mensajes y códigos de Gestión de SCCP (SCMG) ............................................. 179
C.5.7.1- Identificador de formato SCMG ................................................................... 180
C.5.7.2- Parámetros de mensajes SCMG ................................................................... 180
C.6- Usuarios del SCCP .................................................................................. 182
C.6.1- Establecimiento de conexión ............................................................................... 182
C.6.2- Liberación de la conexión.................................................................................... 184
C.6.3- Transferencia de datos de DTAP y BSSMAP ..................................................... 184
8
C.6.3.1- Función de distribución ................................................................................ 185
C.6.3.2- Transferencia de mensajes DTAP ................................................................ 185
C.6.3.3- Transferencia de mensajes BSSMAP ........................................................... 187
C.6.4- Servicio no orientado a conexión ........................................................................ 187
C.6.5- Uso del SCCP para operación y mantenimiento ................................................. 187
C.6.5.1- Servicio sin conexión.................................................................................... 188
C.6.5.2- Servicio orientado a conexión ...................................................................... 188
C.6.6- El BSSMAP ......................................................................................................... 189
C.6.6.1- Procedimientos del BSSMAP....................................................................... 189
C.6.6.2- Mensajes de BSSMAP.................................................................................. 190
C.6.7- El DTAP .............................................................................................................. 191
C.6.7.1- Procedimientos del DTAP ............................................................................ 192
C.6.7.2- Mensajes de DTAP ....................................................................................... 192
http://etsi.org ....................................................................................................................... 197
Apéndice D ............................................................................................................... 198
D.1- Diagrama de clases del domino .............................................................................. 199
D.2- Diagrama de clases de la vista de la aplicación...................................................... 200
D.3- Clases ..................................................................................................................... 201
9
Capítulo 1- Definición del Proyecto
1.1- Introducción
Cuando se crea una tecnología, en este caso de telecomunicaciones (GSM,

Global System Mobile), las instituciones normalizadoras, incorporando varios
grupos de trabajo, llegan a regular y estandarizar los procesos y procedimientos
que manejan todas las comunicaciones de dicha tecnología. Así, todas las
interfaces (enlaces de comunicación) entre equipos, son normalizadas para
funcionar de acuerdo con una regla de entendimiento.
La ETSI (European Telecommunication Standard Institute), junto con otras

instituciones que trabajaron en la estandarización de GSM, definieron las
interfaces entre los equipos que componen la red celular para que fueran abiertas,
esto quiere decir, que puedan interconectarse equipos de distintos fabricantes, lo
que genera la problemática de que a menudo no haya un correcto entendimiento
mutuo entre las partes.
Podemos afirmar que una red celular móvil GSM puede estar constituida por
equipos de distintos fabricantes (puesto que sus interfaces así lo permiten), no
obstante, podemos también consignar que seguramente tendrá problemas de
comunicación en sus interfaces. Una herramienta apropiada para analizar este tipo
de problemas son los analizadores de protocolos de interfaz.
Por otro lado un analizador de protocolo en este caso de la interfaz A del sistema
GSM es una herramienta que permite presentar los mensajes a nivel humano para
que una persona experimentada pueda analizar:
- problemas de funcionamiento.
- como inciden las acciones o modificaciones de parámetros de los equipos en la
señalización.
Un analizador de protocolo es además una herramienta de comprensión y estudio

de los protocolos.
10
1.2- Objetivo
El proyecto tuvo dos objetivos:
Primer objetivo: Estudiar el sistema de señalización Nº 7 de ITU-T en general, y en

particular la pila de protocolos correspondiente a la interfaz A del sistema GSM. El
estudio se focalizó en entender el funcionamiento de la interfaz y la estructura del
protocolo, a los efectos de posibilitar el segundo objetivo.
Segundo objetivo: Diseñar un analizador de interfaz A del sistema GSM, basado

en el análisis de archivos de registro de transferencia de señalización en dicha
interfaz.
1.3- Definición
Un analizador de protocolo es un dispositivo que recoge información de enlaces

de comunicación y realiza su decodificación. Es una herramienta empleada
generalmente en el análisis y caracterización de los problemas que se produce en
las interfaces entre diferentes equipos de una red de telecomunicaciones.
1.4- Alcance
El alcance del proyecto es el desarrollo de un analizador de protocolo para la

interfaz A de GSM, definida entre el MSC y el BSS, basado en el análisis de
archivos de registro de transferencia de señalización en dicha interfaz. Esto
significa que se diseñó un analizador “off-line”. Este analizador desarrollado
permite el análisis de toda la pila de protocolos de la interfaz A.
El análisis “off-line” típicamente es aplicado para estudiar registros de larga

duración de señalización, resultantes de demultiplexar uno o varios time slots de
señalización, de las tramas que los transportan, y registrarlos en archivos de tipo
secuencial. Estos archivos son posteriormente estudiados con herramientas de
análisis.
11
Como se observa en la Figura 1.1, la demultiplexación de las tramas E1 se realizó
con equipamiento fuera del alcance del proyecto. Se consideró como herramienta
de hardware posible el equipo k1103 propiedad de ANTEL (Administración
Nacional de Telecomunicaciones), que demultiplexa tramas E1 para obtener los
time slots de señalización, interpreta los protocolos HDLC de cada enlace y
almacena los octetos resultantes en archivos que posteriormente pueden ser
analizados. Este instrumento puede ser conectado por medio de la interfaz serial
(RS-232C) a otra computadora que realice el análisis, e incluso soporta la
inclusión de una tarjeta de red. El sistema operativo que ejecuta el instrumento de
ANTEL es Windows for Workgroups (3.11), debido a que fue adquirido en el año
1997, no obstante esto se puede interconectar sin problemas con equipos que
emplean sistemas operativos más avanzados, y soporta la incorporación de tarjeta
de red Ethernet de 10 Mbps.
ETAPA PREVIA
BSS MSC
MSU
K1103 CD o Diskette
Entrada de la
aplicación
Salida de la
aplicación
Etapa del proyecto
Figura 1.1
La aplicación fue desarrollada en Java, para permitir que pueda ejecutarse en

cualquier sistema operativo (Windows, DOS, Unix, etc.), y sobre prácticamente
cualquier plataforma de hardware.
El analizador de protocolo desarrollado permite realizar una decodificación

completa de cualquier unidad de señal de mensaje que se transfiere en la interfaz
A del sistema GSM. El diseño consideró mensajes de gestión de red, testeo y
mantenimiento y SCCP y sus usuarios (BSSMAP, DTAP, BSSOMAP).
La visualización de la decodificación de los mensajes se diseñó de modo que se

puede realizar con diferentes niveles de detalle, pudiéndose ver en formato de
12
línea, solo los campos más importantes (tiempo, origen, indicador de servicio, tipo
de mensaje, usuario y mensaje de usuario), o en ventanas individuales cada uno
de los campos con su denominación y la decodificación de sus valores.
El analizador tiene implementada las funciones de búsqueda de mensaje por
tiempo, filtrado de mensaje según las características del mensaje y la opción de
guardar en archivos de texto el análisis detallado de cada mensaje.
Las características de los mensajes que se consideraron para el filtrado son:
 tiempo (eligiendo un rango de tiempo),

 código de punto de señalización de origen,
 código de punto de señalización de destino,
 indicador de servicio
 tipo de mensaje
 usuario de SCCP
1.5- Analizador “off-line” versus “on-line”
A la hora de establecer el alcance del proyecto fue necesario tomar una decisión
acerca del tipo de analizador a desarrollar. Existen dos tipos de analizadores de
protocolo, los analizadores “on – line” (en tiempo real) y los analizadores “off –
line”.Hubo dos factores que fueron esenciales en la decisión: costo y tiempo.
El procesar protocolos en tiempo real resulta en un elevado costo de desarrollo del

analizador, dado que a medida que reciben los octetos del protocolo HDLC se
analizan y visualizan en la pantalla del equipo. Considerando la complejidad de
integrar hardware de demultiplexación de tramas de transporte (generalmente E1),
para obtener los time slots de señalización, en la misma computadora donde se
produce el análisis, demanda una significativa capacidad de procesamiento de
ésta, o la implementación de hardware adicional específico.
Además del costo de implementación del hardware adicional, tal proyecto

requeriría mayor tiempo o un número mayor de integrantes del grupo, no solo para
el desarrollo del hardware sino también para la implementación de un software en
tiempo real que involucra consideraciones especiales.
13
El análisis off-line es una alternativa económica para posibilitar el estudio
mensajes en ciertos protocolos, generalmente de estructura compleja, que no son
fáciles de procesar en tiempo real.
La aplicación desarrollada permite únicamente el análisis “off-line”. En el capítulo 9

realizamos un análisis de una posible solución a implementar como diseño de
software y hardware que permitan realizar el análisis “on-line”.
1.6- Aplicaciones de los analizadores de protocolos de

señalización
En particular la interfaz denominada A por la ETSI, comunica la Central de

Conmutación Móvil con el Subsistema de Estación Base. Esta interfaz maneja un
gran número de señales, que hacen al correcto funcionamiento del sistema; si en
ella existe alguna falta de entendimiento entre las partes, no se establece la
comunicación relacionada con algunas de las actividades, por ejemplo, realizar un
traspaso de frecuencias, buscar un terminal, encriptar la información,
autenticación, etc.
La interfaz A tiene a su cargo la gestión de la movilidad y el control de conexiones

y mensajes relativos a los recursos de radio. Por eso es de gran utilidad
desarrollar un analizador de dicha interfaz, que permita interpretar cualquier
problema entre las partes.
Considerando que los analizadores de señalización interpretan los protocolos de

señalización empleados en los enlaces de interconexión entre los distintos nodos
de una red de telecomunicaciones, es posible obtener información relevante que
surge de la correlación de la información recogida con las secuencias de mensajes
esperadas según las especificaciones técnicas que se aplican. De esta forma
permite al usuario del analizador detectar problemas de funcionamiento entre las
partes o ver como inciden las acciones o modificaciones de parámetros de los
equipos en la señalización.
Una herramienta útil del analizador de protocolo que desarrollamos es el filtrado

de mensajes de gestión de SCCP. A partir de este tipo de mensajes se puede
obtener información del estado de la red, como puntos o enlaces caídos.
14
El analizador de protocolo que hemos desarrollado no incluye herramientas de
filtrado sofisticadas como búsqueda de “Calling Party” o “Called Party”. Nuevas
funcionalidades podrían ser agregadas en una versión futura. Con una
herramienta de filtrado apropiada, un analizador de protocolo permite visualizar
una transacción completa entre dos usuarios y así ver el intercambio de mensajes
que se produce por ejemplo al establecer una conexión, liberar una llamada,
asignación de recursos, etc.
Un analizador de protocolo todavía más completo puede formar parte de equipos

más complejos en dónde sea posible la detección de fallas tales como la pérdida
temporal de un enlace, o fallas esporádicas en el intercambio de mensajes entre
nodos de la red, que conducen a comunicaciones fallidas o pérdida de
prestaciones que se deberían proporcionar a los clientes que las contratan, etc.
Referencias para éste capítulo:
www.telefonica
15
Capítulo 2- Conceptos previos
El estudio del sistema GSM, la interfaz A y su pila de protocolos se desarrolla en

los apéndices. En este capítulo se definen los conceptos más importantes para
permitir una comprensión más clara de la aplicación.
2.1- GSM (Global System for Mobile Comunication)
Es un sistema de comunicación celular digital. Fue desarrollado con el fin de crear

un estándar común europeo de telefonía móvil, pero que fue rápidamente
aceptado en el resto del mundo.
2.1.1- Servicios y facilidades del sistema
 Teleservicios
 Servicios portadores
 Servicios suplementarios
2.1.2- Arquitectura del sistema GSM
El sistema completo está formado por un número de entidades funcionales. La

figura 2.1 muestra las entidades funcionales del sistema y sus interconexiones.
Estas entidades son:
 La estación móvil (MS)
 El subsistema de estación base (BSS)
 La central de conmutacón móvil (MSC)
 Registro de localización de abonado (HLR)
 Registro de localización de visitante (VLR)
 Centro de autenticación (AuC)
 Registro de llamada de grupo (GCR)
 Central de operación y mantenimiento (OMC)
16
Figura 2.1
2.2- Interfaz A
Interfaz de señalización definida entre el BSS y el MSC. Su señalización está

estructurada tomando como ejemplo el modelo de referencia de interconexión de
sistemas abiertos (OSI) y se basa en el Sistema de Señalización por Canal Común
Nº 7 de ITU-T.
La interfaz BSS–MSC debe ser capaz de soportar todos los servicios ofrecidos a
los usuarios y abonados de GSM. Además debe permitir la asignación de recursos
de radio adecuados en la PLMN (Public Land Mobile Network), y la operación y
mantenimiento de estos recursos.
2.2.1- Estructura de la interfaz
La definición de la interfaz sigue un modelo de capas el cual se muestra en la

Figura 3.2.
17
Figura 2.2 - Modelo de referencia del protocolo de señalización
2.2.2- Clases de mensajes de señalización de la interfaz
Las señales entre el BSS y el MSC se clasifican de la siguiente manera:

i) Mensajes de DTAP Mensajes de BSSAP
ii) Mensajes de BSS
iii) Operación y Mantenimiento del BSS
2.2.3- Unidades de señalización
Existen tres tipos de unidad de señalización: unidades de señalización de mensaje

(MSU), unidades de señalización del estado del enlace (LSSU) y unidades de
señalización de relleno (FISU). El análisis se aplicará a las unidades de
señalización de mensaje. En la Figura 2.3 se muestran los formatos básicos de
las unidades de señalización.
18
F B
F CK SIF SIO LI I FSN I BSN F
B B
Primer bit
8 16 8n, n  2 8 2 6 1 7 1 7 8 transmitido
a) Formato básico de una unidad de señalización de mensaje (MSU)
F B
F CK SF LI I FSN I BSN F
B B
Primer bit
8 16 8 ó 16 2 6 1 7 1 7 8 transmitido
b) Formato de la unidad de señalización del estado del enlace (LSSU)
F B
F CK LI I FSN I BSN F
B B
Primer bit
8 16 2 6 1 7 1 7 8
transmitido
c) Formato de la unidad de señalización de relleno (FISU)
T1156540-93
BIB Bit indicador inverso (backward indicator bit)

BSN Número secuencial inverso (hacia atrás) (backward sequence number)
CK Bits de control de errores (check bits)
F Bandera (flag)
FIB Bit indicador directo (forward indicator bit)
FSN Número secuencial directo (hacia adelante) (forward sequence number)
LI Indicador de longitud (length indicator)
n Número de octetos en el SIF
SF Campo de estado (status field)
SIF Campo de información de señalización (signalling information field)
SIO Octeto de información de servicio (service information octet)
Figura 2.3
19
Capítulo 3 - Especificación de Requerimientos
3.1- Propósitos Generales
El proyecto tiene por objeto crear un sistema de análisis “off-line” del protocolo de
la interfaz A, del sistema GSM, basado en el análisis de archivos de registro de
transferencia de señalización en dicha interfaz.
3.2- Metas
La meta es obtener un análisis completo “off-line” de las unidades de mensaje de

señalización sobre la interfaz A, a partir de archivos de registro de transferencia de
señalización.
Más concretamente, la meta incluye:
 Realizar una decodificación completa de cualquier unidad de señal de

mensaje definida para la interfaz A del sistema GSM. Es decir que se
decodificarán los mensajes, campo por campo, de gestión de red, testeo y
mantenimiento, SCCP y sus usuarios (BSSMAP, DTAP, SCMG,
BSSOMAP). Los mensajes de BSSOMAP (formato propietario) se
mostrarán en forma hexadecimal.
 Obtener una descripción breve para cada mensaje con la siguiente
información:
o Tiempo del mensaje
o Origen (OPC)
o Destino (DPC)
o Indicador de servicio: MTP, SCCP, T&M
o Tipo de mensaje
o Usuario de SCCP: BSSMAP, DTAP, BSSOMAP, SCMG
o Tipo de mensaje de usuario
 Búsqueda de mensajes por tiempo.
 Filtrado de mensajes a partir de las siguientes características:
o Rango de tiempo
o OPC
o DPC
20
o Indicador de servicio
o Tipo de mensaje
o Usuario de SCCP
 Generar archivos de texto conteniendo la descripción detallada de los
mensajes seleccionados.
3.3- Requerimientos específicos
3.2.1- Requerimientos funcionales
Ref # Función Categoría

R1.1 Procesar archivo de mensajes. Evidente
R1.2 Analizar los mensajes contenidos en el archivo. Evidente
R1.3 Mostrar el análisis en forma detallada (campo por campo). Evidente
R1.4 Mostrar el análisis en una tabla (hora del mensaje, OPC, Evidente
DPC, indicador de servicio, tipo de mensaje, usuario de
SCCP, tipo de mensaje de usuario).
R1.5 Buscar mensajes que se enviaron en una hora Evidente
determinada.
R1.6 Filtrar mensajes de acuerdo a sus características (rango Evidente
de tiempo, OPC, DPC, indicador de servicio, tipo de
mensaje, usuario).
R1.7 Guardar en un archivo la descripción detallada de los Evidente
mensajes seleccionados.
3.3.2- Requerimientos no funcionales
Requisitos de interfaz del sistema
El sistema debe interactuar con un elemento externo que proporcionará los

mensajes a analizar. Esta interfaz establece restricciones de relevancia para el
sistema.
21
Como los archivos .REC generados por el equipo K1103 no tienen un formato
leíble , se utiliza un programa SHOWREC que transforma los archivos con formato
.REC a archivos .TXT en formato hexadecimal.
Estos archivos .TXT serán la entrada del sistema.
3.3.3- Atributos del software
En el cambiante mundo de las telecomunicaciones cuando se intenta obtener

como resultado de un proyecto una aplicación de software, el producto principal es
un software que satisfaga las necesidades cambiantes de sus usuarios y la
empresa. Para que éste sea desarrollado con calidad duradera, se debe elaborar
una sólida base arquitectónica que sea flexible al cambio. Con tal fin es necesario
que el software tenga los siguientes atributos:
 Eficiencia: buen uso de los recursos.

 Transportabilidad: entre plataformas distintas.
 Verificabilidad: facilidad de comprobar el software.
 Integridad: protección de sus componentes.
 Facilidad de uso.
 Corrección: hacer lo que se pide sin fallos.
 Robustez: salvar situaciones anormales.
 Extensibilidad: capacidad de cambio o evolución.
 Reutilización: ahorro de trabajo.
 Compatibilidad: facilidad de combinar subprogramas.
Plataforma
Como debe correr sobre el sistema operativo del sistema de Operación y

Mantenimiento y éste es un sistema propietario, el analizador debe poder
ejecutarse en la plataforma de Operación y Mantenimiento del fabricante
particular. Es de interés que por lo menos se ejecute en las plataformas Windows
y Unix.
22
3.4- Características del usuario
Actor: Operador
Descripción: Una persona responsable de la operación, mantenimiento o
administración de la red.
3.5- Diagrama de los casos de uso
Obtener análisis de
mensajes con una
característica en común
Extiende
Buscar un mensaje
Extiende ocurrido en un tiempo
Obtener análisis de
específico
mensajes
Extiende
Generar un archivo
con el análisis
detallado de mensajes
23
3.6- Casos de Uso
3.6.1- Obtener análisis de mensajes
Caso de Uso: Obtener análisis de mensajes

Actor: Operador de la red
Propósito: Visualizar la descripción detallada y la descripción breve de
los mensajes contenidos en un archivo.
Resumen: El operador abre el archivo que desea analizar, luego analiza
los mensajes.
Tipo: Primario
Referencias R1.1, R1.2, R1.3, R1.4
cruzadas:
Sección Acción del actor Respuesta del sistema

principal
Flujo normal de 1. Este CU empieza cuando 2. El sistema importa una
eventos el operador abre un archivo porción del archivo al buffer.
de flujo de mensajes.
3. El operador elige la opción 4. El sistema analiza los
de analizar. mensajes importados y los
muestra en pantalla en una
tabla de descripción breve y
en un área de texto de
descripción detallada del
mensaje seleccionado.
Flujos El archivo no es analizable. El operador puede elegir un nuevo
alternativos archivo o salir.
3.6.2- Buscar un mensaje ocurrido en un tiempo específico
Caso de Uso: Buscar un mensaje ocurrido en un tiempo específico

Propósito: Encontrar dentro de los mensajes contenidos en el archivo el
primer mensaje transmitido a una hora en particular.
Resumen: El operador abre el archivo de mensajes, obtiene el análisis
de todos los mensajes, finalmente elige la opción de buscar
tiempo e ingresa el tiempo que desea buscar.
Tipo: Secundario
24
Referencias R1.1, R1.2, R1.3, R1.4, R1.5
cruzadas:

principal
Flujo normal de Extiende de Caso de Uso 1
eventos
5. El operador elige la opción
6. El sistema busca el primer
de buscar por tiempo. mensaje ocurrido en el tiempo
indicado, selecciona en la
tabla de descripción breve el
mensaje encontrado y
muestra su análisis completo
en el área de texto.
Flujos La hora no es encontrada. Se abre una ventana con el
alternativos mensaje “No se produjo mensaje a la hora hh:mm:ss”
3.6.3- Obtener mensajes con una característica en común
Caso de Uso: Obtener mensajes con una característica en común

Propósito: Visualizar la descripción detallada y la descripción breve de
los mensajes de un archivo que tienen una característica en
común.
de todos los mensajes, finalmente elige la opción de filtrado
correspondiente.
Tipo: Secundario
cruzadas:

principal
eventos
5. El operador elige la opción 6. El sistema obtiene solo los
de filtrar de acuerdo a una mensajes que poseen esa
característica en particular e característica y actualiza la
ingresa la característica tabla.
Flujos No se encontró mensaje con la característica seleccionada.

alternativos Se abre una ventana con el mensaje “No se encontró mensaje
con la característica seleccionada”
25
3.6.4- Generar un archivo con el análisis detallado de mensajes
Caso de Uso: Generar un archivo con el análisis detallado de mensajes

Propósito: Obtener un archivo conteniendo la descripción detallada de
una selección de mensajes.
de todos los mensajes, elige la opción de guardar e ingresa el
nombre del mensaje a crear.
Tipo: Secundario
cruzadas:

principal
eventos
5. El operador selecciona un 6. El sistema crea un archivo
conjunto de mensajes en la con las características
tabla, elige la opción de indicadas y escribe en él la
guardar e ingresa el nombre y descripción detallada de cada
la ubicación del archivo a mensaje seleccionado.
generar.
Flujos El nombre de archivo ya existe. Abre una ventana que
alternativos consulta si se quiere remplazar el archivo existente.
Referencias para éste capítulo
PRESSMAN, Roger S. 1998. 4ta Ed. Ingeniería del software. Madrid: McGraw
Hill/Interamericana de España.
LARMAN, Craig. 1999. 1ra Ed. UML y Patrones: Introducción al análisis orientado a
objetos. México: Prentice Hall
26
Capítulo 4- Elección del lenguaje de programación
4.1- JAVA
A partir de los requisitos obtenidos hemos encontrado que el lenguaje de

programación JAVA, es el más apropiado para realizar el diseño debido a que:
- JAVA es independiente de la plataforma por lo tanto el programa puede ser

ejecutado en sistemas operativos distintos. Los programas JAVA logran esa
independencia mediante una máquina virtual. Ésta toma los programas de
JAVA compilados y traduce sus instrucciones en comandos que puede
manejar un sistema operativo. El mismo programa compilado, conformado
en un formato denominado CODIGO DE BYTES, puede ser ejecutado en
cualquier plataforma y sistema operativo que tenga una máquina virtual.
Esto lo podemos ver en la siguiente Figura 4.3.
- JAVA está orientado a objetos, siendo este el modelo que hemos elegido
para el diseño e implementación.
- JAVA posee APIs (Application Programming Interface) para manejar
documentos XML.
WINDOW
Código de bytes
Código de JAV A de JAVA
(independiente Interprete de
de la plataforma) JAVA (Pentium)
WINDOW
Compilador de
JAVA
Interprete de JAVA
(Power PC)
WINDOW
Interprete de
JAVA (SPARC)
Figura 4.3
27
4.2- XML
Para que el analizador reconozca los mensajes debemos hacer que el programa
entienda los códigos correspondientes a ellos e interprete además si posee
campos y parámetros, por ejemplo. Para que un programa entienda
especificaciones de formato es necesario que estos se escriban en un lenguaje
marcado, puesto que para un sistema informático un texto no es más que una
cadena de caracteres carente de sentido. El lenguaje marcado agrega sobre el
documento pistas (marcas) sobre el significado de la información que contiene.
Como JAVA puede manejar el lenguaje marcado XML (Extensible Markup
Languages) a través de APIs apropiadas, lo hemos elegido como lenguaje para
especificaciones de formato de los mensajes, parámetros y elementos de
información.
XML al igual que la plataforma Java hace los datos portables. Los APIs de Java
para XML hacen fácil el uso de documentos escritos en ese lenguaje marcado. En
definitiva obtenemos portabilidad de datos, portabilidad de código y facilidad
de uso.
XML (eXtensible Markup Language) es un estándar industrial para representar

datos, independiente del sistema. Encierra los datos en etiquetas, éstas tienen
relación con el significado del texto que encierran. Como las etiquetas XML
especifican el contenido y la estructura de los datos que encierran es posible
hacer cosas como archivar o buscar datos.
XML es extensible, permitiéndonos escribir nuestras propias etiquetas XML para

describir nuestro contenido.
Está escrito en formato de texto, lo pueden leer tanto los humanos como los
softwares de edición de texto. Las aplicaciones pueden analizar y procesar
documentos XML, y los humanos también pueden leerlos en caso de que haya
algún error en el procesamiento. Otra característica es que como un documento
XML no incluye instrucciones de formateo, puede mostrarse de varias formas.
Mantener los datos separados de las instrucciones de formateo significa que los
mismos datos pueden publicarse en diferentes medios.
28
4.2.1- APIs de Java para XML
Se dividen en dos categorías: aquellas que tratan directamente con documentos

XML y aquellas que tratan con procedimientos:
 Oientadas a Documento:
 API Java para Procesar XML (JAXP) — procesa documentos XML
usando varios analizadores.
 Arquitectura Java para Uniones XML (JAXB) — mapea elementos
XML a clases del lenguaje Java.
 Orientadas a Procedimiento:
 API Java para Mensajería XML (JAXM) — envía mensajes sobre
Internet de una forma estándar.
 API Java para Registros XML (JAXR) — proporciona una forma
estándar para acceder a registros de negocios que comparte
información.
La característica más importante de los APIs de Java para XML es que todos
soportan los estándares de la industria, así se aseguran la interoperabilidad.
Varios grupos de estandarización, como el "World Wide Web Consortium" (W3C) y
la "Organization for the Advancement of Structured Information Standards"
(OASIS), han estado definiendo formas estándares de hacer las cosas para que
las empresas que sigan estos estándares pueden hacer que sus datos y
aplicaciones funcionen juntos.
Otra característica de los APIs de Java para XML es que permiten una gran
flexibilidad. Por ejemplo, el código JAXP puede usar varias herramientas para
procesar un documento XML, y el código JAXM puede usar varios protocolos de
mensajes. Los implementadores también tienen flexibilidad. Los APIs Java para
XML definen requerimientos de compatibilidad estricta para asegurarse que todas
las implementaciones siguen la funcionalidad estándar, pero también le dan a los
desarrolladores una gran libertad para proporcionar implementaciones hechas a
medida para usos específicos.
29
Capítulo 5- Estimación del Riesgo
5.1- Identificación de los riesgos
Se trata de la especificación de las amenazas al plan de proyecto y elaboración de

una lista de comprobación de elementos de riesgo. Existen dos tipos diferenciados
de riesgos: genéricos y específicos del producto.
Los riesgos específicos de producto responden a la pregunta: ¿qué características
especiales de este producto pueden estar amenazadas por nuestro plan de
proyecto?
 Insuficiente comprensión del dominio del problema. A.1

 Ausencia de antecedentes en el dominio del problema. B.1
 Herramientas de software inadecuadas o insuficientes. B.2
 Insuficiente entrenamiento en el lenguaje de programación a usar. B.3
 Incoherencia en la distribución de tareas que le quite cohesión al proyecto. B.4
 Falta de experiencia en estimaciones de tamaño y esfuerzo. B.5
 Disposición insuficiente del tiempo necesario para el estudio de las normas
involucradas. A.2
 Cronograma inadecuado. B.6
 Requerimientos poco claros. A.3
 Hacer un mal diseño de la arquitectura del sistema. A.4
5.2 - Análisis de los riesgos
Se refiere a buscar toda la información posible sobre estos riesgos que nos
permitan tomar las acciones correctas, evaluar su impacto, probabilidad, clasificar
el riesgo, priorizarlo, etc.
Según la metodología SEI, en este caso:
 El 40% de los riesgos pertenecen al grupo A: ingeniería del producto

 El 60% de los riesgos son del grupo B: ambiente de desarrollo.
30
No presentándose riesgos del tipo C en nuestro proyecto.
Distribución de los riesgos por

grupo
40%
Grupo A
60% Grupo B
5.3- Análisis de las acciones tomadas
Para riesgos clasificados como B se tomaron las siguientes medidas con el fin de
minimizar/eliminar el riesgo.
 B.1 Definición del tiempo apropiado para estudiar la tecnología GSM y SS7.
 B.2 Hablar con el tutor y gente que maneja el instrumento K1103 para saber
como se obtienen los datos a partir del instrumento y que herramienta utilizar
para depurarlo, con el fin de aplicarle el análisis.
 B.3 Definición del tiempo apropiado para estudiar Java y XML y obtención de la
Bibliografía necesaria para la consulta permamente. Establecer contacto en los
sitios de internet dónde poder evacuar consultas. Contactar personas con
conocimiento de los lenguajes indicados.
 B.4 División de tareas : Análisis mensajeX / XMLX.
Análisis parámetros / XML .
Diseño Interfaz gráfica.
Integración.
 B.5 y B.6 Planificación y coordinación.
Para los riesgos clasificados como A se tomaron las siguientes decisiones
 A.1 Desglose minucioso y completo extraído de las normas involucradas del

protocolo estandarizado de la interfaz A, donde radica el total del problema a
resolver y a partir del cual se debe diseñar el modelo.
31
 A.2 Definición del tiempo que involucra el estudio minucioso de la norma.
 A.3 Hablar con el tutor para esclarecer los requerimientos.
 A.4 Hacer un pequeño modelo (análisis de un tipo de mensaje de estructura
fija), probar el modelo, si funciona expandirlo y mejorarlo a través de las
pruebas.
5.4 - Proyección del Riesgo
La proyección del riesgo o estimación del riesgo intenta medir cada riesgo de dos
maneras:
1. La probabilidad de que el riesgo sea real.

2. La consecuencia de los problemas asociados si ocurriera.
A partir de los riesgos percibidos en la sección 5.1 elaboramos una tabla 5.2 de
Riesgos en la cual anotamos:
 Probabilidad de aparición del riesgo.
 Impacto del riesgo en el proyecto y en el producto.
Cada componente de riesgo se valora usando la caracterización presentada en la

tabla 5.1 de la Evaluación del impacto.
Componente Rendimiento Planificación

Categoría Temporal
Catastrófico 1 Dejar de cumplir los requisitos provocaría el
fracaso de la misión.
Fecha de entrega inalcanzable.
2 Degradación significativa para no alcanzar el

rendimiento técnico.
Crítico 1 Dejar de cumplir los requisitos degradaría el Posibles retrasos de la fecha de entrega.
rendimiento del sistema hasta el punto donde el
éxito es cuestionable.
2 Alguna reducción en el rendimiento técnico.
Marginal 1 Dejar de cumplir los requisitos provocaría la Planificación temporal realista,
degradación de la misión secundaria. alcanzable.
2 De mínima a pequeña reducción en el
rendimiento técnico.
Despreciable 1 Dejar de cumplir los requisitos provocaría Fecha de entrega fácilmente alcanzable.
inconvenientes o impactos no operativos
2 No hay reducción en el rendimiento técnico.
Tabla 5.1
32
RIESGOS PROBABILIDAD IMPACTO
1-Insuficiente comprensión del 30% 2
dominio del problema.
2-Ausencia de antecedentes en el 90% 3
dominio del problema.
3-Herramientas de software 60% 2
inadecuadas o insuficientes.
4-Insuficiente entrenamiento en el 90% 1
lenguaje de programación a usar.
5-Incoherencia en la distribución 50% 2
de tareas que le quite cohesión al
proyecto.
6-Falta de experiencia en 100% 2
estimaciones de tamaño y
esfuerzo.
7-Disposición insuficiente del 80% 1
tiempo necesario para el estudio
de las normas involucradas.
8-Cronograma inadecuado. 30% 2
9-Requerimientos poco claros. 80% 2
10-Hacer un mal diseño de la 60% 1
arquitectura del sistema.
Tabla 3.2
Valores de impacto:
1- Catastrófico
2- Crítico
3- Marginal
4- Despreciable
5.5- Evaluación del riesgo
En este punto de la gestión del riesgo, hemos establecido un conjunto de ternas

de la forma:
[ri,l i,x i],
donde ri es el riesgo, l i es la probabilidad del riesgo y x i es el impacto del riesgo.

Durante la evaluación del riesgo se examina la exactitud de las estimaciones que
fueron hechas durante la proyección del riesgo se intenta dar prioridad a riesgos
33
que no se habían cubierto y se empieza a pensar las maneras de controlar y/o
impedir los riesgos que sean más probables.
Se define el nivel de referencia de riesgo puesto que si una combinación de

riesgos crea problemas de manera que uno o más de estos niveles de referencias
se excedan, se parará el trabajo.
Un nivel de referencia de riesgo tiene un solo punto, denominado punto de

referencia o punto de ruptura, en el que la decisión de seguir con el proyecto o
dejarlo son igualmente aceptables.
RIESGO
Meses 1
12
11
10 Zona de abandono del
9 proyecto
8
7
6 Pto.de ruptura
5
4
3
2
1
100 80 60 40 20
Efectividad de la
solución
34
RIESGO
Meses
3
12
11 Zona de abandono
10 del proyecto
9
8
7 Pto.de ruptura
6
5
4
3
2
1
100 80 60 40 20
Efectividad de
la solución
RIESGO
4
Meses
12 Zona de abandono
11 del proyecto
10
9
8
Pto.de
7 ruptura
6
5
4
3
2
1
10 80 60 40 20
0 Efectividad de
la solución
35
RIESGO
Meses 5
12
11
Zona de abandono del
10
proyecto
9
8
Pto.de ruptura
7
6
5
4
3
2
1
100 80 60 40 20
Efectividad de la
solución
RIESGO
Meses
6
12
11
10 Zona de abandono
9 del proyecto
8
7
6
5 Pto.de ruptura
4
3
2
1
100 80 60 40 20
Efectividad de la
solución
36
RIESGO
Meses
7
12
11
Zona de abandono del proyecto
10
9
8 Pto.de ruptura
7
6
5
4
3
2
1
100 80 60 40 20
Efectividad de la
solución
RIESGO
Meses
8
12
11
10
9
proyecto
8
7
6
5
4
3
2 Pto.de ruptura
1
100 80 60 40 20
Efectividad de la
solución
37
RIESGO
Meses
9
12
11 Zona de abandono del
10 proyecto
9
8
7
Pto.de ruptura
6
5
4
3
2
1
100 80 60 40 20
Efectividad de la
solución
RIESGO
Meses
10
12
11
10
9
8
proyecto
7
6
5 Pto.de ruptura
4
3
2
1
100 80 60 40 20
Efectividad de la
solución
38
39
Capítulo 6 - Análisis
6.1- Dominio del problema
El dominio del problema se analiza en la Figura 6.1. Dentro del dominio del
problema consideramos las funciones relacionadas con el análisis de los
mensajes, no se consideran las funciones relacionadas con la visualización.
Como se definió en la meta del proyecto, el problema abarca el análisis de

cualquier MSU (definida en el apéndice C.2) que pueda ser transportada en la
interfaz A (detallada en el Apéndice B.1). Como se observa en el esquema de la
Figura 6.1, la MSU puede contener mensajes de servicio de MTP 3, Testeo y
Mantenimiento o SCCP. El campo SIO (service information octet) contiene la
información referente a este servicio. A partir de este campo el analizador
reconoce el tipo de servicio y realiza el análisis del mensaje correspondiente al
mismo.
Para cada tipo de servicio existe una cantidad determinada de posibles mensajes
con un formato determinado, que se describe e interpreta a partir de archivos
escritos en el lenguaje marcado XML. Esta información definida en el lenguaje
XML para cada mensaje especificará una manera única de interpretar el resto de
los campos o parámetros contenidos en el mensaje.
Para mensajes de servicio MTP 3 o T&M los campos contenidos en el MSU son
fijos y la forma de interpretación es sencilla una vez que se obtiene el tipo de
mensaje.
Para mensajes de servicio SCCP la interpretación de la información es más

compleja. Los mensajes de servicio SCCP contienen parámetros obligatorios, de
largo fijo o variable y parámetros opcionales, también de largo fijo o variable. Estos
parámetros están compuestos por un número fijo de campos, especificados en
otro archivo XML de especificación de parámetros.
Dentro de los parámetros contenidos en el mensaje puede estar presente el

parámetro de dato (correspondiente a un usuario del servicio SCCP), en cuyo
caso el analizador también lo analiza en detalle. Este dato puede pertenecer a los
usuarios BSSAP (BSSMAP y DTAP), BSSOMAP o mensajes de gestión de SCCP
40
(SCMG). Para cada uno de los casos existe un archivo escrito en el lenguaje XML
que describe los mensajes de usuario con sus campos, excepto para mensajes de
BSSOMAP.
Si el mensaje tiene parámetro de dirección llamada y dirección llamante (definidos

en el apéndice C.5) y el campo indicador de ruteo indica ruteo en SSN, el SSN
indicará el usuario del servicio. Si no se produce ruteo en SSN el usuario es
BSSAP (BSSMAP o DTAP). En este caso el parámetro de distribución indica cual
es el usuario del servicio.
En caso de que el usuario sea BSSAP o SCMG, analiza en el parámetro de dato,

el tipo de mensaje, y los elementos de información, definidos en otro archivo XML
o campos que el mensaje contenga. En caso de que el usuario sea BSSOMAP,
como no existe un protocolo correspondiente estandarizado, no hemos
implementado ningún protocolo, por lo tanto el parámetro de dato se muestra en
formato hexadecimal.
41
F BSN B FSN F LI SIO SIF CK F
I I MSU
B B
Subservice field Service

Nac o Int) Indicator
0 0 0 0
MENSAJE DE GESTION DE RED (MTP3)
0 0 0 1 MENSAJE DE TESTEO Y MANTENIMIENTO DE RED
Etiqueta H0 Hi
de ruteo 0 0 1 1 MENSAJE DE SCCP
Etiq.de
ruteo Parametros
T&M -parametros Descripcion
SCCP de
Codigo de -largo PF DATOS? del
Descripcion tipo de -largo PV parametro
Tipo de del mensjae -nombre
Descripcion Mensaje
mensaje de -descripcion
del mensjae
MTP 3 Parte fija
obligatoria SSN
Parte
0 0 0 0 0 0 0 1 Descripcion
Descripcion variable
obligatoria del mensaje
del mensjae DDU IL 1 1 1 1 1 1 1 0
Parte
BSSMAP opcional 1 1 1 1 1 1 0 1
Largo de las capas
Descripcion Parametros de subsiguientes
del mensaje Discriminacion
Descripcion SCMG
del mensaje
BSSOMAP
Parametros DLCI
Tipo de conex.de enlace
Descripcion de datos en la interfaz
del mensaje de radio
DTAP 0 0 0 0 0 S3 S2 S1
42
6.2- Identificación de clases
Luego de establecer el dominio del problema identificamos las clases necesarias

para cumplir con lo establecido. De esta forma identificamos las siguientes clases:
Pensamos en una clase Analizador que realice el análisis del archivo de mensajes
por medio de relaciones con el resto de las clases.
Una clase Mensaje que describa el objeto Mensaje que se identifique con un tipo de
mensaje de MTP 3, Testeo y Mantenimiento o SCCP en particular. Esta clase
contiene los atributos del objeto Mensaje, y los procedimientos de análisis del
mensaje.
Una clase Parametro que describa el objeto Parametro relacionado con un parámetro
de mensaje de SCCP, que contenga los atributos y procedimientos relacionados con
el parámetro.
Una clase MensajeUsuario que describa el objeto MenajeUsuario relacionado con un

mensaje de usuario del SCCP, que contenga los atributos y procedimientos
relacionados con el mensaje de usuario.
Una clase ElementoUsuario que describa el objeto ElementoUsuario relacionado con

un elemento de usuario, que contenga los atributos y procedimientos relacionados
con el elemento de usuario.
43
Una clase Campo que describa un objeto Campo, perteneciente a cualquier tipo de
mensaje, parámetro o elemento de usuario, que contenga los atributos relacionados
con el campo.
Para la Vista de la Aplicación se pensó en las siguientes clases:
Una clase Salida que sea la interfaz gráfica, que muestre el análisis de los mensajes
en forma detallada en un área de texto y los campos más importantes en una tabla.
Una clase Present que presente la barra del menú y los procedimientos relacionados
con cada ítem del menú.
Una clase Opciones contenga los procedimientos relacionados con el menú de

opciones.
6.3- Modelo de clases
El diagrama de clases que se definió para el dominio es el que se muestra en la

Figura 6.2. En la Figura 6.3 se muestra el diagrama de agregación de clases con la
cardinalidad.
44
Figura 6.2 - Diagrama de asociación
Figura 6.3 - Diagrama de agregación y cardinalidad
La clase Analizador está relacionada con las clases Parametro, Mensaje,

MensajeUsuario y ElementoUsuario porque contiene arreglos de objetos de estas
clases definidos a partir de la interpretación de la información contenida en los
archivos XML. A partir de la identificación de un mensaje en particular instancia a la
clase Mensaje para que realice el análisis de ese mensaje.
45
La clase Mensaje está relacionada con las clases Parametro, Mensaje,
MensajeUsuario, ElementoUsuario y Campo porque un mensaje en particular puede
contener un objeto de cualquiera de estas clases.
El diagrama de clase que se definió para la Vista de la Aplicación es el que se

muestra en la Figura 6.4. En la Figura 6.5 se muestra la cardinalidad entre las
clases.
Figura 6.4 – Diagrama de clases de la Vista de la Aplicación
Figura 6.5 – Cardinalidad entre clases
La clase Salida está relacionada con la clase Present porque de ella obtiene el menú
a presentar en pantalla y los datos a desplegar en el área de texto y en la tabla. Por
otro lado la clase Present obtiene de salida el modelo de tabla para poder actualizar
los datos.
La clase Present se relaciona con la clase Opciones porque a ella le solicita las
funciones de filtrado y búsqueda.
46
El dominio del problema y la interfaz gráfica se relacionan por medio de las clases
Analizador y Present. Present solicita a Analizador la tabla y la lista de mensajes
analizados.
Present Analizador
objetos. México: Prentice may
RUMBAUGH, James. 1991. 1ra Ed. Object-Oriented Modeling and Design. New Jersey:
Prentice Hall
47
Capítulo 7- Diseño del sistema
7.1- Diseño de los subsistemas
Considerando los requisitos funcionales, los cuales fueron presentados en el

Capítulo 3 junto con los casos de uso, se definieron para el diseño del sistema dos
subsistemas que se comunican ente sí a través de un enlace cliente/servidor. Estos
dos subsistemas son:
 El subsistema de dominio
 El subsistema de vista de la aplicación
En la Figura 6.2 se observa el modelo de colaboración entre los dos subsistemas.
Vista de la aplicación Dominio

Solicitud
Subsistema cliente Subsistema servidor
Estos subsistemas se relacionan a por medio de la siguiente relación de clases:
48
7.2- El subsistema de dominio
El subsistema de dominio es el que resuelve el análisis de los mensajes de la

Interfaz A. Resuelve el análisis del dominio del problema, que se definió en el
capítulo 6.
7.2.1- Diagrama de Clases
En el Apéndice D sección 1 se puede ver el diagrama del diseño de clases

correspondiente al Dominio.
Las clases se muestran en el la sección 3 del Apéndice D.
Analizador
La clase Analizador tiene como métodos fundamentales, el método constructor de

la clase, el método importar, el método analizar y distintos métodos para manejar los
archivos .XML.
En el método constructor de analizador se obtiene la dirección donde se encuentran

los archivos .XML y se inicializan las variables relacionadas con ellos.
El método importar trae al buffer las porciones del archivo a analizar en cantidades
de 10 Kbytes, conforme se vayan solicitando.
El método analizar se aplica al texto contenido en el buffer para obtener un objeto de

la clase ArrayList, lResultado, que contendrá el análisis de cada mensaje.
La clase Analizador tiene una relación de 1 a muchos con la clase Mensaje, tantos
como tipos de mensaje posibles definidos para la interfaz.
Mensaje
La clase Mensaje posee los métodos constructores que permiten crear objetos de la
clase convenientemente y el método analizar que devuelve un objeto, lResultado de
49
la clase String que poseerá el análisis del mensaje, otro objeto de la clase String,
mSI que posee tres estados (“0000”,”0001”,”0011”), otro objeto mUserPart que tiene
tres estados (“BSSMAP”, “DTAP”, OMAP), un objeto mOMAP, que tiene dos estados
(“true”, “false”) y otro objeto mDato, que tiene dos estados (“true” y “false”).
Los estados de estos objetos determinan una relación de asociación de esta clase
con otras.
Si el objeto mSI es igual a “0000” o “0001”, se establece una relación de asociación

de la clase Mensaje con la clase Campo. Si el objeto mSI es igual a “0011” se
establece una relación de uno a muchos de esta clase con la clase Parámetro. Si el
objeto mUserPart es igual a “BSSMAP” o “DTAP” y el objeto mDato es igual a “true”,
la relación establecida es con la clase MensajeUsuario y ElementoUsuario, al igual
que si el objeto mUserPart es igual a “OMAP”, el objeto mOMAP es igual a “true” y el
objeto mDato es igual a “true”.
Parametro
La clase Parametro posee los objetos de la clase String mNombre, mCodigo,

mContenidoDato, mRuteoEnSSN, mContenidoDato y mSSN y el objeto de la clase
ArrayList, mListaCampos y posee un método analizarParametros que devuelve un
objeto String, lResultado. La clase Parametro posee una relación de 1 a muchos
con la clase Campo.
ElementoUsuario
50
La clase ElementoUsuario tiene los objetos de la clase String mNombre, mCodigo,
mLargo, y un objeto de la clase ArrayList, mListaCampos y posee un método
analizarElemento que devuelve un objeto String, lResultado. La clase
ElementoUsuario posee una relación de 1 a muchos con la clase Campo.
Campos
La clase Campos posee los objetos de la clase String mNombre, mLargo, mTipo,
mLoop y de la Clase ArrayList, mListaValores y mListaSignificados.
Mensaje Usuario
La clase MensajeUsuario contiene los objetos de la clase String mNombre,

mCodigo y mDescripcion.
7.2.2- Descripción detallada
En la Figura 7.3 y Figura 7.4 se observan las etapas más importantes durante el
proceso del análisis de mensajes.
Carga por única vez la información

contenida en archivos XML
Se cargan los objetos ArrayList que

contendrán objetos con las características de
los mensajes, parámetros, campos,
elementos de información.
Obtención y análisis de mensajes
Obtención de los mensajes del archivo y

análisis de los mensajes a partir de la
obtención de los objetos relacionados con
los archivos XML
Figura 7.3
51
Como se ve en el primer proceso de la Figura 7.3, en la primera etapa del análisis se
carga la información contenida en los archivos XML en distintos ArrayList. Esto se
realiza en el método constructor de la clase Analizador, a partir de distintos métodos
que utilizan las APIs de JAVA para XML. Estos objetos y sus correspondientes
métodos son los que se muestran a continuación:
ArrayList mListaMensajesMtp3 = getMensajesMtp3();

ArrayList mListaParametros = getParametros();
ArrayList mListaMensajesSccp = getMensajesSccp();
ArrayLIst mListaMensajesTandM = getMensajesTandM();
ArrayList mListaMensajesSCMG = getMensajesSCMG();
ArrayList mListaElementosBSSMAP = getElementosBSSMAP();
ArrayList mListaMensajesBSSMAP = getMensajesBSSMAP();
ArrayList mListaElementosDTAP = getElementosDTAP();
ArrayList mListaMensajesDTAP = getMensajesDTAP();
Los métodos getMensajesMtp3(), getParametros(), getMensajesSccp(), etc. obtienen

cada elemento del archivo XML correspondiente, y del elemento, los atributos
correspondientes. Con las características de estos atributos van cargando en cada
posición del arreglo relacionado, objetos de la clase correspondiente; es decir,
objetos de la clase Mensaje, en los ArrayList mListaMensajesMtp3,
mListaMensajesTandM, mListaMensajesSccp, objetos de la clase Parámetro en el
ArrayList mListaParametros; objetos de la clase ElementosUsuario, en los ArrayList
mElementoBSSMAP y mElementoDTAP; y objetos de la clase MensajeUsuario, en
los ArrayList mListaMensajesDTAP y mListaMensajesBSSMAP y
mListaMensajesSCMG. Este proceso de carga de objetos ocurre una única vez al
inicio de la aplicación.
La siguiente etapa de la capa de análisis, es la obtención de los datos y el análisis

propiamente dicho de los mensajes. Esta etapa se muestra en la Figura 7.4.
En primer lugar se trae al buffer la porción del archivo a analizar. Luego se obtiene
de este texto contenido en el buffer, cada línea, con el fin de obtener el texto
correspondiente a la hora del mensaje y la MSU (unidad de señalización del
mensaje), para cada mensaje. El mensaje se encuentra en formato Hexadecimal por
lo que lo convertimos a binario. Luego colocamos esta información en un Arreglo de
tamaño 2Xn, donde las columnas son la hora y el mensaje en binario y las filas son
cada nuevo mensaje.
52
Archivo en formato .txt
Buffer
Obtención de los mensajes y hora

Se obtienen los mensajes importados al buffer, y se crea
una lista que contiene en cada posición, la hora de cada
mensaje y el mensaje en forma binaria
Análisis de todos los mensajes importados

Se obtiene el código de cada mensaje, se verifica que sea
un código perteneciente al protocolo de señalización de la
interfaz y si se cumplen las condiciones, se analiza.
Figura 7.4
Luego de la obtención, en un arreglo, de la información que vamos a utilizar del

archivo, se analizan los mensajes obtenidos. Este proceso es iterativo, para cada
mensaje y se muestra en la Figura 7.5.
El proceso iterativo de análisis de los mensajes es el siguiente:
Una vez que se tiene el mensaje en formato binario en un String, obtiene los campos
Indicador de Servicio y Código de Tipo de Mensaje. Si el Indicador de Servicio se
corresponde con un protocolo de la Interfaz A (MTP3, Testeo y Mantenimiento,
SCCP) y el código se encuentra en un objeto de la lista correspondiente a ese
Indicador de Servicio, entonces es un mensaje analizable, de lo contrario el resultado
del análisis será “Mensaje no analizable”.
Si el mensaje es analizable, obtiene el objeto de la clase Mensaje que se

corresponde con él. Este objeto contiene las características del mensaje, es decir,
nombre, descripción, lista de campos (en mensajes de servicio MTP3 y T&M) y listas
de parámetros obligatorios fijos y variables (en mensajes de servicio SCCP). Además
realiza las operaciones de análisis del mensaje, en un método analizar que recibe
dos String, el mensaje en forma binaria y la hora del mansaje.
53
Las operaciones del método analizar son las siguientes:
Durante todo el análisis actualiza dos objetos, uno de clase String, que guarda la
descripción detallada, en líneas, de cada campo del mensaje y otro de clase String[ ],
que guarda en cada posición los campos más importantes del mensaje (hora, OPC,
DPC, indicador de servicio, tipo de mensaje, usuario de SCCP y tipo de mensaje de
usuario). Todos los campos se obtienen utilizando punteros al String que tiene el
mensaje en forma binaria.
En primer lugar, este método analiza el encabezado del mensaje, este análisis es en
común para todos los mensajes. Este encabezado corresponde a los campos que
están antes del código del mensaje. Luego analiza el resto del mensaje,
dependiendo del servicio al que pertenece el mensaje (MTP 3, T&M, SCCP).
54
Búsqueda del código del tipo de
mensaje y el indicador de servicio
en el mensaje
¿SI es un indicador de
servicio de la interfaz?
¿El código corresponde a
un mensaje analizable?
Analizar encabezado del

mensaje
Analizar mensaje Analizar mensaje Analizar mensaje Mensaje no

de MTP3 de SCCP de T&M analizable
Resultado del análisis
Figura 7.5
Si el mensaje es de servicio MTP 3 o T&M obtiene los campos que ese tipo de
mensaje tiene, utilizando objetos de clase Campo, que se obtienen de la lista de
campos correspondiente a ese mensaje.
Si el mensaje es de servicio de SCCP, obtiene los parámetros obligatorios de largo

fijo y variable, utilizando objetos de clase Parametro, que se obtienen de las lista de
parámetros de largo fijo y parámetros de largo variable respectivamente. Los
parámetros opcionales se buscan a partir del campo de puntero a inicio de parte
55
opcional, obteniendo de la posición correspondiente el código del campo y a partir de
ahí el objeto correspondiente de la clase Parámetro.
El objeto de la clase Parametro, además de tener las características del parámetro,

como largo, nombre y lista de campos, posee un método “analizarParametro” que
realiza el análisis de los campos que tiene el parámetro.
El método “analizarParametro” obtiene los campos, utilizando objetos de clase

Campo, que se obtienen de las lista de campos de ese parámetro. La clase Campo
posee las características de este, es decir, el nombre, el largo, el tipo de campo, y la
lista de valores y significados para ese campo. El tipo de campo indica de qué forma
se va a mostrar el contenido del campo, si se va a mostrar como un número decimal,
como un número hexadecimal o si se muestra el significado en forma de texto. En
este último caso se obtiene la lista de posibles valores y significados para ese campo
y se comparan los valores de la lista con el valor del contenido del campo; en caso
de que se encuentre el valor, se obtiene el significado de ese valor de la lista de
significados. Si el parámetro es dato (“data” o “long data”), guarda el contenido del
dato para que pueda ser analizado más tarde. Si el parámetro es Dirección Llamada,
o Dirección Llamante, guarda el indicador de ruteo y el SSN, para ser usados en
caso de que el indicador de ruteo indique “Ruteo en SSN”.
Luego de analizar los parámetros, el método “analizar” de la clase Mensaje verifica si

hubo un parámetro de dato en el análisis, en cuyo caso invoca al método
“analizarDato”.
El método “analizarDato” verifica primero si el indicador de ruteo indica “Ruteo en

SSN”, en caso de cumplirse la condición se fija qué usuario indica el SSN (SCMG,
BSSAP o BSSOMAP). Si no se verifica la condición el dato transporta un mensaje de
BSSAP. De acuerdo con estos resultados, invoca a los métodos “analizarBSSAP”,
“analizarSCMG” o “analizarBSSOMAP”.
Método “analizarBSSAP”
Este método obtiene el parámetro de discriminación, que es el primer octeto en un
parámetro de dato perteneciente a un usuario BSSAP. Este octeto indica si el
BSSAP es DTAP o BSSMAP. De acuerdo con el resultado obtenido, invoca a los
métodos “analizarDTAP” o “analizarBSSMAP”. El funcionamiento de estos dos
métodos es similar.
Estos métodos, en primer lugar obtienen el largo del mensaje y el código de tipo de
mensaje. De acuerdo con el código obtienen, a partir de la lista de mensajes
56
correspondiente al usuario, el objeto de la clase MensajeUsuario, que contiene las
características del mensaje (nombre y descripción). Luego, obtienen para cada
elemento de información, el código, el largo y el contenido del elemento. A partir del
código del elemento de información, se obtiene de la lista de elementos de ese
usuario el objeto de la clase ElementoUsuario correspondiente, que posee las
características del elemento (nombre, largo y lista de campos). El objeto de la clase
ElementoUsuario posee también un método que analiza los campos que se
encuentran en la lista de campos del elemento, utilizando la clase Campo.
Método analizarSCMG
Este método, en primer lugar obtiene el código de tipo de mensaje. De acuerdo con
el código obtienen, a partir de la lista de mensajes correspondiente a SCMG, el
objeto de la clase MensajeUsuario, que contiene las características del mensaje
(nombre, descripción y lista de campos). A partir de la lista de campos obtiene los
objetos de la clase Campos que tiene las características de los campos. La clase
MensajeUsuario tiene también un método que realiza el análisis de los campos de la
lista de campos.
Método analizarBSSOMAP
Como el protocolo de BSSOMAP no se encuentra estandarizado no hemos
implementado ningún protocolo de BSSOMAP, por lo tanto, en principio
analizarBSSOMAP mostraría la información de BSSOMAP en formato haxadecimal.
Se implementó una opción de agregar BSSOMAP, que luego de cargar el archivo
con los elementos de información del protocolo, analizaría los elementos de la misma
forma que se analizan los elementos de información de BSSAP.
7.3- El subsistema de vista de la aplicación
Este subsistema realiza las funciones de visualización del análisis y las funciones
relacionadas con las distintas opciones de visualización.
7.3.1- Diagrama de clases
El diagrama de clases de la vista de la aplicación se muestra en la sección 2 del

Apéndice D. Las clases de este subsistema son Present, que hereda atributos y
métodos de JFrame, la clase Salida, que hereda atributos y métodos de JPanel y la
clase Opciones. El diagrama de clases para este subsistema se observa en la
siguiente figura.
57
Present
La clase Present contiene los ítems de Menú, cada uno de ellos tiene asociado un
método que lo relaciona con objetos de la capa interfaz.
Salida
La clase salida contiene los objetos correspondientes a la presentación en pantalla,

que poseen métodos que los relacionan con objetos de la capa interfaz.
Opciones
La clase Opciones contiene los procedimientos relativos a las opciones del menú
(filtrar, buscar).
7.4- Implementación
En el Apéndice E se encuentra la documentación de las clases implementadas.
58
objetos. México: Prentice may
RUMBAUGH, James. 1991. 1ra Ed. Object-Oriented Modeling and Design. New Jersey:
Prentice Hall
59
Capítulo 8 – Pruebas del software
El tipo de pruebas que hicimos durante el proyecto fue de caja negra. En una primera
etapa fuimos realizando pruebas para cada clase o un conjunto de clases.
Las últimas pruebas que realizamos son de caja negra para cada caso de uso y son
las que se muestran a continuación.
8.1- Visualizar análisis de mensaje
Para la siguiente prueba analizamos un archivo Salida.txt.
60
8.2- Obtención de mensajes con una característica en común
La siguiente prueba muestra el filtrado de mensajes por tipo de usuario: BSSMAP del
mismo archivo Salida.txt.
61
8.3- Búsqueda de mensajes en un tiempo específico
La siguiente prueba muestra la búsqueda en el archivo Flujo.txt del tiempo: 11:37:09.
8.4- Generación de un archivo con la descripción detallada de un

conjunto de mensajes
Para la siguiente prueba seleccionamos un conjunto de mensajes del archivo flujo.txt

y generamos un archivo Analisis.txt.
El resultado de la prueba es un archivo Analisis.txt con el siguiente contenido:
-0001101 Backward Sequence Number 13
62
1------- Backward Indicator Bit 1
-0010110 Forward Sequence Number 22
1------- Forward Indicator Bit 1
--000111 Length Indicator 7
00------ Spare 0
----0000 Service Indicator MTP3
--00---- Sub-service Spare
10------ Sub-service: Network Ind International network
**DPC*** Destination Point Code 0/56/4
**OPC*** Originating Point Code 0/12/5
----0000 Signaling Link Selection 0
00010001 Message type Changeover-order signal
-0110000 FSN of last accepted MSU 48
0------- Spare 0

00------ Spare 0
00010001 Message type Changeover-order signal
0------- Spare 0

00------ Spare 0
00100001 Message type Changeover-
acknowledgement signal
0------- Spare 0

00------ Spare 0
63
00100001 Message type Changeover-
acknowledgement signal
0------- Spare 0

00------ Spare 0
00010101 Message type Signalling-route-set-test
signal for prohibited destination
**b14*** Destination 101
00------ Spare 0

00------ Spare 0
----0001 Service Indicator T&M
00010001 Message type Signaling link test
----0000 Spare 0
1111---- Length indicator 15
**B15*** Test pattern 2147483647
64
Capítulo 9- Manual de usuario
9.1- Instalar el programa
Plataforma Windows:
1. Descomprimir el archivo Analizador IA.zip. Este archivo comprimido posee una

carpeta denominada Contexto que contiene los archivos .xml y debe colocarse
como subdirectorio del disco C de la forma: C:\Contexto y el programa de
instalación.
2. Ejecutar el archivo setup.exe
Plataforma Unix:
1. Descomprimir el archivo Analizador IA.zip. Este archivo comprimido posee una

carpeta denominada Contexto que contiene los archivos .xml y debe colocarse
como subdirectorio del disco C de la forma: C:\Contexto y el archivo ejecutable
AnalizadorIA.jar.
2. Ejecutar desde consola el archivo Analizador.jar
9.2- Procedimientos de Uso
Para poder ejecutar este programa se debe poseer una versión Runtime de java (jre
1.4.0 en adelante), la cual puede obtenerse en la siguiente dirección:
http://www.sun.com
Para analizar un archivo proceder de la siguiente forma:
 Obtener un archivo .txt de la interfaz A, para ser analizado.
65
9.2.1- Análisis de un archivo
1- Seleccione en el menú “Archivo” la opción “Abrir”.

2- Indique la ruta de acceso al archivo.
3- En el menú “Archivo” elija la opción “Analizar”.
9.2.2- Búsqueda de un mensaje por tiempo
1- Seleccione en el menú “Buscar”, la opción “Por tiempo”.

2- Escriba en el campo de texto de la ventana que se abre, la hora del mensaje
que desea buscar de la forma: Hora:Minuto:Segundo.
3- Haga un click en el botón “Aceptar”.
9.2.3- Filtrado de mensajes
1- En el menú “Filtrado” elija la opción correspondiente con el criterio de filtrado

que desea aplicar (hora, OPC, DPC, servicio, tipo de mensaje, usuario de
SCCP, tipo de mensaje de usuario).
2- Indique en el campo de texto de la ventana que se abre la característica que
desea filtrar, de la siguiente manera:
a) Si está filtrando por tiempo escriba en el primer campo de texto la hora a
partir de la cual desea filtrar y en el segundo campo la hora final,
escribiendo ambas de la siguiente manera: Hora:Minuto:Segundo.
b) Si es OPC o DPC, escriba el código con el formato definido en la
Recomendación Q708 de la siguiente forma: __/__/__.
c) Si es servicio escriba el servicio correspondiente servicio, de la siguiente
forma:
 MTP3
 T&M
 SCCP
d) Si es tipo de mensaje escriba el nombre del mensaje de la misma forma
que aparece en la norma.
e) Si es usuario de SCCP escriba el correspondiente usuario de la siguiente
forma:
 SCMG
 BSSMAP
 DTAP
 BSSOMAP
f) Si es tipo de mensaje de usuario escriba el nombre del tipo de mensaje
66
3- Haga un click en el botón “Aceptar”.
9.3- Agregar Mensajes en los archivos XML
Los posibles protocolos que se pueden agregar deben estar definirse en lenguaje
XML, con los mismos elementos y atributos con que se definieron los protocolos que
se usan en la aplicación.
Los mensajes que analiza el analizador se encuentran codificados según el estándar

correspondiente en archivos escritos en el lenguaje marcado XML. En el caso de que
fuera necesario modificar el código de un mensaje o un parámetro, o así mismo
agregar algún mensaje que fuera incluído en una fase posterior se debe proceder
como indica a continuación. Todos los archivos XML se encuentran en la carpeta
Contexto, ubicada en C:\ Contexto.
9.3.1- Mensajes de MTP3
Estos son mensajes con estructura fija que se encuentran estandarizados en ITU-T
Q.704 con la siguiente estructura que se puede apreciar en el formato xml a
continuación:
<mensajes nombre="MTP3">
<mensaje nombre="COO" descripcion="Changeover-order signal" codigo="00010001">
<campo nombre="FSN of last accepted MSU" largo="7"/>
<campo nombre="Spare" largo="1"/>
</mensaje>
<mensaje nombre="COA" descripcion="Changeover-acknowledgement signal"
codigo="00010010">
<campo nombre="FSN of last accepted MSU" largo="7"/>
</mensaje>
...................
Agregar un mensaje:
 Abrir el archivo mensajesMTP3.xml ubicado en C:\Contexto.

 Copiar un formato idéntico a la parte sombreada que equivale a la descripción de
un mensaje
67
 Colocar los datos correspondientes al nuevo mensaje, los cuales se encuentran
determinados en la nueva revisión del estandar correspondiente.
 Agregar a la lista, antes de la etiqueta que cierra todos los mensajes
(</mensajes>)
Modificar un mensaje:
 Ubicar el mensaje cuyo valor debe ser modificado.

 Modificar su valor el cual se encuentra entre comillas (" ") a continuación del
signo de igual, en la etiqueta correspondiente.
 Guardar el cambio.
9.3.2- Mensajes de SCCP
Estos mensajes están estructurados de forma más compleja, se hayan definidos en

la norma ITU- T Q.713 y se componen de una parte obligatoria y una opcional y
poseen parámetros de largo fijo o largo variable. El archivo xml se estructura de la
siguiente forma:
<mensajes nombre="SCCP">
<mensaje nombre="CR" descripcion="Conection Request" codigo="00000001">


<mensaje codigo="00111100" nombre="RIR" descripcion="RR Initialisation Request"/>
74
<mensaje codigo="00111011" nombre="AA" descripcion="Additional Assignment"/>
<mensaje codigo="00111111" nombre="IA" descripcion="Inmediate Assignment"/>
<mensaje codigo="00111001" nombre="IAE" descripcion="Inmediate Assignment Extended"/>

<mensaje codigo="00111010" nombre="IAR" descripcion="Inmediate Assignment Reject"/>
..............
</mensajes>
Agregar un mensaje:
 Abrir el archivo mensajesDTAP.xml ubicado en C:\Contexto

un mensaje
Considerando: escribir el código de lago fijo de 8 bits y a continuación el nombre
del mensaje como sigla abreviada, y en la descripción el nombre del mensaje en
inglés. Si alguno no tiene sigla dejar el lugar vacío.
(</mensajes>)

75
Capítulo 10- Análisis del modelo Online
A continuación presentamos un análisis de una posible solución para el desarrollo de

un analizador on-line. No obstante cabe considerar que el lenguaje de desarrollo
Java, no es apropiado para un funcionamiento on-line debido a que java traduce el
código fuente a un código de bytes, por lo tanto no presenta una buena performance
para un análisis en tiempo real.
10.1 - Arquitectura ON-LINE
El objetivo de una arquitectura on-line es obtener el flujo de datos en crudo y

procesarlo.
 Demultiplexar la interfaz A, es decir extraer del flujo de 2Mbps el intervalo de

tiempo (time slot) que lleva la información de señalización de los enlaces de ida y
vuelta.
 Almacenar en dos buffers de forma que uno guarde la información del time slot
de transmisión hacia la MSC y el otro guarde la información del time slot de
recepción para la MSC
10.1.1- Hardware adicional
ANALIZADOR
Tarjeta
demultiplexora
MICROCONTROLADOR
BUFFER BUFFER
TX RX
DEMUX
E1
Figura 10.1
76
10.2 - Arquitectura general básica
Descripción:
La señal que pasa a través del enlace es demultiplexada por una tarjeta inteligente,
dicha señal contiene las tramas de relleno (FISU), las tramas de estado del enlace
(LSSU) y los mensajes (MSU). Mediante una etapa de mediación se recuperan solo
las unidades de señalización de mensaje.
En la tarjeta, la cadena de octetos obtenida es almacenada en dos buffers. Estos

buffers en este caso son críticos y deben ser ajustados de acuerdo con la variación
en el tiempo de las tramas útiles en un enlace de señalización Nº7 tal como indica la
recomendación de la ITU-T Q.791. Este buffer introduce un retardo aceptable.
Por medio de una comunicación entre la tarjeta y la PC se reciben la información

almacenada. Las etapas siguientes son en común con las descriptas para
funcionamiento “off-line”.
Figura 10.2
77
10.3- Resolución del Análisis
La resolución del análisis para el modelo on-line mantiene la misma estructura que el
diseño off-line sólo se diferencia de él en la forma de obtener los datos.
 Obtención de datos
 Análisis
 Salida
Estas tres etapas se identifican en la Figura 10.3. Las etapas de análisis y salida son
en común para los dos tipos de análisis.
Mensajes
analizados
Análisis
Almacenamiento
Flujo de Salida
Lectura
Flujo de Entrada
E1
Figura 10.3- Resolución del análisis on-line
A continuación se describen en detalle las distintas etapas planificadas.
78
10.3.1- Obtención de datos
En esta arquitectura es necesario en primera instancia conseguir la información

demultiplexada que se encuentran en los buffers de la tarjeta demultiplexora.
En el paquete de clases de java.io está implementado un sistema de comunicación
llamado flujos a través del cual la información puede ser guardada y recuperada
posteriormente. Para ello es necesario crear flujos de entrada para leer la
información y flujos de salida para guardar la información.
En esta etapa se deben conseguir los datos a través del puerto serie de la PC, en el
momento deseado. Estos datos serán tomados de un flujo continuo de ida y vuelta y
serán guardados en dos buffers respectivos, como se explicó en el capítulo 5. Estos
buffers tienen una memoria máxima que no debe ser sobrepasada de modo que se
reescriba la información, por lo tanto debe mantenerse una correcta comunicación
entre la tarjeta y el PC para poder informar al PC, habilitando una interrupción,
cuando los buffers se encuentran llenos y deban ser vaciados. Esto se implementaría
por medio de un socket.
Los sockets son un sistema de comunicación entre procesos de diferentes máquinas

conectadas. Más exactamente, un socket es un punto de comunicación por el cual un
proceso puede emitir o recibir información. Utilizan una serie de primitivas para
establecer el punto de comunicación para conectarse a una máquina remota en un
determinado puerto que esté disponible, para escuchar en él, para leer o escribir y
publicar información en él, y finalmente para desconectarse. Con todas estas
primitivas se puede crear un dialogo muy completo. A continuación vemos el
Funcionamiento de una conexión socket, mediante la modalidad Cliente/Servidor.
Los datos obtenidos en la comunicación se guardarían en el buffer del PC y se

analizarían igual que para off-line. Se debe implementar un método que interprete el
formato entregado por la tarjeta.
79
ANALIZADOR TARJETA
Abrir canal de Abrir canal de

comunicación comunicación
ServerSocket ref ServerSocket ref
Publicar la dirección del

canal de comunicación
ref =new(puerto)
Espera recibir solicitudes

while o for o do
Esperar Peticiones Conectar con Servidor

ref.accept() ref =new (host, puerto)
Crear proceso hijo

hijo = ref.accept()
Recepción de datos Envío de datos

hijo.read() hijo.write()
Cerrar canal de Cerrar canal de

comunicación comunicación
ref.close() ref.close()
80
DEITEL H.M.; DEITEL, P.J. 1998. Como programar en Java 2. México: Prentice Hall
Hispanoamericana S.A. Pearson Educación, Addison Wesley.
<http:// java.sun.com>
81
Capítulo 11- Sobre el proyecto
Este capítulo incluye las consideraciones más importantes del proyecto, el ciclo de
vida planteado y las decisiones tomadas.
11.1- Vida del proyecto
Al inicio del proyecto nos planteamos el ciclo de vida que se muestra en la Figura
11.1 al que nos fuimos ajustando. Para esta planificación consideramos los
conocimientos que teníamos y los conocimientos a adquirir.
Como el proyecto involucraba el desarrollo de un analizador de protocolo de la

interfaz A del sistema GSM, era de importancia fundamental el conocimiento del
sistema GSM y el estudio en detalle de la interfaz A y su pila de protocolos. Con tal
fin fue necesario el estudio de las especificaciones GSM e ITU-T que se detallan en
la sección 11.2.
En segundo lugar, era necesario el conocimiento de un lenguaje de programación

que cumpliera con los requisitos del sistema. Como no conocíamos ningún lenguaje
de programación orientado a objetos, debimos elegir un lenguaje que cumpliera con
los requisitos y dedicar una parte del proyecto al estudio del lenguaje. Por las
razones que se describen en el capítulo 4 elegimos el lenguaje de programación
JAVA.
1 8 15 22 29 31
Octubre Investigación del campo Introducción a SS7 aplicada a Telefonía Móvil Celular
Noviembre Capa 1 Capa 2
Diciembre Capa 3
Enero Preparación de entrega y presentación
Febrero Familiarización con el lenguaje a utilizar (Java)
Marzo
Abril Diseño del software
Mayo
Junio Prueba del Software
Julio Preparación de entrega
82
11.2- Especificaciones GSM e ITU-T
Las especificaciones ETSI que estudiamos fueron las siguientes (para algunas se
consideraron solo algunas secciones):
 3GPP TS 04.04 version 8.1.2(2002) : "Layer 1- General Requirements".

 3GPP TS 04.07 version 7.3.0(2000) : "Mobile radio interface signalling Layer 3;
General Aspects".
 3GPP TS 08.01 version 8.0.1(2002) : "General Aspects on the BSS_MSC
Interface".
 3GPP TS 08.02 V8.9.0 (2001):"Base Station System - Mobile Services
Swithing Centre (BSS-MSC) Interface Interface Principles".
 3GPP TS 08.04 V8.9.0 (2001): "Base Station System - Mobile Services
Swithing Centre (BSS-MSC) Interface Layer 1 Specification".
 3GPP TS 08.06 V8.9.0 (2001): "Signalling transport Mechanism Specification
for the Base Station System - Mobile Services Swithing Centre (BSS-MSC)
Interface".
 3GPP TS 08.08 V8.9.0 (2001): "Mobile Services Swithing Centre - Base
Station System (MSC - BSS) interface; Layer 3 specification ".
Las especificaciones ETSI de las distintas capas de la pila de protocolo de la interfaz

A, hacen referencia a algunas especificaciones ITU-T del sistema de Señalización Nº
7, que también fueron estudiadas. Estas especificaciones son:
 ITU-T - G.703 (2001): "Physical/Electrical characteristics of herarchical digital

interfaces".
 ITU-T - G.704 (1998): "Synchronus frame structures used at 1544, 6312, 2048,
8448 and 44736 kbps hierarchical levels".
 ITU-T - G.732 (1988): "Characteristics of primary PCM multiplex equipment
operating at 2048".
 ITU-T - Q.702 (1988): "Signalling data link".
 ITU-T - Q.703 (1996): "Signalling link".
 ITU-T- Q.704 (1996): "Specifications of Signalling System N.7- Message
Transfer Part".
 ITU-T - Q.706 (1993) . "Message transfer part signalling performance".
 ITU-T - Q.707 (1988). "Testing and Maintenance".
 ITU-T- Q.711 (2001). "Functional Description of the signalling connection
control part".
 ITU-T - Q.712 (1996) . "Definition and function of signalling connection control
part messages".
83
 ITU-T - Q.713 (1996). "Specification of Signalling System N. 7-Signalling
Connection Part (SCCP)".
 ITU-T - Q.714 (2001). "Signalling connection control part procedures".
11.3- Archivos XML
Con el fin de obtener la descripción de los campos de cada mensaje, parámetro o

elemento de información se editaron archivos XML, capaces de ser interpretados por
JAVA.
Los archivos editados son los que se muestran en la siguiente tabla, cuya
información se obtiene de las especificaciones ETSI indicadas en la tabla.
Archivo XML Especificaciones relacionadas

MensajesMTP3.XML ITU-T Q.704, 3GPP TS 08.06
MensajesTandM.XML ITU-T Q.707, 3GPP TS 08.06
MensajesSCCP.XML ITU-T Q.713, 3GPP TS 08.06
MensajesSCMG.XML ITU-T Q.713, 3GPP TS 08.06
Parámetros.XML ITU-T Q.713, 3GPP TS 08.06
MensajesBSSMAP.XML 3GPP TS 08.08
MensajesDTAP.XML 3GPP TS 04.08
ElementosBSSMAP.XML 3GPP TS 08.08, 3GPP TS 04.08
ElementosDTAP.XML 3GPP 04.07, 3GPP TS 04.08
MensajesMTP3.XML- Este archivo contiene para cada mensaje de MTP 3, el código,

el nombre, la descripción del mensaje y los campos presentes con la información de
nombre y largo.
MensajesTandM.XML- Idem MensajesMTP3.XML.
MensajesSCCP- Contiene el nombre, código y descripción de cada mensaje de

SCCP. Para cada mensaje contiene el código de los parámetros obligatorios de largo
fijo, con el largo correspondiente, y el código de los parámetros obligatorios de largo
variable.
MensajesSCMG- Contiene el nombre, código y descripción de cada mensaje de

SCMG. Para cada mensaje contiene los campos presentes con el nombre, el largo y
84
el tipo de campo (numérico, texto, dirección). Para los campos de texto contiene los
posibles valores que puede tomar y su significado.
Parametros- Contiene el nombre y código de cada parámetro de SCCP. Para cada

parámetro contiene los campos presentes con el nombre, largo y tipo de campo.
Para campos de texto contiene valores y significados.
MenajesBSSMAP- Contiene el nombre, descripción y código de cada mensaje de

BSSMAP.
MensajesDTAP- Contiene el nombre, descripción y código de cada mensaje de

DTAP. Para cada mensaje contiene los elementos de información obligatorios con
nombre y ubicación (a continuación o al final).
ElementosBSSMAP- Contiene el nombre, código y largo de cada elemento de

información de BSSMAP. Para cada elemento de información contiene los campos
presentes con el nombre, largo, tipo y loop, que indica si el elemento se encuentra
una sola vez o si se repite a continuación.
ElementosDTAP- Contiene el nombre, código, clase y formato de cada elemento de

información de DTAP. La clase y el formato indican la forma en que van a ser leídos
los elementos de información.
La tarea de edición de los archivos XML no fue una tarea sencilla. Por un lado existe
una gran cantidad de mensajes, parámetros y elementos de información. Las
descripciones de ellos no se encuentran definidas en una sola especificación sino
que se encuentran repartidas en distintas especificaciones que hacen referencia a
otras o a distintas secciones de la misma especificación. Por otro lado no existe una
forma estandarizada de definir esta información en las especificaciones por lo tanto
no pueden ser convertidas directamente a XML partir de una transformación.
Todo esto lleva a que exista una gran probabilidad de producirse errores de edición.
La forma en que se validaron estos archivos fue mediante una corroboración de cada
mensaje, parámetro y elemento de información.
85
11.4- Etapa previa
Los archivos que se analizaron provienen del equipo K1103. Los archivos de trazado
de mensajes que se obtienen del equipo K1103 tienen un formato .REC de
propietario. Para la lectura de estos archivos .REC utilizamos un programa
SHOWREC que transforma el archivo .REC a un archivo .TXT de formato leible.
Una porción de un archivo TXT con formato analizable se muestra a continuación.

Para la lectura se leen los primeros 6 caracteres. Si estos son “Number” se extrae de
la línea, en una posición determinada con respecto al origen de línea la hora del
mensaje. Si los 6 primeros caracteres son “ data”, la información que viene a
continuación se interpreta como mensaje.
Number=0001, Type= 1, Length= 44, TimeStamp: 2.02.1998 11:46:57'710913

data= 4c 4c 20 83 80 b5 5b ee 06 88 81 4c 00 01 14 01 00 11 1b 3b 1c 0d a1 0b
data= 02 01 09 02 01 0e 30 03 04 01 2b
data= 02 01 09 02 01 0e 30 03 04 01 2b
data= 02 01 09 02 01 0e 30 03 04 01 2b
B F MSU
F BSN I FSN I LI SIO SIF CK F
B B
Subservice field Service

Nac o Int) Indicator
0 0 0 0
Mensaje de Gestión de Red (MTP3)
0 0 0 1 Mensaje de Testeo y Mantenimiento de Red
Etiqueta H0 Hi
de ruteo 0 0 1 1 Mensaje de SCCP
11.5- Lectura de archivos
Como los archivos de registro de transferencia pueden ser de gran tamaño, en

algunos casos no sería posible importar todo el archivo y analizar los mensajes
importados en un tiempo aceptable para el usuario.
86
Para poder solucionar este problema realizamos un mapeo del archivo en memoria.
Virtualmente el archivo parece estar todo en memoria. En realidad el programa
importa parte del archivo a medida que lo va necesitando.
Cuando el usuario analiza los mensajes, en realidad solo se analiza

aproximadamente 10kbytes del archivo. Cuando el usuario se desplaza hacia arriba
o hacia abajo en la tabla de mensajes y llega al primer o último de los mensajes
analizados, automáticamente importa y analiza una nueva porción de mensajes, en
un tiempo casi imperceptible por el usuario.
El tamaño de la porción del archivo lo elegimos por medio de pruebas, considerando

la percepción del usuario.
87
Bibliografía
BOOCH, Grady; et.al. 1999 El Lenguaje Unificado del Modelado. Madrid: Addison
Wesley Panamericana.
BOSSE, Jhon G. Van. 1997. Signalling in Telecommunication Network. 6ta. ed.

Nueva York: Jhon Wiley & Son Inc.
DEITEL H.M.; et.al. 1998. Como programar en Java 2. México: Pearson Educación.
EUROPEAN TELECOMMUNICATIONS STANDARDS INSTITUTE – 3RD

GENERATION PARTNERSHIP PROJECT – Technical Specification 04.04. Layer 1-
General Requirements. [NORMAS, ESTANDARES]. Sofía Antípolis Cedex, European
Telecommunications Standards Institute, 2002.

GENERATION PARTNERSHIP PROJECT – Technical Specification 04.07. Mobile
radio interface signalling Layer 3; General Aspects. [NORMAS, ESTANDARES].
Sofía Antípolis Cedex, European Telecommunications Standards Institute, 2000.

GENERATION PARTNERSHIP PROJECT – Technical Specification 08.01. General
Aspects on the BSS_MSC Interface. [NORMAS, ESTANDARES]. Sofía Antípolis
Cedex, European Telecommunications Standards Institute, 2002.

GENERATION PARTNERSHIP PROJECT – Technical Specification 08.02. Base
Station System - Mobile Services Swithing Centre (BSS-MSC) Interface Interface
Principles. [NORMAS, ESTANDARES]. Sofía Antípolis Cedex, European

GENERATION PARTNERSHIP PROJECT – Technical Specification 08.04. Base
Station System - Mobile Services Swithing Centre (BSS-MSC) Interface Layer 1
Specification. [NORMAS, ESTANDARES]. Sofía Antípolis Cedex, European

GENERATION PARTNERSHIP PROJECT – Technical Specification 08.06. Signalling
transport Mechanism Specification for the Base Station System - Mobile Services
Swithing Centre (BSS-MSC) Interface. [NORMAS, ESTANDARES]. Sofía Antípolis
Cedex, European Telecommunications Standards Institute, 2001.
88
GENERATION PARTNERSHIP PROJECT – Technical Specification 08.08. Mobile
Services Swithing Centre - Base Station System (MSC - BSS) interface; Layer 3
specification. [NORMAS, ESTANDARES]. Sofía Antípolis Cedex, European
GUTIERREZ, Abraham; et.al. 2001. XML a través de ejemplos. México: Alfaomega

Grupo Editor, S.A. de C.V.
HORTSMAN, Cay S.; et.al. 2003. Core Java 2 Vol. I y II. 6ta. ed. Palo Alto: Prentice
Hall.
INTERNATIONAL TELECOMMUNICATIONS UNION – TELECOMMUNICATION

STANDARIZATION SECTOR - G.703. Physical/Electrical characteristics of
herarchical digital interfaces. [NORMAS, ESTANDARES]. Ginebra, International
Telecommunications Union, 2001.

STANDARIZATION SECTOR - G.704. Synchronus frame structures used at 1544,
6312, 2048, 8448 and 44736 kbps hierarchical levels. [NORMAS, ESTANDARES].
Ginebra, International Telecommunications Union, 1998.

STANDARIZATION SECTOR - G.732. Characteristics of primary PCM multiplex
equipment operating at 2048. [NORMAS, ESTANDARES]. Ginebra, International

STANDARIZATION SECTOR - G.702. Signalling data link. [NORMAS,
ESTANDARES]. Ginebra, International Telecommunications Union, 1988.

STANDARIZATION SECTOR - G.703. Signalling link. [NORMAS, ESTANDARES].
Ginebra, International Telecommunications Union, 1988.

STANDARIZATION SECTOR - G.704. Specifications of Signalling System N.7-
Message Transfer Part. [NORMAS, ESTANDARES]. Ginebra, International

STANDARIZATION SECTOR - G.706. Message transfer part signalling performance.
[NORMAS, ESTANDARES]. Ginebra, International Telecommunications Union,
1993.
89
STANDARIZATION SECTOR - G.707. Testing and Maintenance. [NORMAS,
ESTANDARES]. Ginebra, International Telecommunications Union, 1988.

STANDARIZATION SECTOR - G.711. Functional Description of the signalling
connection control part. [NORMAS, ESTANDARES]. Ginebra, International

STANDARIZATION SECTOR - G.712. Definition and function of signalling connection
control part messages. [NORMAS, ESTANDARES]. Ginebra, International

STANDARIZATION SECTOR - G.713. Specification of Signalling System N. 7-
Signalling Connection Part (SCCP. [NORMAS, ESTANDARES]. Ginebra,
International Telecommunications Union, 1996.

STANDARIZATION SECTOR - G.714. Signalling connection control part procedures.
[NORMAS, ESTANDARES]. Ginebra, International Telecommunications Union,
2001.
JACOBSON, Ivar; et.al. 2000. El Lenguaje Unificado de Desarrollo de Software.

Madrid: Pearson Educación.
LARMAN, Craig. 1999. UML y Patrones: Introducción al análisis orientado a objetos.

México: Prentice May
LEMAY, Laura; et.al. 1999. Aprendiendo Java 2 en 21 días. México: Prentice-Hall.
LINDEM, Peter Vander. 2002. Just Java 2. Palo Alto: Prentice Hall.
PRESSMAN, Roger S. 1998. Ingeniería del software. 5ta ed. Madrid: McGraw
RUMBAUGH, James. 1991. Object-Oriented Modeling and Design. Nueva Jersey:

Prentice Hall
RUSSELL, Travis. 1998. Signaling System Nr. 7. 2da.ed. Nueva York: Mac Graw
Hill.
90
Apéndice A
A.1 - GSM Sistema Mundial de Telecomunicaciones

Móviles
A.1.1- GSM
GSM (Global System for Mobile Comunication) es un sistema de comunicación

celular digital. Fue desarrollado con el fin de crear un estándar común europeo de
telefonía móvil, pero que fue rápidamente aceptado en el resto del mundo. El sistema
estandarizado buscó cumplir ciertos requisitos:
• Eficiencia de espectro
• Itinerancia (roaming) internacional
• Bajo costo en las estaciones base y móviles
• Buena calidad de voz
• Compatibilidad con otros sistemas como la Red Digital de Servicios Integrados
ISDN (Integrated Services Digital Network)
• Habilidad para sostener nuevos servicios
A.1.2- Servicios y Facilidades del Sistema
A.1.2.1- Teleservicios
Son servicios de telecomunicaciones que suministran los medios para la

comunicación entre usuarios según protocolos establecidos por acuerdos entre
operadores de red (red móvil, red fija. ISDN).
 Telefonía:
 Servicios de Fax de grupo 3
 Servicios de mensajes cortos
91
A.1.2.2- Servicios portadores
Son servicios de telecomunicaciones que proporcionan la posibilidad de transmitir

señales entre el usuario y la red, de datos limitados a los niveles 1, 2 y 3 del modelo
de referencia OSI. Soportan velocidades de información que van de los 300 bps a los
9,6 kbps.
A.1.2.3- Servicios suplementarios
Estos son aquellos que modifican o sustituyen a un servicio básico de

telecomunicaciones. Los principales servicios son:
 Llamada restringida, con criterios como:

- Imposibilidad de realizar llamadas salientes o llamadas internacionales,
por ejemplo.
 Desvío de llamadas (si el abonado móvil está ocupado o ausente).
 Identificación del abonado llamante.
 Retransmisión de la llamada (cuando la red no puede localizar al abonado
móvil).
 Llamada en espera.
 Comunicaciones pluripartitas.
 Información de tarificación en tiempo real.
A.1.3- Arquitectura de la red GSM
Las especificaciones de GSM que se encuentran divididas en 12 Series técnicas (en

adelante TS, Technical Specification), definen las diferentes entidades que forman la
red GSM definiendo sus funciones y requerimientos de interfaces.
Series Tecnicas
1) Consideraciones generales
2) Aspectos del servicio
3) Aspectos de la red
4) Interfaz MS-BSS y protocolos
5) Capa física en el trayecto radioeléctrico
6) Especificación de codificación de la señal de voz
7) Adaptadores de terminal para las estaciones móviles
8) Interfaces BSS - MSC
92
9) Interfuncionamiento de red
10) Disponibilidad
11) Equipos y especificaciones de homologación
12) Explotación y mantenimiento
El sistema completo está formado por un número de entidades funcionales. La

figura A.1.1 muestra las entidades funcionales del sistema y sus interconexiones.
Figura A.1.1
A.1.3.1- La Estación Móvil (MS)
La estación móvil consiste en el equipamiento físico usado por el abonado para tener
acceso a los servicios de telecomunicaciones ofrecidos. Consiste de un equipo móvil
(terminal) y una tarjeta inteligente llamada SIM (Subscriber Identity Mobile). La tarjeta
SIM provee de movilidad personal. Insertando dicha tarjeta en cualquier terminal
GSM, el usuario es capaz de recibir llamadas, hacer llamadas o recibir otro servicio
desde ese terminal.
El equipo móvil es identificado por el IMEI (Internacional Mobile Equitment Identity).
La tarjeta SIM contiene el IMSI (Internacional Mobile Subscriber Identity), usado para
identificar al usuario del sistema.
93
A.1.3.2- El Subsistema de Estación Base (BSS)
El Subsistema de Estación Base es el equipo físico usado para dar cobertura a una
determinada zona llamada célula, y para contener el equipamiento necesario para
comunicar con el MS. Funcionalmente el BSS está subdividido en una función de
control, realizada por el Controlador de Estación Base (BSC) y una función de
transmisión realizada por la Estación Transmisora Base (BTS).
La estación base está formada por estos dos elementos, formando la red de acceso:
 BTS: es el propio transmisor/receptor. Comprende la parte radio de la estación
(transceptores antenas, etc). Se conecta al BSC mediante la interfaz normalizada
Abis, mediante el enlace terrestre que corresponda.
 BSC: es el controlador de la estación base. Controla los dispositivos de radio de
la BTS.
El objetivo de la BSS es por consiguiente establecer el enlace entre el equipo de

conmutación y los abonados móviles.
A.1.3.3- Central de Conmutación Móvil (MSC)
El MSC es una central que realiza todas las funciones de conmutación necesarias
para los móviles localizados en un área geográfica asociado, llamado área de MSC.
El MSC toma en cuenta la naturaleza móvil de sus abonados, y maneja los recursos
necesarios de radio, especialmente los procedimientos requeridos para manejar y
adaptar el procedimiento de registro de localidad y los procedimientos necesarios
para llevar a cabo una transferencia hacia las entidades que se encuentran
conectadas con ella (BSSs u otras MSCs).
A.1.3.4- El Registro de Localización de Abonado (HLR)
El registro de ubicación local es una base de datos en la cual se registra la

información referente a las características del servicio de todos los abonados de una
red GSM. El HLR dispone de información sobre el VLR que termaralmente está
atendiendo a cada abonado de la red de un operador, incluso si el VLR pertenece a
otra red móvil. Ello significa que para todas las llamadas para terminación en un
móvil, el HLR podrá señalar dónde se encuentra el móvil, y por lo tanto posibilitar el
94
proceso de entrega de llamada en la central celular que temporalmente lo está
sirviendo, por medio del proceso de entrega de llamada (en inglés call delivery).
A.1.3.5- El Centro de Autenticación (AuC)
Es una base de datos en la que se almacenan varios elementos de información

confidencial sobre los abonados, en particular el Ki, que es una clave destinada a
cada abonado y es utilizada para la autenticación y cifrado en la interfaz aérea. Esto
quiere decir que autoriza al abonado cuando ingresa en la red móvil si sus datos son
correctos para que de ahí en adelante pueda realizar cualquier transacción.
A.1.3.6- El Registro de Localización de Visitantes (VLR)
El registro de localización de visitantes es una base de datos, mantenida por cada

MSC, donde se almacena toda la información necesaria para poder dar servicio a un
móvil que entre en el área de cobertura de la MSC.. En el VLR se almacena la
información de cada abonado servido por el MSC (se asume servido si está
encendido su terminal y dentro del área de cobertura de las estaciones radiobases
controladas por los controladores de radiobases conectados a dicho MSC), la
información del VLR es obtenida del HLR donde está definido cada abonado.
A.1.3.7- Registro de Llamada de Grupo (GCR)
El GCR es una unidad funcional en la red conteniendo todos los atributos necesarios
para establecer y manejar llamadas de grupo de voz y broadcast. Esto incluye la lista
de miembros del grupo de llamada, prioridades, información de red, etc. Los atributos
son asignados en el momento del registro y son cargados en el GCR.
Cuando una llamada de grupo de voz o broadcast se inicia el MSC interroga al GCR
por los parámetros necesarios para establecer la llamada.
A.1.3.8- Central de Operación y Mantenimiento (OMC)
El OMC es la entidad funcional a través de la cual el operador de red puede

monitorear y controlar el sistema.
95
A.1.3.9- Definición de interfaces:
A: Interfaz definida por el ETSI situada entre el BSS y el MSC. Se explica

detenidamente en el siguiente apéndice.
Abis: Interfaz definida por el ETSI y situada entre el BSC y el BTS.
Um: Interfaz aérea definida por el ETSI y situada entre el BTS y el móvil.
Protocolo del nivel físico de la interfaz Um
La capa física de la interfaz Um se compone de canales físicos de radiofrecuencia

multiplexados en el tiempo para el acceso de los abonados al sistema
(FDMA/TDMA).
Las frecuencias que se utilizan en GSM se dividen en dos bandas de 25 MHZ. de la

siguiente forma:
En la banda de frecuencias bajas se implementan los canales ascendentes, es decir
desde el móvil a la estación base y en la banda de frecuencias altas se implementan
los canales descendentes que son dirigidos desde la estación base al móvil.
Sobre el ancho de banda correspondiente se realiza la multiplexación por división en

frecuencia (FDM) en canales de 200 kHz., obteniéndose así los canales de
radiofrecuencia (RFCH). A su vez cada canal de 200 kHz. es multiplexado en el
tiempo (TDM) en 8 intervalos de tiempo (TS) que conforman una trama TDMA (Sobre
el RFCH). Denominándose canal físico a cada TS de un correspondiente RFCH.
Según la información que transfieren los canales físicos, se distinguen en GSM dos
tipos de canales lógicos:
- canales de tráfico
- canales de control
Los canales de tráfico llevan información del usuario (voz o datos), la voz es
digitalizada a 22.8 kbps. También pueden ser de velocidad mitad. Se agrupan en el
tiempo según una multitrama de 26 tramas la cual se vuelve a agrupar en 51
multitramas para formar una supertrama y éstas se agrupan en 2048 supertramas
para formar una hipertrama que contiene 2715647 tramas.
96
Los canales de control se utilizan para la señalización y sincronización. Estos se
agrupan en el tiempo en multitramas de 51 tramas las que se agruparán luego en
una supertrama de 26 multitramas y finalmente en 2048 supertramas para formar
una hipertrama que contiene 2715647 tramas. Se dividen en cuatro grupos: Difusión,
Control Común, Dedicados y Asociados.
CANALES DE
TRÁFICO
CANALES DE
CONTROL
ASOCIADOS
Los canales de control se utilizan para la señalización y sincronización. Estos se

agrupan en el tiempo en multitramas de 51 tramas las que se agruparán luego en
una supertrama de 26 multitramas y finalmente en 2048 supertramas para formar
una hipertrama que contiene 2715647 tramas. Se dividen en cuatro grupos: Difusión,
Control Común, Dedicados y Asociados.
Canales de difusión
 BCCH (canal de control de difusión), en el que se transmite información genérica

sobre la red como por ejemplo, el identificador de la red (correspondiente a los
distintos operadores), identificación de la celda donde se encuentra el móvil,
listado de los canales de frecuencia que están en uso en dicha celda, potencia
máxima con la que puede transmitir el móvil (para que demasiada potencia no
alcance otras celdas que no sea la que le corresponde).
 FCCH (canal de corrección de frecuencia) el cual se emplea para que la estación
móvil pueda sincronizar la frecuencia interna (de reloj) consiguiéndose de esta
forma la sincronización a nivel de bit.
 SCH (canal de sincronización) que se utiliza para identificar la estación base y
sincronizar las tramas. En él se envía el número de trama que va de 0 a 2715647
y el identificador de la celda (BSIC). También se transmite información de
numeración de los TS.
97
Canales de Control Común
 PCH (canal de búsqueda) que se emplea para buscar y notificar a un usuario que
tiene una llamada, se envía por él la identificación internacional de estación móvil
(IMSI) que representa internacionalmente al abonado móvil con el fin de buscarlo.
También se emplea para enviar mensajes cortos a todos los abonados desde la
estación base.
 RACH (Canal de acceso aleatorio) es el canal por el cual el móvil contesta
cuando ha recibido un mensaje de búsqueda. Es un canal común que emplean
todos los móviles enviando un mensaje a la estación base cuando el móvil quiere
acceder al sistema.
 AGCH (canal de asignación) el cual sirve para que la estación base le asigne un
canal al móvil cuando éste ha contestado a un mensaje de búsqueda. A través de
este canal la estación base le indica al móvil qué canal de tráfico (RFCH y Nro. de
TS) deberá sintonizar para realizar la comunicación.
Canales Dedicados
 SDCCH (canal dedicado stand-alone) que se emplean cuando se requieren

servicios de señalización para el usuario, en el tiempo que transcurre desde que
el móvil se conecta con la estación base hasta que ésta le asigna un canal de
tráfico. Durante el tiempo en que la estación base y el móvil están conectados por
el SDCCH se verifican una serie de requisitos como por ejemplo que el abonado
esté dado de alta, que sus datos sean correctos, etc.
Canales Asociados
 SACCH (canal asociado lento) el cual no es un canal que represente a un recurso

físico propio (RFCH, TS) sino que está asociado a un canal de tráfico (TCH) o un
canal de control dedicado (SDCCH) que ya están establecidos y que poseen un
recurso físico propio es decir que en un determinado momento (periódicamente)
el SACCH utilizará el recurso físico del TCH o SDCCH para enviar su mensaje.
Esta es información de control que cambia lenta y periódicamente y que es
enviada por la estación base hacia el móvil como por ejemplo pedidos de
medición de potencia, ajustes de distancia, etc., y a su vez de parte del móvil
hacia la estación base notificando resultados de medidas de señal recibida de
otras frecuencias, etc.
 FACCH (canal asociado rápido) que es otro canal asociado a un canal de tráfico,
el cual se emplea para enviar mensajes urgentes (no periódicos), utiliza en canal
TCH de forma que al modificar en valor de una bandera que se encuentra en la
ráfaga de bitios que pasar por el TS del TCH se notifica que lo que viene a
continuación es información FACCH luego se restauran las banderas y continúa
98
la información del TCH. Un mensaje urgente puede ser la necesidad de cambiar a
otro canal RFCH debido al deterioro de la señal.
CCH
Canales de control
N NB/D
B NB/A B
B
BCCH – enlace
DCCH descendente solo
BCCH Canales de
SDCCH ACCH sincronismo
S F
B B
FACCH SAACH SCH FCH
CCH
A N
B B
RACH – Enlace PCH/AGCH –

ascendente Enlace descendente
Abreviaturas:
NB Ráfaga normal
FB Ráfaga de frecuencia
SB Ráfaga de sincronismo
AB Ráfaga de acceso
DB Ráfaga inicial
99
A.1.4- Algunos aspectos fundamentales del sistema
A.1.4.1- Control de potencia:
El móvil y la BTS funcionan con el nivel de potencia mínimo con el que se pueda
mantener una calidad aceptable de la señal, para minimizar la interferencia cocanal
(aquel canal de otra celda lejana que posee el mismo RFCH). Esto se logra
enviando mensajes para ajustar la potencia. El ajuste de potencia esta bajo el control
del BSC.
A.1.4.2- Salto en Frecuencia:
Si el operador opta por brindar esta característica entonces un canal físico saltará
secuencialmente a distintas frecuencias en la misma posición de TS (dentro del
grupo de RFCH que corresponden a la celda donde se encuentra el móvil) cuya
secuencia será indicada por un algoritmo.
Los radiocanales son canales de desvanecimiento selectivo de frecuencia lo que

significa que las condiciones de propagación son distintas para cada radiocanal. Por
eso en cualquier momento un teléfono móvil puede experimentar en cualquier canal
un desvanecimiento o interferencia. Entonces si se cambiara a otra frecuencia en el
mismo punto no experimentaría el problema.
A cada radiobase se le asignan una cantidad de TRX es decir canales de

radiofrecuencia, denominados “Asignación de Celda” (CA). Este conjunto CA incluye
el canal Co denominado frecuencia piloto, que es la menor frecuencia de las CA y
que queda determinada para los canales de control. Este canal C0 no puede saltar.
El resto de los canales de CA exceptuado el C0 se denomina asignación de móviles
(MA). Un canal físico es decir un par constituido por una RFCH y un TS va a saltar
secuencialmente a distintas frecuencias en la misma posición de TS, para cada
trama según una secuencia tomada del grupo MA y determinada por un algoritmo
que da como resultado el canal RFCH siguiente, en la comunicación
Podemos ver ejemplarizado el salto en frecuencia en la siguiente figura:
100
F
RFCH 533
RFCH 526
RFCH 519
RFCH 512
TS 0 TS 1 TS 2 TS 3 TS 4 TS 5 TS 6 TS 7 TS 0 TS 1 TS 2 TS 3 TS 4 TS 5 TS 6 TS 7 TS 0 TS 1 TS 2 TS 3 TS 4
BCCH
TCH
TCH
Canal de base ráfagas de relleno
A.1.4.3- Traspaso de Frecuencia:
Consiste en el cambio de canal para una comunicación el cual puede ser ocasionado
por tres motivos:
- traspaso de rescate
Esto ocurre cuando empeora la calidad de la señal de modo que se hace necesario
cambiar de RFCH para no perder la comunicación.
- traspaso de tráfico
Esto ocurre cuando una celda está saturada de tráfico y sucede que hay celdas
vecinas con poco tráfico (pocas llamadas) de forma que se intenta pasar llamadas a
la celda con menor tráfico indicando al móvil cambiar a los RFCH libres de dicha
celda.
- traspaso de confinamiento
Se traspasarán móviles a RFCH de otra celda cuando en ésta segunda tenga que
emitir con menor potencia, causando así menos interferencia.
A.1.4.4- Recepción discontinua
Es un método utilizado para ahorrar potencia en la estación móvil. El canal de

búsqueda utilizado por la BTS para señalar una llamada entrante se estructura en
subcanales, de forma que cada estación móvil ha de escuchar únicamente su propio
101
subcanal. En el tiempo que transcurre entre subcanales de búsqueda sucesivos el
móvil puede pasar al modo de reposo, en el que casi no se utiliza potencia.
A.1.4.5- Autenticación
La autenticación se realiza pidiendo al terminal móvil el resultado de un cálculo

específico usando algoritmos específicos sobre un número aleatorio (RAND) que
envía el sistema. Este proceso de cálculo depende de una clave secreta Ki que es
específica para cada abonado y se almacena en el Modulo de Identidad del Abonado
(SIM), que es una pequeña tarjeta de plástico con un chip la cual ha de insertarse en
cualquier terminal móvil para ser identificado como abonado móvil y así poder
acceder y permanecer en el sistema. La Ki también se almacena en el AuC y HLR.
A.1.4.6- Encriptado
Se encripta la ráfaga de bitios que pasa por un canal físico usando un algoritmo de
cifrado al cual se le aplica una clave Kc que se escoge para cada conexión. El
número personal de un abonado IMSI no se encripta para evitar que la gestión del
diálogo preliminar entre el terminal y la red sea compleja, de modo que la protección
de la identidad del abonado se logra usando un sustituto temporal del IMSI llamado
TMSI, que la red asigna la primera vez que un móvil se registra en un área
determinada.
A.1.4.7- Itinerancia
Es la función de seguimiento. Puesto que cuando se introduce la movilidad en un

sistema telefónico diferentes servidores pueden proporcionar servicio a un usuario
dado dependiendo de dónde se encuentre. La itinerancia o roaming solo se puede
proporcionar si se dan una serie de acuerdos administrativos y técnicos y es la
capacidad de un usuario de un operador de servicios de comunicaciones móviles de
usar la red de otro operador.
102
Referencias para este apéndice
BOSSE, Jhon G. Van. 1997. 6ta. Ed. Signalling in Telecommunication Network. New
York: Jhon Wiley & Son Inc.
RUSSELL, Travis. 1998. 2da.Ed. Signaling System Nr. 7. New York: Mac Graw Hill.
<http://etsi.org>
103
Apéndice B
B.1- Interfaz A y su Sistema de Señalización
B.1.1- Interfaz A
La interfaz BSS-MSC, denominada interfaz A, definida en las series 08 de las

Especificaciones Técnicas de GSM está diseñada para soportar un amplio rango de
posibles arquitecturas en ambos extremos. Las características como la localización
física del transcodificador/adaptador de velocidad en el BSS (ya sea integrado en el
transmisor o muy cerca del MSC) o el uso de concentración de tráfico o de
señalización son dejadas a opción del operador. La interfaz no soporta conexión
directa entre dos BSSs.
Esta interfaz está basada en el uso de una o más interfaces de sistemas de

transmisión digital de 2048 kbit/s, según la recomendación G703 de la ITU-T. Cada
una de ellas provee 31 canales de 64 kbps que pueden ser usados para tráfico o
señalización.
La señalización está estructurada tomando como ejemplo el modelo de referencia de

interconexión de sistemas abiertos (OSI) y se basa en el Sistema de Señalización
por Canal Común Nº 7 de ITU-T.
Está definida del lado del MSC y tiene una velocidad por canal de 64 kbps. Como el
canal de tráfico de radio tiene una velocidad menor de 16 kbps, se necesita un
transcodificador o función de adaptación de velocidad para la conversión de
velocidades. La interfaz está diseñada de forma que la función de adaptación de
velocidad pueda ser situada geográficamente del lado del BSS o del lado del MSC,
aunque se considera al transcodificador como parte del BSS.
La interfaz BSS–MSC debe ser capaz de soportar todos los servicios ofrecidos a los
usuarios y abonados de GSM. Además debe permitir la asignación de recursos de
radio adecuados en la PLMN, y la operación y mantenimiento de estos recursos.
104
B.1.1.1- Objetivos de especificación de la interfaz A
Los objetivos de especificación de la interfaz A, definidos en la TS 08.01 son los

siguientes:
i) Conexión de BSSs de distintos fabricantes al mismo MSC;

ii) El uso de MSCs de distintos fabricantes con el mismo tipo de BSS;
iii) El uso del mismo BSS en cualquier PLMN (Public Land Mobile Network);
iv) El uso del mismo MSC en cualquier PLMN;
v) La evolución separada de las tecnologías de MSC y BSS;
vi) La evolución separada de los servicios de O&M;
vii) La evolución hacia velocidades de codificación de voz menores;
viii) Soportar todos los servicios definidos en las series 02 de las
Especificaciones Técnicas GSM.
B.1.1.2- Características de la interfaz A
La interfaz A se define en el límite del MSC.

La interfaz se especifica por un conjunto de características, incluyendo:
i) Parámetros físicos y electromagnéticos;
ii) Estructura de canales;
iii) Procedimientos de operación de red;
iv) Soporte de información de Operación y Mantenimiento.
B.1.1.3- División funcional entre BSS y MSC
105
La TS 08.02 realiza la siguiente división funcional entre ambas entidades:
Función/tarea BSS MSC, VLR, HLR

Gestión de canales terrestres:
asignación de canales X
indicación de bloqueo X
Gestión de canales de radio:
gestión de configuración de canales de radio X
gestión de salto de frecuencia X
observación de canal libre X
control de potencia X
Gestión de TCH:
asignación de canal X
supervisión del enlace X
liberación de canal X X (Invocado por el MSC)
Gestión de BCCH/CCCH:
listado de mensajes X
Gestión de DCCH:
supervisión del enlace X
liberación de canal X X (Invocado por el MSC)
asignación de DCCH X
Indicación de recurso de radio:
reporte de estado de canales libres X
Codificación y decodificación de canal en MSC define el tipo de
base al tipo de llamada X llamada
Transcodificador/adaptador de la velocidad X
Función de interconexión (llamadas de dato) X
Medidas:
reportadas del MS X
enlace X
tráfico X
Handover:
interno (en una celda) X MSC informado
interno (entre celdas) X MSC informado
externo por reconocimiento de una razón de radio X
externo por reconocimiento de razón de tráfico X X
decisión X X
ejecución X
Gestión de movilidad:
autenticación X
actualización de ubicación X
búsqueda X
listado de búsqueda DRX X
Control de llamada: X
Encriptación de datos de usuario X Clave y algoritmo de
permiso del MSC
Encriptación de elementos de señalización X Clave y algoritmo de
permiso del MSC
106
El subsistema de la estación base (BSS)
Un BSS asegura la cobertura en un cierto número de celdas n, donde n puede ser

uno o más. Un lugar geográfico (celda) tiene cobertura radioeléctrica si allí es
posible para el móvil acceder al sistema celular para el establecimiento de una
comunicación con parámetros de calidad apropiados.
La función de un BSS puede ser subdividida en:

 una función de control, llevada a cabo por el controlador de estación base
BSC y
 una función transceptora (transmisión/recepción) llevada a cabo por n
estaciones base, una por cada celda.
En el análisis de la interfaz A, consideraremos al BSS como uno solo. La conexión

directa entre dos BSSs no es soportada en esta interfaz.
El BSS está compuesto por:

• La estación transeptora base (BTS) que es la parte más característica de una
red radioeléctrica celular, se compone de transmisores/receptores
denominados TRX y gestiona el marco radioeléctrico de acuerdo con la
norma.
• El controlador de la estación base (BSC) que por un lado gestiona la BTS
conectada (una o más) y por otro actúa como concentrador respecto de su
MSC.
• El equipo transcodificador y adaptador de la velocidad (TRAU) el cual puede
instalarse en el emplazamiento de la MSC o del BSC y que transcodifica los
canales GSM codificados en 16kbps a la norma de codificación de canal PCM
de 64kbps.
• Equipo submultiplexor (SM) que se utiliza en la interfaz Abis y en la interfaz A
con el fin de submultiplexar los intervalos de tiempo (TS) PCM de 64 kbps
para obtener el enlace de 2 Mbps que constituye dichas interfaces.
El BSS tiene asociado un centro de operación y mantenimiento radioeléctrico (OMC-

R) que gestiona y explota el BSS, manteniendo de esta forma al operador informado
del estado de la red, fundamentalmente del:
- estado de las alarmas
- tipo de alarmas
- tráfico de las células
Se denomina emplazamiento radioeléctrico a un sector geográfico de alcance de
una estación tranceptora base que posee una configuración cualquiera.
107
Central de Conmutación Móvil (MSC)
El centro de servicio de conmutación móvil se compone de tres partes principales:

• Conmutación
• Funciones de control radioeléctrico (RCF)
• Registro de ubicación de visitantes (VLR)
Esta arquitectura funcional ha sido definida por el ETSI para poder separar la función
de conmutación y la función de movilidad.
A la parte de conmutación se le denomina también Punto de Conmutación de
Servicios (SSP).
Se puede además agrupar las funciones de movilidad RCF y VLR en una misma
entidad denominada punto de Control Radioeléctrico (RCP), arquitectura que ha sido
adoptada por varios fabricantes.
El RCP tiene las siguientes funciones:
• Preprocesamiento de la interfaz A con respecto al BSS.
• Funciones de seguridad tales como la autenticación y el cifrado.
• Gestión del traspaso y la itinerancia.
• Tique de llamada.
• Base de datos para abonados visitantes.
• Prueba de los derechos de abonados.
La MSC es un elemento constitutivo del Subsistema de Red (NSS), la cual se puede

ver en la Figura B.1.1.
El NSS está asociado a un centro de operación y mantenimiento de red OMC-NSS
que se utiliza para gestionar los elementos del NSS. Además de esta función de
gestión, el OMC-NSS recibe todos los tiques de llamada del MSC, los controla y los
envía al Centro de Servicios y Atención al Cliente.
El objetivo del NSS es:
- como en toda Red Pública de Conmutación Telefónica (PSTN), lograr el

establecimiento, encaminamiento y gestión de la llamada y la prestación de diversos
servicios tales como los de facturación y servicios de valor añadido (Centro de
atención al cliente y Facturación CCB-C, Correo vocal, servicios de mensajes cortos
del correo vocal SMS-C, Registro de Identidad de Equipo móvil EIR, etc.).
- como en toda red móvil gestionar la movilidad de los usuarios de la red.
Todos los elementos constitutivos del NSS se encuentran del mismo lado de la
interfaz A.
El ETSI señala que el NSS comprende el HLR, el VLR, el AuC y la MSC.
108
Interfaz A
NSS
PSTN
MSC
RCP
CORREO
VOCAL
HLR/AuC
OMC-NSS
EIR SMS-C
CENTRO DE ATENCION AL CLIENTE Y FACTURACION

FACTURACION GESTIION
Figura B.1.1
B.1.1.4- Integración del transcodificador/adaptador de velocidad
El transcodificador estará integrado funcionalmente en el BSS. No se considera una

pieza aparte. El control del transcodificador se llevará a cabo directamente a través
del BSS, no se define una interfaz de control explicita entre el BSS y el
transcodificador.
Dependiendo del costo relativo de la planta de transmisión para una administración

en particular, habrá un beneficio económico para celdas grandes y ciertas topologías
de redes, en localizar el transcodificador del lado del MSC. Para celdas más
pequeñas habrá una penalidad de costos debida a la multiplexación especial.
Aún cuando el transcodificador esté situado del lado del MSC, se considerará parte
del BSS, y como si estuviera del lado del BSS en la interfaz BSS-MSC.
MSC
BTS TRAU
ENLACE DE
16 KBPS
INTERFAZ A
64 KBPS
Figura B.1.2 – Ubicación del transcodificador
109
B.1.1.5- Multiplexación de canales de control común y dedicados
Canales de control común y dedicados serán usados para la misma llamada en el

trayecto de radio. Estos canales serán multiplexados en uno o más canales de
señalización común entre el BSS y el MSC. La función de multiplexación residirá en
el BSS.
B.1.1.6- Clases de mensajes de señalización
Las señales entre el BSS y el MSC se clasifican de la siguiente manera:

iv) Mensajes de DTAP Mensajes de BSSAP
v) Mensajes de BSSMAP
vi) Operación y Mantenimiento del BSS
B.1.1.7- Soporte de servicios distinto a los de voz
Servicios de datos
Con el fin de asegurar que se cumplan los requerimientos de las Especificaciones

Técnicas GSM 03.10, el soporte de servicios de dato requerirá que las siguientes
acciones sean tomadas:
i) el codificador de voz sea desactivado en el móvil
ii) se active una función de adaptación de velocidad en el móvil
iii) un apropiado canal de codificación sea activado en el BSS
iv) una función de adaptación de velocidad sea activada en el BSS
v) cualquier control de eco en el MSC sea evitado o deshabilitado
vi) una apropiada función de interconexión de red sea invocada
Servicios suplementarios
Toda la señalización relacionada con los servicios suplementarios es pasada

transparentemente a por el BSS por medio del DTAP.
110
B.1.1.8- Estructura de la interfaz
La definición de la interfaz sigue un modelo de capas el cual se muestra en la Figura

B.1.2.
Figura B.1.3 - Modelo de referencia del protocolo de señalización
B.1.2- Sistema de señalización
La red de señalización es el sistema nervioso de las redes de telecomunicaciones y

de los servicios que éstas soportan. El analizador de protocolo de la interfaz MSC-
BSS (A) tiene como objetivo supervisar y controlar la calidad y uso de los diferentes
servicios móviles del sistema GSM.
La señalización de la interfaz A se lleva a cabo mediante el Sistema de Señalización

por canal común Nº 7 (SS7), el cual constituye una verdadera red de datos a través
de la cual dialogan los nodos de telecomunicaciones para coordinarse en la provisión
de los servicios.
Señalización hace referencia a un protocolo o lenguaje usado para intercambiar

información entre elementos de red, con el fin de proveer y mantener servicios. El
término señalización deriva de los sistemas originales que usaban señales (pulsos,
DTMF, o tonos MF) para la comunicación. Los sistemas de comunicación modernos
intercambian mensajes digitales complejos entre elementos de red. Señalización por
canal común se refiere a sistemas que llevan los mensajes de señalización por un
camino diferente (dedicado) que los de tráfico de voz y dato.
111
La red de señalización es la base de todo el diálogo entre nodos y por tanto el
soporte de los servicios: desde una simple llamada telefónica hasta los más
complicados servicios de red inteligente.
La introducción de los servicios de telefonía móvil, los servicios de red inteligente

(como la portabilidad de número), la convergencia entre fijo y móvil, etc., que realizan
un uso intensivo de la señalización, acentúan más este papel principal que
desempeña la red de señalización. De lo anterior se deduce la enorme sensibilidad
que presentan los servicios a los problemas de señalización. Baste como ejemplo
que el fallo de un circuito de voz afecta a una sola llamada, mientras que el de un
circuito de señalización puede afectar a miles. De modo que es muy necesario para
una operadora supervisar y planificar con especial cuidado esta red.
Debido a que el diálogo entre los nodos se realiza a través de la red de señalización,
se pueden utilizar los mensajes que se intercambian para conocer datos sobre los
servicios. Para esto debemos conocer los protocolos que utilizan los nodos de la red.
B.1.2.1- Sistema de señalización Nº 7
El Sistema de Señalización Nº 7 es un sistema de señalización de canal común

desarrollado por la ITU-T en respuesta a las demandas de mayores características y
servicio integrado de datos. Es un sistema de señalización de alta velocidad basado
en las recomendaciones de la serie Q.700 de la ITU-T, que se ha convertido en un
estándar de telecomunicación global.
SS7 define la arquitectura, procedimientos y protocolos para el intercambio de

información sobre canales digitales. Está diseñado para soportar establecimiento de
llamadas, ruteos, tarifado, información de base de datos, y funciones especiales de
servicio para PSTN. Las definiciones de ITU-T para SS7 permiten variantes
nacionales como ANSI, Bellcore (América del Norte), ETSI (usado en Europa), y
variantes de distintos países.
Un timeslot en los enlaces de señalización E1 (o T1) es usado para transmisión de

mensajes SS7. Las distintas aplicaciones tienen la flexibilidad para definir cualquiera
de los 31 o 24 timeslots como canal de señalización. Es decir, un canal es asignado
únicamente para enviar información de señalización. Con el fin de soportar esta
arquitectura, se creó un nuevo protocolo, el cual es una variación de conmutación de
paquetes de datos. Los paquetes de los canales de señalización contienen palabras
112
de trama, checksum, direcciones e información. El orden de los paquetes está bien
definido y es flexible de acuerdo a los requerimientos de usuario.
Ejemplo de aplicaciones soportadas por SS7:

 PSTN
 ISDN
 Interacción con bases de datos de la red y SCPs para control de servicios.
 Servicios móviles
 Operaciones de gestión y mantenimiento de redes.
SS7 provee las siguientes funcionalidades:

 Establecimiento de llamadas básicas, administración, tarifado, liberación.
 Incremento de los servicios de llamada, como llamada en espera, reenvío de
llamada, llamada compartida, etc.
 Manejo de congestión y prioridades.
 Servicios de radio, como servicio de roaming y autenticación de abonados
móviles.
 Portabilidad de número local (LNP)
 Servicio de llamadas
 Intercambio de información de bases de dato entre Elementos de Red.
 Administración de redes para la eficiencia y seguridad de las
Telecomunicaciones mundialmente.
Arquitectura de las redes de señalización
Tabla 3.3 - Estructura de la red
113
Enlaces de señalización
Los mensajes de SS7 son intercambiados entre elementos de red sobre uno o más
enlaces de señalización. La señalización ocurre fuera de banda en canales
dedicados, en vez de en banda, en canales de voz. Ventajas de señalización fuera
de banda sobre señalización en banda:
 Velocidad: tiempos más rápidos de establecimiento de llamadas (comparado
con señalización en banda usando tonos de señalización multifrecuentes)
 Eficiencia: mayor eficiencia en el uso de los circuitos de voz, especialmente en
llamadas internacionales o de larga distancia, dónde el canal de voz es solo
ocupado cuando el llamado se encuentra disponible.
 Flexibilidad: mensajes complejos, en lugar de señales simples permiten a SS7
ofrecer más servicios.
 Administración: soporte de señalización entre elementos de red, sin troncales
de voz.
 Control: mejor control sobre manejos de red fraudulentos.
Tipos de enlaces de señalización
La estructura de red de SS7 permite diferentes tipos de conexiones entre SPs

(Signalling Points). Estos enlaces están organizados por tipo (desde A a F), de
acuerdo a su uso en la red. Todos los enlaces son idénticos y soportan las mismas
capas del protocolo.
 Enlace A: Un enlace de acceso conecta SCPs o SSPs con un STP. Solo son
transmitidos por un enlace A mensajes originados desde o destinados hacia
puntos finales.
 Enlace B: Un enlace puente conecta STPs. Típicamente, los enlaces B
conectan STPs primarios de una red con STPs primarios de otra red.
 Enlaces C: Un enlace cruz conecta STPs realizando funciones idénticas, son
usados para mejorar la confiabilidad de la red de señalización. Un enlace C es
usado solo cuando un STP no tiene otra ruta habilitada para un punto de
destino, debido a fallas en un enlace.
 Enlace D: Un enlace diagonal interconecta pares de STPs en diferentes
niveles de jerarquías.
 Enlace E: Un enlace extendido conecta un SSP a un STP alternativo para
proveer un camino alternativo.
 Enlaces F: Un enlace Completamente asociado (Fully) conecta dos puntos
finales (por ejemplo SSP y SCP). Los enlaces F no son generalmente usados
en redes con STPs porque eliminan las características de seguridad provistas
por los STPs.
114
Puntos de Señalización (SP)
Cada punto de señalización en una red SS7 es identificado unívocamente por un

código numérico de punto (PC). Los códigos de punto son transportados en los
mensajes de señalización intercambiados entre puntos de señalización para
identificar el origen (OPC) y destino (DPC) de cada mensaje. Cada punto de
señalización usa una tabla de ruteo para seleccionar el camino de señalización
apropiado para cada mensaje.
Tipos de puntos de señalización
 SSP Service Switching Point: son conmutadores con software SS7 que
originan, finalizan o (tandem) llamadas. Un SSP envía mensajes de
señalización hacia otros SSPs para establecer, administrar y liberar circuitos
de voz requeridos para completar una llamada. Un SSP también debe enviar
un mensaje de pregunta a una base de datos centralizada (SCP) para
determinar el ruteo de una llamada.
 STP Signalling Transfer Point: son conmutadores de paquetes que rutean
tráfico de red entre puntos de señalización. Un STP rutea cada mensaje de
entrada para un enlace de señalización de salida basado en información de
ruteo contenida en el mensaje SS7. Al actuar el STP como un centro de la red,
mejoran la utilización de la red SS7, eliminando la necesidad de enlaces
directos entre puntos de señalización. Los STPs también ofrecen funciones
especiales de ruteo para números sin libres de costo, números de tarjetas de
llamada, o números de identificación de abonados móviles.
 SCP Service Control Point: son bases de datos que proveen la información
necesaria para capacidades avanzadas de procesamiento de llamadas. Los
STPs son usados generalmente en configuraciones pares, en localidades
físicas separadas como un sistema de respaldo. El tráfico es compartido en
todos los enlaces, por lo tanto, si uno de los enlaces falla, el tráfico de señales
es re ruteado sobre otro enlace. El protocolo SS7 provee capacidades de
corrección de error y retransmisión para permitir que el servicio continúe en
caso de que el punto o enlace de señalización fallen.
Capas del protocolo SS7
Como en el modelo OSI de referencia, las funciones de hardware y software del

protocolo SS7, están también divididas en capas funcionales. La arquitectura SS7
inicial se basaba en control de telefonía orientado a conexión, pero al surgir nuevos
115
requerimientos SS7 continúa evolucionando. Actualmente permite transmisión de
información no orientado a conexión, por ejemplo.
MTP (Message Transfer Part)

El MTP se divide en tres partes:
 MTP nivel 1: define las características físicas, eléctricas y funcionales del
enlace digital de señalización. Es equivalente a la Capa Física del modelo
OSI. Las definiciones de las interfaces físicas incluyen, DS1 (1.544 Mbps), E1
(2.048 Mbps), V.35 (64 kbps), DS0 (64 kbps), y DS0A (56 kbps).
 MTP nivel 2: define las funciones y procedimientos para asegurar la
seguridad de los mensajes transmitidos a través del enlace de señalización.
Asegura la transmisión correcta de extremo a extremo de mensajes.
Implementa control de flujo, validación secuencial de mensajes y chequeo de
error. Cuando un error ocurre en un enlace de señalización, los mensajes son
re transmitidos. El MTP nivel 2 es equivalente a la Capa de Enlace de Datos
del modelo OSI.
 MTP nivel 3: define las funciones de transporte, y procedimientos entre
puntos de señalización. Provee ruteo de mensajes entre puntos de
señalización en la red SS7. El MTP nivel 3 re rutea el tráfico cuando un enlace
falla y controla tráfico en caso de congestión. Es equivalente a la Capa Red
del modelo OSI.
SCCP (Signaling Connection Control Part)

Provee funciones adicionales al MTP, para soportar servicio a redes orientado a
conexión y no orientado a conexión y Traducción de Título Global (GTT). El SCCP
provee números de subsistema para permitir que los mensajes sean direccionados
hacia aplicaciones específicas o subsistemas en puntos de señalización específicos.
SCCP es usado como la capa transporte para servicios basados en TCAP.
TUP (Telephone User Part)

Define las funciones de señalización básicas de control de llamadas telefónicas para
establecimiento y liberación de llamadas básicas. El TUP maneja únicamente
circuitos analógicos. TUP fue una implementación inicial de SS7 y no permite
aplicaciones para datos. En la mayoría de los países ISUP ha reemplazado TUP
para la administración de llamadas.
116
ISUP (ISDN User Part)
Define los protocolos usados para establecer, administrar, y liberar circuitos troncales
que transportan voz y dato entre SSPs. ISUP es usado para llamadas ISDN o no.
Las llamadas que se originan en un conmutador y que terminan en el mismo
conmutador no utilizan señalización ISUP.
TC (Transaction Capabilities)
Provee los medios para establecer comunicación no orientada a conexión entre dos
SPs.
TCAP (Transaction Capabilities Application Part): soporta el intercambio de datos
en sistemas no orientados a conexión entre aplicaciones, a través de la red SS7,
usando el servicio no orientado a conexión como un transporte. Diálogos entre SSPs
y SCPs son transportados en mensajes TCAP. En redes móviles, el TCAP lleva
mensajes MAP (Mobile Application Part) enviados entre conmutadores móviles y
bases de datos para soportar autenticación de usuarios, identificación de equipos, y
roaming.
OMAP (Operation, Maintenance and Administration Part) y ASE (Application Service

Element)
El OMAP define mensajes y protocolos que asisten la gestión de redes SS7. Los
servicios OMAP deben ser usados para verificar bases de datos de ruteo de la red, y
para diagnosticar problemas de enlace. El ASE es un módulo o porción de un
protocolo en la Capa de Aplicación 7 del protocolo de pila del modelo OSI. Distintos
ASE son usados para formar un protocolo completo.
Referencias para éste apéndice
3GPP TS 08.01 version 8.0.1(2002) : "General Aspects on the BSS_MSC Interface".
3GPP TS 08.02 V8.9.0 (2001):"Base Station System - Mobile Services Swithing

Centre (BSS-MSC) Interface Interface Principles".
117
3GPP TS 08.04 V8.9.0 (2001): "Base Station System - Mobile Services Swithing
Centre (BSS-MSC) Interface Layer 1 Specification".
3GPP TS 08.06 V8.9.0 (2001): "Signalling transport Mechanism Specification for the
Base Station System - Mobile Services Swithing Centre (BSS-MSC) Interface".
3GPP TS 08.08 V8.9.0 (2001): " Mobile Services Swithing Centre - Base Station
System (MSC - BSS) interface; Layer 3 specification ".
<http://etsi.org>
118
Apéndice C
C.1 - Capa física (MTP1)
La capa 1 soporta los canales de tráfico y la señalización SS7. Se trata de la capa

física la cual es la capa más baja del modelo de referencia OSI y soporta todas las
funciones requeridas para la transmisión del flujo de bitios en el medio físico.
Esta capa utiliza información digital a una velocidad de 2048 kbps con una estructura
de trama de 32 intervalos de tiempo (TS) de 64 kbps, como se especifica en las
Recomendaciones ITU-T G.705 para la interfaz E1 (utilizada para el proyecto); o a
velocidad de 1544 kbps con una estructura de trama de 24 intervalos (TS) de 64
kbps, como se especifica en las especificaciones T1.102, para la interfaz T1.
Las características físicas y eléctricas están definidas en las Recomendaciones ITU-

T G.703, para la interfaz E1.
Las características funcionales están definidas en las Recomendaciones ITU-T
G.732, para la interfaz E1.
Las condiciones de falla deben ser tratadas de acuerdo con las Recomendaciones
ITU-T G.732, sección 4.
La voz es codificada por la Ley A para el sistema E1, como se define en las
Recomendaciones ITU-T G.711.
El BSS deriva la sincronización para transmitir de la señal recibida.
La codificación de dato se realiza de acuerdo con las Especificaciones Técnicas
GSM 08.20.
Un número predeterminado de TS son usados para señalización hacia un BSS o
más.
C.1.1- Enlace de datos de señalización
Un enlace de datos de señalización es un trayecto de transmisión bidireccional para

la señalización, compuesto de dos canales de datos que funcionan conjuntamente en
sentidos opuestos de transmisión a la misma velocidad de datos. Constituye el nivel
funcional más bajo (nivel 1) de la jerarquía funcional del sistema de señalización N°
7. La configuración funcional de un enlace de dato de señalización se muestra en la
Figura C.1.1.
119
Figura C.1.1 - Configuración funcional de un enlace de datos de señalización
Un enlace de datos de señalización digital está constituido por canales de

transmisión digitales y conmutadores digitales o sus equipos terminales que
proporcionan una interfaz a los extremos de señalización. Los canales de transmisión
digital se derivan de una señal múltiplex digital de 1544 o 2048 kbit/s o de flujos
múltiplex digitales que tienen una estructura de trama especificada para circuitos de
datos.
El enlace de datos de señalización operacional debe estar dedicado exclusivamente

al uso de un enlace de señalización del sistema N.° 7 entre dos puntos de
señalización. No deberá transmitirse por el mismo canal ninguna otra información
junto con la información de señalización.
120
Los equipos tales como supresores de eco, atenuadores digitales, o convertidores de
ley A/µ asociados al enlace de transmisión deberán desactivarse a fin de asegurar el
funcionamiento dúplex y la integridad de los bits para el flujo de datos transmitidos.
C.1.1.1- Velocidad de bits para la señalización
La velocidad binaria normalizada en un soporte digital será de 64 kbit/s.

Se podrá adoptar velocidades de bit menores de acuerdo con la aplicación, teniendo
en cuenta los requerimientos de los niveles de usuarios y la capacidad de los enlaces
de transmisión disponibles.
C.1.1.2- Características en lo relativo a los errores y a la disponibilidad
Las características en lo relativo a los errores y los requisitos de disponibilidad se

ajustarán a las Recomendaciones pertinentes (por ejemplo la Recomendación G.821
[9] sobre circuitos digitales).
C.1.1.3- Puntos de especificación del interfaz
Los requisitos de interfaz pueden especificarse en uno de tres puntos A, B o C

indicados en la Figura C.1.2. El hecho de que uno u otro de estos puntos sea
adecuado depende de la naturaleza de los enlaces de transmisión utilizados y del
método seguido para la realización del equipo de interfaz adoptado por cada
Administración. Para GSM el punto C es el apropiado.
Los requisitos de interfaz para un enlace de datos de señalización digital se

especificarán en el punto C de acuerdo con la estructura múltiplex específica
utilizada.
En las realizaciones en que no se satisfagan todos los requisitos indicados en la

Recomendación pertinente, entre las citadas, deberán tenerse en cuenta no
obstante, los requisitos especificados para las acciones de prueba y mantenimiento
que requieren comunicación entre los dos extremos de un enlace de datos. Los
requisitos de interfaz para prueba y mantenimiento se especifican en la
Recomendación Q.707.
121
Figura C.1.2
C.1.1.4- Enlace de datos de señalización digital (derivado del trayecto

digital a 2048 kbps)
Cuando un enlace de datos de señalización deba derivarse de un trayecto digital a

2048 kbit/s, se respetarán las siguientes disposiciones:
a) Los requisitos de interfaz especificados en el punto C de la Figura C.1.2
deberán ajustarse a las Recomendaciones G.703 [17] en cuanto a las características
eléctricas y a la Recomendación G.704 [1] en cuanto a las características
funcionales, en particular la estructura de trama.
b) La velocidad binaria será de 64 kbit/s.
c) El intervalo de tiempo de canal normalizado para el uso de un enlace de datos
de señalización es el intervalo de tiempo 16. Cuando el intervalo de tiempo 16 no
está disponible, puede utilizarse cualquier intervalo de tiempo de canal para la
transmisión de datos de usuario a 64 kbit/s.
d) No se efectúa ninguna inversión de bits.
3GPP TS 04.04 version 8.1.2(2002) : "Layer 1- General Requirements".
122
3GPP TS 08.04 V8.9.0 (2001): "Base Station System - Mobile Services Swithing
Centre (BSS-MSC) Interface Layer 1 Specification".
ITU-T - G.703 (2001): "Physical/Electrical characteristics of herarchical digital

interfaces".
ITU-T - G.704 (1998): "Synchronus frame structures used at 1544, 6312, 2048, 8448
and 44736 kbps hierarchical levels".
ITU-T - G.732 (1988): "Characteristics of primary PCM multiplex equipment operating

at 2048".
ITU-T - Q.702 (1988): "Signalling data link".
http://etsi.org
123
C.2 – Enlace de señalización (MTP2)
El MTP 2 (Message Transfer Part 2) realiza las funciones y procedimientos relativos

a la transferencia de mensajes de señalización por un enlace de datos de
señalización. Las funciones del enlace de señalización, junto con un enlace de datos
de señalización empleado como soporte, proporcionan un enlace de señalización
para la transferencia fiable de mensajes entre dos puntos de señalización
conectados directamente.
Los mensajes de señalización entregados por niveles jerárquicos superiores son

transferidos por el enlace de señalización mediante unidades de señalización de
longitud variable. Las unidades de señalización contienen además de la información
de señalización, información de control de transferencia, para asegurar el
funcionamiento adecuado del enlace de señalización.
Las funciones del enlace de señalización comprenden:
a) delimitación de las unidades de señalización;

b) alineación de las unidades de señalización;
c) detección de errores;
d) corrección de errores;
e) alineación inicial;
f) supervisión de errores en el enlace de señalización;
g) el control de flujo.
Todas estas funciones están coordinadas por la parte control del estado del enlace
como se muestra en la Figura C.2.1.
124
Control del enlace de señalización
(nivel 2)
a)
MSU
LSSUa) Parte
recepción
SUa)
Funciones Detección de Enlace de

Parte control Parte control Bits datos de
de la red de del estado errores, enviados
señalización de congestión delimitación señalización
del enlace y recibidos (nivel 1)
(nivel 3) y alineación
SUa)
Parte
MSUa) recuperada transmisión
a)
MSU
T1156520-93
Flujo de mensajes de señalización

Señales de control e indicaciones
MSU Unidad de señalización de mensaje (message signal unit)
SU Unidad de señalización (signal unit)
LSSU Unidades de señalización del estado de enlace (link status signal units)
a)
Estas unidades de señalización no incluyen toda la información de protección contra errores.
Figura C.2.1 – Interacciones de los bloques de especificación funcional

para el control de enlace de señalización
C.2.1- Delimitación y alineamiento de las unidades de señalización
El principio y el final de una unidad de señalización se indican mediante una

configuración particular de 8 bits, denominada bandera. Se han tomado medidas
para asegurar que la configuración no pueda reproducirse en ningún otro punto de la
unidad.
La pérdida de alineamiento tiene lugar cuando se recibe una configuración de bits no

permitida por el procedimiento de delimitación (más de seis unos consecutivos), o
cuando se rebasa una determinada longitud máxima de la unidad de señalización.
La pérdida de alineamiento provocará un cambio en el modo de funcionamiento del
monitor de la tasa de errores en las unidades de señalización.
C.2.2- Detección de errores
La función de detección de errores se realiza mediante 16 bits de control colocados

al final de cada unidad de señalización. Los bits de control se generan por el extremo
transmisor del enlace de señalización a partir de los bits precedentes de la unidad de
125
señalización según un algoritmo específico. En el terminal receptor del enlace de
señalización, los bits de control recibidos son tratados usando reglas específicas que
corresponden a dicho algoritmo.
Si, de acuerdo con el algoritmo, los bits de control recibidos son incoherentes con los
bits precedentes de la unidad de señalización, existe presencia de errores, por lo que
la unidad de señalización es descartada.
C.2.3- Corrección de errores
El método de corrección de errores que se utiliza en la interfaz es el método básico,

este método se aplica a enlaces que usan medios de interconexión de señalización
terrestres, no intercontinentales, donde el retardo de propagación en un sentido es
menor que 15 ms.
El método básico es un sistema de corrección de errores por retransmisión, con

acuse de recibo positivo/negativo de secuencia no obligada. Una unidad de
señalización transmitida queda retenida en el terminal emisor del enlace de
señalización hasta que se reciba un acuse de recibo positivo de esa señal. Si llega
un acuse de recibo negativo, se interrumpe la transmisión de nuevas unidades de
señalización, y las unidades de señalización que han sido transmitidas pero no han
sido aún objeto de acuse de recibo positivo serán retransmitidas una vez, en el orden
en que fueron transmitidas primeramente comenzando por las indicadas en el acuse
de recibo negativo.
C.2.4- Alineamiento inicial
El procedimiento de alineamiento inicial sirve tanto para la primera inicialización (por

ejemplo, después de "conectar") como para el alineamiento subsiguiente a un
restablecimiento después del fallo de un enlace. El procedimiento se basa en el
intercambio obligatorio de información sobre el estado entre los dos puntos de
señalización en cuestión y en el establecimiento de un periodo de prueba. En el
alineamiento inicial de un enlace particular cualquiera no interviene ningún otro
enlace de señalización; el intercambio tiene lugar solamente en el enlace que se va a
alinear.
126
C.2.5- Supervisión de errores en el enlace de señalización
Se prevén dos funciones de supervisión de la tasa de errores en el enlace de

señalización: una que actúa mientras un enlace de señalización está en servicio y
proporciona uno de los criterios para retirar el enlace del servicio, y otra que actúa
mientras que un enlace está en el periodo de prueba del procedimiento de
alineamiento inicial. Estas funciones se denominan respectivamente monitoreo de la
tasa de errores en las unidades de señalización y monitor de la tasa de errores en la
alineación. Las características del monitoreo de la tasa de errores en las unidades de
señalización se basan en un cómputo de los errores en las unidades de señalización
que es incrementado y decrementado según un principio de memoria elástica que se
conoce por el término anglosajón "leaky bucket", mientras que el monitor de la tasa
de errores en la alineación se basa en un cómputo lineal de los errores en las
unidades de señalización. Durante la pérdida de alineamiento, el cómputo de errores
por el monitoreo de la tasa de errores en las unidades de señalización se incrementa
proporcionalmente a la duración de la pérdida de alineamiento.
C.2.6- Funciones de control del estado del enlace
El control del estado del enlace es una función del enlace de señalización que da
directrices a las otras funciones del enlace de señalización. En la Figura C.2.1 se
muestran las interfaces con el control del estado del enlace. La división en bloques
funcionales representada en la figura tiene por objeto facilitar la descripción de los
procedimientos relativos a los enlaces de señalización y no debe considerarse que
impliquen una realización determinada.
C.2.7- Control del flujo
El control del flujo se inicia cuando se detecta congestión en el extremo receptor del
enlace de señalización. El extremo receptor congestionado del enlace notifica este
estado al extremo transmisor distante, por medio de una unidad de señalización del
estado del enlace apropiada, y retiene los acuses de recibo de todas las unidades de
señalización de mensajes entrantes. Cuando desaparece la congestión, se reanudan
los acuses de recibo de todas las unidades de señalización de mensajes entrantes.
Mientras dura la congestión, se notifica periódicamente de este estado al extremo
transmisor distante. Si la congestión se prolonga excesivamente, el extremo
transmisor distante indicará que el enlace está defectuoso.
127
C.2.8- Formato básico de la unidad de señalización
La señalización y otras informaciones procedentes de un usuario se transfieren por el

enlace de señalización mediante unidades de señalización. Una unidad de
señalización se compone de un campo de información de señalización de longitud
variable, que contiene la información generada por un usuario y un cierto número de
campos de longitud fija que contienen la información necesaria para el control de la
transferencia de mensaje. En el caso de unidades de señalización del estado del
enlace, el campo de información de señalización y el octeto de información de
servicio son sustituidos por un campo de estado, generado por el terminal del enlace
de señalización.
Existen tres tipos de unidad de señalización que se distinguen por medio del
indicador de longitud que figura en todas las unidades de señalización, es decir:
unidades de señalización de mensaje (MSU), unidades de señalización del estado
del enlace (LSSU) y unidades de señalización de relleno (FISU). En caso de error,
las unidades de señalización de mensaje son retransmitidas, mientras que las
unidades de señalización del estado del enlace y las unidades de señalización de
relleno no se retransmiten. En la Figura C.2.3 se muestran los formatos básicos de
las unidades de señalización.
F B
F CK SIF SIO LI I FSN I BSN F
B B
Primer bit
8 16 8n, n  2 8 2 6 1 7 1 7 8 transmitido
a) Formato básico de una unidad de señalización de mensaje (MSU)
F B
F CK SF LI I FSN I BSN F
B B
Primer bit
8 16 8 ó 16 2 6 1 7 1 7 8 transmitido
b) Formato de la unidad de señalización del estado del enlace (LSSU)
F B
F CK LI I FSN I BSN F
B B
Primer bit
8 16 2 6 1 7 1 7 8
transmitido
c) Formato de la unidad de señalización de relleno (FISU)
T1156540-93
BIB Bit indicador inverso (backward indicator bit)

BSN Número secuencial inverso (hacia atrás) (backward sequence number)
CK Bits de control de errores (check bits)
F Bandera (flag)
FIB Bit indicador directo (forward indicator bit)
FSN Número secuencial directo (hacia adelante) (forward sequence number)
LI Indicador de longitud (length indicator)
n Número de octetos en el SIF
SF Campo de estado (status field)
SIF Campo de información de señalización (signalling information field)
SIO Octeto de información de servicio (service information octet)
Figura C.2.3 – Formatos de unidades de señalización
128
C.2.8.1- Funciones y códigos de los campos de la unidad de señalización
La información de control de transferencia de mensaje está contenida en ocho

campos de longitud fija de la unidad de señalización, que contienen información
necesaria para la protección contra errores y la alineación de mensajes.
Bandera
La bandera de apertura (flag) indica el comienzo de una unidad de señalización.
Normalmente, la bandera de apertura de una unidad de señalización es la bandera
de cierre de la unidad de señalización precedente. La bandera de cierre indica el fin
de una unidad de señalización. La configuración de bits para la bandera es
01111110.
Indicador de longitud
El indicador de longitud (LI, lenght indicator) se utiliza para indicar el número de
octetos que siguen al octeto indicador de longitud y preceden a los bits de control, y
es un número en código binario comprendido entre 0 y 63. El indicador de longitud
identifica el tipo de unidades de señalización de la siguiente manera:
Indicador de longitud  0: Unidad de señalización de relleno

Indicador de longitud  1 ó 2: Unidad de señalización del estado del enlace
Indicador de longitud  2: Unidad de señalización del mensaje
Cuando el campo de información de señalización de una unidad de señalización de

mensaje contenga 62 octetos o más, el indicador de longitud se pondrá a 63. Es
obligatorio que el extremo transmisor fije LI a su valor correcto especificado más
arriba.
Octeto de información de servicio

El octeto de información de servicio (Service Information Octet) está dividido en el
indicador de servicio (Service Indicador) y el campo de subservicio (Subservice
Field). El indicador de servicio se utiliza para asociar la información de señalización
con una determinada parte de usuario, y se emplea solamente con unidades de
señalización de mensaje.
129
Numeración secuencial
El número secuencial directo (hacia adelante) (FSN, Forward Sequence Number) es
el número secuencial de la unidad de señalización en la que está contenido.
El número secuencial inverso (hacia atrás) (BSN, Backward Sequence Number) es el
número secuencial de una unidad de señalización de la que se está acusando recibo.
Los números secuenciales hacia adelante y hacia atrás son números codificados en
binario según una secuencia cíclica que va de 0 a 127.
Bits indicadores
El bit indicador directo (hacia adelante) y el bit indicador inverso (hacia atrás) (FIB,
Forward Indicador Bit y BIB, Backward Indicador Bit) junto con el número secuencial
hacia adelante y el número secuencial hacia atrás se emplean en el método básico
de control de errores para efectuar funciones de control de secuencia de unidades de
señalización y funciones de acuse de recibo.
Bits de control
Cada unidad de señalización tiene 16 bits de control para fines de detección de
errores.
Campo de información de señalización

El campo de información de señalización (SIF, Signalling Information Field) está
formado por un número entero de octetos; comprendido entre 2 y 272, ambos valores
inclusive. El valor 272 permite que una única unidad de señalización de mensaje
incluya bloques de información de hasta 268 octetos de longitud acompañados de
una etiqueta de encaminamiento.
El formato y los códigos del campo de información de señalización están definidos

para cada parte de usuario.
Campos reservados
Los campos reservados se codifican 0 (cero), a menos que se indique lo contrario.
Orden de transmisión de los bits

Cada uno de los campos mencionados anteriormente se transmite en el orden
indicado en la Figura C.2.3.
Dentro de cada campo o subcampo, los bits se transmiten comenzando por el bit
menos significativo (el de menor peso). Los 16 bits de control se transmiten en el
mismo orden en que se generan.
130
ITU-T - Q.703 (1996): "Signalling link".
http://etsi.org
131
C.3 – Red de señalización (MTP3)
C.3.1- Introducción
Las funciones y procedimientos relacionados con la transferencia de mensajes entre

dos puntos de señalización, que son los nodos de la red de señalización, son
realizadas por el MTP nivel 3. Las funciones de red de señalización deben asegurar
una transferencia confiable de los mensajes de señalización, de acuerdo a los
requerimientos especificados en las Recomendaciones Q.706, incluso en caso de
falla del enlace y puntos de transferencia de señalización; por esta razón incluyen las
funciones apropiadas y procedimientos necesarios para informar a las partes
remotas de la red sobre las consecuencias de una falla y para reconfigurar
apropiadamente el ruteo de mensajes a través de la red de señalización.
De acuerdo con estos principios las funciones de la red de señalización pueden ser
divididas en dos categorías básicas:
 manejo de mensajes de señalización,

 gestión de la red de señalización.
Si el BSS solo se implementa como un punto terminal de un enlace de señalización,

entonces no soporta función de STP, por lo tanto no habrá que considerar
características de gestión de STP.
C.3.2- Manejo de mensajes de señalización
El propósito de las funciones de manejo de mensajes es asegurar que los mensajes

de señalización originados por un usuario en un punto de señalización son
entregados en el mismo usuario del punto de destino indicado por el usuario que lo
envía. Dependiendo de las circunstancias particulares, la entrega puede ser
realizada a través de un enlace de señalización directamente interconectando los
puntos de origen y destino, o a través de uno o más puntos de transferencia
intermediarios.
132
Las funciones de manejo de mensajes de señalización se basan en la etiqueta
contenida en el mensaje, que explícitamente identifica los puntos de origen y destino.
Esta etiqueta, se llama etiqueta de ruteo.
Como se muestra en la Figura C.3.1, las funciones de manejo de mensajes de

señalización se dividen en:
 función de ruteo de mensaje, usada en cada punto de señalización para

determinar el enlace de señalización de salida sobre el cual un mensaje debe
ser enviado hasta su punto de destino;
 función de discriminación del mensaje, usada en un punto de señalización
para determinar si el mensaje recibido está destinado a tal punto. Cuando el
punto de señalización tiene la capacidad para transmitir y el mensaje no está
destinado a él, el mensaje debe ser transferido a la función de ruteo de
mensaje;
 función de distribución de mensaje, usada en cada punto de señalización
para entregar el mensaje recibido al usuario apropiado.
Level 3 Level 2
Level 4
Message Transfer Part Message
User
Transfer
Parts Signalling network functions Part
Signalling message handling
Message Message
distribution discrimination
Message
routing
Signalling network management
Signalling
traffic
management
Signalling Signalling
route link
management management
T1158780-94/d001
Testing and maintenance (Message Transfer Part)
Signalling message flow
Indications and controls
Figura C.3.1 - Funciones de red de señalización
133
En la función de ruteo de mensaje concierne el mensaje a ser enviado, mientras que
en la función de distribución de mensaje concierne el mensaje recibido. La relación
funcional entre ruteo y distribución aparece en la Figura C.3.2.
Discri-
Distribution mination
To/from level 4
(up level) To/from level 2
Routing
T1158790-94/d02
Figura C.3.2 - Ruteo, discriminación y distribución del mensaje
Cuando un mensaje viene del nivel 4 (o es originado en el nivel 3, en el caso de

mensajes MTP de nivel 3), la elección del enlace de señalización particular en el cual
debe ser enviado es realizada por la función de ruteo de mensaje. Cuando dos o más
enlaces son usados al mismo tiempo para llevar tráfico con el mismo destino, este
tráfico es distribuido a través de él por la función de mensajes compartidos, la cual es
parte de la función de ruteo de mensaje.
Cuando una función viene del nivel 2, la función de discriminación de mensaje es

activada, con el fin de determinar si es destinado a otro punto de señalización.
Cuando el punto de señalización tiene la capacidad de transferencia y el mensaje
recibido no está destinado a él, el mensaje debe ser transmitido sobre un enlace de
salida, de acuerdo con la función de ruteo.
En el caso de que el mensaje esté destinado al punto de señalización receptor, la

función de distribución de mensaje es activada con el fin de entregarlo al usuario
apropiado (o a las funciones locales de MTP 3).
Si no se requiere el uso de STP las funciones de ruteo y discriminación pueden ser

significativamente simplificadas en aplicaciones para GSM. Como la implementación
de esta interfaz está definida para aplicación punto a punto, la función de ruteo en el
MTP estará presente para seleccionar el código de punto apropiado para el MSC.
El ruteo, discriminación y distribución del mensaje se basan en la etiqueta de ruteo,

en el indicador de servicio, y en redes nacionales, en el indicador de red. La etiqueta
usada para mensajes de gestión de la red de señalización es también usada para
mensajes de testeo y mantenimiento (Recomendaciones Q.707).
134
C.3.2.1 Etiqueta de ruteo
La etiqueta contenida en un mensaje de señalización, y usada por el usuario

correspondiente, para identificar la tarea a la cual el mensaje hace referencia, es
también usada por el MTP para rutear el mensaje hacia el punto de destino.
La parte de la etiqueta del mensaje que es usada para rutear se llama etiqueta de
ruteo, y contiene la información necesaria para entregar el mensaje a su punto de
destino.
Normalmente la etiqueta de ruteo es común a todos los servicios y aplicaciones en

una determinada red de señalización, nacional o internacional. La etiqueta de ruteo
estándar debe ser usada en la red internacional, y también es aplicable para
aplicaciones nacionales. Puede haber aplicaciones usando una etiqueta modificada
con la misma función y orden, pero posiblemente diferentes tamaños, con sub-campo
como la etiqueta de ruteo estándar.
La etiqueta de ruteo estándar tiene un largo de 32 bits y se localiza al principio del

campo de información de señalización. Su estructura se ve en la Figura C.3.3.
SLS OPC DPC
First bit
Length n 8 4 14 14 transmitted
(bit) (n  0)
Routing label
Label
T1158800-94/d03
DPC Destination Point Code

OPC Originating Point Code
SLS Signalling Link Selection
Figura 7.3 - Estructura de la etiqueta de ruteo
El Destination Point Code (DPC) indica el punto de destino del mensaje. El

Originating Point Code (OPC) indica el punto de origen del mensaje. La
codificación de estos códigos es puramente binaria. En cada campo, el bit menos
significativo ocupa la primera posición y es transmitido primero.
Un único esquema numérico para la codificación de los campos será usado para los
puntos de señalización de redes internacionales, independientemente de los usuarios
conectados a cada punto de señalización.
El campo Selección de Enlace de Señalización (SLS) es usado cuando se

comparte carga. Este campo existe en todos los tipos de mensajes y siempre en la
135
misma posición. La única excepción a la regla son algunos mensajes del MTP de
nivel 3, para los cuales la función de ruteo de mensaje en el punto de señalización de
origen del mensaje no es dependiente del campo: en este caso particular el campo
no existe como tal, pero es reemplazado por otra información. En los BSSs con más
de un enlace de señalización se compartirá carga utilizando este campo SLS.
En el caso de mensajes MTP de nivel 3, el campo de selección de enlace de

señalización se corresponde exactamente con el Código de Enlace de
Señalización (SLC), el cual indica los enlaces de señalización entre el punto de
origen y el de destino correspondientes al mensaje.
La selección de enlace de mensajes generados por cualquier usuario será usado en

el mecanismo para compartir carga. Como consecuencia, en el caso de usuarios que
no están especificados, pero para los cuales es requisito mantener el orden de
transmisión de mensajes, el campo debe ser codificado con el mismo valor para
todos los mensajes pertenecientes a la misma transacción, enviados en una
determinada dirección.
C.3.2.2- Función de ruteo de mensaje
La función de ruteo de mensaje se basa en información contenida en la etiqueta de

ruteo, específicamente el DPC y el campo SLS; en algunas circunstancias también
es necesario conocer el indicador de servicio.
Cada punto de señalización tendrá una información de ruteo que le permita

determinar el enlace de señalización sobre el cual el mensaje tiene que ser enviado.
Típicamente el DPC está asociado con más de un enlace de señalización que puede
ser usado para llevar el mensaje, la selección del enlace particular se hace de
acuerdo con el SLS.
Se definen dos formas distintas de compartir carga:

1) entre enlaces pertenecientes al mismo grupo de enlaces;
2) entre enlaces no pertenecientes al mismo grupo de enlaces.
La compartición de carga entre grupos de enlaces no es un requerimiento porque

sólo hay un grupo de enlaces entre el BSS y el MSC.
136
En el caso 1), el flujo de tráfico llevado por un grupo de enlaces es compartido (en
base al campo SLS) entre diferentes enlaces pertenecientes al mismo grupo de
enlaces. Un ejemplo de este caso se da en la Figura C.3.4, donde un grupo de
enlaces inter-conexiona directamente los puntos de origen y destino.
SLS = XXX0
A B
SLS = XXX1
T1158810-94/d04
Figura C.3.4 - Ejemplo de carga compartida en un grupo de enlaces
El caso 2) no se da entre BSSs y MSCs.
La información de ruteo debe ser apropiadamente adaptada cuando algún evento

sucede en la red, que sea relevante al punto de señalización. Si un punto de
transferencia recibe un mensaje para un DPC que de acuerdo con la información de
ruteo no existe, el mensaje es descartado y se da una indicación al sistema de
gestión.
Manejo de mensajes de nivel 3
A los mensajes no relacionados con un enlace de señalización se les debe asignar

un SLC para permitir compartir la carga del mensaje, o se le debe asignar un SLC
por defecto como 0000. Son ruteados de acuerdo con la función normal de ruteo,
dónde el SLC es usado como el SLS para compartir carga.
Los mensajes relacionados a un enlace de señalización se deben subdividir en dos
grupos:
1) Mensajes que serán transmitidos sobre un enlace de señalización específico,
dónde una función especial de ruteo debe asegurar que estos mensajes sean
transmitidos exclusivamente sobre un enlace de señalización en particular.
2) Mensajes que no deben ser transmitidos sobre un enlace de señalización en
particular, para los cuales el enlace de señalización definido por el SLC debe
ser evitado.
Manejo de mensajes sobre enlaces de señalización en congestión
En redes de señalización internacionales, las prioridades de congestión de los

mensajes son solo asignadas y la decisión de descartar bajo congestión es solo
realizada por cada usuario. Para el MTP no hay prioridad de congestión.
137
En redes de señalización nacionales, el usuario que genera el mensaje le asigna una
prioridad de congestión. Esto es usado por el MTP para determinar si un mensaje
debe o no ser descartado cuando el enlace está en congestión. Se asignan N+1
niveles de prioridad de congestión ( 0  N  3 ), donde 0 es la menor prioridad y N la
más alta prioridad.
En redes nacionales con más de una prioridad de congestión, la prioridad más alta
es asignada a los mensajes de gestión de red.
Cualquiera de los dos métodos de control de congestión son aceptables para la

interfaz. El método más apropiado depende de las implementaciones nacionales ITU-
T Nº 7.
En redes nacionales usando prioridades de congestión múltiples:

Cuando un enlace de señalización ha sido seleccionado para transmitir un mensaje,
se realizan comparaciones de la prioridad del mensaje con el estado de congestión
del enlace de señalización seleccionado. Si la prioridad de congestión no es menor
que el estado de congestión del enlace de señalización, el mensaje es transmitido
usando el enlace de señalización seleccionado.
De lo contrario se envía un mensaje en respuesta. En este caso, la disposición del
mensaje es determinado de acuerdo al siguiente criterio:
1) Si la prioridad de congestión del mensaje es mayor o igual que el estado de
descarte del enlace de señalización, el mensaje es transmitido.
2) Si la prioridad de congestión del mensaje es menor que el estado de descarte
del enlace, el mensaje es descartado.
C.3.2.3- Funciones de discriminación y distribución de mensaje
Los criterios de ruteo y el método para compartir carga descritos, implican que un
punto de señalización enviando mensajes pertenecientes a una determinada
transacción en un determinado enlace, debe ser capaz de recibir y procesar
mensajes pertenecientes a esa transacción.
El campo de código de punto de destino (DPC) del mensaje recibido es examinado

por la función de discriminación de mensaje con el fin de determinar si es o no
destinado para el punto de señalización receptor. Cuando el punto de señalización
receptor tiene la capacidad de transferencia y el mensaje no está destinado para él,
el mensaje tiene que ser enviado directamente a la función de ruteo como se
138
describió anteriormente, con el fin de ser enviado por el enlace de salida apropiado
hacia al punto de destino.
En el BSS sólo los mensajes con un correcto DPC chequeado serán aceptados.
Otros serán descartados. Se recomienda que si se descarta un mensaje debido a un
incorrecto DPC sea generado un reporte.
En un MSC (que tiene la capacidad de actuar como un STP) una gestión debe
decidir que cada mensaje recibido desde un enlace de señalización BSS sea pasado
por una función de pantalla que chequea que el DPC del mensaje sea igual que el
código del punto de señalización del intercambio. Si es el caso, el mensaje es
enviado a la función MTP de manejo de mensaje. De lo contrario, el mensaje es
descartado y se envía un reporte.
Cuando un punto de transferencia detecta que un mensaje recibido no puede ser

entregado hacia su punto de destino, envía como respuesta un mensaje de
transferencia prohibida. Si el código de punto de destino del mensaje identifica al
punto de señalización receptor, el identificador de servicio es examinado por la
función de distribución de mensaje y el mensaje es entregada al usuario
correspondiente.
Cuando la función de distribución detecta que un mensaje recibido no puede ser

entregado el usuario requerido se debe devolver un mensaje de usuario inhabilitado
al punto final de origen. En el punto de señalización de origen el usuario debe ser
informado a través de una primitiva de MTP-STATUS. Un parámetro de causa es
incluido en la indicación de MTP-STATUS con cuatro valores posibles:
- Congestión de enlace de señalización:
- Usuario inhabilitado: usuario remoto no equipado;
- Usuario inhabilitado: usuario remoto no accesible;
- Usuario inhabilitado: desconocido.
El Usuario debe reducir su tráfico en una manera apropiada y toma acciones
específicas.
El código de punto de señalización para un BSS debe ser incluido en el esquema de

código de punto de señalización nacional en una red de señalización separada. En el
caso de que el código de punto de señalización esté en la red nacional, el MSC
necesita tener solo un código de punto, en el caso en que el código de punto de
señalización se encuentre en una red de señalización “PLMN”, el MSC requerirá
tener dos códigos de punto de señalización, uno para cada red.
139
C.3.3- Gestión de la red de señalización
El propósito de las funciones de gestión de la red de señalización es proveer re

configuración de la red en caso de fallas y controlar el tráfico en caso de congestión.
Esta re configuración es efectiva, por el uso de procedimientos apropiados para
cambiar el ruteo del tráfico de señalización, con el fin de evitar los enlaces o puntos
de señalización fallados; esto requiere comunicación entre puntos de señalización,
informando la ocurrencia de las fallas. En algunas circunstancias es necesario activar
y alinear nuevos enlaces de señalización para restaurar la capacidad de tráfico de
señalización requerida entre dos puntos. Cuando el enlace o punto de señalización
fallado es restaurado, se realizan las acciones y procedimientos opuestos, con el fin
de reestablecer la configuración normal de la red de señalización.
Las funciones de gestión de la red de señalización se dividen en:
 gestión de tráfico de señalización

 gestión de enlace de señalización
 gestión de ruta de señalización (no es un requerimiento para la interfaz).
Las funciones de gestión tienen la capacidad de proveer de las acciones necesarias

y procedimientos requeridos para mantener el servicio de señalización, y para
reestablecer las condiciones normales de señalización cuando ocurre una
interrupción en la red de señalización, así sea en el enlace o en el punto de
señalización. La interrupción en la red de señalización puede ser en forma de pérdida
completa del enlace o punto de señalización, o en reducción de accesibilidad debido
a congestión. Por ejemplo, en el caso de falla del enlace, el tráfico enviado por el
enlace fallado debe ser entregado a uno o más enlaces alternativos. La falla del
enlace también puede resultar en rutas de señalización inhabilitadas y esto puede
causar desviación de tráfico a otros puntos de señalización en la red.
La ocurrencia, o recuperación de fallas o congestión, generalmente resulta en un

cambio en el estado del(los) enlace(s) y ruta(s) afectados. Un enlace de señalización
puede ser considerado por el nivel 3, como habilitado o inhabilitado para cargar
tráfico de señalización; en particular, un enlace de señalización habilitado se
convierte en inhabilitado si es reconocido como “fallado”, “desactivado”, “bloqueado”
o “inhibido”, y vuelve a estar habilitado si es reconocido como “reestablecido”,
“activado”, “no bloqueado” o “no inhibido” respectivamente. Una ruta de señalización
puede ser considerada por el nivel 3 como “habilitada”, “restringida” (opción nacional)
o “inhabilitada”. Un punto de señalización puede estar “habilitado” o “deshabilitado”.
Un grupo de rutas de señalización puede estar “congestionada” o “no
congestionada”.
140
Cuando ocurre un cambio en el estado del enlace, ruta o punto de señalización, las
tres funciones distintas de gestión de la red son activadas de la siguiente manera:
a) La función de gestión de tráfico es usada para desviar el tráfico de
señalización de un enlace o ruta a uno o más enlaces o rutas, para reiniciar un
MTP de un punto de señalización o para temporalmente disminuir el tráfico de
señalización en caso de congestión en un punto de señalización; comprende
los siguientes procedimientos:
- changeover;
- changeback;
- ruteo forzado;
- ruteo controlado;
- reinicio de MTP;
- inhibición de gestión;
- control de flujo de tráfico de señalización.
b) La función de gestión del enlace de señalización es usada para reiniciar el
enlace de señalización fallado; comprende los siguientes procedimientos:
- activación del enlace de señalización, restauración y desactivación;
- activación del grupo de enlaces;
- asignación automática de las terminales de señalización y enlaces de
datos de señalización.
c) La función de gestión de la ruta de señalización (en caso de estar presente)
es usada para distribuir información sobre el estado de la red de señalización,
con el fin de bloquear o desbloquear las rutas de señalización; comprende los
siguientes procedimientos:
- procedimiento de transferencia controlada;
- procedimiento de transferencia prohibida;
- procedimiento de transferencia restringida;
- procedimiento de testeo de ruta de señalización;
- procedimiento de congestión de ruta de señalización.
C.3.3.1- Estado del enlace de señalización
Un enlace de señalización siempre es considerado por el nivel 3 en uno de los dos

mayores estados principales posibles: habilitado e inhabilitado. Dependiendo de la
causa de la inhabilidad, el estado de inhabilitado se puede subdividir en 7 casos
diferentes:
- inhabilitado, fallado o inactivo;
- inhabilitado, bloqueado;
- inhabilitado (fallado o inactivo) y bloqueado;
- inhabilitado, inhibido y (fallado o inactivo);
- inhabilitado, inhibido y bloqueado;
- inhabilitado, (fallado o inactivo), bloqueado e inhibido.
141
El enlace concernido puede ser usado para llevar tráfico de señalización solo si está
habilitado excepto por ciertos casos de test y mensajes gestión. Ocho eventos
posibles pueden cambiar el estado de un enlace: falla del enlace de señalización,
restauración, desactivación, activación, bloqueo, desbloqueo, inhibición y
desinhibición.
C.3.3.2- Estado de las rutas de señalización
Una ruta de señalización puede encontrarse en tres estados para tráfico de

señalización con un determinado destino; estos estados son:
 disponible,
 restringido (no se aplica en la interfaz) y
 no disponible.
C.3.3.3- Estado de los puntos de señalización
Un punto de señalización puede estar en uno de dos estados:

 disponible,
 no disponible.
C.3.3.4- Congestión de una red de señalización
Se especificarán los criterios para determinar el estado de congestión del enlace de

señalización y el estado de congestión del grupo de rutas; y se listarán los
procedimientos relacionados con cada función de gestión de la red, que se aplican
en conexión con los cambios de estado de congestión.
Estado de congestión del enlace de señalización
Cuando niveles predeterminados de MSU que se encuentran en el buffer del

transmisor o retransmisor son excedidos, se da una indicación al nivel 3 advirtiendo
que se ha entrado o salido de un estado de congestión. La localización y
establecimiento de los umbrales de congestión dependen de la implementación.
142
Los criterios para establecer los umbrales de congestión se basan en:
1) la proporción de la capacidad total del buffer que se encuentra ocupada; y/o
2) el número total de mensajes en los buffer de transmisión y retransmisión.
La capacidad del buffer por debajo del umbral debe ser suficiente para admitir picos
de carga debidos a funciones de gestión de la red y el resto de la capacidad del
buffer debe permitir tiempo a los usuarios para reaccionar ante indicaciones de
congestión antes de que ocurran descartes de mensajes.
Existen dos métodos de control de congestión aceptables para la interfaz:

a) Se provee de un umbral de comienzo de congestión y un umbral de salida de
congestión.
b) Se definen múltiples umbrales de congestión, se proveen N(1 < N < 3)
umbrales separados para detectar el comienzo de congestión.
C.3.4 Características generales de los formatos de la unidad de

señal del mensaje
El formato básico de unidad de señal que es común a todas las unidades de señal
fue descrito anteriormente. Desde el punto de vista de las funciones de MTP de nivel
3, las características generales de las unidades de señal son:
- el octeto de información de servicio;
- la etiqueta, contenida en el campo de información de señalización, y en
particular, la etiqueta de ruteo.
C.3.4.1- Octeto de información de servicio
El octeto de información de servicio de las unidades de señal de mensaje contienen

el indicador de servicio y el campo de sub-servicio. La estructura del campo de
información de servicio se ve en la Figura C.3.10.
DCBA DCBA
Sub-service Service
field indicator
First bit
4 4 transmitted
T1158970-94/d022
Figura C.3.10 - Octeto de información de servicio
143
Indicador de servicio
El indicador de servicio es usado por la función de manejo de mensajes para realizar

la distribución de mensajes.
En la interfaz A el indicador de servicio puede tomar uno de estro tres valores:
Bits D C B A
0 0 0 0 Mensajes de gestión de red
0 0 0 1 Mensajes de testeo y mantenimiento de red
0 0 1 1 SCCP
El campo de sub-servicio
El campo de sub-servicio contiene el indicador de red (bits C y D) y dos bits

separados (bits A y B).
Siempre tendrá uno de los siguientes valores:
Bits DC
0 0 red internacional
1 0 red nacional
Los dos bits A y B son para uso nacional, pueden ser usados por ejemplo para
indicar prioridad de mensaje, que es usado en el procedimiento de control de flujo
opcional.
C.3.4.2- Etiqueta
La estructura y contenido de la etiqueta es definida para el SCCP y se especificará

más adelante.
144
C.3.5- Formatos y códigos de mensajes de gestión de red
Los mensajes de gestión de red son llevados por el canal de señalización en

unidades de señal de mensaje, con el formato que se describió previamente.
El campo de información de señalización consiste de un número integral de octetos y
contiene la etiqueta, el código de cabecera y una o más señales e indicaciones.
C.3.5.1- Etiqueta
Para mensajes de gestión de red la etiqueta coincide con la etiqueta de ruteo e indica
el los puntos de señalización de origen y destino del mensaje. La estructura estándar
de la etiqueta, y la definición de los campos que la contienen se especificaron
anteriormente y puedes ser vistos en la Figura C.3.3.
C.3.5.2- Código de cabecera (H0)
El código de cabecera (H0) es el campo de 4 bits que sigue a la etiqueta de ruteo e

identifica el grupo de mensaje.
Los distintos códigos de cabecera son los siguientes:
0000 Libre
0001 Mensajes de changeover y changeback
0010 Mensajes de emergencia de changeover
0011 Mensajes de transferencia controlada y congestión de grupo de rutas
0100 Mensajes de transferencia prohibida, permitida, restringida
0101 Mensajes de testeo de grupo de rutas
0110 Mensajes de inhibición de gestión
0111 Mensajes de permiso de reinicio de tráfico
1000 Mensajes de conexión de enlace de datos
1001 Libre
1010 Mensajes de control de flujo de usuario
Mensaje de changeover
El formato del mensaje de changeover se muestra en la Figura C.3.11.
145
0 DCBA 0001
FSN of last Heading Heading

accepted MSU code H1 code H0 Label
First bit
1 7 4 4 32 transmitted
T1158990-94/d024
Figura C.3.11- Mensaje de changeover
El mensaje de changeover está formado por los siguientes campos:

- Etiqueta.
- Código de cabecera (H0).
- Número de secuencia hacia delante (FSN) de la última unidad de señal de
mensaje aceptada.
- Un bit de relleno de código 0.
El código de cabecera H1 contiene uno de los siguientes códigos:

Bits D C B A
0 0 0 1 Señal de orden de changeover
0 0 1 0 Señal de reconocimiento de changeover
Mensaje de changeback
El formato del mensaje de changeback se puede ver en la Figura C.3.12.
DCBA 0001
Heading Heading
Changeback code Label
code H1 code H0
First bit
8 4 4 32 transmitted
T1159000-94/d025
Figura C.3.12 - Mensaje de changeback
El mensaje de changeback está formado por los siguientes campos:

- Etiqueta.
- Código de changeback
146
Bits D C B A
0 1 0 1 Señal de declaración de changeback
0 1 1 0 Señal de reconocimiento de changeback
El código de changeback es un código de 8 bits asignado por el punto de

señalización que envía el mensaje de acuerdo al criterio descrito anteriormente.
Mensaje de emergencia de changeover
El formato del mensaje de changeback se puede ver en la Figura C.3.13.
DCBA 0010
Heading Heading
code H1 code H0 Label
First bit
4 4 32 transmitted
T1159010-94/d026
Figura C.3.13 - Mensaje de emergencia changeover
El mensaje de emergencia de changeover está formado por los siguientes campos:

- Etiqueta.

Bits D C B A
0 0 0 1 Señal de orden de emergencia de changeover
0 0 1 0 Señal de reconocimiento de emergencia de
changeover
Mensaje de transferencia prohibida
El formato del mensaje de transferencia prohibida se puede ver en la Figura C.3.14.
147
00 DCBA 0100
Heading Heading
Destination code H1 code H0 Label
First bit
T1159020-94/d027
Figura C.3.14 - Mensaje de transferencia prohibida
El mensaje de transferencia prohibida está formado por los siguientes campos:

- Etiqueta.
- Destino.
- (Spare bits) de código 00.
El código de cabecera H1 contiene el siguiente código:

Bits D C B A
0 0 0 1 Señal de orden de transferencia prohibida
El campo de destino contiene la identidad del punto de señalización al cual el

mensaje se refiere.
Mensaje de transferencia permitida
El formato del mensaje de transferencia permitida se puede ver en la Figura C.3.15.
00 DCBA 0100
Destination Heading Heading

First bit
T1159030-94/d028
Figura C.3.15 - Mensaje de transferencia permitida
El mensaje de transferencia permitida está formado por los siguientes campos:

- Etiqueta.
- Destino.
148
- (Spare bits) de código 00.

Bits D C B A
0 1 0 1 Señal de transferencia permitida
Mensaje de inhibición de gestión
El formato del mensaje de inhibición de gestión se puede ver en la Figura C.3.16.
DCBA 0110
Heading Heading
First bit
4 4 32 transmitted
T1159050-94/d030
Figura C.3.16 - Mensaje de inhibición
El mensaje de inhibición de gestión está formado por los siguientes campos:

- Etiqueta.

Bits D C B A
0 0 0 1 Señal de inhibición de enlace
0 0 1 0 Señal de desinhibición de enlace
0 0 1 1 Señal de reconocimiento de enlace inhibido
0 1 0 0 Señal de reconocimiento de enlace desinhibido
0 1 0 1 Señal de inhibición de enlace denegada
0 1 1 0 Señal de enlace desinhibido a la fuerza
0 1 1 1 Señal de testeo de inhibición de enlace local
1 0 0 0 Señal de testeo de inhibición remota de enlace
149
Mensaje de permiso de reinicio de tráfico
El formato del mensaje de permiso de reinicio de tráfico se puede ver en la Figura

C.3.17.
DCBA 0111
Heading Heading
First bit
4 4 32 transmitted
T1159060-94/d031
Figura C.3.17 - Mensaje de permiso de reinicio de tráfico
El mensaje de permiso de reinicio de tráfico está formado por los siguientes campos:
- Etiqueta.

Bits D C B A
0 0 0 1 Señal de reinicio de tráfico
Mensaje de orden de conexión de enlace de datos de señalización
El formato del mensaje de orden de conexión de enlace de datos de señalización se

puede ver en la Figura C.3.18.
DCBA 0111
Heading Heading
First bit
4 4 32 transmitted
T1159060-94/d031
Figura C.3.18 - Mensaje de orden de conexión de enlace de datos
El mensaje de orden de conexión de enlace de datos está formado por los siguientes
campos:
- Etiqueta.
150
- Identidad de enlace de datos de señalización
- (Spare bits) de código 0000

Bits D C B A
0 0 0 1
Señal de orden de conexión de enlace de datos de señalización
El campo de identidad de enlace de datos contiene el Código de Identificación de

Circuito (CIC).
Mensaje de reconocimiento de conexión de enlace de datos
El formato del mensaje de reconocimiento de conexión de enlace de datos de

señalización se puede ver en la Figura C.3.19.
DCBA 1000
Heading Heading
First bit
4 4 32 transmitted
T1159080-94/d033
Figura C.3.19 - Mensaje de reconocimiento de conexión de enlace de datos
El mensaje de reconocimiento de conexión de enlace de datos está formado por los

siguientes campos:
- Etiqueta.

Bits D C B A
0 0 0 1 Señal de conexión exitosa
0 0 1 1 Señal de conexión sin éxito
0 1 0 0 Señal de conexión no posible
151
Mensaje de transferencia controlada
El formato del mensaje de transferencia controlada (TFC) se puede ver en la Figura

C.3.20.
00 DCBA 0011
Heading Heading
Destination Label
code H1 code H0
First bit
T1159090-94/d034
Figura C.3.20 - Mensaje de transferencia controlada
El mensaje de transferencia controlada está formado por los siguientes campos:

- Etiqueta.
- Destino.
- (Spare bits)

Bits D C B A
0 0 1 0 Señal de transferencia controlada
El campo de destino lleva la dirección del destino al que el mensaje se refiere.

En redes usando múltiples estados de congestión, los bits (spare) en el mensaje de
transferencia controlada son usados para llevar el estado de congestión asociado
con el destino.
Mensaje de usuario indisponible
El formato del mensaje de reconocimiento de conexión de enlace de datos de

señalización se puede ver en la Figura C.3.21.
152
DCBA DCBA 00 DCBA 1010
Unavailability User Heading Heading

cause Destination code H1 code H0 Label
part ID
First bit
4 4 2 14 4 4 32 transmitted
T1159110-94/d036
Figura C.3.21 - Mensaje de usuario indisponible
El mensaje de usuario indisponible está formado por los siguientes campos:

- Etiqueta.
- Destino.
- (Spare bits) de código 00
- Identidad de usuario (SCCP)
- Causa de indisponibilidad.
El código de cabecera H1 contiene el código:

Bits D C B A
0 0 0 1 Usuario indisponible
El campo de identidad de usuario contiene el siguiente código:

Bit D C B A
0 0 1 1 SCCP
El campo de causa de indisponibilidad está codificado de la siguiente manera:

Bit D C B A
0 0 0 0 desconocido
0 0 0 1 usuario remoto no equipado
0 0 1 0 usuario remoto inaccesible
0 0 1 1 )
a ) Spare
1 1 1 1 )
153
ITU-T- Q.704 (1996): "Specifications of Signalling System N.7- Message Transfer

Part".
http://etsi.org
154
C.4 – Testeo y Mantenimiento
El MTP del Sistema de Señalización Nº 7 está diseñado como un sistema de

transporte para mensajes de distintos usuarios. Los requerimientos de los distintos
usuarios deben coincidir para el MTP. Estos requerimientos no son necesariamente
los mismos y pueden diferir en importancia y rigidez. Con el fin de satisfacer los
requerimientos individuales de cada usuario, el MTP está diseñado de forma que los
requerimientos se cumplan con la mayor exactitud.
La performance del sistema de señalización se entiende como la capacidad del MTP

de transmitir mensajes de largo variable para diferentes usuarios de manera
diferente, y se encuentra especificado en la Recomendación Q.706. Con el fin de
lograr una performance de señalización apropiada, se toman en cuenta tres grupos
de parámetros:
- El primer grupo encierra los objetivos derivados de los requerimientos de
los diferentes usuarios, que son retardo del mensaje, protección contra
cualquier tipo de falla y garantía de disponibilidad.
- El segundo grupo cubre las características de tráfico de señalización, como
el potencial de carga y la estructura del tráfico de señalización.
- El tercer grupo cubre las influencias del ambiente, como las características
del medio de transmisión.
Con el fin de lograr los requerimientos de performance descritos en la

Recomendación Q.706, se requieren medios y procedimientos para testeo y
mantenimiento de la red de señalización.
C.4.1- Testeo
C.4.1.1- Testeo de enlace de dato de señalización
Como se define en la Recomendación Q.702, el enlace de dato de señalización es

un trayecto de transmisión bidireccional para señalización. La función de testeo y
mantenimiento puede ser iniciada independientemente en cualquier extremo.
El enlace de dato de señalización y sus partes constitutivas deben ser testeados
antes de ser puestos en servicio para asegurar que se cumplen los requerimientos
especificados en la Recomendación Q.702.
155
Como las interrupciones de un enlace de dato de señalización afecta distintas
transacciones, deben ser tratadas con especial cuidado. Se deben tomar medidas
especiales para prevenir accesos de mantenimiento no autorizado que pueden
resultar en interrupciones al servicio.
C.4.1.2- Testeo de enlace de señalización
Como se define en la Recomendación Q.703, el enlace de señalización comprende

un enlace de dato de señalización y las funciones de enlace de señalización en cada
extremo.
Se especifica un procedimiento de testeo on-line del enlace de señalización que

involucra comunicación entre los dos extremos del enlace de señalización
concerniente. El procedimiento se usa cuando un enlace de señalización se
encuentra activado o reiniciado. El enlace de señalización queda disponible solo si el
testeo es exitoso. Este procedimiento debe ser usado mientras el enlace de
señalización se encuentra en servicio. Adicionalmente, se deben realizar
procedimientos locales de detección de falla en cada extremo.
En caso de que se realice un testeo de enlace de señalización (SLT) mientras el

enlace de señalización está en servicio, el mensaje de testeo del enlace de
señalización es enviado en intervalos de tiempo regulares. El testeo de un enlace de
señalización se realiza independientemente para cada extremo. La capacidad de
enviar un mensajes de reconocimiento de testeo de señalización, debe ser provista
en cada punto de señalización. El punto de señalización que inicia el testeo transmite
un mensaje de testeo de enlace de señalización por el enlace que será testeado.
Este mensaje incluye un patrón de testeo que es elegido por el extremo que inicia el
test. Luego de recibir un mensaje SLT, un punto de señalización debe responder con
un mensaje de reconocimiento de testeo de enlace de señalización (SLTA) en el
enlace de señalización especificado por el SLS contenido en el mensaje SLT. El
patrón de testeo incluido en el mensaje de reconocimiento de testeo es idéntico al
patrón de test recibido.
El testeo de enlace de señalización se considerará exitoso si el mensaje de

reconocimiento de testeo de enlace de señalización recibido cumple lo siguiente:
a) el SLC identifica el enlace de señalización físico por el cual el SLTA fue
recibido,
b) el OPC identifica el punto de señalización del otro lado del enlace;
c) el patrón de testeo es correcto.
156
En caso que el criterio no se cumpla o que no se reciba un mensaje SLTA en el
enlace que está siendo testeado durante un tiempo T1 después de que el mensaje
SLT fue enviado, el testeo se considera fallada y se repite una vez. En caso que el
test vuelva a fallar se toman las siguientes acciones:
- aplicación de SLT en activación/reinicio: el enlace es puesto fuera de
servicio, se intenta reinicio y un sistema de gestión debe ser informado
- aplicación de SLT periódicamente.
C.4.2- Localización de falla
La operación de localización de falla, usando equipamiento particular manual o

automático se dejan a discreción de cada punto de señalización.
C.4.3- Monitoreo de la red de señalización
Con el fin de obtener información del estado de la red de señalización, se debe

proveer monitoreo de la actividad de señalización. Las especificaciones de este
monitoreo están contenidas en las recomendaciones Q.791 y Q.795.
C.4.4- Formatos y códigos de mensajes de testeo y mantenimiento
Los mensajes de testeo y mantenimiento son transportadas en el canal de

señalización en las unidades de señal de mensaje. Esos mensajes son distinguidos
por la configuración 0001 del indicador de servicio (SI).
El Campo de Información de Señalización (SIF) consiste de un número integral de
octetos y contiene la etiqueta, el código de cabecera y una o más señales o
indicaciones.
Código de cabecera H0
Es un campo de 4 bits que le sigue a la etiqueta e identifica el grupo de mensaje. Los

distintos códigos son:
0000 Libre
0001 Mensajes de testeo
157
Mensajes de testeo del enlace
El formato de los mensajes se muestra en la Figura C.4.1.
Figura C.4.1
Los mensajes de testeo del enlace están formados por los siguientes campos:
- Etiqueta: (32 bits),
- Código de cabecera H0: (4 bits)
- Código de cabecera H1: (4 bits)
- Bits libres: (4 bits)
- Indicador de longitud: (4 bits)
- Patrón de testeo: (n  8 bits, 1 ### n ### 15).
En la etiqueta, el código de enlace de señalización identifica el enlace de

señalización por el cual el mensaje de testeo es enviado.
El código de cabecera H1 contiene los siguientes códigos de señal:
Bits D C B A
0 0 0 1 Mensajes de testeo de enlace de señalización
(SLTM)
0 0 1 0 Mensajes de reconocimiento de testeo (SLTA)
El indicador de longitud da el número de octetos que comprende el patrón de testeo.

El patrón de testeo es un número integral de octetos a discreción del punto de origen.
158
ITU-T - Q.707 (1988). "Testing and Maintenance".
159
C.5 – SCCP
La SCCP (Signalling Connection Control Part) provee funciones adicionales al MTP,

para soportar servicio a redes orientado a conexión y no orientado a conexión y
Traducción de Título Global (GTT). La SCCP provee números de subsistema para
permitir que los mensajes sean direccionados hacia aplicaciones específicas o
subsistemas en puntos de señalización específicos.
La SCCP provee los medios para:

- Controlar conexiones lógicas de señalización en la red
- Transferir Unidades de Dato de Señalización en la red de señalización con o
sin el uso de conexiones lógicas.
La SCCP también provee una función de gestión, que controla la disponibilidad del
“subsistema”, y envía esta información a otros nodos de la red que tienen una
necesidad de conocer el estado del “subsistema”.
C.5.1- Servicios provistos por la SCCP
Los servicios provistos por la SCCP entran en uno de los siguientes grupos:
- Servicios orientados a conexión

- Servicios sin conexión
El protocolo de SCCP provee cuatro clases de servicios que entran en uno de los
dos grupos:
- Clase 0: clase sin conexión básica

- Clase 1: clase sin conexión con entrega en secuencia (no se utiliza en
la interfaz)
- Clase 2: clase orientada a conexión básica
- Clase 3: clase orientada a conexión con control de flujo (no se utiliza en
la interfaz)
160
C.5.1.1- Servicios con conexión
Debe distinguirse entre:

– conexiones de señalización temporales; y
– conexiones de señalización permanentes.
Las conexiones de señalización temporales (establecimiento, transferencia de datos

incluidas la reinicialización y la liberación) están bajo el control del usuario SCCP.
Las conexiones de señalización permanentes son establecidas y liberadas por la

gestión (función O&M o función de gestión) y se proporcionan al usuario SCCP con
carácter semipermanente, mientras que la transferencia de datos, comprendida la
reinicialización, está bajo el control del usuario SCCP.
Conexiones de señalización temporales
El control de una conexión de señalización se divide en las fases siguientes:

– establecimiento de la conexión;
– transferencia de datos;
– liberación de la conexión.
Fase de establecimiento de la conexión

Los procedimientos de establecimiento de la conexión proporcionan el mecanismo
para establecer conexiones de señalización temporales entre usuarios SCCP.
Una conexión de señalización entre dos usuarios SCCP puede constar de una o más
secciones de conexión.
En el protocolo MSC/BSS no hay definidos nodos intermedios por lo que una
conexión de señalización consiste de una sola sección de señalización. El uso de
múltiples secciones de conexión es una opción nacional.
Durante el establecimiento de la conexión, el SCCP proporciona funciones de
encaminamiento, además de las proporcionadas por el MTP.
Se invoca el procedimiento de rechazo de conexión si el SCCP o el usuario SCCP no
están en condiciones de establecer una conexión de señalización.
Fase de transferencia de datos

El servicio de transferencia de datos proporciona un intercambio de datos de usuario
denominados unidades de datos de servicio de red (NSDU, network service data
161
units), en uno de los dos sentidos de transmisión o simultáneamente en ambos
sentidos, por una conexión de señalización.
Un mensaje SCCP entre dos entidades pares consta de:
– información de control de protocolo de red (NPCI, network protocol control
information);
– unidad de datos de servicio de red (NSDU).
La información de control de protocolo de red soporta el funcionamiento combinado

de las entidades SCCP pares en los dos nodos que se comunican entre sí. Contiene
un parámetro de referencia de conexión que atribuye el mensaje a una determinada
conexión de señalización.
La unidad de datos de servicio de red contiene cierta cantidad de información

procedente del usuario SCCP, que se transferirá entre dos nodos mediante el
servicio de la SCCP.
La NPCI y la NSDU se reúnen y transmiten un mensaje. Si la longitud de los datos de

usuario es demasiado grande para transferirlos en un solo mensaje, esos datos se
segmentan en un número de porciones. Cada porción se hace corresponder con un
mensaje distinto, constituido por la NPCI y una NSDU.
El servicio de transferencia de datos asegura el control de la secuencia y del flujo

según la calidad de servicio requerida por el usuario SCCP.
Fase de liberación de la conexión

Los procedimientos de liberación de la conexión proporcionan los mecanismos para
desconectar conexiones de señalización temporales entre usuarios SCCP.
Conexiones de señalización permanentes
El servicio de establecimiento/liberación está controlado por la administración [por

ejemplo, una aplicación de explotación y mantenimiento, (OMAP)]. Las funciones
para el establecimiento y la liberación pueden ser similares a las proporcionadas
para conexiones de señalización temporales. Las clases de servicio son las mismas.
162
Las conexiones de señalización permanentes pueden requerir mecanismos
adicionales de salvaguardia dentro de los puntos extremos (puntos de relevo) de la
conexión, a fin de garantizar su restablecimiento en caso de interrupción del
procesador seguida de una recuperación.
C.5.1.2- Servicios no orientados a conexión
La SCCP proporciona al usuario del servicio la posibilidad de transferir mensajes de

señalización por la red de señalización sin el establecimiento de una conexión de
señalización. Además de la capacidad MTP, hay que proporcionar la función
"encaminamiento" dentro de la SCCP que establezca la relación de correspondencia
de la dirección llamada con los códigos de punto de señalización del servicio MTP.
Esta función de correspondencia se proporciona dentro de cada nodo, se distribuye
por la red o se proporciona en algunos centros de traducción especiales.
La SCCP también incluye la posibilidad de segmentar/recombinar datos de usuario

que no se pueden cursar en un mensaje MTP. Para más detalles véase 4.1.1/Q.714.
En ciertas condiciones de congestión e indisponibilidad de los subsistemas y/o
puntos de señalización, los mensajes en modo sin conexión en soporte de SDU de
SCCP quizá sean descartados en vez de cursados. Si el usuario SCCP desea que se
le informe de la no entrega de SDU de SCCP ocasionada por un mensaje
descartado, el parámetro opción de devolución se fijará a "devolver SDU de SCCP
en caso de error" en la primitiva transmitida a la SCCP.
La SCCP sin conexión ofrece dos servicios:

Clase 0: Clase sin conexión básica sin entrega en secuencia garantizada de las
SCCP-SDU.
Clase 1: Clase sin conexión de entrega en secuencia con entrega en secuencia
garantizada de SCCP-SDU.
La SCCP proporciona estos dos servicios mediante mecanismos de control de

secuencia suministrados especialmente por la MTP:
a) El servicio de clase 0 permite a la SCCP insertar valores SLS de forma
aleatoria o con el fin de conseguir una compartición de carga adecuada en la
red MTP subyacente.
b) El servicio de clase 1 obliga a la SCCP a insertar el mismo código de
selección de enlace de señalización (SLS, signalling link selection) en todas
163
las SCCP-SDU asociadas con los parámetros "control de secuencia" y
"dirección llamada" dados.
Las reglas para obtener la compartición de la carga en la red MTP no están definidas
en las Recomendaciones sobre la SCCP.
C.5.2- Funciones proporcionadas por la SCCP
C.5.2.1- Funciones del servicio con conexión
Funciones para las conexiones de señalización temporales
Funciones de establecimiento de la conexión:

Las funciones principales de la fase de establecimiento de la conexión son:
– establecimiento de una conexión de señalización;
– establecimiento del tamaño óptimo de las unidades de datos de protocolo de
red (NPDU, network protocol data unit);
– correspondencia de las direcciones de red con las relaciones de señalización;
– selección de funciones que operarán durante la fase de transferencia de
datos (por ejemplo, selección de servicio de capa);
– provisión de medios para distinguir las conexiones de red;
– datos de usuario de transporte (dentro de la petición).
Funciones de la fase de transferencia de datos

Las funciones de la fase de transferencia de datos proporcionan medios para el
transporte bidireccional simultáneo de mensajes entre los dos puntos extremos de la
conexión de señalización.
Las funciones principales de la fase de transferencia de datos enumeradas a
continuación se utilizan, o no se utilizan, de acuerdo con el resultado de la selección
efectuada en la fase de conexión.
– segmentación/reensamblado;
– control de flujo;
– identificación de la conexión;
– delimitación de NSDU (Mbit);
– datos acelerados;
– detección de secuencia errónea;
– reinicialización;
– otras.
164
Funciones de la fase de liberación
Estas funciones proporcionan la desconexión de la conexión de señalización,
cualquiera que sea la fase en que ésta se encuentre. La liberación puede ser
realizada por un estímulo de una capa superior o por una acción de mantenimiento
de la propia SCCP. La liberación puede comenzar en cualquier extremo de la
conexión (procedimiento simétrico).
La función principal de la fase de liberación es la desconexión.
Funciones de las conexiones de señalización permanentes
Funciones de las fases de establecimiento y liberación de la conexión

Los estímulos para el establecimiento y la liberación de las conexiones permanentes
se originan en la función administración.
Funciones de la fase de transferencia de datos

Las funciones de la fase de transferencia de datos en conexiones de señalización
permanentes se corresponden con las funciones para las conexiones temporales.
Pueden existir diferencias con respecto a la calidad de servicio.
C.5.2.2- Funciones del servicio sin conexión
Las funciones del servicio sin conexión son:

– correspondencia de las direcciones de red con las relaciones de señalización;
– servicio de secuenciación;
– segmentación.
C.5.2.3- Funciones de gestión
La SCCP tiene funciones que gestionan el estado de los subsistemas SCCP. Estas
funciones permiten que otros nodos de la red estén informados del cambio de estado
de los subsistemas SCCP en un nodo, y modificar, si procede, los datos de
165
traducción SCCP. La gestión SCCP también vigila los estados de congestión de los
destinos MTP y las SCCP distantes.
En el caso de subsistemas que trabajan en modo dominante o de compartición de

carga, se prevé la posibilidad de negociación al poner un subsistema fuera de
servicio y dejar al otro en servicio. Esto facilita la comprobación de si el otro lado es
capaz (porque tiene recursos suficientes, tiempo real) de recibir la carga de tráfico
adicional. El subsistema replicado que inicia el procedimiento se pone fuera de
servicio después de que el otro subsistema envía una respuesta afirmativa a la
petición.
Cuando un subsistema está fuera de servicio, se activan las funciones de prueba de

la SCCP en los nodos en que se recibe información sobre indisponibilidad. A
intervalos regulares, un procedimiento de gestión SCCP comprueba el estado del
sistema no disponible.
Las funciones de difusión de la gestión SCCP informan de los cambios en el estado

del subsistema a los nodos de la red que tienen una necesidad inmediata de ser
informados de cualquier cambio particular del estado de punto de
señalización/subsistema. También se suministran funciones de notificación a
subsistemas locales del nodo (difusión local).
La capacidad de un nodo SCCP distante para probar la disponibilidad de un

subsistema en un nodo SCCP que rearranca, antes de reanudar el tráfico a ese nodo
o subsistema, queda en estudio. La capacidad de un nodo SCCP distante para
probar la disponibilidad de la SCCP cuando se hace accesible el punto de
señalización, antes de reanudar el tráfico hacia/vía ese nodo, queda en estudio.
Además, la aplicación de estas pruebas y la especificación del protocolo quedan en
estudio.
C.5.2.4- Funciones de encaminamiento y traducción
El encaminamiento SCCP ofrece una potente función de traducción de dirección, que

se utiliza para servicios con y sin conexión. El encaminamiento SCCP proporciona a
sus usuarios una potente función de traducción sobre información de
direccionamiento, gracias a la cual los usuarios SCCP no necesitan almacenar la
información de señalización de encaminamiento SCCP. La función de
encaminamiento también responde a los informes sobre congestión de la MTP y la
SCCP.
166
C.5.3- Definición y funciones de los mensajes de la SCCP
Los mensajes de la parte control de la conexión de señalización (SCCP, signalling

connection control part) se utilizan en el protocolo entre entidades pares. Todos los
mensajes están identificados unívocamente por medio de un código de tipo de
mensaje, que se encuentra en todos los mensajes. La inclusión efectiva de estos
elementos de información en un determinado mensaje depende de la clase de
protocolo.
C.5.3.1- Confirmación de conexión (CC):
La parte control de la conexión de señalización (SCCP) llamada inicia un mensaje de

confirmación de conexión para indicar a la SCCP llamante que se ha realizado el
establecimiento de la conexión de señalización. Al recibir un mensaje de
confirmación de conexión, la SCCP completa el establecimiento de la conexión de
señalización, si es posible. Se utiliza durante la fase de establecimiento de la
conexión por protocolos con conexión de las clases 2 ó 3.
C.5.3.2- Petición de conexión (CR, connection request):
Una parte control de la conexión de señalización (SCCP) inicia un mensaje de

petición de conexión a la SCCP llamada para solicitar el establecimiento de una
conexión de señalización entre las dos entidades. Las características exigidas a la
conexión de señalización se incluyen en varios campos de parámetros. Al recibir un
mensaje de petición de conexión, la SCCP llamada inicia, si es posible, el
establecimiento de la conexión de señalización. Se utiliza durante la fase de
establecimiento de la conexión por protocolos con conexión de las clases 2 ó 3.
C.5.3.3- Conexión rechazada (CREF, connection refused):
La parte control de la conexión de señalización (SCCP) llamada o nodo intermedio

inician un mensaje conexión rechazada para indicar a la SCCP llamante que se ha
rechazado el establecimiento de la conexión de señalización. Se utiliza durante la
fase de establecimiento de la conexión por protocolos con conexión de las
clases 2 ó 3.
167
C.5.3.4- Forma de datos 1 (DT1, data form 1):
Un mensaje de forma de datos 1 es enviado por cualquier extremo de una conexión

de señalización para pasar transparentemente datos de usuario de la parte control de
la conexión de señalización (SCCP) entre dos nodos de la SCCP. Se utiliza durante
la fase de transferencia de datos sólo en protocolos de clase 2.
C.5.3.5- Prueba de inactividad (IT, inactivity test):
Cualquier extremo de una sección de conexión de señalización podrá enviar

periódicamente un mensaje de prueba de inactividad para comprobar si esta
conexión de señalización se encuentra activa en ambos extremos, y para comprobar
la coherencia de los datos de conexión en ambos extremos. Se utiliza en protocolos
de las clases 2 y 3.
C.5.3.6- Liberado (RLSD, released):
Una parte control de la conexión de señalización (SCCP) envía, hacia adelante o

hacia atrás, el mensaje liberado para indicar que desea liberar una conexión de
señalización y que los recursos asociados en dicha SCCP están en la condición de
espera de desconexión. También indica que el nodo receptor debe liberar la
conexión y todos los recursos asociados a la misma.
Se utiliza durante la fase de liberación de conexión en protocolos de las clases 2 y 3.
C.5.3.7- Liberación completa (RLC, release complete):
Un mensaje liberación completa se envía en respuesta a un mensaje de liberación,

indicando que éste se ha recibido y que se ha completado el procedimiento
correspondiente. Se utiliza durante la fase de liberación de conexión en protocolos de
las clases 2 y 3.
168
C.5.3.8- Subsistema autorizado (SSA, subsystem-allowed):
Un mensaje de subsistema autorizado se envía a los destinos pertinentes para

informar a éstos de que un subsistema anteriormente prohibido está ahora
autorizado o que una parte control de la conexión de señalización (SCCP)
anteriormente indisponible está ahora disponible. Se utiliza en la gestión de la SCCP.
C.5.3.9- Subsistema prohibido (SSP, subsystem-prohibited):
Un mensaje de subsistema prohibido se envía a los destinos pertinentes para

informar a la gestión de la parte control de la conexión de señalización (SCMG) en
dichos destinos sobre el fallo de un subsistema. Se utiliza en la gestión del
subsistema de la SCCP.
C.5.3.10- Prueba de estado de subsistema (SST, subsystem-status-test):
El mensaje de prueba de estado de subsistema se envía para verificar el estado de

un subsistema marcado como prohibido o el estado de una parte control de la
conexión de señalización (SCCP) marcada como no disponible. Se utiliza en la
gestión de la SCCP.
C.5.3.11- Dato unidad (UDT, unitdata):
Una parte control de la conexión de señalización (SCCP) que desee enviar datos sin
conexión puede utilizar el mensaje de dato unidad. Se utiliza en protocolos sin
conexión de las clases 0 y 1.
C.5.3.12- Dato unidad ampliado (XUDT, extended unitdata):
La parte control de la conexión de señalización (SCCP) que desee enviar datos junto
con parámetros facultativos en un modo sin conexión, utiliza el mensaje de dato
unidad ampliado. Se utiliza en protocolos sin conexión de las clases 0 y 1.
169
C.5.3.13- Servicio de dato unidad ampliado (XUDTS, extended unitdata
service):
El mensaje de servicio de dato unidad ampliado se utiliza para indicar a la parte

control de la conexión de señalización (SCCP) de origen que un dato unidad
ampliado (XUDT) no puede entregarse en su destino. Excepcionalmente, y sujeto a
consideraciones de interfuncionamiento de protocolos, podría igualmente utilizarse
en respuesta un mensaje de servicio de dato unidad ampliado (XUDTS) como
mensaje dato unidad o dato unidad largo (LUDT). Un mensaje XUDTS sólo se envía
cuando se pone la opción de retorno en el XUDT (o posiblemente el LUDT). Se utiliza
en protocolos sin conexión de las clases 0 y 1.
C.5.3.14- Subsistema congestionado (SSC, subsystem congested):
El mensaje subsistema congestionado es enviado por un nodo de la parte control de

la conexión de señalización (SCCP) cuando experimenta congestión.
C.5.3.15- Dato unidad largo (LUDT, long unitdata):
La parte control de la conexión de señalización (SCCP) utiliza un mensaje de dato

unidad largo para enviar datos (junto con parámetros opcionales) en un modo sin
conexión. Cuando estén presentes las capacidades de la parte transferencia de
mensajes de acuerdo con la Recomendación Q.2210, permite el envío de unidades
de datos de servicio de red con un tamaño de hasta 3952 octetos sin segmentación.
Se utiliza en protocolos sin conexión de las clases 0 y 1.
C.5.3.16- Servicio de dato unidad largo (LUDTS, long unitdata service):
El mensaje de servicio de dato unidad largo se utiliza para indicar a la parte control
de la conexión de señalización (SCCP) de origen que un dato unidad largo (LUDT)
no puede entregarse en su destino. Un mensaje servicio dato unidad largo sólo se
envía cuando se pone la opción de retorno mensaje con error en el LUDT. Se utiliza
en protocolos sin conexión de las clases 0 y 1.
170
C.5.4- Parámetros de mensajes del SCCP
Los parámetros que pueden aparecer en los mensajes de la SCCP son:
 Código de punto afectado

 Número de subsistema afectado
 Dirección de parte llamada/llamante
 Crédito
 Dato
 Causa de error
 Fin de parámetros opcionales
 Número de referencia local (fuente/destino)
 Clase de protocolo
 Causa de rechazo
 Causa de liberación
 Causa de devolución
 Segmentación/reensamblado
 Secuenciamiento/segmentación
 Indicador de multiplicidad de subsistema
 Contador de saltos
 Segmentación
 Importancia
 Nivel de congestión
 Dato largo
C.5.4.1- Parámetros a tener en cuenta
Fin de parámetros opcionales
Consiste en un campo conteniendo todo ceros.
Dirección del la parte llamada
La dirección incluye un PC y/o un GT (Global Title), dependiendo de los lugares

dónde se encuentran las entidades en la transacción:
 En la misma PLMN, es un PC.
171
 En el mismo país pero en distintas PLMNs es un GT, acorde con el plan de
numeración de la red fija en ese país. Formato E. 164.
 En distinto país, es un GT con formato E. 214.
La dirección de la parte llamada es un parámetro de largo variable. Su estructura se

muestra en la Figura C.5.1.
8 7 6 5 4 3 2 1
octeto 1 Indicador de dirección
octeto 2
. Dirección
octeto n
Figura C.5.1 - Dirección de la parte llamada/llamante
Indicador de dirección
El indicador de dirección indica el tipo de información de dirección contenida en el
campo de dirección, como se muestra en la Figura C.5.1. La dirección consiste de
una combinación cualquiera de los siguientes elementos:
- código de punto de señalización;
- título global (por ejemplo, dígitos marcados);
- número de subsistema;
8 7 6 5 4 3 2 1
Reservado Indicador de Indicador de Título Indicador de Indicador de

para uso ruteo Global SSN código de
nacional punto
Figura C.5.1 - Código del Indicador de dirección
Un “1” en el bit 1 indica que la dirección contiene un código de punto de señalización.

Un “1” en el bit 2 indica que la dirección contiene un número de subsistema.
Los bits 3-6 del octeto indicador de dirección contienen el Indicador de Título Global
(GTI), que se codifica como sigue:
Bits 6543
0000 no título global incluido
172
0001 el título global incluye naturaleza del indicador de dirección
únicamente
0010 el título global incluye únicamente tipo de traducción
0011 el título global incluye tipo de traducción, plan de numeración y
esquema de codificación
0100 el título global incluye tipo de traducción, plan de numeración,
esquema de codificación y naturaleza del indicador de dirección
0101
a libres para uso internacional
0111
1000
a libres para uso nacional
1110
1111 reservado para extensión
El bit del octeto indicador de dirección contiene información de ruteo que identifica
que elemento de dirección debe ser usado para el ruteo, y se codifica como sigue:
Bit 7
1 Ruteo en SSN
0 Ruteo en GT.
El bit 8 del octeto indicador de dirección está reservado para uso nacional y siempre
es 0 en una red internacional.
Para estructuras de red punto a punto (por ejemplo conexiones directas entre MSC y
BSS) la dirección de la parte llamada consiste en un único elemento:
- número de subsistema.
No se usa título global. El código de punto de señalización que está codificado en la

etiqueta de ruteo del MTP y el número de subsistema en la dirección de la parte
llamada permiten el ruteo del mensaje.
Se debe elegir la siguiente codificación del indicador de dirección: X100 0010.

Si no se usa una estructura de red punto a punto, entonces el título global es un
requerimiento. Es una opción nacional.
Dirección
Los distintos elementos, cuando están ocurren en el orden: código de punto, número
de subsistema, título global, como se muestra en la Figura C.5.2. Se sugiere que la
173
dirección de la parte llamada tenga un número de subsistema, con el fin de
simplificar la reformación de mensaje luego de la traducción de título global. El
número de subsistema debe ser codificado “0000 0000” cuanto el número de
subsistema es desconocido, por ejemplo antes de la traducción.
8 7 6 5 4 3 2 1
Código de punto de señalización
Número de subsistema
Título global
Figura C.5.2 - Orden de los elementos de dirección
Código de punto de señalización

El código de punto de señalización, cuando está presente, está representado por dos
octetos (como se ve en la Figura C.5.3. Los bits 7 y 8 del segundo octeto se ponen
en 0.
8 7 6 5 4 3 2 1
LSB
0 0 MSB
Figura C.5.3 - Codificación del código de punto de señalización
Número de subsistema
Los números de subsistema (SSN) son usados para identificar aplicaciones en las
entidades de red que usan SCCP. Los valores de SSN usados en la interfaz MSC –
BSS son los especificados en 3GPP 03.03, que se detallan a continuación.
BITS 8 7 6 5 4 3 2 1
00000001 SCMG
11111101 O&M (interfaz A)
11111110 BSSAP (interfaz A)
174
Título global
Como se dijo anteriormente, el Título Global (GT) se encuentra solo en caso en que
la estructura de la red no sea punto a punto.El formato de Título Global es de largo
variable.
Dirección de la parte llamante
La dirección de la parte llamante es un parámetro de largo variable. Su estructura es

la misma que la dirección de la parte llamada.
Por razones de compatibilidad con versiones anteriores, un SCCP debe ser capaz de
recibir y/o transmitir un mensaje (X)UDT en el cual el parámetro de dirección de la
parte llamante solo consiste en un octeto identificador de dirección, donde los bits del
1 a 7 son codificados cero.
Se recomienda que el punto de origen no codifique el octeto indicador de dirección
con los bits del 1 al 7 todos 0.
Clase de protocolo
El campo de parámetro clase de protocolo es un octeto. Existen 4 clases de

protocolo, pero solo la clase 0 y 2 son usadas en la interfaz. El campo está
estructurado de la siguiente manera.
Bits 4321
0000 clase 0
0010 clase 2
Cuando los bits 1-4 están codificados para indicar una clase de protocolo orientado a
conexión (clase 2), los bits 5-8 son libres. Cuando los bits 1-4 están codificados para
indicar una clase de protocolo no orientado a conexión (clase 0), los bits 5-8 son
usados para especificar manejo de mensaje de la siguiente manera:
175
Bits 8765
0000 no hay opciones especiales
0001
a libres
0111
1000 error en retorno de mensaje
1001
a libre
1111
C.5.5- Formato de los mensajes del SCCP
Un mensaje de SCCP está formado por las siguientes partes que se pueden ver en
la Figura C.5.4:
• el código de tipo de mensaje;

• la parte fija obligatoria;
• la parte variable obligatoria;
• la parte opcional, que puede contener campos de largo fijo o variable
Figura C.5.4
C.5.5.1- Principios del formato
Cada mensaje consiste de un número de parámetros, cada parámetro tiene un

nombre que puede ser representado por un octeto, y está presente en parámetros
opcionales. El largo de un parámetro puede ser fijo o variable, y debe ser incluido un
176
indicador de tamaño de un octeto para cada parámetro. El indicador de tamaño del
parámetro de dato largo deben ser dos octetos, con el octeto menos significativo
precediendo la transmisión del octeto más significativo.
Un formato de mensaje SCCP general se muestra en la Figura C.5.5.
Octeto de fin de parámetros opcionales

Después de que todos los parámetros opcionales han sido enviados, un octeto de fin
de parámetros opcionales, conteniendo todo ceros es transmitido. Este octeto es
incluido solo si hay presentes en el mensaje parámetros opcionales. El octeto de fin
de parámetros opcionales no debe ser usado para detectar el fin de mensajes.
Orden de transmisión
Como todos los parámetros consisten en un número integral de octetos, los formatos
están presentes como una pila de octetos. El primer octeto transmitido es el de arriba
de la pila de la figura anterior, y el último es el de debajo de la pila.
Código de bits libres

Los bits libres son codificados como 0 a menos de que sea indicado en los nodos
originadores.
Parámetros y tipos de mensajes nacionales

Si los códigos de tipo de mensajes y parámetros son requeridos para uso nacional,
se sugiere que los códigos sean seleccionados desde el código más alto hacia abajo,
es decir empezando por el código 11111110. El código 11111111 es reservado para
uso futuro.
Parámetros y tipos de mensajes internacionales

Los códigos de tipos de mensajes y parámetros que son requeridos para uso
internacional son seleccionados desde el valor de código más bajo hacia arriba, es
decir empezando en el 00000000.
177
Order of octet
8 7 6 5 4 3 2 1 transmission
Message type code
Mandatory parameter A
Mandatory
fixed part
Mandatory parameter F
Pointer to parameter M
Pointer to parameter P
Pointer to start of optional part
Length indicator of parameter M
Mandatory
Parameter M variable part
Length indicator of parameter P
Parameter P
Parameter name = X
Length indicator of parameter X
Parameter X
Optional part
Parameter name = Z
Length indicator of parameter Z
Parameter Z
End of optional parameters T1178720-96
Figura C.5.5 - Formato general de mensaje SCCP
C.5.5.2- Código de tipo de mensaje
El código de tipo de mensaje consiste en un campo de un octeto y es obligatorio para

todos los mensajes. El código de tipo de mensaje define la función y formato de cada
mensaje SCCP.
C.5.5.3- Parte fija obligatoria
Los parámetros que son obligatorios y de largo fijo para un tipo de mensaje en
particular estarán contenidos en la parte fija obligatoria. La posición, tamaño y orden
del parámetro es únicamente definida por el tipo de mensaje. Los nombres de los
parámetros y el indicador de tamaño no están incluidos en el mensaje.
178
C.5.5.4- Parte variable obligatoria
Los parámetros obligatorios de largo variable están incluidos en la parte variable

obligatoria. El nombre de cada parámetro y el orden en que los punteros son
enviados están implícitos en el tipo de mensaje. Los nombres de los parámetros no
están incluidos en el mensaje. Un puntero es usado para indicar el comienzo de cada
parámetro, por lo tanto los parámetros pueden ser enviados en distinto orden que los
punteros. Cada puntero está codificado como un octeto o dos octetos en el caso de
LUDT y LUDTS. En el caso de puntero de dos octetos. El octeto menos significativo
debe ser transmitido antes que el octeto más significativo. El número de parámetros
y punteros es definido por el tipo de mensaje.
También es incluido un puntero para indicar el comienzo de la parte opcional. Si el

tipo de mensaje indica que no hay permitida parte opcional, entonces el puntero no
estará presente. Si el tipo de mensaje indica que es posible una parte opcional, pero
esta no está incluida en este mensaje en particular, se usará un campo de puntero
conteniendo todos ceros.
Todos los punteros son enviados consecutivamente al comienzo de la parte variable

obligatoria. Cada parámetro contiene el indicador de tamaño del parámetro seguido
por el contenido del parámetro.
C.5.5.5- Parte opcional
La parte opcional consiste en un bloque contiguo de parámetros que pueden o no

ocurrir en cualquier tipo de mensaje particular. Puede empezar después del puntero
o después de la parte variable obligatoria. Pueden ser incluidos tanto parámetros de
largo fijo como parámetros de largo variable. Los parámetros opcionales pueden ser
transmitidos en cualquier orden. Cada parámetro opcional incluirá el nombre del
parámetro (un octeto) y el indicador de tamaño (un octeto) seguido por el contenido
del parámetro.
C.5.7- Mensajes y códigos de Gestión de SCCP (SCMG)
Los mensajes de gestión de SCCP (SCMG) son transferidos usando el servicio sin
conexión del SCCP. Para la transferencia de mensajes SCMG, se utiliza el protocolo
de clase o, sin opciones especiales. Los parámetros de dirección de parte llamada y
llamante deben contener el valor de SSN igual a 1 y tendrán el indicador de ruteo
establecido para “Ruteo en SSN”. Estos mensajes son provistos en el parámetro de
dato.
179
C.5.7.1- Identificador de formato SCMG
El identificador de formato SCMG consiste de un campo de un octeto, que es

obligatorio para todos los mensajes SCMG, y define la función o formato de cada
mensaje SCMG. Estos identificadores se pueden ver en la siguiente tabla:
Mensaje Código 87654321

Subsistema permitido (SSA) 00000001
Subsistema prohibido (SSP) 00000010
Test de estado de subsistema (SST) 00000011
Solicitud de subsistema fuera de servicio (SOR) 00000100
Aceptación de subsistema fuera de servicio (SOG) 00000101
SCCP/subsistema en congestión (SSC) 00000110
C.5.7.2- Parámetros de mensajes SCMG
Los parámetros que aparecen en los mensajes SCMG son obligatorios, de largo fijo,
y son los siguientes:
 SSN afectado
 PC afectado
 Nivel de congestión de SCCP
Los mensajes SSA, SSP, SST, SOR y SOG tienen los siguientes parámetros:
 Identificador de formato SCMG

 SSN afectado
 PC afectado
El menaje SSC tiene los mismos parámetros y el parámetro de nivel de congestión

de SCCP.
180
ITU-T- Q.711 (2001). "Functional Description of the signalling connection control part
".
ITU-T - Q.712 (1996) . "Definition and function of signalling connection control part
messages".
ITU-T - Q.713 (1996). "Specification of Signalling System N. 7-Signalling Connection

Part (SCCP)".
ITU-T - Q.714 (2001) . "Signalling connection control part procedures".
http://etsi.org
181
C.6- Usuarios del SCCP
El mecanismo de transporte de capas, definido para llevar información entre el BSS y

el MSC es el MTP (Message Transfer Part), y el SCCP (Signaling Connection Control
Part) del SS7. El MTP y el SCCP son usados para soportar comunicación entre el
MSC y dos entidades conceptuales en el BSS, estas son:
- la parte aplicación de operación y mantenimiento del BSS (BSSOMAP, BSS

Operation and Maintenance Application Part);
- la parte aplicación del BSS (BSSAP, BSS Application Part).
El BSSAP, está dividido en dos partes de subaplicación, estas partes son:
- La parte aplicación de transferencia directa (DTAP, Direct Transfer Application

Part) es usada para transferir mensajes entre el MSC y el MS; la información
en estos mensajes no es interpretada por el BSS. Las descripciones del
protocolo de intercambio de información entre MS – MSC, están contenidas en
las Especificaciones Técnicas de las series 04 para GSM.
- La parte aplicación de gestión del BSS (BSSMAP, BSS Management
Application Part) soporta otros procedimientos entre el MSC y el BSS
relacionados con el MS (gestión de recursos, control de handover), o con una
celda del BSS, o todo el BSS. El protocolo para el intercambio de información
para la BSSMAP está contenido en la Recomendación GSM 08.08.
Para el soporte del BSSMAP se utilizan tanto procedimientos orientados a conexión

como no orientados a conexión.
Para soporte del DTAP se usan procedimientos orientados a conexión.

Una función de distribución perteneciente al BSSAP, realiza la discriminación para el
dato relacionado a cada subparte.
C.6.1- Establecimiento de conexión
Una nueva conexión de SCCP es establecida cuando información relacionada a la

comunicación entre un MS y la red sobre un recurso de radio dedicado tiene que ser
intercambiada entre el BSS y el MSC, y no existe una conexión involucrada para
dicha estación móvil. Una nueva conexión de SCCP es también establecida cuando
se produce un handover externo entre celdas de un BSS.
182
Se distinguen dos casos de establecimiento de conexión:
1) Siguiendo una Solicitud de Acceso realizada por un MS en el Canal de

Acceso Randómico, luego de que ha sido asignado un recurso de radio y se
ha establecido una conexión en el nivel inferior en el recurso asignado. En
este caso el establecimiento de la conexión es iniciada por el BSS.
2) El MSC decide llevar a cabo un traspaso externo y un nuevo recurso de
radio dedicado ha sido reservado en el nuevo BSS. El establecimiento de la
conexión SCCP es entonces iniciada por la MSC.
3) Siguiendo a la solicitud para una llamada grupal o de difusión que es
recibido en una MSC. Entonces el establecimiento de una conexión SCCP
entre el MSC y el BSS para cada celda en el área de la llamada y MSC y el
BSS para cada BSS en el área de llamada grupal es iniciada por la MSC.
Cabe notar que una conexión SCCP para el originador puede haber sido
establecida ya, via caso 1.
4) Durante llamadas de grupo vocal o difusión si la red decide colocar algunos
participantes en un canal dedicado entonces establecerá una conexión
SCCP para soportar este canal.
BSS MSC
CR {SSN=BSSAP, a1, BSSMAP message}

------------------------------------------->
CC {a1,a2, BSSMAP or DTAP message or no user data}

<------------------------------------------
or
CREF{a2, DTAP message or no user data
<------------------------------------------
a1 = source local reference,

a2 = destination local reference
Figure C.6.1 – Establecimiento de conexiones de SCCP en la primer interfaz

BSS/MSC
183
BSS MSC
CR {SSN=BSSAP, a1, BSSMAP message or no user data}

<-----------------------------------------
CC {a1, a2, BSSMAP message or no user data}

------------------------------------------>
or
CREF{a2, BSSMAP message or no user data}
------------------------------------------>
a1 = source local reference,

a2 = destination local reference
Figure C.6.2 – Establecimiento de conexiones en una nueva interfaz BSS/MSC

(handover)
C.6.2- Liberación de la conexión
Este procedimiento es siempre iniciado del lado del MSC. Una conexión es liberada
cuando el MSC reconoce que una conexión de señalización ya no es requerida. Lo
cual ocurrirá, en casos normales cuando:
- un procedimiento de liberación de BSSAP termina;

- un procedimiento de asignación de recurso de handover falla y la conexión
estaba establecida.
El MSC envía al SCCP mensajes de liberación. Estos mensajes no deben contener

ningún campo de dato de usuario.
C.6.3- Transferencia de datos de DTAP y BSSMAP
Los mensajes de DTAP y BSSMAP entre MSC y BSS están contenidos en el campo
de dato de usuario de las tramas SCCP intercambiadas. Este campo es opcional
para Connection Request, Connection Confirm y Connection Refused para
conexiones originadas por el BSS. El uso de este campo en los distintos casos de
conexión, permiten reducciones in retardos y mejora la eficiencia. El campo de dato
184
de usuario es obligatorio en parámetros de las tramas de Dato (DT); el campo de
dato de usuario siempre contiene un mensaje DTAP o BSSMAP.
C.6.3.1- Función de distribución
La distribución de mensajes entre las funciones BSSMAP y DTAP y la

distribución/multiplexación de mensajes DTAP hacia o desde varios enlaces de radio
entre puntos de acceso son procesados en una capa intermedia de protocolo entre
SCCP y capa las capas de usuario, referida como la distribución subcapa.
El protocolo de esta subcapa simplemente consiste en la gestión de uno o dos
octetos de Unidad de Dato de Distribución (Distribution Data Unit). Cada campo de
datos de usuario SCCP necesariamente contiene tal DDU como un encabezamiento,
seguido por un indicador de longitud y el actual mensaje BSSMAP o DTAP de capa
3.
C.6.3.2- Transferencia de mensajes DTAP
La función de DTAP esta encargada de transferir los mensajes de usuario desde el

MS a la MSC sin ningún análisis del contenido del mensaje. La inteconexión entre el
protocolo del lado de radio y el sistema de señalización Nº 7 del lado de la red esta
basada en el uso individual de conexiones SCCP para cada móvil y en la función de
distribución.
La estructura del campo de datos de usuario se ve en la figura C.6.3.
Figura 3. Estructura del campo de datos de usuario
185
El campo de datos de usuario contiene una unidad de distibución de dato, un
indicador de longitud, y el mensaje de usuario.
Este campo DDU está compuesto por dos parámetros: el parámetro de

Discriminación y el parámetro de Identificación de Conexión de Enlace de Datos
(DLCI).
El parámetro de discriminación, es seteado a un valor “transparente” y es codificado

en un octeto como sigue:
El bit de discriminación D es seteado al valor transparente 1.
El parámetro DLCI es usado para mensajes de la MSC al BSS para indicar el tipo de
conexión de enlace de datos a ser usado sobre la interfaz de radio y en la dirección
BSS al MSC, este parámetro es usado para indicar el tipo de enlace de dato
originador de la conexión sobre la interfaz de radio. El parámetro DLCI es codificado
en un octeto como sigue:
C1 C2 representa la identificación del canal de control.

C2 = 0; C1 = 0 indica que el canal de control no se especificará en adelante.
C2 = 1; C1 = 0 representa el FACCH o el SDCCH.
C2 = 1; C1 = 1 representa el SACCH.
Otros valores son reservados.
S3 S2 S1 representa el valor SAPI usado en el enlace de radio.
Bits 4, 5 y 6 están libres.
El indicador de longitud es codificado en un octeto y es la representación binaria de

un número de octetos del parámetro de mensaje de usuario.
186
C.6.3.3- Transferencia de mensajes BSSMAP
La transferencia de mensajes BSSMAP sobre una conexión SCCP permite a las

funciones BSSMAP en el MSC y en el BSS identificar a cual asociación particular del
MS (asignación, solicitud de traspaso, etc.) aplica el mensaje intercambiado.
La estructura del campo de datos de usuario se ve en la figura C.6.3. Este campo

contiene una DDU, un indicador de la longitud y el mensaje de usuario. La DDU
consiste solo del parametro de Discriminación el cual es seteado a un valor “no
transparente” este parámetro es codificado en un octeto como sigue:
El bit de discriminación D es seteado al valor no transparente 0.
El indicador de longitud es codificado en un octeto, y es la representación binaria de

un número de octetos del subsequente parámetro de mensaje de usuario.
C.6.4- Servicio no orientado a conexión
Algunos procedimientos de BSSMAP usan servicios sin conexión del SCCP.

La estructura del campo de datos de usuario de la unidad de mensaje de dato (UDT)
se ve en la figura C.6.3. Este campo contiene la unidad de distribución de datos, el
indicador de longitud y mensaje.
La unidad de distribución de datos solo consiste del parámetro de discriminación, el

cual es seteado a un valor “No transparente”.
C.6.5- Uso del SCCP para operación y mantenimiento
Los sistemas de Operación y Mantenimiento son extremadamente importantes en las

redes GSM. Cuando un operador extiende su red con el fin de cubrir áreas más
187
grandes, la red puede rápidamente crecer en miles de entidades. Un sistema de
Operación y Mantenimiento reúne la gestión de todas estas entidades en uno o
varios Centros de Operación y Mantenimiento. A través de este sistema, el operador
puede configurar entidades, efectuar mantenimiento de software, agregar abonados
y realizar otras tareas.
Desafortunadamente, las especificaciones GSM no especifican un protocolo

detallado para el propósito de Operación y Mantenimiento. Las series 12 de las
Especificaciones Técnicas GSM dan las líneas generales para desarrollar un
protocolo de Operación y Mantenimiento. También establece algunas funciones que
deben ser implementadas en los equipos GSM.
La mayoría de los fabricantes de equipos de redes GSM usan su propio protocolo

propietario en sus implementaciones de O&M. Por esta razón, los operadores de red
deben elegir todos los equipos del mismo fabricante, o debe existir un OMC para
cada tipo de equipo.
Los mensajes de operación y mantenimiento tienen que ser pasados entre las
funciones de O&M y el BSS. Si las funciones O&M usan la interfaz A para transportar
mensajes al BSS, entonces el SCCP del SS7 debería ser usada.
X25 puede también ser usado para transferir mensajes O&M entre el BSS y el OMC.
C.6.5.1- Servicio sin conexión
El servicio sin conexión del SCCP es soportado en el BSS para propósitos de gestión
y puede ser usado para el transporte de información O&M. El direccionamiento
debería ser decidido por el operador y fabricante.
C.6.5.2- Servicio orientado a conexión
Servicios orientados a conexión son también soportados por el BSS para gestión y
control de llamadas. También pueden ser usados para transportar información de
O&M. Con el fin de iniciar la conexión se requiere en el BSS capacidad de
direccionamiento adicional. Para usar una conexión de señalización entre el BSS y el
OMC a través del MSC se requiere la misma interfaz BSSOMAP-SCCP tanto para el
BSS como para el OMC.
188
C.6.6- El BSSMAP
El BSSMAP soporta todos los procedimientos entre el MSC y el BSS que requieren
interpretación y procesamiento de información relacionada con las llamadas
individuales, y gestión de recursos. Algunos de los procedimientos del BSSMAP
resultan en, o son provocados por mensajes de gestión de recursos de radio (RR).
C.6.6.1- Procedimientos del BSSMAP
A continuación se describirán los procedimientos relacionados con el BSSMAP.

Estos son los siguientes procedimientos principales:
* Asignación
# Bloqueo
# Indicación de recursos
# Reset
* Indicación de requerimiento de Handover
* Asignación de los recursos de Handover
* Ejecución de Handover
# Pregunta de candidato de Handover
* Liberación
# Búsqueda
# Control de flujo
* Adaptación de marca de clase
* Control de modo cifrado
* Invocación de traza
* Mensaje MS inicial
* Indicación de cola
* Control de enlace de datos SAPI no igual a 0
# Circuito de reset
* Control de flujo PDSS1
* Reselección de circuito
* Adquisición de localización
# Transferencia de información sin conexión
* ID Común
El símbolo (#) denota un procedimiento global que concierne a una celda completa o
BSS, o a circuitos terrestres específicos. El símbolo (*) denota un procedimiento
dedicado que concierne a un solo recurso de radio dedicado en la interfaz de radio, o
en el caso de configuración de slots múltiples, todos los recursos localizados en una
estación móvil.
189
Los mensajes usados para soportar procedimientos globales son establecidos
usando los servicios sin conexión del SCCP.
Los mensajes usados para soportar procedimientos dedicados son establecidos

usando los servicios orientados a conexión del SCCP, en la conexión que ha sido
establecida para soportar esa llamada o transacción.
C.6.6.2- Mensajes de BSSMAP
Los mensajes del BSSMAP tienen un campo a continuación del indicador de longitud
que contiene el código de tipo de mensaje. Cada mensaje de BSSMAP tiene
elementos de información relacionados que pueden ser obligatorios u opcionales,
que se transportan a continuación del código de tipo de mensaje en un orden que
varía de acuerdo al mensaje. Los mensajes de BSSMAP definidos en las
Especificaciones Técnicas 08.08 son los siguientes:
190
C.6.7- El DTAP
La parte aplicación de transferencia directa (DTAP) es usada para transferir

mensajes de control de llamadas y gestión de movilidad entre el MSC y el MS. La
información del DTAP en estos mensajes no es interpretada por el BSS. Las
especificaciones 3GPP TS 08.06 contienen más detalles relacionados con el manejo
de mensajes DTAP en el BSS, la multiplexación de estos mensajes en el canal de
señalización relevante de la interfaz de radio, y el uso de servicios de SCCP.
Los mensajes recibidos del MS son identificados como DTAP por el Elemento de
Información de Discriminación del Protocolo como se describe en el 3GPP TS 04.08,
excepto para mensajes Iniciales de Capa 3. La mayoría de los mensajes de la
interfaz de radio son transferidos a través de la interfaz BSS-MSC por el DTAP, con
la excepción de los mensajes pertenecientes al protocolo de gestión de los recursos
de radio (RR, radio resourse).
191
C.6.7.1- Procedimientos del DTAP
Los procedimientos especificados para el DTAP son los siguientes:

a) Procedimientos para gestión de recursos de radio:
- Broadcasting de información del sistema
- Establecimiento de conexión de RR
- Procedimientos en modo dedicado y en modo de transmisión en grupo
- Liberación de conexión de recursos de radio
- Procedimientos específicos de RR para canales de broadcast de voz y
para canales de llamadas de voz grupales
- Procedimientos de aplicación
- Procedimientos de RR en CCCH relacionados con establecimiento de
flujo de bloqueo temporal
- Procedimiento de asignación de enlace descendente de paquete
usando CCCH
- Procedimientos de RR en DCCH relacionados con establecimiento de
flujo de bloqueo temporal
b) Procedimientos para gestión de movilidad
- Procedimientos comunes de gestión de movilidad
- Procedimientos específicos de gestión de movilidad
- Provisión de servicio de subcapa de gestión de conexión
- Procedimientos específicos de gestión de movilidad para GPRS
- Procedimientos comunes de gestión de movilidad para GPRS
c) Procedimientos para conmutación de circuito de control de llamada:
- Establecimiento de llamada de móvil de origen
- Establecimiento de llamada de móvil terminal
- Procedimientos de señalización durante el estado activo
- Liberación de llamada iniciada por la estación móvil
- Liberación de llamada iniciada por la red
- Procedimientos misceláneos
d) Procedimientos elementales para gestión de sesión
- Procedimientos de gestión de sesión GPRS
C.6.7.2- Mensajes de DTAP
Los mensajes del DTAP tienen un campo a continuación del indicador de longitud
que contiene el código de tipo de mensaje. Cada mensaje de DTAP tiene elementos
de información relacionados que pueden ser obligatorios u opcionales. Los mensajes
de BSSMAP definidos en las Especificaciones Técnicas 08.08 son los siguientes:
192
Tipos de mensaje de gestión de Recursos de Radio:
193
Tipos de mensaje de gestión de RR usando el discriminador de protocolo corto
de RR
194
Tipos de mensaje de gestión de movilidad
Tipos de mensaje para control de llamada
195
Tipos de mensaje de gestión de movilidad para GPRS
Tipos de mensaje de gestión de sesión para GPRS
196
3GPP TS 04.07 version 7.3.0(2000) : "Mobile radio interface signalling Layer 3;

General Aspects".
3GPP TS 08.08 V8.9.0 (2001): " Mobile Services Swithing Centre - Base Station
System (MSC - BSS) interface; Layer 3 specification ".
http://etsi.org
197
Apéndice D
198
D.1- Diagrama de clases del domino
199
D.2- Diagrama de clases de la vista de la aplicación
200
D.3- Clases
201
202
203
204
205
206

Analizador de Protocolo de La Interfaz A Del Sistema GSM

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Analizador de Protocolo de La Interfaz A Del Sistema GSM

Diunggah oleh

Hak Cipta:

Format Tersedia

Universidad ORT Uruguay

Patricia Gutiérrez - 111996

Al Ing. Alejandro Paz, por proponer la idea de la utilidad de un analizador de la

A Martín Vázquez, que nos indicó como hacer el Programa de Instalación.

El presente trabajo contiene el planteamiento y la resolución de un analizador de

El trabajo está organizado en 11 capítulos y 5 apéndices. El capítulo 1 define el

El apéndice A describe el sistema GSM, su arquitectura y servicios. El apéndice B

Cuando se crea una tecnología, en este caso de telecomunicaciones (GSM,

La ETSI (European Telecommunication Standard Institute), junto con otras

Un analizador de protocolo es además una herramienta de comprensión y estudio

El proyecto tuvo dos objetivos:

Primer objetivo: Estudiar el sistema de señalización Nº 7 de ITU-T en general, y en

Segundo objetivo: Diseñar un analizador de interfaz A del sistema GSM, basado

Un analizador de protocolo es un dispositivo que recoge información de enlaces

El alcance del proyecto es el desarrollo de un analizador de protocolo para la

El análisis “off-line” típicamente es aplicado para estudiar registros de larga

Etapa del proyecto

La aplicación fue desarrollada en Java, para permitir que pueda ejecutarse en

El analizador de protocolo desarrollado permite realizar una decodificación

La visualización de la decodificación de los mensajes se diseñó de modo que se

Las características de los mensajes que se consideraron para el filtrado son:

 tiempo (eligiendo un rango de tiempo),

1.5- Analizador “off-line” versus “on-line”

El procesar protocolos en tiempo real resulta en un elevado costo de desarrollo del

Además del costo de implementación del hardware adicional, tal proyecto

La aplicación desarrollada permite únicamente el análisis “off-line”. En el capítulo 9

1.6- Aplicaciones de los analizadores de protocolos de

En particular la interfaz denominada A por la ETSI, comunica la Central de

La interfaz A tiene a su cargo la gestión de la movilidad y el control de conexiones

Considerando que los analizadores de señalización interpretan los protocolos de

Una herramienta útil del analizador de protocolo que desarrollamos es el filtrado

Un analizador de protocolo todavía más completo puede formar parte de equipos

Referencias para éste capítulo:

El estudio del sistema GSM, la interfaz A y su pila de protocolos se desarrolla en

2.1- GSM (Global System for Mobile Comunication)

Es un sistema de comunicación celular digital. Fue desarrollado con el fin de crear

2.1.1- Servicios y facilidades del sistema

2.1.2- Arquitectura del sistema GSM

El sistema completo está formado por un número de entidades funcionales. La

Interfaz de señalización definida entre el BSS y el MSC. Su señalización está

2.2.1- Estructura de la interfaz

La definición de la interfaz sigue un modelo de capas el cual se muestra en la

2.2.2- Clases de mensajes de señalización de la interfaz

Las señales entre el BSS y el MSC se clasifican de la siguiente manera:

2.2.3- Unidades de señalización

Existen tres tipos de unidad de señalización: unidades de señalización de mensaje

BIB Bit indicador inverso (backward indicator bit)

3.1- Propósitos Generales

La meta es obtener un análisis completo “off-line” de las unidades de mensaje de

Más concretamente, la meta incluye:

 Realizar una decodificación completa de cualquier unidad de señal de

3.3- Requerimientos específicos

3.2.1- Requerimientos funcionales

Ref # Función Categoría

3.3.2- Requerimientos no funcionales

Requisitos de interfaz del sistema

El sistema debe interactuar con un elemento externo que proporcionará los

Estos archivos .TXT serán la entrada del sistema.

3.3.3- Atributos del software

En el cambiante mundo de las telecomunicaciones cuando se intenta obtener

 Eficiencia: buen uso de los recursos.

Como debe correr sobre el sistema operativo del sistema de Operación y

3.5- Diagrama de los casos de uso