Índice

ÍNDICE
ÍNDICE
GLOSARIO..................................................................................................................... 3
INTRODUCCIÓN .......................................................................................................... 7
LA SEÑALIZACIÓN SS7 EN UNA RED MÓVIL................................................... 11

2.1 QUÉ ES LA SEÑALIZACIÓN............................................................................ 12
2.2 ARQUITECTURA DE LA RED SS7 .................................................................. 12
2.2.1 Puntos de Transferencia de Señalización (STP)............................................ 13
2.2.2 Punto de control de servicios (SCP) .............................................................. 14
2.2.3 Punto de Datos de Servicio (SDP)................................................................. 14
2.2.4 Registro de localización de usuarios (HLR).................................................. 15
2.2.5 Registro de localización de visitantes (VLR) ................................................ 15
2.2.6 Centro de Servicio de Mensajes Cortos (SMSC) .......................................... 16
2.2.7 Enlaces de señalización SS7.......................................................................... 16
2.2.8 Señalización asociada.................................................................................... 16
2.2.9 Señalización cuasi-asociada .......................................................................... 17
2.3 CAPAS DEL PROTOCOLO SS7 ........................................................................ 17
2.3.1 Nivel Físico ................................................................................................... 17
2.3.2 Parte de Transferencia de Mensajes (MTP) – Nivel 2 .................................. 18
2.3.3 Parte de Transferencia de Mensajes (MTP) – Nivel 3 .................................. 19
2.3.4 Parte de usuario de RDSI (ISUP) .................................................................. 23
2.3.5 Parte de Control de Conexión de Señalización (SCCP)................................ 24
2.3.6 Parte de Aplicación de Capacidades de Transacción (TCAP) ...................... 27
2.3.7 Parte de Aplicación de Movilidad (MAP)..................................................... 27
2.4 TRANSACCIONES MAP EN EL SERVICIO SMS........................................... 28
2.4.1 Mensaje corto originado ................................................................................ 28
2.4.2 Mensaje corto terminado ............................................................................... 29
TRANSPORTE DE SEÑALIZACIÓN SS7 SOBRE IP ........................................... 31

3.1 SIGTRAN............................................................................................................. 32
3.1.1 Qué es el Sigtran............................................................................................ 32
3.1.2 Arquitectura de los protocolos SIGTRAN .................................................... 32
3.1.3 Necesidad de implementar un nuevo protocolo de transporte....................... 33
3.2 SCTP [RFC2960] ................................................................................................. 34
3.2.1 Características principales ............................................................................. 34
3.2.2 Funciones de SCTP ....................................................................................... 36
3.3 M2PA.................................................................................................................... 39
3.3.1 Funciones soportadas por M2PA................................................................... 39
3.3.2 Formato de los mensajes M2PA.................................................................... 41
3.4 M2UA [RFC 3331]............................................................................................... 41
3.5 M3UA [RFC 3332]............................................................................................... 44
3.5.1 Representación mediante códigos de punto de señalización ......................... 45
3.5.2 Routing Keys ................................................................................................. 46
3.5.3 Redundancia .................................................................................................. 46
3.5.4 Formato de los mensajes de datos de usuario................................................ 47
3.5.5 Utilización de M3UA .................................................................................... 48
3.6 SUA ...................................................................................................................... 48
-1-
Diseño de una red de señalización SS7 sobre IP para redes de telefonía móvil GSM y UMTS
3.6.1 Encaminamiento de mensajes........................................................................ 49

3.6.2 Utilización de SUA........................................................................................ 50
DISEÑO DE UNA RED DE TRANSPORTE DE SMS SOBRE IP ......................... 51

4.1 OBJETIVO DE DISEÑO ..................................................................................... 52
4.2 PRESENTACIÓN DEL CASO DE ESTUDIO ................................................... 52
4.2.1 Distribución de usuarios ................................................................................ 52
4.2.2 Distribución de MSCs con acceso radio........................................................ 53
4.2.3 Red de tránsito............................................................................................... 54
4.2.4 Red de señalización ....................................................................................... 57
4.2.5 Portabilidad de numeración móvil................................................................. 61
4.2.6 Tráfico de SMS.............................................................................................. 62
4.2.7 SMSCs........................................................................................................... 63
4.2.8 Distribución de nodos por emplazamiento .................................................... 64
4.3 RED SIGTRAN NECESARIA ............................................................................ 65
4.3.1 Nodos ampliables con señalizadores SIGTRAN........................................... 65
4.3.2 Alternativas de implementación .................................................................... 65
4.3.3 Arquitectura de la red SIGTRAN objetivo.................................................... 67
4.3.4 Tráfico IP en SGWs....................................................................................... 69
4.3.5 Tráfico IP en HLRs ....................................................................................... 73
4.3.6 Tráfico IP en SMSCs..................................................................................... 75
4.3.7 VLANes SIGTRAN ...................................................................................... 77
4.3.8 Ancho de banda entre emplazamientos ......................................................... 81
4.3.9 Plan de direccionamiento IP.......................................................................... 90
4.3.10 Configuración en MSCs .............................................................................. 94
4.3.11 Configuración en STP/SGWs...................................................................... 97
4.3.12 Configuración en SMSCs .......................................................................... 101
4.3.13 Configuración en HLRs............................................................................. 107
COMPARACIÓN ENTRE SOLUCIÓN TRADICIONAL Y SOLUCIÓN

SIGTRAN .................................................................................................................... 111
5.1 OBJETIVO DE LA COMPARACIÓN.............................................................. 112
5.2 RED EQUIVALENTE TRADICIONAL........................................................... 112
5.3 COMPARACIÓN DE AMBAS SOLUCIONES ............................................... 113
5.3.1 Ancho de banda entre emplazamientos ....................................................... 113
5.3.2 Coste de los SMSCs .................................................................................... 115
5.3.3 Coste de la red ............................................................................................. 116
5.3.4 Flexibilidad de las plataformas.................................................................... 116
5.3.5 Capacidad de la red ..................................................................................... 117
5.3.6 Comportamiento ante congestión ................................................................ 117
5.3.7 Experiencia en la tecnología........................................................................ 118
5.3.8 Evolución de la red...................................................................................... 118
5.4 RESULTADO DE LA COMPARACIÓN ......................................................... 120
BIBLIOGRAFÍA ........................................................................................................ 123
-2-
GLOSARIO
GLOSARIO
• 3GPP Third generation partnership project. Grupo normalizador de las

redes de telefonía móvil de tercera generación.
• ACK Mensaje de asentimiento a otro mensaje enviado previamente.
• BSC Base Station Controller. Nodo de conmutación dedicado a controlar
estaciones base de radio.
• CAMEL Protocolo de Red Inteligente normalizado específico para redes de
telefonía móvil.
• Chunk Unidad de información en la que se divide un paquete del protocolo
SCTP.
• CIC Circuit Identification Code. Código identificador de un circuito de
voz entre dos nodos de conmutación.
• CRC Cyclic redundancy check. Comprobación de redundancia cíclica.
• Diffserv Método de caracterización de tráfico IP basado en diferenciación por
servicios.
• DPC Destination Point Code. Código de punto de señalización destino.
• FISU Fill-in signal unit. Unidad de señalización de relleno.
• FSM-MO Forward Short Message Mobile Originated. Envío de mensaje corto
originado en móvil.
• FSM-MO-ack Forward Short Message Mobile Originatd acknowledgement.
Mensaje de asentimiento al envío de mensaje corto originado en
móvil.
• FSM-MT Forward Short Message Mobile Terminated. Envío de mensaje corto
terminado en móvil.
• FSM-MT-ack Forward Short Message Mobile Originatd acknowledgemente.
Mensaje de asentimiento al envío de mensaje corto terminado en
móvil.
• GMSC Gateway Mobile Switching Centre. Central de conmutación móvil
con capacidad para enviar mensajes a los registros de localización de
usuarios.
• GPRS General Packet Radio Service. Servicio general de envío de
paquetes vía radio.
-3-
• GSM: Global Switched Mobile Network. Red de conmutación móvil

global.
• GT Global Title. Título Global.
• GTT Global Title Translation. Traducción de títulos globales.
• HLR Home Location Register. Registro de localización de los usuarios de
la propia red.
• IEEE Institute of Electrical and Electronics Engineers. Instituto de
Ingenieros eléctricos y electrónicos.
• IETF Internet Engineering Task Force. Grupo de Trabajo de ingeniería de
Internet.
• INAP Intelligent Network Application Part. Parte de aplicación de Red
Inteligente.
• IP: Internet Protocol. Protocolo de Internet.
• ISPC International Signalling Point Code. Código de punto de
señalización nacional
• ISUP Integrated Services User Part. Parte de usuario de servicios
integrados.
• IUA ISDN Q.921-User Adaptation Layer. Capa de adaptación del usuario
del protocolo Q.921 de la Red Digital de Servicios Integrados.
• Linkset Conjunto de enlaces de señalización entre dos nodos adyacentes.
• LSSU Link Status Signal Unit. Unidad de señalización de estado de enlace.
• M2PA MTP2-User Peer-to-Peer Adaptation Layer. Capa de adaptación
entre pares de usuario de MTP2.
• M2UA MTP2-User Adaptation Layer. Capa de adaptación de usuario de
MTP2.
• M3UA MTP3-User Adaptation Layer. Capa de adaptación de usuario de
MTP3.
• MAP Mobile Application Part. Parte de aplicación móvil.
• MSC Mobile Switching Centre. Central de conmutación de telefonía
móvil.
• MSISDN Mobile Station Integrated Service Digital Network Number. Número
de línea de telefonía móvil.
• MSU Message Signal Unit. Unidad de señalización de mensaje.
-4-
GLOSARIO
• MTP Message Transfer Protocol. Protocolo de transferencia de mensajes

de señalización.
• MTP3 Message Transfer Protocol layer 3. Capa de red del protocolo de
transferencia de mensajes de señalización.
• NI Network Indication. Indicador de Red.
• OPC Originating Point Code. Código de punto de señalización origen.
• OSI Open System Interconnection. Interconexión de sistemas abiertos.
• RANAP Radio Access Network Application Part. Parte de aplicación de la
red de acceso radio.
• Roaming Utilización por parte de un usuario de telefonía móvil de una red
distinta de la suya.
• SCCP Signalling Connection Control Part. Parte de control de conexión de
señalización.
• SCP Service Control Point. Punto de control de servicios.
• SCTP Stream Control Transmission Protocol. Protocolo de transmisión de
flujos de control.
• SDP Service Data Point. Punto de datos del servicio.
• SGSN Serving GPRS support node. Nodo servidor de soporte de la red
GPRS.
• SGW Signalling Gateway. Pasarela de señalización.
• SI Service Indicator. Indicador de servicio.
• SIGTRAN Signalling Transport. Transporte de señalización.
• SIO Service Information Octet. Octeto de información de servicio.
• SLC Signalling link code. Código de enlace de señalización.
• SLS Signalling link selection. Selección de enlace de señalización.
• SMS Short Message Service. Servicio de mensajes cortos.
• SMSC Short Message Service Centre. Central del servicio de mensajes
cortos.
• SMS-MO Short Message Service-Mobile Originated. Mensaje corto originado
en móvil.
• SMS-MT Short Message Service-Mobile Terminated. Mensaje corto terminado
en móvil.
• SPC Signalling Point Code. Código de punto de señalización.
-5-
• SRI Send Routing Information. Envío de información de

encaminamiento.
• SRIfSM Send Routing Information for Short Message. Envío de información
de encaminamiento para mensaje corto.
• SS7 Sistema de señalización número siete.
• SSN Subsystem number. Número de subsistema.
• STP Signalling Transfer Point. Punto de transferencia de señalización.
• SUA SCCP-User Adaptation Layer. Capa de adaptación de usuarios de
SCCP.
• Stream Secuencia de mensajes de usuario de SCTP que debe entregarse al
nivel superior de forma ordenada.
• TCAP Transaction Capabilities Application Part. Parte de aplicación de
capacidades de transacción.
• TCP Transmission Control Protocol. Protocolo de control de transmisión.
• TDM Time division multiplexation. Multiplexación por división en el
tiempo.
• TSN Transmission Sequence Number. Número de secuencia de
transmisión.
• TUA TCAP User Adaptation Layer. Capa de adaptación de usuarios de
TCAP.
• UDP User Datagram Protocol. Protocolo de datagramas de usuario.
• UIT-T Unión Internacional de Telecomunicaciones-Sector de
normalización de telecomunicaciones.
• UMTS: Universal Mobile Telecommunications System. Sistema universal de
telecomunicaciones móviles.
• USSD Unstructured suplementary service data. Datos no estructurados de
servicios suplementarios.
• VLAN Virtual local area network. Red de área local virtual.
• VLR Visitor Location Register. Registro de localización de visitantes.
-6-
INTRODUCCIÓN
1
INTRODUCCIÓN
-7-
Los operadores móviles están experimentando un importante crecimiento en el

número de usuarios, junto con una creciente difusión de nuevos servicios de
comunicaciones basados en transacciones de datos. Como consecuencia de ello, se
plantea la necesidad de contar con una red de transporte de datos más orientada al
tráfico de mensajería.
Los nodos de las redes GSM utilizan el sistema de señalización número 7 (en
adelante SS7) para intercambiar información relativa al control de llamadas,
información de control de la movilidad de los usuarios y también para transportar los
mensajes de texto intercambiados entre usuarios (en adelante SMS, de Short Message
Service).
El sistema SS7 surgió dentro del entorno de la telefonía fija. Fue necesario crear
un nuevo protocolo (MAP) para añadirle las funcionalidades requeridas por las redes
GSM, tales como consulta a registros de usuarios. Basándose en estas nuevas
funcionalidades se implementó el servicio de envío de mensajes de texto de móvil a
móvil (SMS). Sin embargo, tanto las nuevas funcionalidades como las originales,
utilizan como base el protocolo de transporte de señalización MTP, diseñado para unas
redes con un tráfico de señalización mucho menor que el de las redes móviles. En redes
con alta densidad de usuarios, las limitaciones del MTP suponen un serio problema a la
hora de cursar la señalización de determinados nodos.
Lo más importante en una red de transporte de señalización es la fiabilidad. Dado

que esta red transporta el control de todas las comunicaciones, un fallo en ella podría
suponer la indisponibilidad de gran parte de la red y pérdidas económicas mucho
mayores que las que produciría un fallo equivalente en un nodo de transporte de tráfico
de usuario. Este nivel de fiabilidad se debe mantener porque al operador le interesa que
el tráfico de señalización relativo a llamadas siempre se pueda cursar, y con unos
retardos máximos garantizados. Sin embargo, el tráfico de envío de mensajes cortos no
es tan crítico.
-8-
INTRODUCCIÓN
El servicio de mensajes cortos es de tipo “datagrama” y sin requisitos de retardo.

El tráfico que genera tiene requisitos de transporte poco exigentes. Sin embargo, el
sistema GSM utiliza la red SS7 para transportarlos. Por esta red se transmite también la
señalización relativa a llamadas, que tiene unos requisitos muy estrictos en cuanto a
retardos y sobre todo, a disponibilidad de la red. Como la red SS7 no puede distinguir
un tipo de tráfico de otro, añadir un tráfico de mensajes cortos importante supone
ampliar toda la red de señalización lo suficiente como para garantizar alta disponibilidad
y bajo retardo a todo este nuevo tráfico, que realmente no lo necesita.
En el momento en que es necesario realizar inversiones en la red de señalización,

red fiable y de disponibilidad total, motivadas por el transporte de mensajes cortos,
servicio sin requisitos de retardo, el operador debe plantearse utilizar redes de transporte
alternativas al sistema SS7 tradicional, de forma que pueda ofrecer el mismo servicio a
sus usuarios pero con la mínima inversión.
Las redes IP son claramente más adecuadas que las redes SS7 para el transporte de
información sin requisitos estrictos de retardo o ancho de banda. Por ello, los
operadores de telefonía móvil pueden encontrar ventajoso utilizar esta tecnología para el
transporte de SMS.
En un futuro cercano, las redes de telefonía móvil de tercera generación utilizarán

como única red de transporte una red IP, por lo que también le puede resultar interesante
a los operadores móviles de segunda y tercera generación, utilizar la misma red de
transporte de su sistema de tercera generación para cursar el tráfico de voz y
señalización de su red de segunda generación. Esto resultará especialmente ventajoso
cuando la tecnología GSM se encuentre en declive, tal como le ocurre actualmente a la
telefonía móvil analógica.
-9-
LA SEÑALIZACIÓN SS7 EN UNA RED MÓVIL
2
LA SEÑALIZACIÓN
SS7 EN UNA RED
MÓVIL
- 11 -
2.1 QUÉ ES LA SEÑALIZACIÓN
En una Red de Conmutación, se entiende por señalización el intercambio de

información entre diferentes nodos de la red necesario para proveer un servicio de
comunicación.
Los usuarios de una Red de Conmutación, como es una red GSM, también
intercambian señalización con elementos de la red, por ejemplo al marcar un número de
teléfono, o al colgar.
El Sistema de Señalización SS7 es un medio que utilizan los elementos de la red

de conmutación para intercambiar información. Esta información se transporta en forma
de mensajes. Los mensajes SS7 transportan información relativa a establecimiento y
liberación de llamadas. Además, en las redes de telefonía móvil también transportan
información de localización del usuario en la red, así como mensajes de texto de usuario
(SMS).
2.2 ARQUITECTURA DE LA RED SS7
El sistema SS7 consiste básicamente en una red de transporte de mensajes cuyos

usuarios son nodos de conmutación. Esta red de transporte de señalización es paralela a
la red de conmutación que forman los nodos que la utilizan, y su topología es, en
general, completamente diferente. La Figura 1 muestra un esquema de red SS7 de una
red GSM, con los componentes fundamentales.
- 12 -
HLR
MSC STP STP
SCP
MSC STP STP
SMSC
Enlaces de señalización
Enlaces de voz
Figura 1. Esquema de Red SS7 en una red GSM.
Los elementos que forman la red SS7 en una red GSM son los siguientes:
2.2.1 Puntos de Transferencia de Señalización (STP)
Un STP es un conmutador de paquetes diseñado específicamente para enviar

mensajes de señalización SS7. Los STPs encaminan mensajes entre centrales de
conmutación (MSCs y GMSCs en una red móvil), bases de datos, como los registros de
localización de los usuarios (HLRs), y nodos de control de servicios basados en Red
Inteligente (SCPs).
La disponibilidad de la Red SS7 que interconecta los nodos de conmutación de

una red de telefonía es un factor de máxima importancia en el procesamiento de las
llamadas. Si dos centrales no pueden intercambiarse señalización, no podrán establecer
ninguna llamada entre ellas. Por esta razón, la red SS7 se diseña con una arquitectura
completamente redundante. Además, los protocolos de transporte de mensajes de
señalización se han definido con mecanismos de re-encaminamiento de tráfico de
señalización en caso de fallos en elementos de la propia red de señalización. Para el
caso de los STPs, éstos siempre se configuran en parejas exactamente iguales. Todos los
nodos que se conectan a un STP, también se conectan al otro STP de la pareja,
formando una red redundante.
- 13 -
2.2.2 Punto de control de servicios (SCP)
Los servicios de telefonía que necesitan de un procesamiento avanzado de las

llamadas (procesamiento que no pueden acometer las centrales de conmutación) se
implementan mediante nodos de control de servicios (SCP). Estos nodos intercambian
señalización de control de llamada con las centrales de conmutación, y en ellos se
implementa la lógica del servicio. Este tipo de servicios se conoce también con el
nombre de Red Inteligente.
Un ejemplo de servicio de Red Inteligente puede ser el de llamadas al servicio de

atención telefónica de una empresa con presencia en varias ciudades, de manera que
marcando un único número 900, la llamada siempre se encamine al centro de atención
telefónica más cercano al origen de la llamada. En este caso, la central de conmutación
en la que se origine la llamada efectuará una consulta al SCP para proseguir con el
encaminamiento de la llamada. Esta consulta consistirá en un intercambio de mensajes
de señalización entre central y SCP.
Dependiendo de la importancia del servicio al que atienden, los SCPs se pueden

configurar como parejas redundantes, del mismo modo que los STPs.
En general, los SCPs implementan servicios basados en llamadas, no basados en

otras portadoras utilizadas para enviar información en las redes móviles, como pueden
ser SMS, USSD o GPRS.
2.2.3 Punto de Datos de Servicio (SDP)
Es posible que para proveer algunos servicios de Red Inteligente de forma masiva
sea necesario disponer de varios nodos SCP, para distribuir la carga total de proceso del
servicio. Si estos nodos requieren utilizar una base de datos común, es necesario
disponer de un nodo independiente que la contenga. Este nodo se llama SDP, y también
utiliza la Red SS7 para recibir y responder las consultas que provienen de los nodos
SCP.
La base de datos del SDP se puede distribuir físicamente en varios nodos en caso
de bases de datos de millones de registros y frecuencias de acceso elevadas, para mayor
facilidad de implementación.
- 14 -
2.2.4 Registro de localización de usuarios (HLR)
Consiste en una base de datos que almacena, tanto la MSC en la que se encuentra
registrado cada usuario como la información de acceso a servicios de los clientes. El
HLR recibe peticiones de actualización de localización y envío de registros de usuario
por parte de una GMSCs (Una GMSC es una MSC capaz de interrogar al HLR) cuando
un nuevo usuario entra en el área de cobertura atendida por ésta. En el caso de redes de
2.5G, con GPRS, los nodos SGSN también piden el registro de cada usuario al que
atienden, y envían peticiones de actualización de localización al HLR, de igual manera
que una GMSC.
Todas las peticiones de actualización y consultas que recibe el HLR, así como sus
respuestas correspondientes, son señalización entre nodos, y se envían mediante una red
SS7.
Normalmente un operador con más de un millón de usuarios cuenta con varios

nodos HLR, ya que la capacidad de memoria y carga de procesador de los nodos HLR
es limitada. Además, si falla un HLR todos los usuarios definidos en él dejarán de estar
atendidos por la red, por lo que conviene contar con algún esquema de redundancia de
HLRs (por ejemplo, n+1).
2.2.5 Registro de localización de visitantes (VLR)
El VLR es una base de datos que almacena los registros de los usuarios activos
que se encuentran atendidos por una MSC. En la mayoría de fabricantes, el VLR es un
software que se ejecuta en la propia MSC. En el VLR se copian íntegramente los
registros del HLR para todos los usuarios a los que atiende la MSC, de forma que ésta
no necesita realizar consultas reiteradas al HLR para determinar si un cierto usuario
puede acceder un servicio concreto. De este modo se reduce el tráfico de señalización
entre MSC y HLR.
Cuando un usuario se mueve y pasa a estar atendido por otra MSC, el VLR
antiguo recibe del HLR la orden de borrar el registro local del usuario.
- 15 -
2.2.6 Centro de Servicio de Mensajes Cortos (SMSC)
Es el elemento fundamental que permite a los usuarios enviar y recibir SMSs.

Estos centros reciben los SMSs enviados por los usuarios a la red. La MSC que atiende
al usuario lo envía al SMSC y allí se almacena. Para conocer la MSC en la que se
encuentra el usuario destino, el SMSC debe interrogar al HLR por la posición del
usuario correspondiente. Entonces comienza una secuencia de intentos de entrega del
SMS a la MSC destino. Si se entrega con éxito, el SMS se borra del SMSC. Si no, se
almacena hasta el siguiente reintento. Si al cabo de un número de reintentos
determinado no se ha entregado el SMS, se borrará del SMSC y se perderá.
Los SMSs se transmiten entre MSCs y SMSCs en forma de mensajes de

señalización, y se cursan por tanto, a través de una red SS7.
2.2.7 Enlaces de señalización SS7
Se entiende por enlace de señalización un circuito de datos bidireccional que

conecta dos nodos individuales en una red SS7. El conjunto de enlaces de señalización o
SLCs (de Signalling Link Circuit) que se define entre dos nodos de la red SS7 se conoce
como Linkset.
2.2.8 Señalización asociada
En ocasiones, se implementan enlaces de señalización directos entre dos nodos de

conmutación, sin utilizar ninguna red SS7 de tránsito. Este esquema de señalización se
denomina señalización asociada.
Si bien en general es preferible enviar la señalización a través de la red SS7, por su

fiabilidad, existen casos en los que no es posible implementar linksets hacia STPs. Un
ejemplo puede ser la interconexión con un operador de telefonía básica pequeño, que no
cuente con STPs, o que únicamente cuente con un punto de interconexión al otro
operador, a través de una central.
- 16 -
En otros casos realmente no se pierde seguridad por no utilizar los STPs para
enviar la señalización. Los nodos que únicamente envían señalización a un solo destino
no necesitan una red de transmisión de señalización. Con un linkset directo es
suficiente. Un ejemplo de estos nodos son las BSCs. Una BSC se conecta únicamente a
una MSC, y sólo le envía mensajes de señalización a ésta. Si falla la BSC, la MSC, o la
transmisión entre estos nodos, la BSC quedará fuera de servicio, por lo que no se gana
seguridad estableciendo enlaces de señalización redundantes.
2.2.9 Señalización cuasi-asociada
Como contraposición a la señalización asociada, la arquitectura en la que se

establecen enlaces de señalización entre los nodos de conmutación y los STPs de la red
SS7 se denomina señalización cuasi-asociada.
2.3 CAPAS DEL PROTOCOLO SS7
Lo fundamental en una red SS7 es el protocolo de transferencia de mensajes de

señalización (MTP). Este protocolo comprende los niveles dos y tres de la torre OSI, y
sobre él se transmite toda la señalización de todas las redes de conmutación de circuitos
tradicionales, tanto de operadores de telefonía fija como de telefonía móvil.
2.3.1 Nivel Físico
En general, en las redes SS7 tradicionales los enlaces de señalización se

implementan mediante transmisión TDM (Multiplexación por División en el Tiempo)
utilizando canales de 64 kbps dentro de tramas punto a punto de 2 Mbps (E1
normalizados)1.
1
En la norma americana las líneas punto a punto son T1s en lugar de E1s, y el ancho de banda de
los canales digitales multiplexados es de 56 kbps.
- 17 -
Entre dos nodos de una red SS7 se pueden definir como máximo 16 canales, pero
por lo general no se suelen implementar más de 8 en las redes reales, debido a
limitaciones del protocolo MTP que se analizarán en el apartado 2.3.3.3. Se puede
observar que de la transmisión TDM sobre enlaces punto a punto de 2 Mbps (32 canales
de 64 kbps) se utiliza, en el mejor de los casos, hasta un 25%. En realidad, si se utilizan
enlaces redundantes la carga de tráfico en uno de ellos no debe superar el 50%, de
forma que en caso de caída de un enlace se pueda cursar todo el tráfico por el otro, por
lo que el tráfico máximo que se puede cursar por los E1s, de 2Mbps, es de 256 kbps
(12’5% como máximo). El consumo de recursos de transmisión en la red SS7
tradicional es claramente poco eficiente.
Definidos
como linkset Canales desaprovechados
STP 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 STP
32 x 64 kbps
Sincronismo de trama
Figura 2 Aprovechamiento de la transmisión TDM en una red SS7
Si se dispone de multiplexores TDM, se puede aumentar el aprovechamiento de la

transmisión enviando distintos linksets entre nodos de los mismos emplazamientos por
la misma trama, o incluso utilizar canales de tramas dedicadas al transporte de canales
de voz para transportar los SLCs de uno o varios linksets.
2.3.2 Parte de Transferencia de Mensajes (MTP) – Nivel 2
Esta capa del protocolo se encarga de todas las tareas de nivel de enlace, de forma
que se asegura que entre los dos extremos de un enlace de señalización se pueden
intercambiar mensajes de forma fiable. Estas tareas son:
• Sincronismo de enlace.
• Monitorización de tasa de errores.
• Generación y comprobación de códigos de redundancia cíclica (CRC) y
números de secuencia de MSUs.
• Gestión de colas de entrada y salida de MSUs y monitorización de
congestión.
- 18 -
• Transmisión, recepción y reenvío en caso de error de MSUs.
2.3.3 Parte de Transferencia de Mensajes (MTP) – Nivel 3
Este nivel es el corazón de la red SS7. El nivel 3 de MTP (en adelante MTP-3) es
el encargado de proveer conectividad entre todos los nodos de la red, de forma que
asegura que dos nodos puedan intercambiar mensajes de señalización,
independientemente de si están directamente conectados o no.
Las principales funciones de este nivel son:
• Identificación de todos los nodos de la red.

• Encaminamiento y reenvío de mensajes, y reparto de carga entre varios
enlaces.
• Gestión del estado de enlaces.
2.3.3.1 Códigos de Punto de Señalización (SPC)
En MTP los nodos se identifican mediante al menos un código de 14 bits2

denominado Signalling Point Code (SPC). En los mensajes MTP3 se incluyen los
campos OPC (Originating Point Code) y DPC (Destination Point Code), que
corresponden a los SPCs de los nodos origen y destino del mensaje MTP3,
respectivamente.
Existe, además, un identificador de red (NI) de dos bits que aplica al mensaje
MTP entero y se utiliza para diferenciar los mensajes MTP3 intercambiados entre las
redes MTP nacionales y la red MTP internacional.
El uso del campo NI, según la UIT-T es el siguiente:
• 00: Red Internacional.

• 01: Uso privado internacional.
• 10: Red Nacional.
• 11: Uso privado nacional.
2
14 bits según norma de la UIT-T. En Japón se utilizan 16 bits, y en Norte América 24 bits.
- 19 -
De esta forma, un mismo nodo puede usar un identificador nacional para

intercambiar mensajes con nodos de su mismo país (incluso de otras operadoras
nacionales), y un identificador internacional para intercambiar mensajes con nodos de
otros países. Sin embargo, como el identificador de red aplica tanto al OPC como al
DPC, un nodo que únicamente tiene identificador nacional no puede enviar mensajes a
un nodo con únicamente identificador internacional.
Así, un SPCs de 14 bits no identifica un nodo. Es necesario especificar además la

red (espacio de direccionamiento) en la que se aplican. Los SPCs se representan en
notación decimal junto con el campo NI, de la siguiente forma:
• NI=10 (Ámbito Nacional) en binario. 2 en decimal.

• SPC=10010001110110 en binario; 9334 en decimal.
• Notación decimal: 2-9334.
Todos los nodos de conmutación de un mismo país deben utilizar el mismo

conjunto de 14 bits para identificar sus nodos en sus comunicaciones de ámbito
nacional. Para comunicaciones que únicamente se dan en el ámbito de una operadora
concreta (sin interconexión) se puede utilizar también un ámbito de red nacional privado
(NI=11 en binario, 3 en decimal).
2.3.3.2 Encaminamiento de mensajes por SPC
El encaminamiento de mensajes basado en SPC (en realidad SPC más NI) consiste
en el conjunto de reglas que se aplican en el momento en que llega un mensaje MTP al
nivel de red del protocolo (nivel 3). Mediante estas reglas se decide si el propio nodo es
el destino de un mensaje o, en caso de no serlo, por qué enlace de señalización (nivel 2)
cursar el mensaje. El nivel MTP-3 de un nodo puede enviar mensajes hacia cualquiera
de los niveles MTP-2, definidos en cada uno de sus enlaces de señalización. Encaminar
los mensajes, en este nivel, es decidir por qué enlace de señalización enviarlos.
- 20 -
STP
A
BSC MSC HLR
STP
Enlaces de señalización B
Enlaces de voz
Figura 3. Ejemplo de conexión de una MSC a la Red SS7
En la Figura 3, la MSC dispone de tres linksets, por ejemplo, de cuatro SLCs hacia
la BSC y de ocho SLCs hacia los STPs. La capa de Red de MTP de la MSC dispone en
total de 20 enlaces de señalización a los que poder entregar mensajes. Para discriminar
qué mensajes enviar por cada enlace, en primer lugar se escoge el linkset por el que se
entregará el mensaje. La capa MTP-3 dispondrá de una tabla como la que se muestra a
continuación:
Tabla 1. Ejemplo de encaminamientos MTP3
Bit del SLS de

DPC (Destino MTP-3) Linkset de salida Prioridad
reparto de carga
SPC de la BSC Linkset hacia BSC 1 -
Linkset hacia STP-A 1 3
SPC del HLR
Linkset hacia STP-B 1 3
- 21 -
De acuerdo con la tabla anterior, la MSC enviaría todos los mensajes MTP-3 cuyo
destino es la BSC por el linkset directo hacia la BSC (aún no se ha determinado cuál de
los cuatro enlaces hacia la BSC utilizar en cada mensaje concreto). Para el caso de los
mensajes MTP-3 cuyo destino es el HLR, la MSC dispone de dos linksets con la misma
prioridad para enviarlos. En este caso, la mitad de los mensajes los enviará por el linkset
con el STP-A y la otra mitad por el linkset con el STP-B (reparto de carga). De nuevo,
quedaría por determinar qué enlace dentro del linkset utilizar parar enviar un mensaje
MTP concreto. Si el linkset hacia STP-B tuviera, por ejemplo, prioridad 2, se enviarían
todos los mensajes hacia el STP-A, y sólo se enviarían hacia el STP-B en caso de fallo
en la entrega por el linkset hacia el STP-A.
2.3.3.3 Reparto de carga entre enlaces
El protocolo MTP3 (norma UIT-T Q.704) define una serie de mecanismos

normalizados de encaminamiento de mensajes con reparto de carga entre linksets y entre
SLCs dentro de cada linkset. Estos mecanismos se basan en utilizar el campo SLS de los
mensajes MTP-3 (Signalling Link Selection). Cada vez que se origina un mensaje MTP-
3 se le asigna un número de cuatro bits, del 0000 a 1111, en general de forma
secuencial, aunque con restricciones3. Este número será el valor del campo SLS del
mensaje MTP-3. Para repartir carga de señalización entre dos linksets, es decir, para
enviar la mitad de los mensajes MTP-3 hacia un destino concreto por un linkset y la otra
mitad por otro, el protocolo se fija en el valor de un bit del SLS determinado en la tabla
de encaminamiento MTP. Los mensajes con ese bit igual a 0 se envían por un linkset y
los mensajes con el bit igual a 1 se envían por el otro.
3
Todos los mensajes MTP pertenecientes a la misma transacción de nivel superior (en redes GSM
ISUP o SCCP) siempre utilizan el mismo valor de SLS. De esta forma se garantiza que todos esos
mensajes se envían por el mismo camino, asegurándose el orden en la entrega de mensajes para una
misma transacción.
- 22 -
Dentro de un linkset, se utilizan los bits menos significativos del campo SLS para
escoger el SLC por el que enviar el mensaje. Para repartir carga entre los enlaces de un
linkset de dos SLCs se utiliza el bit menos significativo. Para repartir carga entre cuatro
SLCs se utilizarán los dos bits menos significativos del SLS, y para repartir entre ocho
SLCs se utilizarán los tres bits menos significativos del SLS. Ahora bien, si se define un
linkset con un número de SLCs que no sea potencia de 2, no se repartirá bien la carga de
señalización entre ellos.
El principal inconveniente de la utilización del campo SLS para repartir carga

entre enlaces es que con cuatro4 bits sólo se puede repartir carga entre 16 caminos
distintos. Si se utiliza un bit para escoger entre dos linksets, sólo quedan tres bits
disponibles para elegir SLC dentro del linkset, por lo que en este caso el máximo
número de SLCs en los linksets es ocho.
En cualquier caso, es decisión de los fabricantes de equipos de conmutación

implementar el nivel 3 del protocolo MTP de acuerdo a la norma, ya que es posible
utilizar otras estrategias de encaminamiento de mensajes MTP que garantizan el orden
en la entrega de mensajes dentro de la misma transacción y que además, permiten
utilizar reparto de carga entre linksets de 16 SLCs (Ver [GRAD]).
2.3.4 Parte de usuario de RDSI (ISUP)
El protocolo ISUP se encarga del establecimiento y liberación de llamadas de voz

y datos sobre redes de conmutación de circuitos de 64 kbps. Para ello gestiona en cada
tramo de la llamada la toma de enlace, y su correspondiente liberación posterior, dentro
de las tramas disponibles entre centrales de conmutación de voz. Los mensajes ISUP se
transportan directamente sobre MTP-3.
4
Según norma de la UIT-T el campo SLS se compone de cuatro bits. En norma ANSI se utilizan 5
u 8 bits.
- 23 -
Cuando se marca un número de teléfono, la central de conmutación de voz (en

redes móviles son MSCs) decide cuál es el siguiente tramo del circuito de voz que se
debe establecer entre el usuario que marca el número y el destino de la llamada. Una
vez que la central decide que debe tomar un enlace hacia otra central, le envía a esta
última un mensaje ISUP de petición de toma de canal, con información del número A
(origen de la llamada), número B (destino de la llamada) y tipo de servicio portador
solicitado (voz, datos o fax).
Aunque desde el punto de vista de la red de conmutación de voz sólo se

intercambia señalización ISUP entre nodos adyacentes, estos nodos no tienen por qué
ser adyacentes desde el punto de vista de la red SS7. En las redes con señalización
cuasi-asociada no lo son, y por eso se necesita el protocolo MTP para encaminar los
mensajes ISUP de una central de conmutación de voz a otra (Ver Figura 1).
2.3.5 Parte de Control de Conexión de Señalización (SCCP)
El protocolo SCCP provee dos funciones fundamentales de las que carece MTP.
La primera de ellas es la capacidad de discriminar aplicaciones dentro de un nodo con
un único punto de señalización. MTP sólo reconoce nodos completos, y no distingue
entre las diferentes aplicaciones software dentro de un único nodo físico. Las
aplicaciones software que se ejecutan en los nodos de conmutación se denominan
subsistemas. De esta forma, una MSC puede funcionar a la vez como HLR, y
distinguirá la aplicación a la que entregar los mensajes por el número de subsistema
enviado en el mensaje SCCP.
2.3.5.1 Traducción de Títulos Globales
La segunda función proporcionada por el protocolo SCCP es la capacidad de

realizar encaminamiento incremental de los mensajes, utilizando lo que se denomina
Traducción de Títulos Globales (o GTT).
- 24 -
Los Títulos Globales son identificadores únicos de aplicaciones sobre nodos de

conmutación. El espacio de direccionamiento de los títulos globales, como su propio
nombre indica, es global. Es decir, un GT identifica unívocamente una aplicación sobre
un nodo de conmutación en todo el mundo. Gracias a este espacio de direccionamiento
común a todas las redes SS7 es posible enviar mensajes desde un HLR de una red a una
MSC de otra red incluso en otro país.
Los GTs consisten en secuencias de dígitos decimales con formato según la norma
UIT-T E.164, es decir, idénticos en su codificación a los números de teléfono
habituales. Como sabemos, mediante los “números de teléfono” podemos identificar
líneas de teléfono en todo el mundo. Es decir, el rango de direcciones de líneas de
teléfono tiene ámbito global, y las centrales de conmutación de telefonía están diseñadas
para interpretar estas secuencias. Por eso se decidió utilizar estos mismos
identificadores, en lugar de para identificar líneas de teléfono, para identificar a los
propios nodos de las redes de conmutación.
Puesto que se utiliza el mismo espacio de direccionamiento, cada red deberá

reservar una parte de su rango de numeración de líneas de abonado, o MSISDNs, para
utilizarlos como GTs de sus nodos de conmutación.
A la hora de enviar un mensaje SCCP a través de una red MTP, se debe realizar
una traducción de la dirección SCCP (GT) a la dirección MTP (SPC). Sin embargo, un
nodo puede realizar una traducción “parcial” del GT a SPC. La dirección MTP a la que
se envía el mensaje puede corresponder con un nodo intermedio. En este caso, el nodo
intermedio recibe un mensaje con su dirección MTP. Por tanto, lo abre y lo entrega a su
nivel SCCP, y a este nivel la dirección destino (GT) no es el propio nodo, por lo que de
nuevo se realiza una traducción de GT a SPC, pero esta vez en el nodo intermedio.
- 25 -
Como ejemplo de delegación de traducciones de GTs se puede pensar en una red

GSM en la que todos sus HLRs deben ser capaces de enviar mensajes SCCP a las MSCs
de las redes en donde sus usuarios pueden hacer roaming internacional. Lo normal es
que los HLRs únicamente pertenezcan a una red MTP nacional (NI=2) y no pertenezcan
a la red MTP internacional (NI=0). De esta forma, los HLRs deberán traducir el GT de
la MSC destino a el SPC de un STP que pertenezca a la vez a la red nacional e
internacional. El STP abrirá el mensaje MTP y realizará una segunda traducción del GT
destino a una dirección MTP de la red internacional que seguramente corresponderá con
los STPs internacionales de la operadora destino. Los STPs de la operadora destino
volverán a abrir el mensaje MTP y realizarán una última traducción del GT al SPC de la
MSC destino del mensaje.
GT=A GT=C GT=D GT=B

SPC=2-A SPC=2-C’ SPC=2-D’ SPC=2-B
SPC=0-C SPC=0-D
HLR STP STP MSC
SCCP SCCP SCCP SCCP
MTP3 MTP3 MTP3 MTP3 MTP3 MTP3
RRed
edMTP
MTP
Red MTP internacional
internacional Red MTP
Red MTP Red MTP
nacional nacional
nacional nacional
GT dest =B → DPC=2-C’ GT dest =B → DPC=0-D GT dest =B → DPC=2-B

OPC=2-A OPC=0-C OPC=2-D’
Figura 4. Traducción de GTs
En el tramo final, la red nacional destino puede enviar el mensaje SCCP tanto al
GT destino como al DPC+SSN del nodo destino.
- 26 -
2.3.6 Parte de Aplicación de Capacidades de Transacción

(TCAP)
El protocolo TCAP surge de la necesidad de disponer de un mecanismo de

comunicaciones entre nodos de conmutación no orientados a la toma de circuitos de
voz. Este protocolo introduce el concepto de transacción, de forma que ofrece al nivel
superior el control de comunicaciones basadas en instrucciones y respuestas,
relacionándolas entre sí.
Gracias a TCAP, los protocolos de nivel superior (INAP, CAMEL y MAP)

pueden enviar ordenes a otros nodos, y recibir las respuestas correspondientes.
TCAP no aporta más funcionalidad aparte de la correlación entre órdenes y

respuestas. Es un protocolo de transporte de instrucciones entre nodos de conmutación.
En los protocolos de nivel superior deberá implementarse la verdadera funcionalidad de
consulta de bases de datos, o de control avanzado de llamadas.
2.3.7 Parte de Aplicación de Movilidad (MAP)
El protocolo MAP se utiliza en las redes de telefonía móvil para intercambiar

información de gestión de la movilidad de los usuarios, controlar el traspaso de
llamadas (handover) entre centrales y para enviar mensajes de texto de usuario (SMS).
MAP especifica una serie de flujos de información y servicios que posibilitan que
un usuario pueda engancharse a cualquier MSC que le de cobertura, y pueda acceder a
todos sus servicios independientemente de su localización. Además, MAP define
mecanismos de autentificación de usuarios y terminales, derivados del acceso radio de
los usuarios.
Adicionalmente, se implementó en el protocolo MAP el servicio de envío de

mensajes de texto de hasta 160 caracteres (SMS) entre los usuarios de las redes GSM,
así como el envío de señalización no estructurada de usuario (USSD).
- 27 -
2.4 TRANSACCIONES MAP EN EL SERVICIO SMS
El servicio SMS se basa en el envío de mensajes entre el usuario origen y un

usuario destino a través de un nodo intermedio denominado SMSC.
Primero se establece una comunicación entre el usuario origen y el SMSC, en la

cuál se envía el mensaje y se almacena en el SMSC. Este mensaje se denomina
“mensaje corto originado en móvil”. Después, el SMSC analiza el número del usuario
destino del mensaje, interroga al HLR por la MSC en la que se encuentra el usuario
destino y comienza un proceso de intentos de entrega. Este mensaje entre SMSC y MSC
destino se denomina “mensaje corto terminado en móvil”, y es posible que se envíe más
de uno para un mensaje originado, ya que el usuario destino puede encontrarse fuera de
cobertura.
2.4.1 Mensaje corto originado
El envío de un mensaje corto originado desde una MSC hasta un SMSC se

encapsula en el mensaje MAP Forward Short Message Mobile Originated (FSM-MO).
Este mensaje lo envía la MSC origen al SMSC destino basándose en el GT que el
usuario indica en su terminal, aunque las MSCs pueden modificar este GT y enviar sus
SMSs a un SMSC prefijado.
La Figura 5 muestra los mensajes MAP intercambiados en un envío de un mensaje

corto originado en móvil. Dado que el envío se realiza sin analizar el número destino,
únicamente analizando un GT, que corresponde siempre a un mismo nodo, no es
necesario consultar al HLR.
El mensaje Forward Short Message Mobile Originated Acknowledgement (FSM-

MO-ack) sirve como confirmación de entrega del mensaje corto desde la MSC al
SMSC.
- 28 -
MSC SMSC
FORWARD
S HORT MESS
AGE (MO)
ACK
ESSA GE (MO)
D SH O R T M
FORWAR
t t
Figura 5. Mensaje corto originado
2.4.2 Mensaje corto terminado
Una vez que el SMSC procesa el mensaje, comienza una serie de intentos de
entrega de dicho mensaje al usuario destino. Para ello, en cada intento interroga al HLR
acerca de la MSC en la que se encuentra el usuario destino. Este mensaje MAP se
denomina Send Routing Information for Short Message (SRIfSM), y la respuesta
también, aunque se transporta sobre un mensaje TCAP de tipo response, por lo que para
distinguirlo se dice SRIfSM-response.
Una vez que el SMSC conoce la MSC destino envía un mensaje MAP
denominado Forward Short Message Mobile Terminating (FSM-MT). Si el SMSC no
recibe el mensaje de asentimiento correspondiente, Forward Short Message Mobile
Terminating Acknowledgement (FSM-MT-ack), se inicia un proceso de reintentos
sucesivos con diferentes esquemas de tiempo entre reintentos. Si después de un número
prefijado de reintentos no se recibe el mensaje de asentimiento de la MSC destino, el
mensaje se borra en el SMSC.
La Figura 6 muestra los mensajes MAP enviados en una transacción de mensaje

corto terminado con éxito.
- 29 -
SMSC HLR
MSC
Send Routing
Info . for SM
e
- respons
outi ng Info. for SM
Send R
t
Forward Short Mess

age Mobile Terminatin
g
rminating-ack
t Messa ge Mobile Te
Forward Shor
t t
Figura 6. Transacciones MAP en un mensaje corto terminado
- 30 -
TRANSPORTE DE SEÑALIZACIÓN SS7 SOBRE IP
3
TRANSPORTE DE
SEÑALIZACIÓN SS7
SOBRE IP
- 31 -
3.1 SIGTRAN
3.1.1 Qué es el Sigtran
SIGTRAN (de signalling transport) es el nombre del grupo de trabajo del IETF
encargado de definir una arquitectura para el transporte de señalización en tiempo real
sobre redes IP. A raíz de ello, no sólo se creó una arquitectura, sino que se definió un
conjunto de protocolos de comunicaciones para transportar mensajes SS7 sobre IP.
3.1.2 Arquitectura de los protocolos SIGTRAN
La arquitectura definida por el Sigtran [RFC2719] consta de tres componentes:
• IP estándar como protocolo de red.

• Un protocolo común de transporte de señalización. Los protocolos definidos por
el Sigtran se basan en un nuevo protocolo de transporte sobre IP, llamado SCTP
(Stream Control Transmission Protocol).
• Capas de adaptación específicas para cada capa de la torre SS7 que se necesite
transportar. El IETF ha definido las siguientes: M2PA, M2UA, M3UA, SUA,
TUA e IUA.
S7UP/S7AP
Capa de adaptación
SCTP
IP
Figura 7 Arquitectura de protocolos SIGTRAN.
- 32 -
3.1.3 Necesidad de implementar un nuevo protocolo de

transporte
Los anteriores protocolos de transporte sobre IP, TCP y UDP, se diseñaron como
protocolos de propósito general, y presentan ciertas limitaciones que les hacen
inadecuados para transportar señalización SS7, debido a las características de este
tráfico.
3.1.3.1 Inconvenientes de UDP
Las características de UDP que lo hacen inadecuado para el transporte de

señalización SS7 son las siguientes:
• No soporta acuse de recibo de los mensajes (ACK).

• No garantiza entrega ordenada de los mensajes.
• No incorpora mecanismos de seguridad.
En general, aunque UDP es un protocolo que permite enviar mensajes a mayor

velocidad, no es fiable ni, por tanto, adecuado para transportar tráfico con las
necesidades de integridad que impone la señalización SS7.
3.1.3.2 Inconvenientes de TCP
Las siguientes particularidades de TCP hacen que éste tampoco resulte un

protocolo de transporte adecuado para el tráfico SS7:
• TCP transporta un flujo de octetos (byte-stream) entre un puerto origen y un

puerto destino. Dentro de este flujo monolítico, se garantiza la entrega ordenada
en destino de todos los octetos, sin tener en cuenta el origen de éstos y sin
diferenciar unos datos de otros.
• TCP es muy sensible a retardos provocados por un fallo de transmisión en algún
mensaje TCP. Cuando esto ocurre, TCP no envía más datos del flujo de octetos
hasta que se confirma la entrega correcta del mensaje que se transmitió con
errores. La consecuencia de esto es que si se utiliza TCP para enviar mensajes
ISUP entre dos centrales de conmutación, y uno de los mensajes,
correspondiente a una llamada concreta, se transmite con errores, todos los
- 33 -
mensajes ISUP, correspondientes a todas las llamadas, tendrían que esperar

hasta que se retransmitiera correctamente el mensaje erróneo.
• La duración de algunos temporizadores (time-outs) definidos en el protocolo,
especialmente el de retransmisión, puede ocasionar retardos no aceptables en un
establecimiento de llamada.
• Un problema adicional de TCP es su relativa vulnerabilidad ante ataques de
negación de servicio, como los ataques por SYN5.
3.2 SCTP [RFC2960]
3.2.1 Características principales
Debido a los inconvenientes mencionados de TCP y UDP, el SIGTRAN definió el

protocolo SCTP, cuyas principales características son las siguientes:
• Es un protocolo punto a punto. Se establece intercambio de datos entre dos

extremos conocidos.
• Define tiempos de reintento (time-outs) mucho menores que los de TCP.
• Proporciona transporte fiable de datos de usuario, detectando y reparando los
datos erróneos o fuera de secuencia.
• Se adapta a la tasa de transferencia, disminuyendo la velocidad de envío de datos
en caso de congestión en la red.
• Permite definir en un mismo extremo SCTP en varios servidores físicos (multi-
homing). Un único extremo SCTP se puede definir en varias direcciones IP.
Hacia cada una de ellas se encaminan los mensajes de forma independiente, de
manera que si uno de los nodos físicos queda fuera de servicio, el resto de
comunicaciones no se ven afectadas.
5
Para iniciar una conexión TCP, un cliente envía un mensaje SYN a un servidor. El servidor le
envía un SYN ACK y espera un nuevo ACK de este último mensaje para establecer la conexión. El
ataque por SYN consiste en enviar a un servidor mensajes SYN con direcciones origen aleatorias, de
forma masiva. Como los ACKs de los SYN-ACKs no se reciben, se satura el buffer donde el protocolo
almacena los establecimientos de conexiones en curso, de forma que se colapsa el servidor y éste no
puede atender nuevas conexiones.
- 34 -
• Utiliza un procedimiento de inicialización basado en cookies, para evitar ataques

de negación de servicio tipo SYN.
• Permite compactar varios mensajes de señalización en un mismo mensaje SCTP.
• A su vez, permite fragmentar los mensajes de señalización, de forma que un
mismo mensaje se divida en varios mensajes SCTP.
• Está orientado a mensajes, y define tramas de datos estructurados, al contrario
que TCP, que transporta trenes de octetos no estructurados.
• Los datos se pueden dividir en múltiples trenes (streams), cada uno con un orden
de entrega de mensajes independiente.
Los dos últimos puntos son los que hacen que SCTP sea mucho más adecuado
para el transporte de señalización, aparte de la mayor protección frente a ataques de este
protocolo. La posibilidad de establecer múltiples trenes de datos (streams) entre dos
aplicaciones permite que exista un proceso de nivel de aplicación de SCTP que gestione
la señalización ISUP. Los mensajes asociados a una llamada se envían por un stream
concreto. Si un mensaje ISUP no se entrega correctamente y es necesario retransmitirlo,
el resto de streams no se ven afectados por el retardo (Ver Figura 8).
Llamada 1 Llamada 1 Llamada 1
Figura 8. Secuencia de mensajes ISUP transmitidos en varios streams de SCTP.
Si las llamadas ISUP se transmitieran mediante TCP, un fallo en un mensaje de

una llamada retrasaría la entrega de los mensajes del resto de llamadas
innecesariamente.
- 35 -
3.2.2 Funciones de SCTP
3.2.2.1 Establecimiento y liberación de Asociaciones
Una asociación SCTP es una relación de comunicación de mensajes entre dos

entidades SCTP (comunicación orientada a conexión). Las asociaciones SCTP se
establecen a petición del usuario de nivel superior de este protocolo.
Para proporcionar protección frente a ataques de denegación de servicio, se

emplea un protocolo de establecimiento de asociaciones en cuatro pasos, basado en
cookies [RFC2522].
3.2.2.2 Entrega ordenada dentro del Stream
Dentro del protocolo SCTP, se utiliza el término stream para referirse a una
secuencia de mensajes de usuario que debe entregarse al nivel superior de forma
ordenada.
El número de streams que se enviarán a través de una asociación se define en el

establecimiento de la misma, de forma negociada entre ambos extremos de la
comunicación. Los streams son unidireccionales, de forma que para una comunicación
bidireccional se deberán definir al menos dos streams en una asociación SCTP.
Los mensajes de usuario se asocian a streams determinados, de forma que el

extremo receptor SCTP entrega al nivel superior todos los mensajes de un mismo
stream en el mismo orden en que se enviaron. Sin embargo, no existen restricciones de
entrega ordenada entre mensajes de distintos streams de la misma asociación. De esta
forma, los mensajes de un stream se pueden seguir entregando aunque otro esté
bloqueado esperando el siguiente mensaje.
Adicionalmente, SCTP proporciona un mecanismo para no utilizar el servicio de

entrega ordenada de mensajes, de forma que los mensajes enviados mediante dicho
mecanismo se entregan al nivel superior del destino SCTP tan pronto como se reciben.
- 36 -
3.2.2.3 Fragmentación de los datos de usuario
SCTP posee mecanismos de fragmentación y re-ensamblado de mensajes de

usuario para adecuarlos al tamaño requerido por el nivel inferior (IP en el caso de SS7
sobre IP).
3.2.2.4 Control de entrega de mensajes
SCTP asigna un número de secuencia de transmisión (TSN) a cada mensaje de

datos de usuario, fragmentado o no. El TSN es independiente del stream por el que se
envía el mensaje. El extremo receptor envía acuses de recibo (ACK) de todos los TSNs
recibidos, aunque no lleguen de forma ordenada. De esta forma, la fiabilidad en la
entrega de los mensajes se mantiene funcionalmente separada de la entrega ordenada
dentro del stream.
Si al cabo de un cierto tiempo no se recibe un ACK de un mensaje, se retransmite,

aunque con condiciones determinadas por procedimientos de control de congestión
similares a los de TCP.
3.2.2.5 Formato de paquetes
Un paquete SCTP se compone de una cabecera de 24 octetos y una serie de

unidades de información, denominadas chunks. Estas unidades de información pueden
contener datos de usuario, o instrucciones de control del propio protocolo SCTP
(establecimiento y liberación de asociaciones, control de flujo, retransmisiones, etc).
Los chunks tienen estructura propia, y presentan una serie de campos, dependiendo del
tipo de chunk que sean.
En el ámbito de la planificación de una red SS7 sobre IP, el dato más relevante es
el tamaño de las cabeceras de los datos de usuario. La cabecera de un chunk de datos de
usuario mide 16 octetos, y pueden contener hasta 65520 octetos de información del
nivel superior. Esto significa que, en principio, cualquier mensaje de cualquier
operación MAP, ISUP o CAMEL cabe en un chunk de datos SCTP, incluyendo las
cabeceras de los protocolos de adaptación intermedios.
Además, SCTP permite transportar varios mensajes de usuario en un único

mensaje SCTP, mediante el uso de distintos chunks de datos dentro del mismo mensaje.
- 37 -
CABECERA COM ÚN 2 4 o c te to s
CABECERA CHUNK DATOS 1 6 o c te to s
D A T O S U S U A R IO S C T P H a s ta 6 5 5 2 0 o c te to s
Figura 9 . Formato paquete SCTP con datos de usuario
3.2.2.6 Validación de paquetes
Dentro de la cabecera común de SCTP se incluye un campo de verificación

obligatorio, aparte de otro campo de 32 bits con una suma de comprobación (checksum)
frente a errores. El valor del campo de verificación obligatorio lo decide el extremo de
la comunicación SCTP en el establecimiento de la asociación. De esta forma se
consigue más protección frente a comunicaciones con suplantación de identidad.
La suma de comprobación se calcula a partir de los datos de la propia cabecera

SCTP y la protege frente a errores en la comunicación.
3.2.2.7 Gestión de conexiones
El usuario del nivel SCTP puede manipular el conjunto de direcciones de

transporte destino de los mensajes. La función de gestión de conexiones de SCTP
escoge la dirección de transporte destino para cada paquete SCTP que se envía,
basándose en las instrucciones del usuario de SCTP y en las direcciones disponibles
alcanzables para ese destino SCTP.
- 38 -
En periodos de inactividad, la función de gestión de conexiones monitoriza la

disponibilidad de los extremos de la comunicación mediante mensajes de comprobación
(heartbeats). Si SCTP percibe algún extremo como inalcanzable informa a su usuario de
nivel superior.
En el establecimiento de la asociación, se define un camino primario para cada

extremo SCTP, que es el que se usa en el envío normal de paquetes.
En el extremo receptor, la gestión de conexiones se encarga de comprobar la

existencia de una asociación SCTP válida a la que pertenece cada paquete SCTP
recibido.
3.3 M2PA
M2PA son las siglas de MTP2-user peer-to-peer adaptation. Es un protocolo de

adaptación de MTP-3 (único usuario de MTP2) a SCTP, cuya característica
fundamental es que es entre pares. Esto quiere decir que un mensaje MTP3 enviado por
M2PA tiene como destino otra capa MTP3 de un nodo con capa M2PA, y todas las
órdenes, o primitivas, de MTP3 las procesa la capa M2PA del mismo nodo, tal como
haría MTP2. Además, dos pares M2PA se pueden intercambiar información de estado e
informar a sus respectivos niveles superiores.
Al ser un protocolo entre pares (peer-to-peer), es el protocolo más adecuado para

transportar señalización entre dos nodos SS7 puros (sin capa IP) a través de una red IP,
ya que reemplaza completamente la capa MTP2, y permite comunicación entre SGWs.
3.3.1 Funciones soportadas por M2PA

• Transmisión transparente entre pares con protocolo MTP3 a través de una conexión
sobre red IP. En el protocolo SS7, MTP2 envía tres tipos de mensajes: MSUs,
LSSUs y FISUs. El primero encapsula los datos provenientes de MTP3, y en M2PA
se corresponden con mensajes de usuario (User Data). El segundo transporta
información de estado entre dos pares MTP2. En M2PA esto se implementa
mediante los mensajes de estado de enlace (Link Status). Los mensajes FISU de
MTP2 sirven como asentimiento de mensajes y como comprobación de que un nodo
- 39 -
está activo. Ambas funciones las realiza SCTP, por lo que no se implementan en el
protocolo M2PA.
• El interfaz hacia MTP3 es el mismo que el interfaz MTP3/MTP2, pero M2PA
gestiona asociaciones SCTP en lugar de enlaces MTP2.
• Informa a MTP3 de los cambios de estado de forma asíncrona.
• M2PA procesa las primitivas que le indica la capa MTP3, de forma que reemplaza
completamente la capa MTP2.
La Figura 10 muestra un punto de señalización SS7 conectado a una pasarela de

señalización (SGW) con enlaces IP. El SGW actúa de hecho como un STP, ya que
necesita realizar reenvío de mensajes MTP3.
Nodo SS7 Nodo IP
TCAP TCAP
SGW
SCCP SCCP
MTP3 MTP3 MTP3
MTP2 MTP2 M2PA M2PA
SCTP SCTP
MTP1 MTP1
IP IP
Enlace SS7
Red
RedIP
IP
Figura 10. Pasarela de señalización IP con M2PA
La especificación MTP requiere que todos los nodos con capa MTP3, incluidos los
SGWs M2PA, cuenten con un punto de señalización.
Otro ejemplo de utilización de M2PA, diferenciador respecto a otros protocolos de

adaptación a SCTP, es el que se muestra en la Figura 11. En ella, se utiliza una red IP
para transportar señalización SS7 entre dos nodos SS7 no IP.
- 40 -
Nodo SS7 Nodo SS7
TCAP TCAP
SGW SGW
SCCP SCCP
MTP3 MTP3 MTP3 MTP3
MTP2 MTP2 M2PA M2PA MTP2 MTP2
SCTP SCTP
MTP1 MTP1 MTP1 MTP1
IP IP
Enlace SS7 Enlace SS7

Red
RedIP
IP
Figura 11. Transporte de mensajes entre nodos SS7 mediante SGWs M2PA.
3.3.2 Formato de los mensajes M2PA
Existen dos tipos de mensajes M2PA, los de usuario y los de estado de enlace.
Todos los mensajes M2PA cuentan con una cabecera común, de 16 octetos. Los
mensajes de usuario, de longitud variable, cuentan además con una cabecera de 2
octetos, en donde se incluye el campo SIO de MTP.
3.4 M2UA [RFC 3331]
M2UA son las siglas de MTP2 User Adaptation. El protocolo M2UA, al igual que
M2PA, adapta MTP3 a SCTP, e igualmente gestiona asociaciones SCTP en lugar de
enlaces MTP3. M2UA permite el intercambio de mensajes MTP3 entre dos puntos de
señalización IP o entre un punto de señalización IP y una pasarela IP-SS7.
M2UA es un protocolo entre pares en caso de que la comunicación comience y

termine en dos puntos de señalización IP, sin SGWs intermedios, tal como muestra la
Figura 12.
- 41 -
Nodo IP Nodo IP
TCAP TCAP
SCCP SCCP
MTP3 MTP3
M2UA M2UA
SCTP SCTP
IP IP
Red
RedIP
IP
Figura 12. Transporte de MTP3 entre dos puntos de señalización IP, mediante M2UA
Sin embargo, M2UA no es un protocolo entre pares si se implementa en una

pasarela de señalización. En ese caso, M2UA no procesa las órdenes (primitivas del
protocolo) que le llegan desde la capa superior (MTP3), sino que las envía tal cual hacia
un nodo remoto, mediante SCTP.
Como M2UA no procesa las primitivas de MTP3, sino que las reenvía, en caso de
que se utilice un SGW se debe entender este protocolo como un medio que comunica la
capa MTP3 de un nodo IP con la capa MTP2 de un SGW, tal como muestra la Figura
13. De esta forma, varios puntos de señalización IP con MTP3 sobre M2UA pueden
acceder a la red SS7 tradicional a través de los mismos enlaces MTP2 físicos.
Es importante tener en cuenta que, debido a la propia naturaleza del protocolo,

sólo puede existir un SGW M2UA en una misma comunicación MTP3, por lo que no se
puede utilizar para transportar mensajes MTP3 entre dos nodos SS7 puros a través de
una red IP. Si se utiliza M2UA, alguno de los extremos es un punto de señalización IP.
- 42 -
Nodo SS7 Nodo IP
TCAP TCAP
SGW
SCCP SCCP
MTP3 Traducción MTP3
MTP2 MTP2 M2UA M2UA
SCTP SCTP
MTP1 MTP1
IP IP
Enlace SS7
Red
RedIP
IP
Figura 13. Transporte de primitivas MTP3 hacia una capa MTP2 remota, mediante M2UA.
Lo que sí es posible es que existan varios SGWs con funcionalidad de STP, es

decir, con el protocolo MTP3. De esta forma, el SGW sería el fin de la comunicación
MTP3 vía M2UA, por lo que en realidad el esquema sería el descrito en la Figura 12,
siendo uno de los extremos un STP. Sin embargo, si se utilizan SGWs con capa MTP3,
es más recomendable utilizar M2PA, ya que es un protocolo diseñado para trabajar
como reemplazo de MTP2. Por otro lado, M2UA es más adecuado si no se quiere que
los SGWs dispongan de nuevos puntos de señalización SS7.
El principal inconveniente de M2UA es que no es un protocolo entre pares y

mantiene la capa MTP3. Por lo primero, no sirve para transportar tráfico entre nodos
SS7 tradicionales, y por lo segundo resulta menos eficiente que otros protocolos
SIGTRAN para puntos de señalización IP, como M3UA o SUA, ya que incluye las
cabeceras de MTP3. Sin embargo, para el caso de redes con muchos nodos con linksets
de señalización de larga distancia, puede que interese el transporte en IP pero sin
consumir dos puntos de señalización por nodo, o utilizar SGWs más simples y baratos.
En estos casos M2UA sería un protocolo de adaptación adecuado. Este tipo de redes se
da en países con separaciones entre ciudades mucho mayores que las de España, como
Brasil, Chile o EEUU.
- 43 -
3.5 M3UA [RFC 3332]
M3UA son las siglas de MTP3-User Adaptation. M3UA es un protocolo que

transporta mensajes procedentes de un usuario de MTP3 (ISUP, TUP o SCCP) a través
de una red SCTP/IP hasta un nodo remoto. De forma similar a M2UA, M3UA
simplemente transporta los mensajes hasta el destino, pero no realiza por sí mismo las
funciones de la capa MTP3. Esto significa que M3UA no dispone de tablas de
encaminamiento basadas en puntos de señalización, ni realiza ninguna otra función
propia de MTP3.
En general, M3UA se utilizará como medio de transporte de primitivas entre la

capa usuaria de MTP-3 (SCCP o ISUP) de un punto de señalización IP y la capa MTP3
de un SGW remoto, tal como muestra la Figura 14.
Nodo SS7 Nodo IP

SGW
TCAP TCAP
ISUP SCCP Traducción SCCP ISUP
MTP3 MTP3 M3UA M3UA
MTP2 MTP2 SCTP SCTP
MTP1 MTP1 IP IP
Enlace SS7
Red
RedIP
IP
Figura 14. Transporte con M3UA de primitivas ISUP o SCCP hacia una capa MTP3 remota.
Para el caso simplificado de comunicación entre dos puntos de señalización IP,

mostrado en la Figura 15, M3UA sí es capaz de encaminar los mensajes SCCP o ISUP
hasta su destino, ya que la red percibida por SCCP o ISUP se limita a una línea punto a
punto y no se necesitan encaminamientos MTP3.
- 44 -
Nodo IP Nodo IP
TCAP TCAP
ISUP SCCP SCCP ISUP
M3UA M3UA
SCTP SCTP
IP IP
Red
RedIP
IP
Figura 15. Comunicación punto a punto entre dos nodos IP mediante M3UA.
3.5.1 Representación mediante códigos de punto de

señalización
Tal como se ve en la Figura 14, es en los SGWs con M3UA donde reside la capa
MTP3 de los puntos de señalización IP. Los códigos de punto de señalización
(direcciones MTP3) de los nodos IP residirán, por tanto, en los SGWs mediante los que
accedan a la red SS7.
Un SGW puede albergar los niveles MTP3, y por tanto los códigos de punto de
señalización, de varios nodos IP. Los propios SGWs deben contar con código de punto
de señalización, pero éste se puede compartir con uno o con varios nodos IP.
Si un nodo IP accede a la red SS7 a través de dos SGWs M3UA (ver Figura 16),
es recomendable que a dicho nodo se acceda mediante un SPC distinto de los de los
SGWs. Así, desde el punto de vista de la red SS7, los SGWs serían STPs con “rutas”
hacia el SPC del nodo IP. De esta forma se pueden seguir utilizando los mecanismos
tradicionales de redundancia de acceso a la red SS7.
- 45 -
SGW
Red
RedIP
IP NODO
Red
Red redundante
redundante IP
SS7/TDM
SS7/TDM
SGW
Figura 16. Acceso a red SS7 a través de dos SGWs M3UA
Incluso en este caso, un segundo nodo IP podría compartir el mismo código de

punto de señalización, ya que M3UA puede discriminar el nodo destino mediante
distintos parámetros (ver apartado 3.5.2).
3.5.2 Routing Keys
La distribución de mensajes SS7 entre los SGWs y los nodos IP se decide en

función de lo que se conoce como routing keys. Un routing key es un conjunto de
parámetros SS7 en función de los cuales se decide el encaminamiento de un mensaje
desde un SGW hacia un nodo IP. Un routing key puede contener el OPC, DPC o SIO
presente en la cabecera de MTP3, y también puede incluir parámetros específicos de la
capa usuaria de MTP3, como el GT de SCCP o el CIC de ISUP. Cualquier combinación
es válida.
El protocolo M3UA asocia a cada routing key un identificador (routing context),

que sirve como índice de entrada a una tabla de encaminamiento de salida. La
definición de routing keys en un SGW debe permitir determinar el destino de todos los
mensajes SS7 recibidos por el nodo.
A diferencia de los protocolos SS7 tradicionales, distintos SGWs pueden

intercambiarse routing keys, de forma que la tabla de encaminamiento de los nodos
puede modificarse tanto estática como dinámicamente.
3.5.3 Redundancia
En el SGW, todos los mensajes MTP3 que cumplen un determinado routing key se
encaminan hacia el mismo “nodo IP”. Este nodo IP lógico puede estar implementado
mediante varios servidores físicos. Estos servidores pueden estar activos (procesan
tráfico), inutilizables por fallo, o en reserva.
- 46 -
El modelo de redundancia de servidores IP de M3UA es n+k, donde “n” es el

número de servidores activos y “k” el número de servidores de reserva, que pasarían a
modo activo en caso de fallo de alguno de los “n” servidores activos.
Existen tres modos de reparto de tráfico hacia servidores físicos activos

pertenecientes al mismo nodo IP lógico: reparto de carga (loadshare), difusión
(broadcast) o prioritario (override). En reparto de carga, cada servidor del nodo procesa
una parte del tráfico total del nodo. En difusión, todos los servidores procesan todo el
tráfico del nodo. Por último, en modo prioritario uno de los servidores asume todo el
tráfico del nodo, independientemente del resto.
3.5.4 Formato de los mensajes de datos de usuario
Los mensajes de transporte de datos de usuario de M3UA se componen de tres

campos opcionales y uno obligatorio. Los campos opcionales son: Apariencia de Red,
Routing Context, e identificador de correlación. El campo obligatorio corresponde con
los datos del protocolo, y en él se transporta el mensaje MTP3 entero, incluyendo la
cabecera de encaminamiento (OPC, DPC, SI, NI y SLS).
La estructura de un mensaje de datos de M3UA se muestra a continuación:
4 o c te to s
T ip o : A p . R e d L o n g = 4 o c te to s
A P A R I E N C IA D E R E D
O p c io n a l
T ip o : R o u t . C o n t x t L o n g = 4 o c te to s
R O U T IN G C O N T E X T
T ip o : D A T O S L o n g it u d
OPC
DPC
SI NI MP SLS
M e n s a je M T P
M E N S A J E U S U A R IO M T P
T ip o : C o r r e la c ió n L o n g = 4 o c te to s
O p c io n a l
ID E N T IF IC A D O R D E C O R R E L A C IÓ N
Figura 17. Estructura de los mensajes de datos de M3UA
- 47 -
Como puede observarse, la cabecera M3UA consta de 16 octetos obligatorios

sobre el mensaje SCCP o ISUP, y hasta 24 octetos más variables. Sin embargo, la
apariencia de red no se utiliza en redes con nodos dedicados, por lo que se puede
considerar, para cálculos de tráfico, que la cabecera M3UA añade 32 octetos al mensaje
SCCP o ISUP que transporta.
3.5.5 Utilización de M3UA
Como se ha visto, dado que M3UA transporta primitivas desde la capa ISUP o
SCCP de un nodo hasta la capa MTP3 de otro (típicamente un SGW), este protocolo
sólo puede utilizarse para conectar nodos con señalización IP a una red SS7. Por tanto,
no se puede utilizar M3UA para descargar tráfico SS7 entre dos nodos TDM a través de
red IP, a no ser que se utilicen SGWs con SCCP. Pero para esta aplicación es mucho
más adecuado utilizar SGWs con M2PA, por los motivos indicados en el apartado 3.3.
El 3GPP ha decidido utilizar este protocolo de adaptación en las siguientes

versiones de red UMTS, lo que hace que sea especialmente interesante utilizarlo para
adaptar nodos UMTS o GSM con señalización IP a la red de señalización de una red
GSM ya establecida de un operador con licencia GSM y UMTS. Esto permite, por
ejemplo, utilizar los mismos HLRs para usuarios UMTS y GSM.
3.6 SUA
SUA son las siglas de SCCP User Adaptatio Layer. Es un protocolo de adaptación
de los usuarios de SCCP (TCAP, RANAP, etc) a SCTP. SUA está orientado al
transporte de primitivas desde un nodo IP hasta un SGW en donde residiría el nivel
SCCP, de forma análoga a M2UA y M3UA, tal como muestra la Figura 18.
- 48 -
Nodo SS7 SGW Nodo IP
TCAP Traducción TCAP
SCCP SCCP
SUA SUA
MTP3 MTP3
MTP2 MTP2 SCTP SCTP
MTP1 MTP1 IP IP
Enlace SS7
Red
RedIP
IP
Figura 18. Transporte con SUA de primitivas TCAP hacia una capa SCCP remota
Adicionalmente, SUA permite comunicación extremo a extremo entre dos nodos

IP, debido a la simplicidad del caso punto a punto.
SUA ofrece los siguientes servicios:
• Transferencia de mensajes de usuarios de SCCP.

• Servicio orientado y no orientado a conexión de SCCP. Permite utilizar las cuatro
clases del protocolo SCCP
• Permite comunicación completa entre pares usuarios de SCCP.
• Permite reenvío de mensajes SCCP, e incluye la función de traducción de títulos
globales (GTT).
• Gestión de asociaciones SCTP entre un SGW y uno o varios nodos con señalización
IP.
• Trabaja con nodos de señalización IP distribuidos.
• Informa de los cambios de estado de manera asíncrona.
3.6.1 Encaminamiento de mensajes
Para determinar la asociación SCTP destino por la que enviar un mensaje de nivel
superior, SUA debe realizar una traducción de direcciones a asociaciones SCTP. SUA
seleccionará la asociación destino basándose en routing keys análogos a los de M3UA
(ver apartado 3.5.2).
- 49 -
Cada routing key se corresponde con un conjunto de puntos de señalización IP

destino, que pueden estar activos, en espera o inalcanzables. También de forma análoga
a M3UA, SUA puede enviar el tráfico hacia los servidores activos en reparto de carga
(loadshare), con difusión (broadcast) o a un nodo prioritario (override). Los routing
keys de SUA pueden contener cualquiera de los siguientes parámetros: OPC, DPC, SIO,
número de subsistema (SSN), identificador de transacción, direcciones IP y nombres de
máquina. Al igual que en M3UA, dos nodos con SUA se pueden intercambiar routing
keys, de forma que las tablas de encaminamiento se pueden establecer tanto estática
como dinámicamente.
SUA puede reenviar un mensaje hacia otro nodo con capa SUA que no sea el
destino final del mensaje, de forma análoga a la traducción de GTs de SCCP [UIT-T
Q.714], y así poder distribuir la resolución de direcciones de forma flexible y fácilmente
ampliable. Esto puede resultar muy interesante en redes de gran tamaño con muchos
nodos con señalización sobre SUA, para simplificar las tablas de traducción de
direcciones.
Un punto de señalización IP con SUA puede utilizar varios SGWs para enviar
mensajes hacia una red SS7. La elección del SGW concreto dependerá de la dirección
del nodo destino y del estado de los SGWs percibido desde el nodo IP, del mismo modo
que M3UA, aunque SUA deberá enviar todos los mensajes pertenecientes a la misma
transacción por el mismo SGW.
3.6.2 Utilización de SUA
La principal ventaja de SUA es que es la capa de adaptación que elimina más

capas de la red SS7, y por ello resulta más eficiente en cuanto al uso del ancho de banda
IP. Además, los nodos IP con SUA son más simples que los nodos con otras capas de
adaptación a SCTP, y por ello más baratos.
El inconveniente fundamental de SUA es que no puede transportar ISUP. Por ello,

para facilitar la interconexión entre operadores directamente en IP, el 3GPP ha optado
por la utilización de M3UA como protocolo estándar de señalización en el núcleo de red
UMTS, dejándose SUA como alternativa interna a cada red de adaptación para nodos de
tipo base de datos.
- 50 -
4
DISEÑO DE UNA RED
DE TRANSPORTE DE
SMS SOBRE IP
- 51 -
4.1 OBJETIVO DE DISEÑO
Se parte de una red de telefonía móvil GSM ejemplo, de cobertura nacional, con
10 millones de usuarios. Se pretende implementar una red de transporte de señalización
sobre IP cuyo objetivo inicial sea el transporte de todo el tráfico debido a SMSs de la
red ejemplo, pero teniendo en cuenta que en el futuro la red debe ser capaz de crecer
hasta poder cursar toda la señalización de la red GSM y de una red UMTS nueva, que
desde el principio accederá a la red SS7 mediante M3UA.
Disponer de una red de transporte de SMS sobre IP permite desarrollar de forma

rápida nuevos servicios basados en mensajería, además de descargar una parte del
tráfico de señalización de la red SS7 ya establecida.
Además, contar con una red de transporte de señalización sobre IP permite una
evolución más rápida de la red, tanto en nuevas plataformas de servicios como en
integración de nodos UMTS.
4.2 PRESENTACIÓN DEL CASO DE ESTUDIO
4.2.1 Distribución de usuarios
La distribución de los diez millones de usuarios por Comunidades Autónomas es

la que muestra la Tabla 2, y corresponde con la distribución de población de España
según el Censo Oficial, con fecha 1/11/2001 [INE].
- 52 -
Tabla 2. Distribución de usuarios.
Comunidad Autónoma % Usuarios Usuarios

Madrid (Comunidad de) 13,3% 1.327.719
Cataluña 15,5% 1.552.881
Andalucí a + Ceuta y Melilla 18,0% 1.801.232
Comunidad Valenciana 10,2% 1.019.105
Paí s Vasco 5,1% 509.846
Galicia 6,6% 659.989
Castilla y León 6,0% 601.379
Castilla-La Mancha 4,3% 430.999
Canarias 4,1% 414.831
Aragón + La Rioja 2,9% 294.808
Murcia (Región de) 2,9% 293.200
Asturias (Principado de) 2,6% 260.237
Extremadura 2,6% 259.136
Baleares (Islas) 2,1% 206.052
Navarra (Cdad. Foral de) 1,4% 136.075
Cantabria 1,3% 131.007
T OT AL NACIONAL 10.000.000
4.2.2 Distribución de MSCs con acceso radio
Se ha supuesto una red de MSCs distribuida de la siguiente manera: en Madrid y

País Vasco, zonas con alta densidad de población, existe una MSC por cada 150.000
usuarios, debido a la fuerte carga de procesador que provoca la alta movilidad entre
áreas de servicio de MSCs de los usuarios. En Cataluña, existe una MSC por cada
200.000 usuarios, dada la alta densidad de población de Barcelona y la costa,
combinada con áreas menos pobladas en el interior. En el resto de España se ha
supuesto una MSC cada 300.000 usuarios.
Con los criterios antes indicados, se obtiene la distribución de MSCs en la red.
- 53 -
Tabla 3. Distribución de MSCs con acceso radio
Comunidad Autónoma Usuarios Usuarios por MSC MSCs

Madrid (Comunidad de) 1.327.719 150.000 9
Cataluña 1.552.881 200.000 8
Andalucí a + Ceuta y Melilla 1.801.232 300.000 7
Comunidad Valenciana 1.019.105 300.000 4
Paí s Vasco 509.846 150.000 4
Galicia 659.989 300.000 3
Castilla y León 601.379 300.000 3
Castilla-La Mancha 430.999 300.000 2
Canarias 414.831 300.000 2
Aragón + La Rioja 294.808 300.000 1
Murcia (Región de) 293.200 300.000 1
Asturias (Principado de) 260.237 300.000 1
Extremadura 259.136 300.000 1
Baleares (Islas) 206.052 300.000 1
Navarra (Cdad. Foral de) 136.075 300.000 1
Cantabria 131.007 300.000 1
T OT AL NACIONAL 10.000.000 204.000 49
4.2.3 Red de tránsito
Se ha supuesto una organización jerárquica de la red de MSCs, en cuatro áreas de

conmutación, tal como se muestra en la Figura 19.
Figura 19. Distribución geográfica de MSCs de acceso y áreas de servicio.
- 54 -
Todas las MSCs de un área de conmutación cuentan con rutas de voz hacia dos
centrales de tránsito. Estas centrales son GMSCs pero no utilizan el VLR, ya que no
disponen de conexión con ninguna BSC. La interconexión de voz con otros operadores
se efectúa desde las centrales de tránsito, y por ello desde estas GMSCs se realizan
consultas a los HLRs (mensajes SRI).
La Figura 20 muestra el esquema de la estructura jerárquica de la red GSM de

estudio.
BSC
BSCBSC
BTS
BTS . MSC
.
. STP
MSC MSC
.
BSC . MSC
BSC . STP
BTS BSC
BTS MSC
Acceso Tránsito Red SS7
Red de Acceso Radio Núcleo de Red

Enlaces de voz
Figura 20. Estructura jerárquica del caso de estudio.
Las ocho MSCs de tránsito están completamente malladas entre sí con rutas de
voz.
- 55 -
STP STP
Norte
MSC MSC
STP MSC MSC STP
Centro Este
STP MSC MSC STP
MSC MSC
Sur
STP STP
Figura 21. Red de tránsito de voz del caso de estudio.
La distribución de usuarios por área de conmutación es la que muestra la Tabla 4.
Tabla 4. Distribución de usuarios por área de conmutación.
Comunidad Autónoma Área MSCs Usuarios

Madrid (Comunidad de) CENTRO 9 1.327.719
Castilla-La Mancha CENTRO 2 430.999
T OT AL CENT RO 11 1.758.718
Cataluña ESTE 8 1.552.881
Comunidad Valenciana ESTE 4 1.019.105
Aragón + La Rioja ESTE 1 294.808
Baleares (Islas) ESTE 1 206.052
T OT AL EST E 14 3.072.846
Paí s Vasco NORTE 4 509.846
Galicia NORTE 3 659.989
Castilla y León NORTE 3 601.379
Asturias (Principado de) NORTE 1 260.237
Navarra (Cdad. Foral de) NORTE 1 136.075
Cantabria NORTE 1 131.007
T OT AL NORT E 13 2.298.532
Andalucí a + Ceuta y Melilla SUR 7 1.801.232
Canarias SUR 2 414.831
Murcia (Región de) SUR 1 293.200
Extremadura SUR 1 259.136
T OT AL SUR 11 2.768.399
- 56 -
4.2.4 Red de señalización
Tal como se observa en la Figura 21, existe un STP en cada emplazamiento con
MSC de tránsito. La red SS7 de partida del caso de estudio consta de cuatro dobletes de
STPs, uno por cada área de conmutación (ver Figura 19). Los STPs sólo cuentan con
conexión física directa con la MSC de tránsito de su mismo emplazamiento, aunque
cuentan con linksets hacia todos los STPs de la red y todas las MSCs de su área de
conmutación.
4.2.4.1 Conexión de las MSCs a los STPs
Las MSCs de acceso cuentan con un linkset hacia cada STP de su área geográfica.
Para implementar estos linksets se utilizan canales de las rutas de voz que las unen con
las MSCs de tránsito, tal como muestra la Figura 22.
STP
MSC
MSC
MSC
STP
Acceso Transmisión directa

Tránsito
Figura 22. Implementación de los linksets de las MSCs de acceso.
Para el caso de los linksets de las propias MSCs de tránsito, la estructura es

similar, salvo que uno de los linksets es directo hacia el STP situado en su mismo
emplazamiento.
4.2.4.2 Enlaces entre STPs
Los linksets que forman la malla de STPs se implementan de forma análoga a los
de las MSCs, utilizando canales de la malla de la red de tránsito de voz, tal como
muestra la Figura 23.
- 57 -
MSC MSC
STP STP
STP STP
MSC MSC
Transmisión directa
Figura 23. Implementación de los linksets entre STPs
Mediante este esquema, se consigue aprovechar el gran número de puertos TDM

de las MSCs de tránsito, que sirven como concentradores de canales de 64 kbps, además
de reducir el número de E1s dedicados a señalización en la red. Así se aprovechan al
máximo todos los recursos.
En la red que se plantea, todas las MSCs y todos los STPs son del mismo
fabricante y se basan en la misma plataforma. Esta plataforma se supone que se
implementa con hardware redundante, de forma que su fiabilidad es muy alta. La
probabilidad de que la MSC en donde hace tránsito un STP falle es la misma que la de
que el propio STP falle, y es muy baja. La probabilidad combinada de fallo de
cualquiera de los dos será el doble, pero igualmente aceptable.
Más allá de la MSC de tránsito, los linksets no cuentan con ningún punto en
común. Se puede comprobar que el único nodo que, ante un fallo en un único elemento,
puede perder sus dos linksets hacia un doblete de STPs “A” es otro STP de otro doblete
“B” por fallo del propio STP o de la MSC de tránsito de su propio emplazamiento. Aún
así, el doblete “B” se compone de dos STPs, por lo que aún existiría otro camino a
través del STP pareja del nodo caído.
Por tanto, la concentración de todos los enlaces hacia un STP en una MSC de
tránsito no añade falibilidad a la red, ya que los STPs se disponen en dobletes de nodos
capaces de cursar de forma individual todo el tráfico ofrecido a la pareja.
- 58 -
4.2.4.3 Conexión de los HLRs a los STPs
La red ejemplo utiliza un HLR por cada 700.000 usuarios. De esta forma, para
10.000.000 de usuarios se necesitarían 14 HLRs completos. Existirá, por tanto, un HLR
adicional para poder definir nuevos usuarios. En total, la red contará con 15 HLRs
“activos”.
En el caso de estudio, no se implementa redundancia automática en los HLRs. En

su lugar, se dispone de un HLR de respaldo en caso de caída de uno activo. En dicho
HLR se cargarían manualmente los datos de los usuarios del HLR caído.
Los HLRs disponen de linksets hacia los ocho STPs de la red de señalización,
debido al alto tráfico de señalización de dichos nodos. Dada a la importancia de los
HLRs, y su relativa debilidad, por no disponer de redundancia, se prefiere implementar
estos enlaces de señalización mediante tramas directas entre los HLRs y las MSCs de
tránsito que sirven como concentradores de canales de señalización hacia los STPs. Esta
estructura se muestra en la Figura 24.
- 59 -
STP STP
Norte
MSC MSC
STP STP
MSC MSC
Centro HLR Este
MSC MSC
STP STP
MSC MSC
Sur
STP STP Enlace SS7
Figura 24. Conexión de los HLRs a la red SS7 en el caso de estudio.
4.2.4.4 Interconexión de señalización hacia otras redes
Los dobletes de STPs del Centro y del Este cuentan con linksets de interconexión
con los otros operadores nacionales móviles y con aquellos operadores de telefonía fija
con señalización cuasi-asociada. Además, estos cuatro STPs cuentan con código de
punto de señalización internacional (ISPC) y con linksets directos hacia la red MTP
internacional.
Los dobletes de interconexión realizan una traducción de títulos globales capaz de

encaminar todos los mensajes SCCP hacia todas las redes con las que se tiene acuerdo
de roaming o acuerdo de interconexión SMS nacional.
La implementación de los linksets se realiza, o bien utilizando canales de las rutas

de interconexión de voz, o bien mediante tramas específicas para señalización entre las
MSCs de tránsito y la red de otro operador.
- 60 -
4.2.5 Portabilidad de numeración móvil
En España, los operadores de telefonía móvil están obligados a permitir la

portabilidad de numeración. Esto significa que se debe permitir que un usuario de una
red pueda utilizar un número de teléfono (MSISDN) perteneciente a un rango
originalmente otorgado a otro operador.
Para encaminar las llamadas de voz hacia otros operadores móviles nacionales, no
basta con conocer el rango de numeración dado por los tres primeros dígitos del número
destino (por ejemplo: 609 – Movistar, 637 – Vodafone, etc.), ya que el usuario no tiene
por qué pertenecer al operador al que se otorgó ese rango. Por ello, cada operador de
telefonía móvil debe contar con una base de datos de usuarios, para determinar el
operador al que pertenece actualmente el usuario destino de la llamada.
La consulta a la base de datos de numeración se puede efectuar de dos maneras:

disparando una consulta de red inteligente, o mediante la técnica denominada Signalling
Relay Function (Función de reenvío de señalización).
El primer método dispara una consulta de red inteligente para todas las llamadas
terminadas en un rango de numeración móvil nacional. La respuesta contendrá el
operador destino. Este método añade una gran carga de señalización a la red, ya que por
cada llamada terminada en móvil se debe efectuar una consulta a un SCP. Además, las
consultas de Red Inteligente suponen un aumento notable en la carga del procesador de
las MSCs.
El método de reenvío de señalización consiste en modificar los encaminamientos

de los mensajes SRI (Send Routing Information), de forma que, en lugar de enviarse
directamente a los HLRs, se envían a un nodo intermedio. Este nodo intermedio analiza
el MSISDN enviado en el mensaje SRI, y si éste pertenece a la propia red, entonces
reenvía el mensaje hacia el HLR correspondiente. Si pertenece a otra, el nodo
intermedio envía a la MSC origen de la llamada la información de encaminamiento
hacia el operador al que pertenece actualmente el MSISDN destino.
- 61 -
Este método añade carga de señalización a la red, ya que se deben enviar mensajes
SRI para todas las numeraciones móviles, no sólo para la numeración propia. Sin
embargo, la carga introducida es menor que la del método por red inteligente, ya que en
el caso de llamadas terminadas en usuarios propios no portados a otra red, no se
introduce ninguna carga adicional.
En la red ejemplo, se utiliza el método de reenvío de señalización, y la aplicación

de consulta a la base de datos de numeración portada se implementa en todos los STPs
de la red, ya que todos los mensajes SRI deben pasar por ellos de igual manera.
4.2.6 Tráfico de SMS
La distribución de mensajes cortos originados por usuarios es la que refleja la

Tabla 5, en términos relativos, y la Tabla 6, en términos absolutos.
Tabla 5. Número de SMS por usuario, día y edad
Edades 10 a 19 20 a 40 40 a 64 65 en adelante
Distrib. Usuarios 30% 40% 27% 3%
SMS/usuario y día 2,0 1,0 0,2 0,0
% Prepago 100% 60% 60% 70%
Tabla 6. Total SMS originados por día y segmento de usuarios.
Edades 10 a 19 20 a 40 40 a 64 65+ Total

Usuarios 3.000.000 4.000.000 2.700.000 300.000 10.000.000
Usuarios prepago 3.000.000 2.400.000 1.620.000 210.000 7.230.000
SMS/día 6.000.000 4.000.000 540.000 0 10.540.000
SMS prepago/día 6.000.000 2.400.000 324.000 0 8.724.000
El tráfico total debido a SMS cursado durante la hora cargada es aproximadamente

la décima parte del tráfico total cursado durante el día. Durante la hora cargada, se
asume un perfil plano igual al tráfico medio durante esa hora.
Con el perfil de tráfico anterior, se puede calcular el número de SMS originados

por segundo en hora cargada dividiendo el número total de SMSs cursados al día entre
10 y entre 3600.
- 62 -
En término medio, la mitad de los SMS originados en hora cargada en la red

terminan en la propia red, y la otra mitad en otras redes. Además, el número de
mensajes cortos enviados hacia otras redes es aproximadamente igual al número de
mensajes cortos recibidos de otras redes. Estas proporciones se mantienen para cada
MSC. Es decir, cada MSC recibe un número de SMS terminados igual al de SMS
originados, proviniendo la mitad de ellos de otras redes.
4.2.7 SMSCs
La red ejemplo cuenta con dos SMSCs idénticos, ambos con capacidad de cursar
300 SMS/s, y ambos se pueden ampliar con señalizadores SIGTRAN.
La mitad de las MSCs de la red envían los SMSs originados por sus usuarios hacia
uno de los dos SMSCs en primera opción, o al otro en caso de fallo del primero.
Existen, por tanto, dos grupos de MSCs en la red de ejemplo, según el SMSC al que
envían los SMSs originados en primera opción.
La Tabla 7 muestra el tráfico en hora cargada debido a SMSs originados en cada

MSC, y el SMSC al que envía los SMSs cada MSC.
Tabla 7. Tráfico SMS por CCAA y SMSC destino.
Comunidad Autónoma Usuarios MSCs SMS/dí a por MSC SMS/s por MSC SMS/s CCAA SMSC
Madrid (Comunidad de) 1.327.719 9 155.000 4,3 38,9 A
Cataluña 1.552.881 8 205.000 5,7 45,5 B
Andalucí a + Ceuta y Melilla 1.801.232 7 271.000 7,5 52,7 A
Comunidad Valenciana 1.019.105 4 269.000 7,5 29,8 B
Paí s Vasco 509.846 4 134.000 3,7 14,9 B
Galicia 659.989 3 232.000 6,4 19,3 A
Castilla y León 601.379 3 211.000 5,9 17,6 A
Castilla-La Mancha 430.999 2 227.000 6,3 12,6 B
Canarias 414.831 2 219.000 6,1 12,1 B
Aragón + La Rioja 294.808 1 311.000 8,6 8,6 B
Murcia (Región de) 293.200 1 309.000 8,6 8,6 B
Asturias (Principado de) 260.237 1 274.000 7,6 7,6 A
Extremadura 259.136 1 273.000 7,6 7,6 A
Baleares (Islas) 206.052 1 217.000 6,0 6,0 B
Navarra (Cdad. Foral de) 136.075 1 143.000 4,0 4,0 B
Cantabria 131.007 1 138.000 3,8 3,8 A
T OT AL SMSC A 25 148 51%
T OT AL SMSC B 24 142 49%
T OT AL NACIONAL 10.000.000 49 290
- 63 -
Se ha supuesto una distribución uniforme de edades por Comunidades

Autónomas, por lo que los SMS diarios originados por MSC se obtienen multiplicando
el número de usuarios por MSC por el número medio de SMSs originados por usuario.
A partir de los datos mostrados en la Tabla 6 se deduce fácilmente que el número medio
global de SMS originados por usuario y día es 0,98.
4.2.8 Distribución de nodos por emplazamiento
En la red ejemplo, la utilización de emplazamientos para albergar nodos se ha

realizado teniendo en cuenta dos criterios. El primero indica que por seguridad, en el
mismo emplazamiento no debe haber más de tres MSCs, tres HLRs o un STP. El
segundo criterio consiste en contar con MSC de acceso tan cerca como sea posible de
los nodos de acceso radio (BSCs), lo que lleva a necesitar al menos un emplazamiento
por comunidad autónoma.
Los emplazamientos de la red de ejemplo, y la distribución de nodos de núcleo de

red en ellos, se indica en la Tabla 8.
Tabla 8. Emplazamientos y distribución de nodos de núcleo de red.
Área Comunidad Autónoma Emplazamiento MSC T ransito ST P MSC Acceso HLR SMSC T IPO
Madrid-1 1 1 2 2 1 T1
Madrid-2 1 1 2 2 0 T2
Madrid (Comunidad de)
CENTRO Madrid-3 0 0 3 0 0 A
Madrid-4 0 0 2 0 0 A
Castilla-La Mancha T oledo-1 0 0 2 0 0 A
Barcelona-1 1 1 2 2 1 T1
Barcelona-2 1 1 2 2 0 T2
Cataluña
Barcelona-3 0 0 2 0 0 A
T arragona-1 0 0 2 0 0 A
ESTE
Valencia-1 0 0 2 0 0 A
Comunidad Valenciana
Valencia-2 0 0 2 0 0 A
Aragón + La Rioja Zaragoza-1 0 0 1 0 0 A
Baleares (Islas) Palma de Mallorca-1 0 0 1 0 0 A
Bilbao-1 1 1 2 2 0 T2
Paí s Vasco
Bilbao-2 1 1 2 2 0 T2
NORTE Galicia Coruña-1 0 0 3 0 0 A
Castilla y León León-1 0 0 3 0 0 A
Cantabria+ Asturias + Navarra Santander-1 0 0 3 0 0 A
Sevilla-1 1 1 2 2 0 T2
Andalucí a + Ceuta y Melilla Sevilla-2 1 1 2 1 0 T2
Málaga-1 0 0 3 0 0 A
SUR
Canarias T enerife-1 0 0 2 0 0 A
Murcia (Región de) Murcia-1 0 0 1 0 0 A
Extremadura Cáceres-1 0 0 1 0 0 A
- 64 -
Como puede verse, en función de los nodos de conmutación que albergan, existen
tres tipos de emplazamientos:
• Tipo T1. Emplazamientos con MSCs de acceso, MSC de tránsito, STP, HLR y
SMSC.
• Tipo T2. Emplazamientos con MSCs de acceso, MSC de tránsito, STP y HLR.
• Tipo A. Emplazamientos únicamente con MSCs de acceso.
4.3 RED SIGTRAN NECESARIA
4.3.1 Nodos ampliables con señalizadores SIGTRAN
La red de partida cuenta con MSCs, STPs, SCPs y HLRs basados en la misma
plataforma hardware, y se les puede añadir una ampliación de hardware con la cual
pueden enviar señalización M3UA. El fabricante ha decidido utilizar señalización IP
basada en M3UA para facilitar la convergencia de sus nodos con las normas del 3GPP
sobre la red UMTS.
Los SMSCs de la red ejemplo, como se menciona en el apartado 4.2.7, también se

pueden ampliar con señalizadores SIGTRAN, tanto con M3UA como con SUA.
4.3.2 Alternativas de implementación
Una primera idea de implementación de una red de descarga de señalización de

SMS sobre IP consistiría en extender una red IP a la que accedieran todas las MSCs y
todos los SMSCs. Sin embargo, tal como se observa en el apartado 2.4, también existe
tráfico debido a SMSs entre SMSCs y HLRs (mensaje SRIfSM de consulta para
determinar la MSC destino del mensaje), por lo que los HLRs también deberán acceder
a la red IP de transporte de tráfico SMS.
Además, en el apartado 4.2.5 se indica que en los STPs de la red ejemplo se

realiza la consulta a la base de datos de portabilidad, por lo que, o bien los propios STPs
acceden a la red IP, o bien se traslada la funcionalidad SRF a las MSCs o HLRs.
- 65 -
Se utilizará el protocolo de adaptación M3UA, ya que es el único que el fabricante

de los nodos de conmutación de la red ejemplo ha implementado. El fabricante ha
decidido esto motivado por la normalización de los protocolos de control de UMTS, en
donde se recomienda utilizar M3UA como protocolo de adaptación de señalización SS7
sobre SCTP.
Sería posible ampliar todas las MSCs, todos los HLRs, y los dos SMSCs con
señalizadores M3UA. De esta forma, sería necesario realizar la siguiente inversión:
• 49 ampliaciones M3UA en MSCs.

• 15 ampliaciones M3UA en HLRs.
• 2 ampliaciones M3UA en SMSCs.
En total, 66 ampliaciones con equipamiento M3UA.
Además, es muy importante tener en cuenta que, en la red ejemplo, los enlaces de
señalización entre MSCs de acceso y STPs se implementan sobre canales pertenecientes
a las tramas dedicadas al transporte de voz entre MSCs de acceso y MSCs de tránsito.
Con esta estructura, la reducción del tráfico en estos enlaces no va a repercutir en una
reducción del coste de la transmisión entre emplazamientos. Es más, podría ocurrir que
no existiera ancho de banda IP disponible entre dos emplazamientos y que hubiera que
contratar más capacidad en caso de desviar tráfico SS7 hacia una red IP.
Si en lugar de ampliar todas las MSCs, se centraliza el acceso a la red IP en los

STPs, convirtiéndolos en SGWs, se reduce fuertemente la inversión necesaria en
equipo, con el mismo coste en transmisión que en el caso anterior. En este caso, sería
necesario realizar la siguiente inversión:
• 15 ampliaciones M3UA en HLRs.

• 8 ampliaciones M3UA en STPs.
• 2 ampliaciones M3UA en SMSCs.
En total, 25 ampliaciones con equipamiento M3UA.
Teniendo en cuenta que la red IP ejemplo parte de cero, esta opción es la que
resulta más adecuada. Además, las consultas a la base de datos de portabilidad,
residente en los STPs, se seguiría realizando de la misma manera.
- 66 -
En cuanto a los HLRs de la red ejemplo, son los únicos nodos que cuentan con
tramas E1 dedicadas a señalización. En este caso, sí es adecuado ampliar todos los
HLRs con señalizadores M3UA. En esta primera fase se rebajaría una pequeña parte del
tráfico de estos nodos, pero sobre todo quedarían preparados para que, en fases
posteriores de desarrollo de la red SIGTRAN de la red ejemplo, se convirtieran en
nodos de acceso único IP, lo que facilita su integración desde el principio en una futura
red UMTS.
4.3.3 Arquitectura de la red SIGTRAN objetivo
Teniendo en cuenta la arquitectura de la red ejemplo, la red SIGTRAN inicial se

basa en lo siguiente:
• Conversión de los STPs a STP/SGWs-M3UA.

• El acceso de las MSCs a la red SIGTRAN se realizará a través de los STP/SGWs.
• Los HLRs se convierten en nodos duales, tanto nativos IP como nativos SS7.
• Los SMSCs pasan a ser nodos con acceso exclusivo a través de IP.
Aunque el tráfico SMS no es tan esencial como el resto del tráfico de control de la
red, para permitir la evolución hacia una red SS7 completamente transportada sobre IP,
se decide partir desde el principio de una red SIGTRAN implementada sobre dos redes
de transporte IP físicamente separadas, cuyos únicos nodos comunes son los nodos
usuarios de ambas redes. De esta forma se sigue el esquema de transporte de
señalización sin puntos únicos de fallo utilizado en las redes SS7 tradicionales.
El esquema general de la red SIGTRAN se resume en los siguientes puntos:
• Los SGWs se configuran en parejas idénticas, denominadas dobletes.

• Todos los nodos SS7 que accedan a la red SIGTRAN lo harán a través de al menos
un doblete de SGWs, de forma que en caso de fallo de uno de los SGWs, todo el
tráfico se puede entregar a través del otro. De igual manera, todos los nodos
SIGTRAN accederán a los nodos SS7 utilizando al menos un doblete de SGWs, de
forma que en caso de fallo de uno de los SGWs, todo el tráfico se puede entregar a
través del otro.
• Se establecen dos redes IP de transporte, denominadas “Azul” y “Roja”. Dichas
redes IP no tienen ningún punto en común, ni equipos ni medios de transmisión.
- 67 -
• Cada SGW de un doblete se conecta a una, y sólo a una, red IP de transporte

distinta. De esta forma, cuatro SGWs se conectarán la red “Azul” y los otros cuatro
a la red “Roja”.
• Los nodos SIGTRAN nativos (SMSCs y HLRs en esta primera fase) se conectarán
tanto a la red IP “Azul” como a la red IP “Roja”.
STP STP
SGW SGW
STP
STP
Red
Red IP
IP SGW
SGW
STP Red
Red IP
IP
STP
SGW SGW
STP STP
SGW SGW
Figura 25. Conexión de los SGWs a las redes IP de transporte.
SMSC
STP
Red
Red IP
IP
IP
SGW
MSC
HLR
STP Red
Red IP
IP
SGW
Figura 26. Conexión de MSC, SMSC y HLR a las redes IP de transporte.
En cada emplazamiento que albergue nodos con señalización SIGTRAN se

establecerán dos VLANes, una perteneciente a la red “Azul” y la otra perteneciente a la
red “Roja”. Cada VLAN accederá al resto de emplazamientos a través de un router
diferente. Por tanto, existirá en cada uno de estos emplazamientos una pareja de routers,
uno perteneciente a la red “Azul” y otro perteneciente a la red “Roja”.
- 68 -
4.3.4 Tráfico IP en SGWs
Según la arquitectura de esta red ejemplo, y teniendo en cuenta que únicamente se

cursará el tráfico de señalización debido al servicio de SMS, el tráfico IP que cursan los
SGWs hacia y desde la red SIGTRAN es la suma de los siguientes componentes:
• Mensajes Forward Short Message (Originado en Móvil), desde las MSCs hasta los
SMSCs.
• Mensajes Forward Short Message (Originado en Móvil) acknowledgement,
confirmación del mensaje anterior, desde los SMSCs hasta las MSCs.
• Mensajes Forward Short Message (Terminado en Móvil), desde los SMSCs de la
red hasta las MSCs, tanto las de la red propia como las de otros operadores. Después
del STP/SGW, los mensajes hacia MSCs de otros operadores se enviarán por la
interconexión correspondiente.
• Mensajes Forward Short Message (Terminado en Móvil) acknowledgement,
confirmación de entrega desde las MSCs hasta los SMSCs de la propia red. Los
mensajes hacia los SMSCs de otros operadores no se cursarán por la red IP, sino que
se enviarán directamente a la interconexión de señalización correspondiente.
• Mensajes Send Routing Info for Short Message, preguntas desde el SMSC acerca de
la MSC en la que se encuentra el usuario destino del SMS.
• Mensajes Send Routing Info for Short Message response, respuestas de los HLRs a
la pregunta anterior, que incluyen la dirección SCCP de la MSC en la que el usuario
destino está acampado.
- 69 -
K FSM-MO
AC
MO SRIfSM
SMSC
M-
FS STP
Red
Red IP
IP FSM-MT ACK IP
SGW
FSM-MT
SR
MSC IfS
M
STP Red
Red IP
IP
SRIfSM ACK
HLR
SGW
FSM-MO (+ACK) : 1 x SMS-MO en MSC

FSM-MT (+ACK) : 1 x SMS-MO en MSC
Otros
Otros SRIfSM (SMSC->SGW): 1 x SMS-MT
operadores
operadores SRIfSM (SGW->HLR): 1 x SMS-MT en MSC
SRIfSM-ACK (INTX->SGW->SMSC): 1 x SMS-INTX-MT
Figura 27. Mensajes MAP cursados en el interfaz IP en los SGWs
Debe tenerse en cuenta que la carga de tráfico en el interfaz IP del SGW (interfaz
Ethernet) se compone tanto de los mensajes hacia la red IP como de los mensajes desde
la red IP.
Para calcular el tráfico en el interfaz IP, debe computarse el tamaño de las

cabeceras de los protocolos sobre los que se transportan los mensajes MAP citados
anteriormente. Estos son TCAP, SCCP, M3UA, SCTP, IP y finalmente Ethernet [IEEE
802]. Los tamaños de las cabeceras de los protocolos se detallan en la Tabla 9.
Tabla 9. Tamaños de las cabeceras de los protocolos.
Protocolo Tamaño en octetos de la cabecera

SCCP 25
M3UA 32 (ver apartado 3.5.4)
SCTP 40 (ver apartado 3.2.2.5)
IP 20 [RFC791]
Ethernet 26 [IEEE802.3]
Total 143 octetos = 1144 bits
- 70 -
Por otro lado, aparte del tamaño de las cabeceras desde SCCP hay que tener en
cuenta, evidentemente, el tamaño de los mensajes intercambiados en cada envío de
SMS, hasta nivel TCAP. En el caso de los mensajes Forward Short Message, su tamaño
depende del texto que envíe cada usuario, pero se estima un tamaño medio de texto de
usuario de 100 caracteres.
Los tamaños de los mensajes intercambiados se muestran en la Tabla 10, tanto a

nivel TCAP como a nivel Ethernet.
Tabla 10. Tamaño de los mensajes que cursan los SGWs
Mensaje T amaño hasta T CAP (octetos) T amaño en interfaz fí sico (octetos)

FSM 145 288
FSM-ack 15 158
SRIfSM 39 182
SRIfSM ack 44 187
Las MSCs envían sus mensajes destinados en los SMSC-IP en reparto de carga a
los dos STP/SGW con los que tiene enlaces SS7 directos (SGWs cabecera de área). De
acuerdo con la Tabla 7, cada doblete de SGW cursará en hora cargada un determinado
número de SMS/s originados en usuarios de la red ejemplo, mostrado en la Tabla 11.
Tabla 11. Total SMS/s originados en MSCs cursados por cada SGW
Área SMS/s SGW /Área (SMS/s) / SGW

Centro 51,5 2 25,7
Este 90,0 2 45,0
Norte 67,3 2 33,6
Sur 81,1 2 40,5
En la Tabla 12 se muestra el número total de mensajes que cursa cada SGW, y el

tráfico total en el interfaz SIGTRAN de dichos nodos.
Tabla 12. Cálculo del tráfico de cada SGW hacia la red SIGTRAN
SGW (SMS MO) / s (SMS MT ) /s FSM/s FSM-ack/s SRIfSM/s SRIfSM ack /s T ráfico total en SGW (kbps)
Madrid-1 25,7 49,1 74,8 74,8 54,3 36,2 400
Madrid-2 25,7 49,1 74,8 74,8 54,3 36,2 400
Barcelona-1 45,0 58,7 103,7 103,7 54,3 36,2 500
Barcelona-2 45,0 58,7 103,7 103,7 54,3 36,2 500
Bilbao-1 33,6 16,8 50,5 50,5 54,3 0,0 260
Bilbao-2 33,6 16,8 50,5 50,5 54,3 0,0 260
Sevilla-1 40,5 20,3 60,8 60,8 54,3 0,0 300
Sevilla-2 40,5 20,3 60,8 60,8 54,3 0,0 300
El tráfico en el SGW se ha calculado tal como se muestra en la Ecuación 1.
- 71 -
Ecuación 1. Tráfico total en los SGW
Trafico total en SGW = ( N º SMS MO s + N º SMS MT s ) × [Tamaño( FSM ) + Tamaño( FSM ack ) ] +
N º SMS MO / s
× Tamaño( SRIfSM ) +
N º SGW
N º SMS MO / s Nº total SMS originado y terminado en red propia
× × Tamaño( SRIfSM ) +
N º SGW Nº total SMS MO
N º SMS Entrantes desde interconexion / s
× Tamaño( SRIfSM resp )
N º SGW con interconexion
Donde,
• Tráfico total en SGW es el tráfico en hora cargada en la interfaz Ethernet de cada

SGW de la red.
• Nº SMS MO/s es la frecuencia de mensajes cortos originados en los móviles
acampados en las MSCs pertenecientes al área geográfica del que es cabecera el
SGW sobre el que se calcula el tráfico en su interfaz Ethernet. Cada uno de estos
mensajes se entrega a un SMSC-IP, y después se reenvía desde el SMSC-IP hacia el
destino correspondiente, por lo que de nuevo se cursa a través de los SGW hacia la
MSC destino (propia o de otro operador). Un SMS originado en un área geográfica
no tiene por qué terminar en esa misma área, por lo que puede entrar en la red
SIGTRAN por un doblete de SGW y salir de ella por otro distinto. Sin embargo, se
estima que en media por cada doblete de SGW entran tantos SMSs hacia la red
SIGTRAN como mensajes SMS salen de ella hacia la red SS7 tradicional. Los
SMSCs entregarán los SMSs terminados en otros operadores en reparto de carga a
los cuatro STP/SGWs con interconexión.
• En la red ejemplo los SMSs-MO se reparten al 50% entre mensajes SMS terminados
en otro operador y mensajes SMS terminados en la propia red.
• FSM es un mensaje MAP Forward Short Message, sobre el cual se transporta el
mensaje de texto del usuario.
• Los mensajes FSM provenientes de interconexión no se cursan a través de la red
SIGTRAN, sino que se entregan directamente desde la interconexión hasta la MSC
destino.
• FSM ack/s es un mensaje MAP de asentimiento de entrega de mensaje FSM.
• Los tamaños de los mensajes MAP son los que se muestran en la Tabla 10.
• Las frecuencias de mensajes SMS originados en cada área de conmutación son los
que se muestran en la Tabla 11.
- 72 -
• SRIfSM es un mensaje MAP Send Routing Info for Short Message originado en los
SMSCs. Estas consultas las debe analizar la funcionalidad de portabilidad de
numeración, implementada en los nodos STP/SGW, aunque terminan en los HLRs,
de forma que los SMSCs las pueden enviar indistintamente a cualquiera de los
SGW/STPs. Los SMSCs entregarán estos mensajes repartiendo uniformemente la
carga entre los ocho SGW. Por eso para calcular el número de estos mensajes que se
cursan a través de un SGW se calcula el número total de mensajes SRIfSM
generados en los SMSCs y se divide entre el número de SGWs (8).
• Una vez consultada la portabilidad, si el SMS termina en móvil de la red (50% de
los SRIfSM), los STP/SGW reenvían el mensaje SRIfSM al HLR correspondiente
por la red SIGTRAN. La otra mitad de SRIfSMs se entregarán por la interconexión
correspondiente.
• SRIfSM resp es el mensaje MAP respuesta al mensaje SRIfSM. Los mensajes entre
los HLRs y SMSCs de la red ejemplo se cursan directamente por la red SIGTRAN,
sin pasar por los STP/SGWs.
• La respuesta de los HLRs de otros operadores a los mensajes SRIfSM se cursarán
por los SGWs.
• Los STP/SGW por los que entran los mensajes de interconexión son los dobletes de
Madrid y Barcelona.
4.3.5 Tráfico IP en HLRs
En esta fase de despliegue de red SIGTRAN, los HLRs únicamente cursan

mensajes SRIfSM y SRIfSM-response desde y hacia la red IP, respectivamente. Los
mensajes SRIfSM los generan los SMSCs de la red propia. Los de otros operadores
hacia los HLRs de la red se cursan a través de la red SS7 tradicional. Además, debido a
la utilización de consulta de portabilidad de numeración móvil basada en los mensajes
SRIfSM, los originados por los SMSCs de la red deben enviarse a los STP/SGWs en
donde reside la base de datos de numeración portada, para decidir si el HLR destino del
mensaje es de la red propia o debe enviarse a interconexión. El intercambio de mensajes
MAP se representa en la Figura 28.
- 73 -
SRIfSM
SMSC
STP IP
SGW Red
Red IP
IP RIfS
Ma
ck
S
SR
I fSM
STP
Red
Red IP
IP HLR
SGW
SRIfSM (SMSC->SGW): 1 x SMS-MT

SRIfSM (SGW->HLR): 1 x SMS-MT en MSC
SRIfSM-ACK (HLR->SMSC): 1 x SMS-MT en MSC
Figura 28. Mensajes cursados por los HLRs hacia la red SIGTRAN
En la red ejemplo, la distribución geográfica de los usuarios definidos en un HLR

concreto es aproximadamente la misma que la del total de usuarios de la red. Por ello, y
dado que en la red ejemplo todos los HLRs tienen el mismo número de usuarios activos,
se puede suponer que el número de mensajes SRIfSM que llega a cada HLR, originados
en los SMSCs de la red, es igual para todos los HLRs de la red.
La Ecuación 2 muestra el cálculo realizado para obtener el tráfico en el interfaz IP

de los HLRs.
Ecuación 2. Tráfico en interfaz IP en cada HLR
Nº Total SMSs originados y terminados en red

Trafico en HLR = × [Tamaño( SRIfSM ) + Tamaño( SRIfSM response)]
Nº total de HLRs
Cada SMS originado y terminado en la red ejemplo genera un mensaje SRIfSM

que se cursa por la red SIGTRAN. Como se ha mencionado en el apartado 4.2.6 (Pág.
62), la mitad de los SMSs originados en la red terminan en la propia red. Con todo ello,
la Tabla 13 muestra el tráfico hacia red SIGTRAN de todos los HLRs:
- 74 -
Tabla 13. Cálculo del tráfico SIGTRAN en HLRs
HLR Cualquiera
(SMS MO) en red / s 289,8
(SMS MO y MT ) en red / s 144,9
SRIfSM/s hacia HLRs 144,9
Nº HLRs en red 15
SRIfSM/s por HLR 9,7
SRIfSM resp /s por HLR 9,7
T amaño SRIfSM (octetos en Ethernet) 182,0
T amaño SRIfSM response (octetos en Ethernet) 187,0
T ráfico total SIGT RAN en HLR (kbps) 30
El número total de SMSs por segundo originados en la red en hora cargada se ha

calculado sumando los valores de cada Comunidad Autónoma indicados en la Tabla 7
(Pág. 63), y el tamaño de los mensajes es el que se indica en la Tabla 10.
Como puede observarse, el tráfico IP en los HLRs es muy bajo si únicamente

cursan hacia la red SIGTRAN los mensajes SRIfSM y SRIfSM-response de los
mensajes originados y terminados en la propia red.
4.3.6 Tráfico IP en SMSCs
Todo el tráfico de los SMSCs de la red ejemplo se cursa a través de la red

SIGTRAN. Éste se compone de los siguientes mensajes:
• Mensajes Forward Short Message (Originado en Móvil), desde las MSCs hasta los
SMSCs IP. Existe uno por cada SMS originado en la red.
• Mensajes Forward Short Message (Originado en Móvil) acknowledgement,
confirmación del mensaje anterior, desde los SMSCs hasta las MSCs. Existe uno por
cada SMS originado en la red.
• Mensajes Forward Short Message (Terminado en Móvil), desde los SMSCs de la
red hasta las MSCs, tanto hasta las MSCs de la red propia como hasta las MSCs de
otros operadores. Después del STP/SGW, los mensajes hacia MSCs de otros
operadores se enviarán por la interconexión. Existe, por tanto, uno de estos mensajes
por cada SMS originado en la red.
• Mensajes Forward Short Message (Terminado en Móvil) acknowledgement,
confirmación de entrega desde las MSCs hasta los SMSCs de la propia red. Los
mensajes hacia los SMSCs de otros operadores no se cursarán por la red IP, sino que
- 75 -
se enviarán directamente a la interconexión de señalización. Existe uno de estos

mensajes por cada mensaje FSM-MT, por lo que de nuevo habrá tantos como
mensajes SMS originados en la red.
• Mensajes Send Routing Info for Short Message, preguntas desde el SMSC acerca de
la MSC en la que se encuentra el usuario destino del SMS. Estos mensajes pueden
terminar tanto en los HLRs de la propia red como en HLRs de otras redes. Por tanto,
existirá uno de estos mensajes por cada SMS originado en la red.
• Mensajes Send Routing Info for Short Message response, respuestas de los HLRs a
la pregunta anterior, que incluyen la dirección SCCP de la MSC en la que el usuario
está acampado. Existe uno por cada mensaje SRIfSM, y por tanto, uno por cada
SMS originado en la red.
K FSM-MO
AC
- MO SRIfSM
SMSC
M
FS STP
Red
Red IP
IP FSM-MT ACK IP
SGW
FSM-MT
MSC
STP SRIfSM ACK Red

Red IP
IP
SRIfSM ack HLR
SGW
FSM-MO (+ACK) : 1 x SMS-MO en MSC

FSM-MT (+ACK) : 1 x SMS-MO en MSC
Otros
Otros SRIfSM (SMSC->SGW): 1 x SMS-MT=1 x SMS-MO
operadores
operadores SRIfSM-ACK (SGW o HLR->SMSC): 1 x SMS-MT=1xSMS-MO
Figura 29. Mensajes MAP en la interfaz IP de los SMSCs
La Tabla 7 (Pág. 63) muestra el número total de SMS originados en las MSCs y el
total que se envía a cada SMSC de la red. Con ello, junto con lo expuesto en este mismo
apartado, se deduce el cálculo del tráfico en el interfaz IP de cada SMSC.
Tabla 14. Tráfico total en cada SMSC
SMSC (SMS MO) / s FSM/s FSM-ack/s SRIfSM/s SRIfSM ack /s T ráfico total en SMSC (kbps)
Madrid-1 147,6 295,2 295,2 147,6 147,6 1490
Barcelona-1 142,2 284,5 284,5 142,2 142,2 1430
En la Tabla 14 se ha calculado el tráfico total en SMSC de acuerdo con la

Ecuación 3.
- 76 -
Ecuación 3. Cálculo del tráfico en SMSC.
Trafico total SMSC=Nº SMS-MO × [ 2 × Tamaño( FSM ) + 2 × Tamaño( FSM -ack ) + Tamaño( SRIfSM ) + Tamaño( SRIfSM -resp )]
Los tamaños de los mensajes a nivel Ethernet son los indicados en la Tabla 10
(Pág. 71).
4.3.7 VLANes SIGTRAN
A continuación se muestran las VLANes SIGTRAN que se implementarán en

cada emplazamiento. En todos los emplazamientos se utilizarán dos switches diferentes,
uno para la VLAN “Roja” y otro para la VLAN “Azul”.
MADRID 1
MSC MSC
2 3
SMSC HLR HLR STP SS7/TDM

MSC
IP 1 2 1
SGW
SIGTRAN
ROUTER ROUTER
Red
RedIP
IP
Red
RedIP
IP
Figura 30. VLANes SIGTRAN en Madrid-1
- 77 -
MADRID 2
MSC MSC
2 3
STP SS7/TDM
HLR HLR MSC
1 2 SGW 1
SIGTRAN
ROUTER ROUTER
Red
RedIP
IP
Red
RedIP
IP
Figura 31. VLANes SIGTRAN en Madrid-2
BARCELONA 1
MSC MSC
2 3
SMSC HLR HLR STP SS7/TDM

MSC
IP 1 2 1
SGW
SIGTRAN
ROUTER ROUTER
Red
RedIP
IP
Red
RedIP
IP
Figura 32. VLANes SIGTRAN en Barcelona-1
- 78 -
BARCELONA 2
MSC MSC
2 3
STP SS7/TDM
HLR HLR MSC
1 2 SGW 1
SIGTRAN
ROUTER ROUTER
Red
RedIP
IP
Red
RedIP
IP
Figura 33. VLANes SIGTRAN Barcelona-2
BILBAO 1
MSC MSC
2 3
STP SS7/TDM
HLR HLR MSC
1 2 SGW 1
SIGTRAN
ROUTER ROUTER
Red
RedIP
IP
Red
RedIP
IP
Figura 34. VLANes SIGTRAN en Bilbao-1
- 79 -
BILBAO 2
MSC MSC
2 3
STP SS7/TDM
HLR HLR MSC
1 2 SGW 1
SIGTRAN
ROUTER ROUTER
Red
RedIP
IP
Red
RedIP
IP
Figura 35. VLANes SIGTRAN en Bilbao-2
SEVILLA 1
MSC MSC
2 3
STP SS7/TDM
HLR HLR MSC
1 2 SGW 1
SIGTRAN
ROUTER ROUTER
Red
RedIP
IP
Red
RedIP
IP
Figura 36. VLANes SIGTRAN en Sevilla-1
- 80 -
SEVILLA 2
MSC MSC
2 3
STP SS7/TDM
HLR MSC
1 SGW 1
SIGTRAN
ROUTER ROUTER
Red
RedIP
IP
Red
RedIP
IP
Figura 37. VLANes SIGTRAN en Sevilla-2
Se puede observar que cada STP/SGW de un doblete se conecta a una red IP

diferente.
4.3.8 Ancho de banda entre emplazamientos
A continuación se presentan tablas resumen de los tráficos intercambiados entre

cada nodo SIGTRAN y todos los demás. Estos tráficos se deducen de todo lo
comentado en los apartados 4.3.4, 4.3.5 y 4.3.6, junto con los datos de distribución de
mensajes SMS originados expuestos en la Tabla 7.
4.3.8.1 Tráfico originado en Madrid-1

Tabla 15. Tráfico originado en Madrid-1 SGW-1
SGW (SMS MO) / s

Madrid-1 25,7
Mensaje Nº mensajes/ s Tamaño mensaje (octetos) Nodo Destino Emplazamiento destino Tráfico hacia nodo (kbps)
FSM-MO 19,4 288 SMSC-Madrid 1 Madrid-1 (interno) 45
FSM-MO 6,3 288 SMSC-Barcelona 1 Barcelona-1 15
FSM-MT-a c k 28,2 158 SMSC-Madrid 1 Madrid-1 (interno) 36
FSM-MT-a c k 20,9 158 SMSC-Barcelona 1 Barcelona-1 26
SRIfSM 1,2 182 Madrid-1 HLR-1 Madrid-1 (interno) 2
SRIfSM 1,2 182 Resto HLRs Emplazamientos T1 y T2 2
SRIfSM a c k 2,4 187 Madrid-1 HLR-1 Madrid-1 (interno) 4
SRIfSM a c k 2,4 187 Resto HLRs Emplazamientos T1 y T2 4
- 81 -
Tabla 16. Tráfico originado en Madrid-1 SMSC-1
SMSC (SMS MT) / s

Madrid-1 147,6
Mensa je Nº mensa jes/ s Ta ma ño mensaje (octetos) Nodo Destino Empla za miento destino Trá fico ha cia nodo (kbps)
FSM-MT 28,2 288 SGW-1 Madrid-1 Madrid-1 (interno) 65
FSM-MT 28,2 288 SGW-1 Madrid-2 Madrid-2 65
FSM-MT 18,4 288 SGW-1 Barcelona-1 Barcelona-1 43
FSM-MT 12,1 288 SGW-1 Bilbao-1 Bilbao-1 28
FSM-MT 15,1 288 SGW-1 Sevilla-1 Sevilla-1 35
FSM-MO-a ck 19,4 158 SGW-1 Madrid-1 Madrid-1 (interno) 25
FSM-MO-a ck 19,4 158 SGW-1 Madrid-2 Madrid-2 25
FSM-MO-a ck 0,0 158 SGW-1 Barcelona-1 Barcelona-1 0
FSM-MO-a ck 0,0 158 SGW-1 Barcelona-2 Barcelona-2 0
FSM-MO-a ck 24,2 158 SGW-1 Bilbao-1 Bilbao-1 31
FSM-MO-a ck 24,2 158 SGW-1 Bilbao-2 Bilbao-2 31
FSM-MO-a ck 30,2 158 SGW-1 Sevilla-1 Sevilla-1 38
FSM-MO-a ck 30,2 158 SGW-1 Sevilla-2 Sevilla-2 38
SRIfSM 18,4 182 SGW-1 Madrid-1 Madrid-1 (interno) 27
SRIfSM 18,4 182 Resto de SGWs Emplazamientos T1 y T2 27
Tabla 17. Tráfico originado en Madrid-1 HLR-1 y HLR-2
HLRs (SRIfSM) / s
Madrid-1 HLR-1 9,7
Mensaje Nº mensajes/ s Tamaño mensaje (octetos) Nodo Destino Emplaza miento destino Tráfico hacia nodo (kbps)
SRIfSM ack 4,9 187 SMSC-Madrid 1 Madrid-1 (interno) 7
SRIfSM ack 4,7 187 SMSC-Barcelona 1 Barcelona-1 7
HLRs (SRIfSM) / s
Madrid-1 HLR-2 9,7
Mensaje Nº mensajes/ s Tamaño mensaje (octetos) Nodo Destino Emplaza miento destino Tráfico hacia nodo (kbps)
SRIfSM ack 4,9 187 SMSC-Madrid 1 Madrid-1 (interno) 7
Agregando, se obtiene el tráfico entre Madrid-1 y el resto de emplazamientos con

red SIGTRAN:
Tabla 18. Tráfico total originado en Madrid-1
Emplazamiento destino T ráfico originado en SGW (kbps) T ráfico originado en SMSC (kbps) T ráfico originado en HLRs (kbps) T otal (kbps)
Madrid-1 - - - -
Madrid-2 12 117 0 129
Barcelona-1 53 70 14 137
Barcelona-2 12 70 0 82
Bilbao-1 12 86 0 98
Bilbao-2 12 86 0 98
Sevilla-1 12 100 0 112
Sevilla-2 6 100 0 106
- 82 -
4.3.8.2 Tráfico originado en Madrid-2

Tabla 19. Tráfico originado en Madrid-2 SGW-1
SGW (SMS MO) / s

Madrid-2 25,7
Mensa je Nº mensajes/ s Ta ma ño mensaje (octetos) Nodo Destino Emplazamiento destino Tráfico ha cia nodo (kbps)
FSM-MO 19,4 288 SMSC-Madrid 1 Madrid-1 45
FSM-MT-a c k 28,2 158 SMSC-Madrid 1 Madrid-1 36
Tabla 20. Tráfico originado en Madrid-2 HLR-1 y HLR-2
HLRs (SRIfSM) / s
Madrid-2 HLR-1 9,7
SRIfSM a ck 4,9 187 SMSC-Madrid 1 Madrid-1 7
SRIfSM a ck 4,7 187 SMSC-Barcelona 1 Barcelona-1 7
HLRs (SRIfSM) / s
Madrid-2 HLR-2 9,7
Tabla 21. Tráfico total originado en Madrid-2
Emplazamiento destino T ráfico originado en SGW (kbps) T ráfico originado en HLRs (kbps) T ráfico total (kbps)
Madrid-1 93 14 107
Madrid-2 - - -
Barcelona-1 53 14 67
Barcelona-2 12 0 12
Bilbao-1 12 0 12
Bilbao-2 12 0 12
Sevilla-1 12 0 12
Sevilla-2 6 0 6
- 83 -
4.3.8.3 Tráfico originado en Barcelona-1

Tabla 22. Tráfico originado en Barcelona-1 SGW-1
SGW (SMS MO) / s

Barcelona-1 45,0
FSM-MO 45,0 288 SMSC-Barcelona 1 Barcelona-1 (interno) 104
FSM-MT-a c k 40,3 158 SMSC-Barcelona 1 Barcelona-1 (interno) 51
SRIfSM 1,2 182 Barcelona-1 HLR-1 Barcelona-1 (interno) 2
SRIfSM a c k 2,4 187 Barcelona-1 HLR-1 Barcelona-1 (interno) 4
Tabla 23. Tráfico originado en Barcelona-1 SMSC-1
SMSC (SMS MT) / s

Barcelona-1 142,2
FSM-MT 40,3 288 SGW-1 Barcelona-1 Barcelona-1 (interno) 93
FSM-MO-a c k 0,0 158 SGW-1 Madrid-1 Madrid-1 0
FSM-MO-a c k 0,0 158 SGW-1 Madrid-2 Madrid-2 0
FSM-MO-a c k 45,0 158 SGW-1 Barcelona-1 Barcelona-1 (interno) 57
FSM-MO-a c k 45,0 158 SGW-1 Barcelona-2 Barcelona-2 57
FSM-MO-a c k 9,5 158 SGW-1 Bilbao-1 Bilbao-1 12
FSM-MO-a c k 9,5 158 SGW-1 Bilbao-2 Bilbao-2 12
FSM-MO-a c k 10,4 158 SGW-1 Sevilla-1 Sevilla-1 13
FSM-MO-a c k 10,4 158 SGW-1 Sevilla-2 Sevilla-2 13
SRIfSM 17,8 182 SGW-1 Barcelona-1 Barcelona-1 (interno) 26
SRIfSM 17,8 182 Resto de SGWs Emplazamientos T1 y T2 26
Tabla 24. Tráfico originado en Barcelona-1 HLR-1 y HLR-2
HLRs (SRIfSM) / s
Barcelona -1 HLR-1 9,7
Mensa je Nº mensajes/ s Ta ma ño mensaje (octetos) Nodo Destino Empla za miento destino Trá fico hacia nodo (kbps)
SRIfSM a ck 4,7 187 SMSC-Barcelona 1 Barcelona-1 (interno) 7
HLRs (SRIfSM) / s
Barcelona -1 HLR-2 9,7
Mensa je Nº mensajes/ s Ta ma ño mensaje (octetos) Nodo Destino Empla za miento destino Trá fico hacia nodo (kbps)
SRIfSM a ck 4,7 187 SMSC-Barcelona 1 Barcelona-1 (interno) 7
- 84 -
Tabla 25. Tráfico total originado en Barcelona-1
Emplazamiento destino T ráfico originado en SGW (kbps) T ráfico originado en SMSC (kbps) T ráfico originado en HLRs (kbps) T otal (kbps)
Madrid-1 35 67 14 116
Madrid-2 12 67 0 79
Barcelona-1 - - - -
Barcelona-2 12 176 0 188
Bilbao-1 12 49 0 61
Bilbao-2 12 49 0 61
Sevilla-1 12 51 0 63
Sevilla-2 6 51 0 57
4.3.8.4 Tráfico originado en Barcelona-2

Tabla 26. Tráfico originado en Barcelona-2 SGW-1
SGW (SMS MO) / s

Ba rcelona -2 45,0
Mensa je Nº mensajes/ s Ta ma ño mensa je (octetos) Nodo Destino Empla za miento destino Trá fico ha cia nodo (kbps)
Tabla 27. Tráfico originado en Barcelona-2 HLR-1 y HLR-2
HLRs (SRIfSM) / s
Ba rcelona -2 HLR-1 9,7
Mensa je Nº mensa jes/ s Ta ma ño mensa je (octetos) Nodo Destino Empla za miento destino Tráfico ha cia nodo (kbps)
HLRs (SRIfSM) / s
Ba rcelona -2 HLR-2 9,7
Mensa je Nº mensa jes/ s Ta ma ño mensa je (octetos) Nodo Destino Empla za miento destino Tráfico ha cia nodo (kbps)
Tabla 28. Tráfico total originado en Barcelona-2
Madrid-1 35 14 49
Madrid-2 12 0 12
Barcelona-2 - - -
Bilbao-1 12 0 12
Bilbao-2 12 0 12
Sevilla-1 12 0 12
Sevilla-2 6 0 6
- 85 -
4.3.8.5 Tráfico originado en Bilbao-1

Tabla 29. Tráfico originado en Bilbao-1 SGW-1
SGW (SMS MO) / s

Bilbao-1 33,6
Mensa je Nº mensa jes/ s Ta ma ño mensa je (octetos) Nodo Destino Empla zamiento destino Tráfico ha cia nodo (kbps)
SRIfSM 1,2 182 Bilbao-1 HLR-1 Bilbao-1 (interno) 2
SRIfSM a c k 2,4 187 Bilbao-1 HLR-1 Bilbao-1 (interno) 4
Tabla 30. Tráfico originado en Bilbao-1 HLR-1 y HLR-2
HLRs (SRIfSM) / s
Bilba o-1 HLR-1 9,7
HLRs (SRIfSM) / s
Bilba o-1 HLR-2 9,7
Tabla 31. Tráfico total originado en Bilbao-1
Madrid-1 83 14 97
Madrid-2 12 0 12
Barcelona-2 12 0 12
Bilbao-1 - - -
Bilbao-2 12 0 12
Sevilla-1 12 0 12
Sevilla-2 6 0 6
- 86 -
4.3.8.6 Tráfico originado en Bilbao-2

Tabla 32. Tráfico originado en Bilbao-2 SGW-1
SGW (SMS MO) / s

Bilbao-2 33,6
Mensaje Nº mensajes/ s Tamaño mensa je (octetos) Nodo Destino Emplaza miento destino Trá fico hacia nodo (kbps)
Tabla 33. Tráfico originado en Bilbao-2 HLR-1 y HLR-2
HLRs (SRIfSM) / s
Bilbao-2 HLR-1 9,7
HLRs (SRIfSM) / s
Bilbao-2 HLR-2 9,7
Tabla 34. Tráfico total originado en Bilbao-2
Madrid-1 83 14 97
Madrid-2 12 0 12
Barcelona-2 12 0 12
Bilbao-1 12 0 12
Bilbao-2 - - -
Sevilla-1 12 0 12
Sevilla-2 6 0 6
- 87 -
4.3.8.7 Tráfico originado en Sevilla-1

Tabla 35. Tráfico originado en Sevilla-1 SGW-1
SGW (SMS MO) / s

Sevilla-1 40,5
SRIfSM 1,2 182 Sevilla-1 HLR-1 Sevilla-1 (interno) 2
SRIfSM a c k 2,4 187 Sevilla-1 HLR-1 Sevilla-1 (interno) 4
Tabla 36. Tráfico originado en Sevilla-1 HLR-1 y HLR-2
HLRs (SRIfSM) / s
Sevilla-1 HLR-1 9,7
Mensaje Nº mensajes/ s Ta maño mensa je (octetos) Nodo Destino Empla zamiento destino Tráfico hacia nodo (kbps)
HLRs (SRIfSM) / s
Sevilla-1 HLR-2 9,7
Mensaje Nº mensajes/ s Ta maño mensa je (octetos) Nodo Destino Empla zamiento destino Tráfico hacia nodo (kbps)
Tabla 37. Tráfico originado en Sevilla-1
Madrid-1 100 14 114
Madrid-2 12 0 12
Barcelona-2 12 0 12
Bilbao-1 12 0 12
Bilbao-2 12 0 12
Sevilla-1 - - -
Sevilla-2 6 0 6
- 88 -
4.3.8.8 Tráfico originado en Sevilla-2

Tabla 38. Tráfico originado en Sevilla-2 SGW-1
SGW (SMS MO) / s

Sevilla -2 40,5
Mensa je Nº mensajes/ s Ta ma ño mensa je (octetos) Nodo Destino Emplaza miento destino Tráfico hacia nodo (kbps)
Tabla 39. Tráfico originado en Sevilla-2 HLR-1
HLRs (SRIfSM) / s
Sevilla-2 HLR-1 9,7
SRIfSM ack 4,9 187 SMSC-Madrid 1 Madrid-1 7
Tabla 40. Tráfico total originado en Sevilla-2
Madrid-1 100 7 107
Madrid-2 12 0 12
Barcelona-1 43 7 50
Barcelona-2 12 0 12
Bilbao-1 12 0 12
Bilbao-2 12 0 12
Sevilla-1 12 0 12
Sevilla-2 - - -
4.3.8.9 Matriz de tráfico entre emplazamientos
Como resumen de todas las tablas de tráfico anteriores, la Tabla 41 muestra la

matriz de tráfico SIGTRAN (en kbps) entre los ocho emplazamientos con señalización
sobre IP. El tráfico que se muestra en ella es la necesidad de ancho de banda IP entre
emplazamientos en la hora cargada.
- 89 -
Tabla 41. Matriz de tráfico SIGTRAN entre los emplazamientos de la red
Origen
Madrid-1 Madrid-2 Barcelona-1 Barcelona-2 Bilbao-1 Bilbao-2 Sevilla-1 Sevilla-2
Madrid-1 - 107 116 49 97 97 114 107
Madrid-2 129 - 79 12 12 12 12 12
Barcelona-1 137 67 - 181 54 54 57 50
Destino
Barcelona-2 82 12 188 - 12 12 12 12
Bilbao-1 98 12 61 12 - 12 12 12
Bilbao-2 98 12 61 12 12 - 12 12
Sevilla-1 112 12 63 12 12 12 - 12
Sevilla-2 106 6 57 6 6 6 6 -
Se puede comprobar que el ancho de banda utilizado en hora cargada en la red IP

de transporte es relativamente bajo. En el tramo con más tráfico (entre Barcelona-1 y
Barcelona-2), no se superan los 200 kbps.
Debe tenerse en cuenta que la red IP de transporte debe contar capacidad

disponible entre emplazamientos en ambas redes de transporte, tanto en la “Red Azul”
como en la “Red Roja”, para poder cursar todo el tráfico indicado en la Tabla 41 en caso
de caída de algún elemento de alguna de las redes.
4.3.9 Plan de direccionamiento IP
Todos los nodos con señalización sobre IP deben contar con una dirección IP por
cada interfaz hacia la red SIGTRAN. En este caso, los HLRs y SMSCs contarán con un
interfaz hacia la red IP “Roja” y otro hacia la red IP “Azul”, mientras que los SGWs
únicamente contarán con un interfaz, bien sea hacia la red IP “Roja” o hacia la “Azul”.
Para facilitar los encaminamientos dentro de las redes IP de transporte, las

direcciones IP de los interfaces de los nodos se deben asignar de acuerdo con ciertos
criterios de agrupamiento.
El plan de direccionamiento IP depende del número de direcciones IP de la red y

de la localización de dichos interfaces IP. En el caso de la red ejemplo se utilizarán los
siguientes criterios para asignar direcciones IP:
• Existirá una primera división entre las direcciones IP de la red “Roja” y “Azul”, de
forma que el resto de divisiones se aplicarán igualmente a ambas redes. Se crearán
- 90 -
dos subrangos. En este caso se necesitarán cuatro bits para poder diferenciar los dos
rangos y contar además con una dirección de red y otra de difusión.
• La segunda división se realizará en función del emplazamiento en el que se sitúe el
nodo. Aunque en la primera fase sólo existen ocho emplazamientos con red IP, el
plan de direccionamiento debe realizarse de forma que sea aplicable en el futuro.
Por ello, puesto que la red ejemplo actualmente cuenta con 24 emplazamientos, se
estima que una división en 126 subrangos (en cada uno de los dos subrangos
anteriores) será suficiente incluso para el futuro de la red, en el que previsiblemente
se utilizarán más emplazamientos con nodos IP si se despliega una red UMTS. Para
ello, se necesitará utilizar 7 bits.
• Dentro de cada red SIGTRAN (“Roja” o “Azul”) y de cada emplazamiento, se
realizará una tercera división que distinga entre VLANes. En la red inicial propuesta
sólo existe una VLAN por “color” y emplazamiento. Sin embargo, en el futuro
puede que algún nodo, por falta de capacidad de transmisión en sus señalizadores
SIGTRAN, necesite conectarse a varias VLANes. En cualquier caso, un límite de
seis VLANes de un mismo “color” en un mismo emplazamiento no parece
fácilmente alcanzable ni tan siquiera a largo plazo. Se creará una tercera división en
6 VLANes, para lo que se necesitará utilizar ocho bits más.
• Una vez efectuadas estas tres divisiones, debe tenerse un rango de direcciones
disponible suficientemente grande. Se estima que 254 direcciones IP por cada
VLAN SIGTRAN es suficiente. Para ello se utilizarán 8 bits más.
La Figura 38 muestra visualmente las divisiones en el direccionamiento IP fijadas

en los puntos anteriores.
12 bits 2 bits 7 bits 3 bits 8 bits
Fijo red SIGTRAN Color Emplazamiento VLAN Nodo
Figura 38. Estructura de direccionamiento IP de la red SIGTRAN
Para toda la red SIGTRAN se utilizará direccionamiento IPv4 privado, por lo que
se tienen 32 bits como máximo. Dado que al menos se necesitan 19 bits, será necesario
contar con una parte de una clase A de las reservadas para direccionamiento privado. En
la red ejemplo se escoge utilizar una parte de la red 10.0.0.0/8.
- 91 -
La Tabla 42 muestra la asignación de subredes y direcciones IP para la red

SIGTRAN “Azul”, siguiendo la estructura descrita en este apartado, mientras que la
Tabla 43 muestra la misma asignación para la red SIGTRAN “Roja”.
Tabla 42. Direccionamiento IP Red SIGTRAN “Azul”
Subred / Interfaz octeto 1 octeto 2 octeto 3 octeto 4 IP Decimal /Máscara

Red SIGTRAN 00001010 0001CCEE EEEEEVVV XXXXXXXX 10.16.0.0 /12
Red "Azul" 00001010 000101EE EEEEEVVV XXXXXXXX 10.20.0.0 /14
Red "Azul", Madrid-1 00001010 00010100 00001VVV XXXXXXXX 10.20.8.0 /21
Red "Azul", Madrid-1, VLAN-1 00001010 00010100 00001001 XXXXXXXX 10.20.9.0 /24
Red "Azul", Madrid-1, VLAN-1, Router Azul 00001010 00010100 00001001 00000001 10.20.9.1
Red "Azul", Madrid-1, VLAN-1, SMSC-1 00001010 00010100 00001001 00000010 10.20.9.2
Red "Azul", Madrid-1, VLAN-1, HLR-1 00001010 00010100 00001001 00000011 10.20.9.3
Red "Azul", Madrid-2 00001010 00010100 00010VVV XXXXXXXX 10.20.16.0 /21
Red "Azul", Madrid-2, VLAN-1 00001010 00010100 00010001 XXXXXXXX 10.20.17.0 /24
Red "Azul", Madrid-2, VLAN-1, Router Azul 00001010 00010100 00010001 00000001 10.20.17.1
Red "Azul", Madrid-2, VLAN-1, SGW-1 00001010 00010100 00010001 00001111 10.20.17.15
Red "Azul", Barcelona-1 00001010 00010100 00011VVV XXXXXXXX 10.20.24.0 /21
Red "Azul", Barcelona-1, VLAN-1 00001010 00010100 00011001 XXXXXXXX 10.20.25.0 /24
Red "Azul", Barcelona-1, VLAN-1, Router Azul 00001010 00010100 00011001 00000001 10.20.25.1
Red "Azul", Barcelona-1, VLAN-1, SMSC-1 00001010 00010100 00011001 00000010 10.20.25.2
Red "Azul", Barcelona-1, VLAN-1, HLR-1 00001010 00010100 00011001 00000011 10.20.25.3
Red "Azul", Barcelona-1, VLAN-1, SGW-1 00001010 00010100 00011001 00001111 10.20.25.15
Red "Azul", Barcelona-2 00001010 00010100 00100VVV XXXXXXXX 10.20.32.0 /21
Red "Azul", Barcelona-2, VLAN-1 00001010 00010100 00100001 XXXXXXXX 10.20.33.0 /24
Red "Azul", Barcelona-2, VLAN-1, Router Azul 00001010 00010100 00100001 00000001 10.20.33.1
Red "Azul", Bilbao-1 00001010 00010100 00101VVV XXXXXXXX 10.20.40.0 /21
Red "Azul", Bilbao-1, VLAN-1 00001010 00010100 00101001 XXXXXXXX 10.20.41.0 /24
Red "Azul", Bilbao-1, VLAN-1, Router Azul 00001010 00010100 00101001 00000001 10.20.41.1
Red "Azul", Bilbao-1, VLAN-1, HLR-1 00001010 00010100 00101001 00000010 10.20.41.2
Red "Azul", Bilbao-1, VLAN-1, SGW-1 00001010 00010100 00101001 00001111 10.20.41.15
Red "Azul", Bilbao-2 00001010 00010100 00110VVV XXXXXXXX 10.20.48.0 /21
Red "Azul", Bilbao-2, VLAN-1 00001010 00010100 00110001 XXXXXXXX 10.20.49.0 /24
Red "Azul", Bilbao-2, VLAN-1, Router Azul 00001010 00010100 00110001 00000001 10.20.49.1
Red "Azul", Sevilla.1 00001010 00010100 00111VVV XXXXXXXX 10.20.56.0 /21
Red "Azul", Sevilla-1, VLAN-1 00001010 00010100 00111001 XXXXXXXX 10.20.57.0 /24
Red "Azul", Sevilla-1, VLAN-1, Router Azul 00001010 00010100 00111001 00000001 10.20.57.1
Red "Azul", Sevilla-1, VLAN-1, HLR-1 00001010 00010100 00111001 00000010 10.20.57.2
Red "Azul", Sevilla-1, VLAN-1, SGW-1 00001010 00010100 00111001 00001111 10.20.57.15
Red "Azul", Sevilla.2 00001010 00010100 01000VVV XXXXXXXX 10.20.64.0 /21
Red "Azul", Sevilla-2, VLAN-1 00001010 00010100 01000001 XXXXXXXX 10.20.65.0 /24
Red "Azul", Sevilla-2, VLAN-1, Router Azul 00001010 00010100 01000001 00000001 10.20.65.1
- 92 -
Tabla 43. Direccionamiento IP Red SIGTRAN “Roja”
Subred / Interfaz octeto 1 octeto 2 octeto 3 octeto 4 IP Decimal /Máscara

Red SIGTRAN 00001010 0001CCEE EEEEEVVV XXXXXXXX 10.16.0.0 /12
Red "Roja" 00001010 000110EE EEEEEVVV XXXXXXXX 10.24.0.0 /14
Red "Roja", Madrid-1 00001010 00011000 00001VVV XXXXXXXX 10.24.8.0 /21
Red "Roja", Madrid-1, VLAN-1 00001010 00011000 00001001 XXXXXXXX 10.24.9.0 /24
Red "Roja", Madrid-1, VLAN-1, Router Rojo 00001010 00011000 00001001 00000001 10.24.9.1
Red "Roja", Madrid-1, VLAN-1, SMSC-1 00001010 00011000 00001001 00000010 10.24.9.2
Red "Roja", Madrid-1, VLAN-1, HLR-1 00001010 00011000 00001001 00000011 10.24.9.3
Red "Roja", Madrid-1, VLAN-1, SGW-1 00001010 00011000 00001001 00001111 10.24.9.15
Red "Roja", Madrid-2 00001010 00011000 00010VVV XXXXXXXX 10.24.16.0 /21
Red "Roja", Madrid-2, VLAN-1 00001010 00011000 00010001 XXXXXXXX 10.24.17.0 /24
Red "Roja", Madrid-2, VLAN-1, Router Rojo 00001010 00011000 00010001 00000001 10.24.17.1
Red "Roja", Barcelona-1 00001010 00011000 00011VVV XXXXXXXX 10.24.24.0 /21
Red "Roja", Barcelona-1, VLAN-1 00001010 00011000 00011001 XXXXXXXX 10.24.25.0 /24
Red "Roja", Barcelona-1, VLAN-1, Router Rojo 00001010 00011000 00011001 00000001 10.24.25.1
Red "Roja", Barcelona-1, VLAN-1, SMSC-1 00001010 00011000 00011001 00000010 10.24.25.2
Red "Roja", Barcelona-1, VLAN-1, HLR-1 00001010 00011000 00011001 00000011 10.24.25.3
Red "Roja", Barcelona-2 00001010 00011000 00100VVV XXXXXXXX 10.24.32.0 /21
Red "Roja", Barcelona-2, VLAN-1 00001010 00011000 00100001 XXXXXXXX 10.24.33.0 /24
Red "Roja", Barcelona-2, VLAN-1, Router Rojo 00001010 00011000 00100001 00000001 10.24.33.1
Red "Roja", Barcelona-2, VLAN-1, SGW-1 00001010 00011000 00100001 00001111 10.24.33.15
Red "Roja", Bilbao-1 00001010 00011000 00101VVV XXXXXXXX 10.24.40.0 /21
Red "Roja", Bilbao-1, VLAN-1 00001010 00011000 00101001 XXXXXXXX 10.24.41.0 /24
Red "Roja", Bilbao-1, VLAN-1, Router Rojo 00001010 00011000 00101001 00000001 10.24.41.1
Red "Roja", Bilbao-1, VLAN-1, HLR-1 00001010 00011000 00101001 00000010 10.24.41.2
Red "Roja", Bilbao-2 00001010 00011000 00110VVV XXXXXXXX 10.24.48.0 /21
Red "Roja", Bilbao-2, VLAN-1 00001010 00011000 00110001 XXXXXXXX 10.24.49.0 /24
Red "Roja", Bilbao-2, VLAN-1, Router Rojo 00001010 00011000 00110001 00000001 10.24.49.1
Red "Roja", Bilbao-2, VLAN-1, SGW-1 00001010 00011000 00110001 00001111 10.24.49.15
Red "Roja", Sevilla.1 00001010 00011000 00111VVV XXXXXXXX 10.24.56.0 /21
Red "Roja", Sevilla-1, VLAN-1 00001010 00011000 00111001 XXXXXXXX 10.24.57.0 /24
Red "Roja", Sevilla-1, VLAN-1, Router Rojo 00001010 00011000 00111001 00000001 10.24.57.1
Red "Roja", Sevilla-1, VLAN-1, HLR-1 00001010 00011000 00111001 00000010 10.24.57.2
Red "Roja", Sevilla.2 00001010 00011000 01000VVV XXXXXXXX 10.24.64.0 /21
Red "Roja", Sevilla-2, VLAN-1 00001010 00011000 01000001 XXXXXXXX 10.24.65.0 /24
Red "Roja", Sevilla-2, VLAN-1, Router Rojo 00001010 00011000 01000001 00000001 10.24.65.1
Red "Roja", Sevilla-2, VLAN-1, SGW-1 00001010 00011000 01000001 00001111 10.24.65.15
En la asignación de direcciones IP a nodos, se han reservado las direcciones

X.X.X.1 para los interfaces de los Routers de cada VLAN, y las direcciones X.X.X.15
para los interfaces de los SGWs.
- 93 -
Además, los nodos con interfaces hacia las dos redes SIGTRAN utilizan para
ambos interfaces direcciones IP iguales, excepto en los bits que determinan el “color”
de la subred SIGTRAN. De esta forma, por ejemplo, el SMSC-1 de Madrid-1 utiliza la
dirección IP 10.20.9.2 en su interfaz hacia la VLAN-1 Azul y la 10.24.9.2 en su interfaz
hacia la red Roja.
4.3.10 Configuración en MSCs
4.3.10.1 SCCP
Las MSCs de la red están configuradas de forma que a la hora de formar el

mensaje MAP Forward Short Message, Mobile Originated, modifican el centro de
servicio configurado por el usuario en su terminal, si es un usuario propio (no un
usuario de otra red en “roaming”). Independientemente de lo que configure el usuario,
la MSC enviará el mensaje SCCP utilizando como GT destino uno de los dos definidos
en los SMSCs. Después, las MSCs de la red realizarán la traducción de los títulos
globales de los SMSCs a punto de señalización, de acuerdo con la Tabla 44.
Tabla 44. Traducción de GTs en MSCs
Comunidad Autónoma MSC origen Dir. Centro Servicio GT SCCP DPC Primario DPC Secundario
Castilla-La Mancha Cualquiera GT-Pareja SMSCs, Primario Barna Barcelona-1 SMSC Madrid-1 SMSC
Madrid (Comunidad de) Cualquiera GT-Pareja SMSCs, Primario Madrid Madrid-1 SMSC Barcelona-1 SMSC
Aragón + La Rioja Cualquiera GT-Pareja SMSCs, Primario Barna Barcelona-1 SMSC Madrid-1 SMSC
Baleares (Islas) Cualquiera GT-Pareja SMSCs, Primario Barna Barcelona-1 SMSC Madrid-1 SMSC
Cataluña Cualquiera GT-Pareja SMSCs, Primario Barna Barcelona-1 SMSC Madrid-1 SMSC
Comunidad Valenciana Cualquiera GT-Pareja SMSCs, Primario Barna Barcelona-1 SMSC Madrid-1 SMSC
Asturias (Principado de) Cualquiera GT-Pareja SMSCs, Primario Madrid Madrid-1 SMSC Barcelona-1 SMSC
Cantabria Cualquiera GT-Pareja SMSCs, Primario Madrid Madrid-1 SMSC Barcelona-1 SMSC
Castilla y León Cualquiera GT-Pareja SMSCs, Primario Madrid Madrid-1 SMSC Barcelona-1 SMSC
Galicia Cualquiera GT-Pareja SMSCs, Primario Madrid Madrid-1 SMSC Barcelona-1 SMSC
Navarra (Cdad. Foral de) Cualquiera GT-Pareja SMSCs, Primario Barna Barcelona-1 SMSC Madrid-1 SMSC
Paí s Vasco Cualquiera GT-Pareja SMSCs, Primario Barna Barcelona-1 SMSC Madrid-1 SMSC
Andalucí a + Ceuta y Melilla Cualquiera GT-Pareja SMSCs, Primario Madrid Madrid-1 SMSC Barcelona-1 SMSC
Canarias Cualquiera GT-Pareja SMSCs, Primario Barna Barcelona-1 SMSC Madrid-1 SMSC
Extremadura Cualquiera GT-Pareja SMSCs, Primario Madrid Madrid-1 SMSC Barcelona-1 SMSC
Murcia (Región de) Cualquiera GT-Pareja SMSCs, Primario Barna Barcelona-1 SMSC Madrid-1 SMSC
Como puede comprobarse, se definen dos GTs en ambos SMSCs, pero cada uno
con un SPC distinto. En caso de fallo del SMSC al que pertenece el DPC al que se
traduce en primera opción el GT, el protocolo SCCP de las MSCs realizará la
traducción al DPC secundario, que pertenece al otro SMSC.
- 94 -
Los usuarios deberán configurar en su terminal una dirección de centro de servicio

(GT de un SMSC) para poder utilizar el servicio SMS estando en roaming en otra red.
Este GT estará definido en ambos SMSCs, pero en los STPs de interconexión de Madrid
se traducirá en primera opción al SMSC de Madrid-1 y en segunda opción al SMSC de
Barcelona-1, y viceversa en los STPs de interconexión de Barcelona.
4.3.10.2 Encaminamientos MTP
Una vez que las MSCs han efectuado la traducción del GT de los SMSCs al punto
de señalización del SMSC concreto al que se envía el mensaje, se debe elegir el STP al
que la MSC envía el mensaje MTP, de acuerdo con la Tabla 45.
- 95 -
Tabla 45. Encaminamientos MTP3 en las MSCs
BIT SLS usado

Valor BIT
MSC origen DPC linkset salida para reparto de
reparto carga
carga (0 a 3)
Madrid-1 STP/SGW 3 0
Madrid-1 SMSC
Mitad MSCs Madrid-2 STP/SGW 3 1
Centro Madrid-1 STP/SGW 3 0
Barcelona-1 SMSC
Madrid-1 SMSC
Mitad MSCs Madrid-2 STP/SGW 3 0
Centro Madrid-1 STP/SGW 3 1
Barcelona-1 SMSC
Barcelona-1 STP/SGW 3 0
Madrid-1 SMSC
Mitad MSCs Barcelona-2 STP/SGW 3 1
Este Barcelona-1 STP/SGW 3 0
Barcelona-1 SMSC
Madrid-1 SMSC
Mitad MSCs Barcelona-2 STP/SGW 3 0
Este Barcelona-1 STP/SGW 3 1
Barcelona-1 SMSC
Bilbao-1 STP/SGW 3 0
Madrid-1 SMSC
Mitad MSCs Bilbao-2 STP/SGW 3 1
Norte Bilbao-1 STP/SGW 3 0
Barcelona-1 SMSC
Madrid-1 SMSC
Mitad MSCs Bilbao-2 STP/SGW 3 0
Norte Bilbao-1 STP/SGW 3 1
Barcelona-1 SMSC
Sevilla-1 STP/SGW 3 0
Madrid-1 SMSC
Mitad MSCs Sevilla-2 STP/SGW 3 1
Sur Sevilla-1 STP/SGW 3 0
Barcelona-1 SMSC
Madrid-1 SMSC
Mitad MSCs Sevilla-2 STP/SGW 3 0
Sur Sevilla-1 STP/SGW 3 1
Barcelona-1 SMSC
Se observa que se utiliza el valor del bit número 3 del campo SLS (el bit 0 es el
menos significativo, el bit 3 es el más significativo) para decidir a qué STP enviar el
mensaje MTP. Para que a cada STP/SGW lleguen mensajes con los valores del campo
SLS lo más distribuido posible, la mitad de las MSC de un área envía los mensajes con
el valor del bit de reparto igual a cero a un STP y la otra mitad al otro STP del doblete
del área.
- 96 -
4.3.11 Configuración en STP/SGWs
4.3.11.1 SCTP
Se definirá una asociación SCTP entre cada SGW y cada HLR y SMSCs. Puesto
que se utiliza M3UA, no existirá comunicación entre SGWs y, por tanto, no se definirán
asociaciones SCTP entre ellos.
En principio, bastaría con definir dos streams de datos dentro de cada asociación
entre nodos, uno para cada sentido de la comunicación. Sin embargo, para minimizar las
consecuencias de un fallo de transmisión a nivel SCTP, es conveniente disponer de
varios streams para cada sentido de comunicación, de forma que se bloquee el mínimo
número de comunicaciones en caso de retransmisión en un stream SCTP concreto. Si
únicamente se tiene un stream, y éste se bloquea por retransmisiones de mensajes, todas
las comunicaciones de la asociación entre nodos quedan bloqueadas. Si se tienen n
streams, y una traducción uniforme de transacciones de nivel superior a stream de
salida, en caso de bloqueo de un stream se bloquearán 1/n de las transacciones de la
asociación.
El número de streams que se va a utilizar depende de cómo elija el nivel superior

de SCTP qué stream utilizar en cada envío de datos. Por el mismo stream se enviarán
los mensajes pertenecientes a la misma transacción, ya que son los que se deben
entregar de forma ordenada. Dado que en este caso el nivel superior es M3UA, que a su
vez transporta únicamente SCCP, los parámetros con los que cuenta para decidir qué
stream utilizar son los códigos de punto de señalización origen y destino (OPC y DPC),
el número de subsistema (SSN) y el valor del campo de selección de enlace (SLS).
Puesto que en la red ejemplo cada nodo únicamente implementa un subsistema

(HLR, SMSC, SGW), y el valor del campo SLS puede variar desde 0 hasta 15, aunque
se definan más de 16 streams en una asociación SCTP que transporta SCCP sobre
M3UA entre dos nodos, no se van a utilizar más que 16, ya que M3UA no dispone de
más mecanismos, aparte del valor del campo SLS, para distinguir a qué transacciones de
nivel superior pertenece un mensaje concreto.
- 97 -
Por lo anterior, en cada SGW hacia los HLRs y SMSCs, se definirán 16 streams
de sentido saliente en cada asociación hacia otros nodos SIGTRAN, dedicados a tráfico
SCCP sobre M3UA.
En sentido entrante, tal como se verá en el apartado 4.3.12.1, se definirán 8

streams para transporte de datos en cada asociación, ya que el nivel M3UA de los HLRs
y SMSCs deberá utilizar, de forma análoga a MTP3, un bit del campo SLS para elegir a
través de qué SGW enviará los mensajes hacia un nodo de la red SS7. De otra forma, no
se garantizaría la entrega ordenada de los mensajes extremo a extremo. Todos los
mensajes MTP3 pertenecientes a la misma transacción de nivel superior deben enviarse
por el mismo camino, y por ello deben utilizar el mismo valor en el campo SLS.
En todas las asociaciones SCTP de la red se definirán, además, dos streams, uno
de sentido entrante y otro saliente, dedicado a transportar el tráfico de gestión generado
por el propio protocolo M3UA de los SGWs, SMSCs y HLRs. Para facilitar el
mantenimiento de la red, estos streams de gestión se identificaran en la red ejemplo
siempre como stream-0 en cada sentido de la asociación.
Con todo, en la Tabla 46 se muestra la definición de asociaciones SCTP en los

SGWs conectados a la “Red Azul”, y en la Tabla 47, las asociaciones SCTP en los
SGWs conectados a la “Red Roja”. Los identificadores de las asociaciones SCTP tienen
sentido local en cada SGW.
- 98 -
Tabla 46. Asociaciones SCTP en SGWs de la “Red Azul”
SGW Asociación SCT P Nodo destino Dirección IP destino Streams entrada Streams salida
1 Madrid-1 SMSC 10.20.9.2 8+1 16+1
2 Barcelona-1 SMSC 10.20.25.2 8+1 16+1
3 Madrid-1 HLR-1 10.20.9.3 8+1 16+1
4 Madrid-1 HLR-2 10.20.9.4 8+1 16+1
5 Madrid-2 HLR-1 10.20.17.2 8+1 16+1
6 Madrid-2 HLR-2 10.20.17.3 8+1 16+1
Madrid-2 SGW (10.20.17.15) 7 Barcelona-1 HLR-1 10.20.25.3 8+1 16+1
Barcelona-1 SGW (10.20.25.15) 8 Barcelona-1 HLR-2 10.20.25.4 8+1 16+1
Bilbao-1 SGW (10.20.41.15) 9 Barcelona-2 HLR-1 10.20.33.2 8+1 16+1
Sevilla-1 SGW (10.20.57.15) 10 Barcelona-2 HLR-2 10.20.33.3 8+1 16+1
11 Bilbao-1 HLR-1 10.20.41.2 8+1 16+1
12 Bilbao-1 HLR-2 10.20.41.3 8+1 16+1
13 Bilbao-2 HLR-1 10.20.49.2 8+1 16+1
14 Bilbao-2 HLR-2 10.20.49.3 8+1 16+1
15 Sevilla-1 HLR-1 10.20.57.2 8+1 16+1
16 Sevilla-1 HLR-2 10.20.57.3 8+1 16+1
17 Sevilla-2 HLR-1 10.20.65.2 8+1 16+1
Tabla 47. Asociaciones SCTP en SGWs de la “Red Roja”
SGW Asociación SCT P Nodo destino Dirección IP destino Streams entrada Streams salida
1 Madrid-1 SMSC 10.24.9.2 8+1 16+1
2 Barcelona-1 SMSC 10.24.25.2 8+1 16+1
3 Madrid-1 HLR-1 10.24.9.3 8+1 16+1
4 Madrid-1 HLR-2 10.24.9.4 8+1 16+1
5 Madrid-2 HLR-1 10.24.17.2 8+1 16+1
6 Madrid-2 HLR-2 10.24.17.3 8+1 16+1
Madrid-1 SGW (10.24.9.15) 7 Barcelona-1 HLR-1 10.24.25.3 8+1 16+1
Barcelona-2 SGW (10.24.33.15) 8 Barcelona-1 HLR-2 10.24.25.4 8+1 16+1
Bilbao-2 SGW (10.24.49.15) 9 Barcelona-2 HLR-1 10.24.33.2 8+1 16+1
Sevilla-2 SGW (10.24.65.15) 10 Barcelona-2 HLR-2 10.24.33.3 8+1 16+1
11 Bilbao-1 HLR-1 10.24.41.2 8+1 16+1
12 Bilbao-1 HLR-2 10.24.41.3 8+1 16+1
13 Bilbao-2 HLR-1 10.24.49.2 8+1 16+1
14 Bilbao-2 HLR-2 10.24.49.3 8+1 16+1
15 Sevilla-1 HLR-1 10.24.57.2 8+1 16+1
16 Sevilla-1 HLR-2 10.24.57.3 8+1 16+1
17 Sevilla-2 HLR-1 10.24.65.2 8+1 16+1
4.3.11.2 M3UA
En los SGWs se deben definir los encaminamientos de los mensajes entre el nivel
MTP3 del propio SGW y el nivel SCCP del nodo IP remoto. Para ello, el protocolo
M3UA en el SGW asocia mensajes MTP3 a asociaciones SCTP, que en el nodo destino
se entregan al nivel M3UA y después al nivel SCCP remoto.
- 99 -
Tal como se indica en el apartado 3.5.2, el protocolo M3UA encamina los

mensajes MTP3 provenientes de la red SS7 utilizando los denominados routing keys,
que son correspondencias entre parámetros de mensajes SS7 que se van a enviar (MTP3
en SGWs o SCCP en HLRs y SMSCs, en la red ejemplo) y asociaciones SCTP de
salida.
El protocolo M3UA permite definir varias asociaciones SCTP para entregar

mensajes a un mismo destino, pudiéndose entregar el tráfico tanto en reparto de carga
como con prioridad. Esto es útil si el mismo servicio está implementado sobre varios
servidores idénticos, o si un servidor cuenta con varios interfaces hacia la red IP.
En el caso de la red ejemplo, desde el punto de vista del nivel MTP3 de los SGWs,
los dos SMSCs de Madrid-1 y Barcelona-1 son servidores independientes. Además, se
evita expresamente la comunicación desde un interfaz IP de la “Red Azul” y de la “Red
Roja”. Por ello, se decide que sea el nivel SCCP de las MSCs el que se encargue de
decidir a cuál de los dos envía los mensajes, dado que estos mecanismos ya están
utilizándose en las MSCs de la red ejemplo y además este protocolo es el único que se
da extremo a extremo entre MSCs y SMSCs y HLRs.
La funcionalidad de envío a servidores redundantes a nivel M3UA se utilizará en

caso de que los nodos SMSCs o HLRs, individuales desde el punto de vista funcional de
MTP3, se implementen físicamente mediante plataformas hardware duplicadas.
Teniendo en cuenta lo anterior, bastará con definir como routing keys

correspondencias simples entre el DPC de los nodos destino y las asociaciones SCTP
terminadas en dichos nodos, tal como muestra la Tabla 48.
- 100 -
Tabla 48. Configuración M3UA en SGWs
SGW Routing context Routing key Nodo destino SCT P Asociación SCT P salida Valor SLS decimal Stream salida
1 DPC=Madrid-1 SMSC Madrid-1 SMSC 1 n (n=[0..15]) n+1
2 DPC=Barcelona-1 SMSC Barcelona-1 SMSC 2 n (n=[0..15]) n+1
3 DPC=Madrid-1 HLR-1 Madrid-1 HLR-1 3 n (n=[0..15]) n+1
7 DPC=Barcelona-1 HLR-1 Barcelona-1 HLR-1 7 n (n=[0..15]) n+1
T odos 9 DPC=Barcelona-2 HLR-1 Barcelona-2 HLR-1 9 n (n=[0..15]) n+1
11 DPC=Bilbao-1 HLR-1 Bilbao-1 HLR-1 11 n (n=[0..15]) n+1
15 DPC=Sevilla-1 HLR-1 Sevilla-1 HLR-1 15 n (n=[0..15]) n+1
En la tabla se ha incluido el stream de salida dentro de la asociación SCTP. Como

se ha visto en el apartado , el stream-0 en ambos sentidos de cada asociación SCTP se
dedica al transporte de tráfico de gestión entre los niveles M3UA de los extremos de la
asociación. Como los mensajes pertenecientes a la misma transacción en la red SS7
deben utilizar el mismo valor en el campo SLS, y en la red SIGTRAN se deben enviar
por el mismo stream, se utiliza el campo SLS para seleccionar el stream de salida
dentro de cada asociación SCTP.
El encaminamiento inverso, es decir, el de los mensajes que llegan al SGW desde

la red IP destinados en nodos SS7, lo realiza el protocolo MTP3 del SGW, de forma
análoga al resto de nodos SS7.
4.3.12 Configuración en SMSCs
4.3.12.1 SCCP
Los SMSCs realizarán la traducción de los GTs (direcciones SCCP) de las MSCs
de la red a los códigos de punto de señalización (direcciones MTP3) de los nodos
remotos. En este caso, los GTs se traducen en un DPC, sin ninguna alternativa, ya que
no existen en la red ejemplo MSCs redundantes.
- 101 -
Para los GTs de otros operadores, tanto nacionales como extranjeros, los SMSCs
delegarán esta traducción en los STPs de interconexión. Como existen cuatro STPs de
interconexión (Madrid-1, Madrid-2, Barcelona-1 y Barcelona-2), en los SMSCs se
establecerán cuatro grupos de GTs de otros operadores, de forma que cada grupo se
enviará en primera opción a un STP de interconexión distinto, y en segunda opción a su
STP pareja del doblete.
Para analizar la portabilidad, los SMSCs deberán enviar aproximadamente 1/8 de

los mensajes SRIfSM a cada STP/SGW en primera opción, y en segunda opción a su
pareja del doblete. Estos mensajes se encaminan utilizando el MSISDN destino como
GT, por lo que se establecerán 8 grupos de MSISDNs para encaminar estos mensajes
equitativamente entre los SGW/STP de la red.
La Tabla 49 muestra la tabla de traducciones de GTs que se definirá en los

SMSCs.
Tabla 49. Traducción de GTs en SMSCs
GT destino DPC Primario DPC Secundario

GT MSC Red propia DPC MSC -
Grupo 1 de MSISDNs DPC Madrid-1 STP/SGW DPC Madrid-2 STP/SGW
Grupo 2 de MSISDNs DPC Madrid-2 STP/SGW DPC Madrid-1 STP/SGW
Grupo 3 de MSISDNs DPC Barcelona-1 STP/SGW DPC Barcelona-2 STP/SGW
Grupo 4 de MSISDNs DPC Barcelona-2 STP/SGW DPC Barcelona-1 STP/SGW
Grupo 5 de MSISDNs DPC Bilbao-1 STP/SGW DPC Bilbao-2 STP/SGW
Grupo 6 de MSISDNs DPC Bilbao-2 STP/SGW DPC Bilbao-1 STP/SGW
Grupo 7 de MSISDNs DPC Sevilla-1 STP/SGW DPC Sevilla-2 STP/SGW
Grupo 8 de MSISDNs DPC Sevilla-2 STP/SGW DPC Sevilla-1 STP/SGW
Grupo 1 de GT s de otras redes DPC Madrid-1 STP/SGW DPC Madrid-2 STP/SGW
Grupo 3 de GT s de otras redes DPC Barcelona-1 STP/SGW DPC Barcelona-2 STP/SGW
Debe tenerse en cuenta que no existen mensajes directos originados en los SMSCs
y destinados en los HLRs, ya que los mensajes MAP SRIfSM deben evaluarse
previamente en los STP/SGWs, en los que reside el análisis de la portabilidad de
numeración móvil.
- 102 -
4.3.12.2 SCTP
Teniendo en cuenta los flujos de tráfico mencionados en el apartado 4.3.6, los

SMSCs deberán contar con asociaciones SCTP hacia todos los SGWs y hacia todos los
HLRs.
El número de streams en sentido saliente desde los SMSCs hacia los SGWs, como
se ha mencionado en el apartado 4.3.11.1 depende de los mecanismos que garantizan la
entrega ordenada de los mensajes hasta las MSCs destino, y eso incluye la red SS7. El
nivel SCCP de los SMSCs debe elegir a qué nivel MTP3 remoto enviar cada mensaje.
Este reparto de mensajes SCCP a niveles MTP3 de SGWs remotos lo realiza el nivel
M3UA, y como se verá en el apartado 4.3.12.3, se realizará basándose en el valor de un
bit concreto del campo SLS. Como los mensajes pertenecientes a la misma transacción
utilizan el mismo valor en el campo SLS, para garantizar la entrega ordenada extremo a
extremo, y dado que en una asociación SCTP los mensajes que se deben entregar en
orden se deben enviar por el mismo stream, desde los SMSCs hasta cada SGW no se
utilizarán más de 8 streams (de los 4 bits del campo SLS, uno se utiliza para elegir el
SGW destino, por lo que quedan 3 bits para elegir stream dentro de la asociación).
La comunicación IP entre SMSCs y HLRs es diferente. Sólo se envían mensajes

MAP desde los HLRs hasta los SMSCs, ya que el mensaje en sentido contrario, el
SRIfSM, debe cursarse a través de los STP/SGW, que es donde se analiza la
portabilidad de numeración móvil.
Además, tanto los HLRs como los SMSCs son nodos con M3UA y ambos cuentan
con dos interfaces hacia la red SIGTRAN.
Por tanto, se definirán dos asociaciones SCTP entre cada HLR y cada SMSC, una
por la “Red Roja” y otra por la “Red Azul”. Dentro de estas asociaciones se definirán 8
streams de entrada a los SMSCs para transporte de SCCP sobre M3UA, y ninguno de
salida.
- 103 -
En cualquier caso, SCCP seguirá manteniendo el criterio de utilizar el mismo

valor en el campo SLS para los mensajes pertenecientes a la misma transacción, por lo
que se pueden utilizar hasta 16 streams en total entre todas las asociaciones que se
definan entre un SMSC y un HLR, en ambos sentidos de la comunicación, enviando los
mensajes con el mismo valor del campo SLS por el mismo stream. Esto significa que en
cada una de las dos asociaciones SCTP entre un SMSC y un HLR se definirán 8 streams
para transporte de datos de usuario de M3UA.
Además de los streams mencionados, en todas las asociaciones se definirá un

stream en ambos sentidos (stream-0), que se utilizará, para intercambiar información de
gestión entre los protocolos M3UA de los nodos extremos de las asociaciones.
La Tabla 50 muestra, de acuerdo con todo lo mencionado, las asociaciones SCTP

que se definirán en los SMSCs.
- 104 -
Tabla 50. Asociaciones SCTP en SMSCs
SMSC (Dirección IP origen) Asociación SCT P Nodo destino Dirección IP destino Streams entrada Streams salida
2 Madrid-2 SGW 10.20.17.15 16+1 8+1
3 Barcelona-1 SGW 10.20.25.15 16+1 8+1
5 Bilbao-1 SGW 10.20.41.15 16+1 8+1
7 Sevilla-1 SGW 10.20.57.15 16+1 8+1
9 Madrid-1 HLR-1 10.20.9.3 8+1 0+1
11 Madrid-1 HLR-2 10.20.9.4 8+1 0+1
13 Madrid-2 HLR-1 10.20.17.2 8+1 0+1
15 Madrid-2 HLR-2 10.20.17.3 8+1 0+1
17 Barcelona-1 HLR-1 10.20.25.3 8+1 0+1
Madrid-1 SMSC (10.20.9.2) 19 Barcelona-1 HLR-2 10.20.25.4 8+1 0+1
Barcelona-1 SMSC (10.20.25.2) 21 Barcelona-2 HLR-1 10.20.33.2 8+1 0+1
23 Barcelona-2 HLR-2 10.20.33.3 8+1 0+1
25 Bilbao-1 HLR-1 10.20.41.2 8+1 0+1
27 Bilbao-1 HLR-2 10.20.41.3 8+1 0+1
29 Bilbao-2 HLR-1 10.20.49.2 8+1 0+1
31 Bilbao-2 HLR-2 10.20.49.3 8+1 0+1
33 Sevilla-1 HLR-1 10.20.57.2 8+1 0+1
35 Sevilla-1 HLR-2 10.20.57.3 8+1 0+1
37 Sevilla-2 HLR-1 10.20.65.2 8+1 0+1
SMSC (Dirección IP origen) Asociación SCT P Nodo destino Dirección IP destino Streams entrada Streams salida
1 Madrid-1 SGW 10.24.9.15 16+1 8+1
4 Barcelona-2 SGW 10.24.33.15 16+1 8+1
6 Bilbao-2 SGW 10.24.49.15 16+1 8+1
8 Sevilla-2 SGW 10.24.65.15 16+1 8+1
10 Madrid-1 HLR-1 10.24.9.3 8+1 0+1
12 Madrid-1 HLR-2 10.24.9.4 8+1 0+1
14 Madrid-2 HLR-1 10.24.17.2 8+1 0+1
16 Madrid-2 HLR-2 10.24.17.3 8+1 0+1
18 Barcelona-1 HLR-1 10.24.25.3 8+1 0+1
Madrid-1 SMSC (10.24.9.2) 20 Barcelona-1 HLR-2 10.24.25.4 8+1 0+1
Barcelona-1 SMSC (10.24.25.2) 22 Barcelona-2 HLR-1 10.24.33.2 8+1 0+1
24 Barcelona-2 HLR-2 10.24.33.3 8+1 0+1
26 Bilbao-1 HLR-1 10.24.41.2 8+1 0+1
28 Bilbao-1 HLR-2 10.24.41.3 8+1 0+1
30 Bilbao-2 HLR-1 10.24.49.2 8+1 0+1
32 Bilbao-2 HLR-2 10.24.49.3 8+1 0+1
34 Sevilla-1 HLR-1 10.24.57.2 8+1 0+1
36 Sevilla-1 HLR-2 10.24.57.3 8+1 0+1
38 Sevilla-2 HLR-1 10.24.65.2 8+1 0+1
4.3.12.3 M3UA
El protocolo SCCP de los SMSCs puede enviar mensajes, mediante M3UA, al

nivel MTP3 remoto situado en cualquiera de los ocho SGWs de la red. Será el protocolo
M3UA de los SMSCs el encargado de seleccionar el SGW remoto, para cada mensaje
SCCP.
- 105 -
La selección de SGW remoto se realiza utilizando tablas de correspondencias

(routing keys) entre parámetros de encaminamiento destinados al protocolo MTP3
(OPC, DPC, SLS, CIC si se enviara ISUP) y asociaciones SCTP de salida.
Teniendo en cuenta la topología de la red ejemplo, en la que una MSC está

directamente conectada a dos STP/SGW, se encaminarán todos los mensajes destinados
a una MSC en reparto de carga a través del doblete de SGWs a los que está
directamente conectada.
Para garantizar la entrega ordenada de mensajes extremo a extremo, todos los

mensajes pertenecientes a la misma transacción utilizan el mismo valor en el campo
SLS. Por ello, para repartir carga entre los dos SGWs de un doblete se utilizará el valor
de un bit del campo SLS, de forma análoga al reparto de carga MTP3.
Por otro lado, la comunicación de SMSC a HLR (mensaje SRIfSM) se envía al

DPC de los propios STPs/SGW, según la traducción ya efectuada por el nivel SCCP. A
nivel M3UA no se implementarán encaminamientos redundantes, puesto que SCCP ya
se encarga de ello.
Con todo, la Tabla 51 muestra los routing keys que se definirán en los SMSCs.
Tabla 51. Configuración M3UA en los SMSCs
SMSC Routing key Nodo destino SCT P Asociación SCT P salida Valor SLS decimal Stream salida
DPC=Madrid-1 STP/SGW Madrid-1 STP/SGW 1 n (n=[0..15]) (n MOD 8)+1
DPC=Madrid-2 STP/SGW Madrid-2 STP/SGW 2 n (n=[0..15]) (n MOD 8)+1
DPC=Barcelona-1 STP/SGW Barcelona-1 STP/SGW 3 n (n=[0..15]) (n MOD 8)+1
DPC=Barcelona-2 STP/SGW Barcelona-2 STP/SGW 4 n (n=[0..15]) (n MOD 8)+1
DPC=Bilbao-1 STP/SGW Bilbao-1 STP/SGW 5 n (n=[0..15]) (n MOD 8)+1
DPC=Bilbao-2 STP/SGW Bilbao-2 STP/SGW 6 n (n=[0..15]) (n MOD 8)+1
DPC=Sevilla-1 STP/SGW Sevilla-1 STP/SGW 7 n (n=[0..15]) (n MOD 8)+1
DPC=Sevilla-2 STP/SGW Sevilla-2 STP/SGW 8 n (n=[0..15]) (n MOD 8)+1
T odos
Madrid-1 STP/SGW 1 n (n=[0..7]) (n MOD 8)+1
DPC=MSC Centro
Barcelona-1 STP/SGW 3 n (n=[0..7]) (n MOD 8)+1
DPC=MSC Noreste
Bilbao-1 STP/SGW 5 n (n=[0..7]) (n MOD 8)+1
DPC=MSC Norte
Sevilla-1 STP/SGW 7 n (n=[0..7]) (n MOD 8)+1
DPC=MSC Sur
- 106 -
4.3.13 Configuración en HLRs
4.3.13.1 SCCP
Los HLRs realizarán la traducción de los GTs (direcciones SCCP) de las MSCs y
SMSCs de la propia red a los códigos de punto de señalización (direcciones MTP3) de
los nodos remotos. Los GTs de las MSCs se traducen a un único DPC, ya que no hay
MSCs redundantes. Por el contrario, los GTs asociados a los SMSCs se traducirán al
SPC de uno de los dos en primera opción, y al SPC del otro en segunda opción, ya que
uno de los SMSCs puede asumir el tráfico de otro SMSC en caso de fallo de este
último.
Para la traducción de los GTs de otros operadores, tanto nacionales como

extranjeros, los HLRs delegarán esta traducción en los STPs de interconexión. Como
existen cuatro STPs de interconexión (Madrid-1, Madrid-2, Barcelona-1 y Barcelona-2),
en los HLRs se establecerán cuatro grupos de GTs de otros operadores, de forma que
cada grupo se enviará en primera opción a un STP de interconexión distinto, y en
segunda opción a su STP pareja del doblete. Estos grupos serán los mismos que los
definidos en los SMSCs, par simplificar la gestión de la red.
La Tabla 52 muestra la tabla de traducción de GTs que se definirá en los HLRs.
Tabla 52. Traducción de GTs en HLRs
GT destino DPC Primario DPC Secundario

GT MSC Red propia DPC MSC -
GT Pareja SMSCs, Primario Madrid DPC Madrid-1 SMSC DPC Barcelona-1 SMSC
GT Pareja SMSCs, Primario Barna DPC Barcelona-1 SMSC DPC Madrid-1 SMSC
- 107 -
4.3.13.2 SCTP
Los HLRs, como se ha visto en apartados anteriores, contarán con asociaciones

SCTP hacia los SMSCs y los SGWs. Hacia los SMSCs se definirán dos asociaciones
SCTP, una a través de la “Red Azul” y otra a través de la “Red Roja”. Hacia los SGWs
sólo se definirá una asociación, a través de la red a la que esté conectado el SGW
remoto.
En todas las asociaciones SCTP, tanto hacia SMSCs como hacia SGWs se
configurará el stream-0 en ambos sentidos para intercambiar información de gestión del
propio protocolo M3UA.
Para intercambiar señalización SCCP sobre M3UA, se definirán 8 streams en cada

asociación hacia SMSCs y SGWs en sentido saliente. En sentido entrante, tal como se
ha especificado en los apartados anteriores, se definirán 16 streams desde los SGWs y 8
desde los SMSCs.
Con todo, la Tabla 53 muestra la configuración SCTP en los HLRs.
Tabla 53. Configuración SCTP en los HLRs
HLR (Dirección IP origen) Asociación SCT P Nodo destino Dirección IP destino Streams entrada Streams salida
2 Madrid-2 SGW 10.20.17.15 16+1 8+1
3 Barcelona-1 SGW 10.20.25.15 16+1 8+1
5 Bilbao-1 SGW 10.20.41.15 16+1 8+1
T odos (IP origen de la "Red Azul")
7 Sevilla-1 SGW 10.20.57.15 16+1 8+1
9 Madrid-1 SMSC 10.20.9.2 8+1 8+1
11 Barcelona-1 SMSC 10.20.25.2 8+1 8+1
HLR (Dirección IP origen) Asociación SCT P Nodo destino Dirección IP destino Streams entrada Streams salida
1 Madrid-1 SGW 10.24.9.15 16+1 8+1
4 Barcelona-2 SGW 10.24.33.15 16+1 8+1
6 Bilbao-2 SGW 10.24.49.15 16+1 8+1
T odos (IP origen de la "Red Roja")
8 Sevilla-2 SGW 10.24.65.15 16+1 8+1
10 Madrid-1 SMSC 10.24.9.2 8+1 8+1
12 Barcelona-1 SMSC 10.24.25.2 8+1 8+1
- 108 -
4.3.13.3 M3UA
El protocolo SCCP de los HLRs puede enviar mensajes, mediante M3UA, al nivel
MTP3 remoto situado en cualquiera de los ocho SGWs de la red, para enviar mensajes
hacia las MSCs. Será el protocolo M3UA de los HLRs el encargado de seleccionar el
SGW remoto, para cada mensaje SCCP.
La selección de SGW remoto se realiza utilizando tablas de correspondencias

(routing keys) entre parámetros de encaminamiento destinados al protocolo MTP3
(OPC, DPC, SLS, CIC si se enviara ISUP) y asociaciones SCTP de salida.
Teniendo en cuenta la topología de la red ejemplo, en la que una MSC está

directamente conectada a dos STP/SGW, se encaminarán todos los mensajes destinados
a una MSC en reparto de carga a través del doblete de SGWs a los que está
directamente conectada.
Para garantizar la entrega ordenada de mensajes extremo a extremo, todos los

mensajes pertenecientes a la misma transacción utilizan el mismo valor en el campo
SLS. Por ello, para repartir carga entre los dos SGWs de un doblete se utilizará el valor
de un bit del campo SLS, de forma análoga al reparto de carga MTP3.
Para la comunicación entre un HLR y un SMSC, existen dos asociaciones SCTP

disponibles hacia cada SMSC, una a través de la “Red Roja” y otra a través de la “Red
Azul”. En este caso se utiliza el modelo de redundancia 2+0 de M3UA (dos en reparto
de carga en primera opción y cero en segunda opción).
Para repartir carga entre las dos asociaciones se utilizará el valor de un bit del
campo SLS, de forma análoga al reparto de carga MTP.
La tabla de encaminamientos M3UA en los HLRs queda definida de acuerdo con

la Tabla 54.
- 109 -
Tabla 54. Configuración M3UA en HLRs
HLR Routing key Nodo destino SCT P Asociación SCT P salida Valor SLS decimal Stream salida
DPC=MSC Centro
DPC=MSC Noreste
DPC=MSC Norte
T odos
DPC=MSC Sur
9 n (n=[0..7]) (n MOD 8)+1
DPC=Madrid-1 SMSC Madrid-1 SMSC
10 n (n=[8..15]) (n MOD 8)+1
11 n (n=[0..7]) (n MOD 8)+1
DPC=Barcelona-1 SMSC Barcelona-1 SMSC
12 n (n=[8..15]) (n MOD 8)+1
- 110 -
COMPARACIÓN ENTRE SOLUCIÓN TRADICIONAL Y SOLUCIÓN SIGTRAN
5
COMPARACIÓN
ENTRE SOLUCIÓN
TRADICIONAL Y
SOLUCIÓN SIGTRAN
- 111 -
5.1 OBJETIVO DE LA COMPARACIÓN
En este capítulo se evaluarán las ventajas e inconvenientes que presenta la red

SIGTRAN de transporte de la señalización asociada a SMSs frente a la solución
tradicional (SS7 sobre red TDM).
Los aspectos que se valorarán serán el coste de los nodos, el alquiler de la

transmisión asociada, la facilidad de gestionar la red, la resistencia frente a situaciones
de congestión o fallos de elementos de red, la posibilidad de compartir recursos de
transmisión de voz, y la capacidad de crecimiento y de implantación de nuevos
servicios.
5.2 RED EQUIVALENTE TRADICIONAL
Una posible red equivalente tradicional consistiría en utilizar dos SMSCs con
señalización SS7, cada uno con capacidad para cursar 300 SMS/s en hora cargada, y
ambos con linksets directos hacia los dobletes de STPs de Madrid y Barcelona. Esta
topología se muestra en la Figura 39.
Madrid-1
STP SMSC STP

MSC MSC
SS7
Centro Este
SMSC
MSC MSC
STP SS7 STP
Barcelona-1
Enlace SS7
Figura 39. Topología de la Red SS7 alternativa a la red SIGTRAN.
Con esa topología, y teniendo en cuenta el tráfico originado en MSCs (ver Tabla
7), el tráfico en los enlaces SS7 de los SMSCs es el que se muestra en la Tabla 55.
- 112 -
Tabla 55. Tráfico SS7 en SMSCs
SMSC (SMS MO) / s FSM/s FSM-ack/s SRIfSM/s SRIfSM ack /s T ráfico total en SMSC (kbps)
Madrid-1 147,6 295,2 295,2 147,6 147,6 440
Barcelona-1 142,2 284,5 284,5 142,2 142,2 420
En este caso, como los enlaces SS7 son bidireccionales, el tráfico se ha calculado
como el tráfico en el sentido en que éste es máximo. Con este tráfico, se puede
comprobar que con linksets de 4 SLCs, la carga en los enlaces en hora cargada se
situaría en torno al 28%.
5.3 COMPARACIÓN DE AMBAS SOLUCIONES
5.3.1 Ancho de banda entre emplazamientos
Para comparar las necesidades de ancho de banda de ambas soluciones, tramo a

tramo se calculará el total de km. de línea de transmisión necesarios, multiplicados por
el ancho de banda correspondiente. Se calculará el producto kbps x km y después se
computará la suma de ellas.
La Tabla 56 muestra el total ancho de banda por kilómetro si se utiliza una red
SS7 tradicional. En esta solución es necesario utilizar tramas E1 de 2 Mbps entre nodos.
Tabla 56. Transmisión necesaria (ancho de banda por distancia) con red SS7
Extremo A Extremo B Ancho de banda (kbps) Distancia (km) Mbps x km

ST P Madrid-1 2048 0 0
ST P Madrid-2 2048 5 10
SMSC Madrid-1
ST P Barcelona-1 2048 620 1.240
ST P Barcelona-2 2048 620 1.240
ST P Madrid-1 2048 620 1.240
ST P Madrid-2 2048 620 1.240
SMSC Barcelona-1
ST P Barcelona-1 2048 0 0
ST P Barcelona-2 2048 5 10
T otal 4.980
Por otro lado, la muestra el ancho de banda por kilómetro utilizando la red
SIGTRAN diseñada en el capítulo 4. En este caso, el ancho de banda necesario es el
calculado en el apartado 4.3.8.9.
- 113 -
Tabla 57. Transmisión necesaria (ancho de banda por kilómetro) con red SIGTRAN
E x tr e m o A E x tr e m o B Ancho d e banda (kb ps) D i s ta n c i a ( k m ) M bps x km

M ad rid - 1 - 0 ,0 0 ,0
M ad rid - 2 1 2 9 ,0 5 ,0 0 ,6
B arcelon a- 1 1 3 7 ,0 6 2 0 ,0 8 2 ,9
B arcelon a- 2 8 2 ,0 6 2 0 ,0 4 9 ,6
M a d rid - 1
B ilb a o- 1 9 8 ,0 3 9 5 ,0 3 7 ,8
B ilb a o- 2 9 8 ,0 3 9 5 ,0 3 7 ,8
S e v illa - 1 1 1 2 ,0 5 4 0 ,0 5 9 ,1
S e v illa - 2 1 0 6 ,0 5 4 0 ,0 5 5 ,9
M ad rid - 1 1 0 7 ,0 5 ,0 0 ,5
M ad rid - 2 - 0 ,0 0 ,0
B arcelon a- 1 6 7 ,0 6 2 0 ,0 4 0 ,6
B arcelon a- 2 1 2 ,0 6 2 0 ,0 7 ,3
M a d rid - 2
B ilb a o- 1 1 2 ,0 3 9 5 ,0 4 ,6
B ilb a o- 2 1 2 ,0 3 9 5 ,0 4 ,6
S e v illa - 1 1 2 ,0 5 4 0 ,0 6 ,3
S e v illa - 2 6 ,0 5 4 0 ,0 3 ,2
M ad rid - 1 1 1 6 ,0 6 2 0 ,0 7 0 ,2
M ad rid - 2 7 9 ,0 6 2 0 ,0 4 7 ,8
B arcelon a- 1 - 0 ,0 0 ,0
B arcelon a- 2 1 8 8 ,0 5 ,0 0 ,9
B a rc e lon a - 1
B ilb a o- 1 6 1 ,0 6 2 0 ,0 3 6 ,9
B ilb a o- 2 6 1 ,0 6 2 0 ,0 3 6 ,9
S e v illa - 1 6 3 ,0 1 .0 4 6 ,0 6 4 ,4
S e v illa - 2 5 7 ,0 1 .0 4 6 ,0 5 8 ,2
M ad rid - 1 4 9 ,0 6 2 0 ,0 2 9 ,7
M ad rid - 2 1 2 ,0 6 2 0 ,0 7 ,3
B arcelon a- 1 1 8 1 ,0 5 ,0 0 ,9
B arcelon a- 2 - 0 ,0 0 ,0
B a rc e lon a - 2
B ilb a o- 1 1 2 ,0 6 2 0 ,0 7 ,3
B ilb a o- 2 1 2 ,0 6 2 0 ,0 7 ,3
S e v illa - 1 1 2 ,0 1 .0 4 6 ,0 1 2 ,3
S e v illa - 2 6 ,0 1 .0 4 6 ,0 6 ,1
M ad rid - 1 9 7 ,0 3 9 5 ,0 3 7 ,4
M ad rid - 2 1 2 ,0 3 9 5 ,0 4 ,6
B arcelon a- 1 5 4 ,0 6 2 0 ,0 3 2 ,7
B arcelon a- 2 1 2 ,0 6 2 0 ,0 7 ,3
B ilb ao-1
B ilb a o- 1 - 0 ,0 0 ,0
B ilb a o- 2 1 2 ,0 5 ,0 0 ,1
S e v illa - 1 1 2 ,0 9 3 3 ,0 1 0 ,9
S e v illa - 2 6 ,0 9 3 3 ,0 5 ,5
M ad rid - 1 9 7 ,0 3 9 5 ,0 3 7 ,4
M ad rid - 2 1 2 ,0 3 9 5 ,0 4 ,6
B arcelon a- 1 5 4 ,0 6 2 0 ,0 3 2 ,7
B arcelon a- 2 1 2 ,0 6 2 0 ,0 7 ,3
B ilb ao-2
B ilb a o- 1 1 2 ,0 5 ,0 0 ,1
B ilb a o- 2 - 0 ,0 0 ,0
S e v illa - 1 1 2 ,0 9 3 3 ,0 1 0 ,9
S e v illa - 2 6 ,0 9 3 3 ,0 5 ,5
M ad rid - 1 1 1 4 ,0 5 4 0 ,0 6 0 ,1
M ad rid - 2 1 2 ,0 5 4 0 ,0 6 ,3
B arcelon a- 1 5 7 ,0 1 .0 4 6 ,0 5 8 ,2
B arcelon a- 2 1 2 ,0 1 .0 4 6 ,0 1 2 ,3
S e v illa - 1
B ilb a o- 1 1 2 ,0 9 3 3 ,0 1 0 ,9
B ilb a o- 2 1 2 ,0 9 3 3 ,0 1 0 ,9
S e v illa - 1 - 0 ,0 0 ,0
S e v illa - 2 6 ,0 5 ,0 0 ,0
M ad rid - 1 1 0 7 ,0 5 4 0 ,0 5 6 ,4
M ad rid - 2 1 2 ,0 5 4 0 ,0 6 ,3
B arcelon a- 1 5 0 ,0 1 .0 4 6 ,0 5 1 ,1
B arcelon a- 2 1 2 ,0 1 .0 4 6 ,0 1 2 ,3
S e v illa - 2
B ilb a o- 1 1 2 ,0 9 3 3 ,0 1 0 ,9
B ilb a o- 2 1 2 ,0 9 3 3 ,0 1 0 ,9
S e v illa - 1 1 2 ,0 5 ,0 0 ,1
S e v illa - 2 - 0 ,0 0 ,0
T o ta l 1 .2 8 0 ,8
- 114 -
Dependiendo del contrato con el suministrador de la transmisión, el gasto en podrá

variar. En el caso de las redes de paquetes, se puede contratar un precio por un ancho de
banda medio consumido, asegurando el doble de capacidad de transmisión de pico.
Como puede comprobarse, utilizando una red IP no se tienen las restricciones que
impone la transmisión TDM, con lo que se necesita casi la mitad de capacidad de
transmisión utilizando red SIGTRAN, y por tanto, el gasto en alquiler de transmisión
variará entre la mitad y la cuarta parte del gasto si se utilizara SS7 tradicional,
dependiendo de si se paga por capacidad contratada o por ancho de banda utilizado.
Es cierto que en el caso de la solución tradicional, con el mismo gasto en alquiler

se podría duplicar la capacidad de los enlaces (de 4 a 8 SLCs por linksets), si se
generase ese tráfico en la red. En ese caso, y suponiendo que se contrate la capacidad
máxima necesaria (el doble del ancho de banda utilizado en hora cargada en
funcionamiento normal) la solución basada en IP supondría el mismo gasto en alquiler
de transmisión.
Por otra parte, en la solución tradicional no se ha cuantificado pero existiría

aumento del tráfico SS7 entre dobletes de STPs para encaminar el tráfico desde las
MSCs del Norte y del Sur hasta los SMSCs.
5.3.2 Coste de los SMSCs
La razón fundamental por la cual es interesante utilizar señalización M3UA o

SUA en lugar de SS7 tradicional reside precisamente en la mayor simplicidad de los
nodos únicamente conectados a la red SIGTRAN. Los interfaces Ethernet, gracias a su
producción en masa, son mucho más baratos que los interfaces de tipo TDM, como
pueden ser los controladores de tramas de 2 Mbps, y los procesadores de señalización
MTP, ya que estos últimos se han desarrollado para un mercado mucho menor, como
son los operadores de telefonía.
- 115 -
Por otro lado, cualquier nodo con las pilas de protocolos de M3UA (sobre
SCTP/IP) y SCCP y un par de tarjetas Ethernet es capaz de enviar señalización al resto
de la red a través de una red SIGTRAN. Esto significa que se puede encargar a terceros
el desarrollo de funcionalidades específicas (software) implementadas simplemente
sobre ordenadores industriales con tarjetas Ethernet, en lugar de verse obligado a
adquirir las soluciones cerradas que tradicionalmente ofrecen los fabricantes de equipos
de conmutación.
5.3.3 Coste de la red
En el caso de la solución tradicional, aparte de los SMSCs no se necesitan nuevos

nodos de red. Únicamente se consumen en la red SS7 dos tarjetas controladoras de
transmisión TDM y ocho controladores de señalización en los cuatro STPs a los que se
conectan los SMSCs.
Por otro lado, la solución con red SIGTRAN requiere realizar inversión, ya que se
deben montar equipos nuevos y ampliar los actuales. En concreto, dejando aparte los
SMSCs, las inversiones requeridas son las siguientes:
• 15 ampliaciones hardware M3UA en HLRs.

• 8 ampliaciones hardware M3UA en STPs para convertirlos en STP/SGWs.
• 16 routers dedicados.
• 16 switches dedicados.
• En caso de que algún nodo conectado a la red SIGTRAN se conectara a su vez a
otra red IP externa, directa o indirectamente, sería necesario adquirir elementos de
seguridad (firewalls).
5.3.4 Flexibilidad de las plataformas
La posibilidad de utilizar plataformas abiertas conectadas a la red de señalización

supone poder desarrollar servicios a medida, y no limitarse a comprar la funcionalidad
que un determinado fabricante ofrezca.
- 116 -
En el caso de los SMSCs, si se han desarrollado en una plataforma abierta y se

puede reprogramar la funcionalidad del centro, se pueden desarrollar servicios de valor
añadido exclusivos de cada operadora, lo que puede resultar decisivo para diferenciarse
de la competencia.
Por otro lado, si se utilizan SMSCs “estándar”, al ser soluciones cerradas su

funcionalidad es limitada, y normalmente se requiere contar con otras plataformas
conectadas a los SMSCs para implementar diferentes servicios, y aún así, se tendrán con
las restricciones de conectividad que imponga el SMSC.
5.3.5 Capacidad de la red
Las limitaciones de la red SS7 en cuanto a encaminamientos MTP (únicamente

estáticos), junto con el sistema de transmisión TDM limitan su capacidad de transmisión
y complican la configuración de los encaminamientos. Como ventaja, se puede
garantizar un comportamiento del tráfico regular e inmejorable en cuanto a retardos de
transmisión y fiabilidad.
Por otra parte, la red IP no impone restricciones de ancho de banda entre nodos y
los routers tienen una capacidad de encaminamiento, tanto estático como dinámico
amplísima. El protocolo IP se diseñó específicamente para resistir caídas de nodos re-
encaminando el tráfico de forma dinámica, y esto es una cualidad especialmente
interesante si se intercambia tráfico de señalización. Por otro lado, no se conoce el
comportamiento real del tráfico SCTP sobre IP, ya que es un protocolo nuevo.
5.3.6 Comportamiento ante congestión
Para el caso concreto estudiado en el capítulo 4, no existen tráficos más

prioritarios que otros en la red SIGTRAN propuesta. Todos se deben a SMSs. Por ello,
no es necesario implementar en los routers frontera de las VLANes SIGTRAN
mecanismos de ingeniería de tráfico. En caso de congestión en la red IP se descartarán
paquetes indiscriminadamente.
- 117 -
En el caso de la solución equivalente utilizando red SS7 tradicional, un aumento

excesivo del tráfico SMS provocaría un aumento importante en la señalización
intercambiada entre los dobletes de STPs, motivado por la topología elegida, afectando
a tráfico de señalización no debido a SMS.
En caso de que se enviase otro tipo de señalización a través de la red SIGTRAN,

la red IP de transporte permite utilizar protocolos intermedios que implementan
diferenciación de tráfico y aseguramiento de calidad de servicio para ciertos tráficos
prioritarios. Estos protocolos de ingeniería de tráfico IP no existen en la red SS7, de
forma que si un enlace se congestiona se descartan paquetes indiscriminadamente, sin
posibilidad de priorizar ciertos tráficos.
5.3.7 Experiencia en la tecnología
Los protocolos SIGTRAN son nuevos, y no se tiene ninguna experiencia en su

configuración, gestión y soporte. Por eso se propone un escenario en el que únicamente
se cursa tráfico debido a SMS, ya que se considera que es el tráfico de señalización
menos sensible en caso de fallos. La operadora necesitará formar a parte de su plantilla
en la nueva tecnología, y la resolución de los problemas que se presenten no se podrá
basar en plantillas predefinidas generadas a partir de experiencias similares ocurridas.
Por el contrario, la tecnología SS7 tradicional es muy madura, se tiene un

conocimiento extenso de los protocolos y se ha trabajado con ellos durante largo
tiempo. Los procedimientos de configuración, gestión y soporte de la red son habituales
en las operadoras de telefonía móvil y se cuenta con plantillas de resolución de errores
basadas en casos anteriores.
5.3.8 Evolución de la red
Una vez que se cuenta con una infraestructura básica de transmisión de

señalización sobre IP mediante M3UA, se cuenta con ventajas a corto plazo. Por una
parte, se pueden integrar nuevas plataformas de servicios basadas en señalización o
mensajería SMS muy rápidamente, ya que no es necesario desplegar transmisión TDM
hacia STPs. Además, se pueden desarrollar servicios nuevos sobre servidores de
propósito general, consiguiendo diferenciación respecto de la competencia y reduciendo
costes en red.
- 118 -
Sin embargo, además de las ventajas a corto plazo, la principal ventaja reside en el
largo plazo. Una vez que se haya adquirido experiencia en la nueva tecnología, en lugar
de ampliar la red SS7 sobre TDM ya instalada, será más rentable ampliar la red
SIGTRAN. Además, paulatinamente se podrá migrar toda la señalización hacia nodos
ampliables con señalizadores SIGTRAN hacia la nueva red.
Por último, la red SIGTRAN ya instalada permite también transportar las

comunicaciones de control entre los nodos de la futura red UMTS. De esta forma, se
consigue desde un primer momento contar plataformas de servicios y nodos de red
accesibles a través de la red GSM y de la red UMTS. Como ejemplo, todos los nodos
HLR de la red podrían utilizarse para definir usuarios UMTS sin ningún problema.
Otros nodos de red como el EIR o el AuC también podrían utilizarse en ambas redes, de
igual forma que los nodos de Red Inteligente, SMSCs, o los nodos en donde resida la
funcionalidad de consulta de portabilidad.
A largo plazo es inevitable contar con señalización SIGTRAN, ya que

previsiblemente los nodos de conmutación UMTS, a partir de un cierto momento no se
fabricarán con acceso TDM.
- 119 -
5.4 RESULTADO DE LA COMPARACIÓN
La Tabla 58 muestra el resumen de las características de ambas soluciones.
Tabla 58. Comparación entre solución SIGTRAN y SS7 tradicional
Solución SIGTRAN Solución SS7 tradicional

Ancho de banda entre En media la mitad que en la El doble que la solución SIGTRAN.
emplazamientos solución tradicional.
Coste de los SMSCs Plataformas más baratas. Plataformas más caras.
Coste de la red Necesario ampliar hardware y Utiliza hardware ya instalado en
adquirir routers y switches. STPs. Coste menor.
Flexibilidad de la plataforma Plataformas abiertas. Muy Soluciones cerradas. Poco flexibles.
flexible.
Capacidad de la Red Gran ancho de banda. Ancho de banda más limitado. Sólo
Encaminamientos dinámicos. encaminamientos estáticos.
Comportamiento ante congestión Es posible descartar tráfico en Descarta paquetes sin distinguir tipo
función de distintos tipos. de tráfico
Experiencia en la tecnología Ninguna. Necesaria formación. Amplia. No se requiere formación.
Evolución de la red La red UMTS necesitará contar A largo plazo tenderá al desuso.
con una red de transporte de
tráfico de control sobre IP.
Una comparación desde el punto de vista económico únicamente, puede resultar

en la conveniencia de una u otra solución en función de los costes concretos de los
equipos a instalar en cada caso y del alquiler de la transmisión. Sin embargo, aparte del
coste de la instalación de las dos plataformas, existe un valor añadido mayor para la
operadora si utiliza red SIGTRAN, y es la posibilidad de desarrollar servicios o
funcionalidades a medida.
Una vez que se tiene una red SIGTRAN básica en la red, se puede derivar el
crecimiento de la red SS7 hacia la red nueva, lo que redundará en un menor coste de
transmisión y de nodos y una mayor capacidad de crecimiento.
- 120 -
Finalmente, dado que la tendencia de la transmisión TDM es que quedará en

desuso en el futuro, puede resultar una ventaja adquirir experiencia cuanto antes en la
nueva tecnología y facilitar la evolución de la red hacia una arquitectura con una red de
transmisión de tipo “All-IP” y el despliegue de la futura red UMTS.
- 121 -
BIBLIOGRAFÍA
BIBLIOGRAFÍA
[E.164] ITU-T E.164 (05/97). The international public telecommunication

numbering plan. [En línea]. Disponible en http://www.itu.int. [Consulta:
12 de febrero de 2003].
[GRAD] GRADISCHNIG, K.D.; et al. Loadsharing – A key to the reliability for

SS7-networks [en línea]. Año 2000. Disponible en:
http://www.c7.com/ss7/whitepapers/loadsharing_drcn2000.pdf [Consulta:
9 de febrero de 2003]
[IEEE802.3] IEEE 802.3. IEEE Standard for Information technology.

Telecommunications and information exchange between systems. Local
and metropolitan area networks. Specific requirements. Part 3: Carrier
sense multiple access with collision detection (CSMA/CD) access method
and physical layer specifications. [En línea]. Disponible en:
http://standards.ieee.org/getieee802/download/802.3-2002.pdf. [Consulta:
9 de febrero de 2003]
[INE] Instituto Nacional de Estadística. Resultados de los Censos de Población

y Viviendas 2001. Fecha de referencia 1/11/2001: Población por
comunidades autónomas y provincias y por capitales de provincia. [En
línea]. INE. Madrid. Julio 2002. Disponible en
http://www.ine.es/censo2001/pob_cen01_tab1.xls. [Consulta: 11 de
febrero de 2003]
[M2PA] GEORGE, T.; et al. INTERNET-DRAFT: SS7 MTP2-User Peer-to-Peer

Adaptation Layer. [En línea]. The Internet Society. 17 de enero de 2003.
Disponible en http://www.ietf.org/internet-drafts/draft-ietf-sigtran-m2pa-
07.txt. [Consulta: 9 de febrero de 2003]
[MAP] ETSI 3GPP TS 29.002 version 5.1.0 Release 5. Digital cellular

telecommunications system (Phase 2+) (GSM); Universal Mobile
Telecommunications System (UMTS); Mobile Application Part (MAP)
specification (3GPP TS 29.002 version 5.1.0 Release 5) Mobile
Application Part (MAP). [En línea]. Disponible en: http://www.etsi.org.
[Consulta: 10 de febrero de 2003]
[RFC2719] ONG, L.; et al. Request for Comments 2719: Framework Architecture for
Signaling Transport. [En línea]. The Internet Society. Octubre 1999.
Disponible en: http://www.ietf.org/rfc/rfc2719.txt. [Consulta: 9 de febrero
de 2003]
[RFC2960] STEWART, R.; et al. Request for Comments 2960: Stream Control
Transmission Protocol. [En línea]. The Internet Society. Octubre 2000.
de 2003]
[RFC3057] MORNEAULT, K.; et al. Request for Comments 3057: ISDN Q.921-User
Adaptation Layer. [En línea]. The Internet Society. Febrero 2001.
- 123 -

de 2003]
[RFC3331] MORNEAULT, K.; et al. Request for Comments 3331: Signaling System
7 (SS7) Message Transfer Part 2 (MTP2)-User Adaptation Layer. [En
línea]. The Internet Society. Septiembre 2002. Disponible en:
http://www.ietf.org/rfc/rfc3331.txt. [Consulta: 9 de febrero de 2003]
[RFC3332] SIDEBOTTOM, G.; et al. Request for Comments 3332: Signaling System
7 (SS7) Message Transfer Part 3 (MTP3)-User Adaptation Layer
(M3UA). [En línea]. The Internet Society. Septiembre 2002. Disponible
en: http://www.ietf.org/rfc/rfc3332.txt. [Consulta: 9 de febrero de 2003]
[RFC791] Information Sciences Institute University of Southern California. Request

for Comments 791: Internet Protocol DARPA Internet Program Protocol
Specification. [En línea]. University of Southern California. Septiembre
1981. Publicado por The Internet Society. Disponible en:
http://www.ietf.org/rfc/rfc791.txt. [Consulta: 9 de febrero de 2003]
[SS7] ITU-T Q.700 a Q.775. Specifications of Signalling System No. 7.
[SUA] SIDEBOTTOM, G.; et al. INTERNET-DRAFT: Signalling Connection

Control Part User Adaptation Layer (SUA). [En línea]. The Internet
Society. Junio 2002. Disponible en: http://www.ietf.org/internet-
drafts/draft-ietf-sigtran-sua-14.txt. [Consulta: 15 de diciembre de 2003]
- 124 -

Índice

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Índice

Cargado por

Copyright:

Formatos disponibles

ÍNDICE

LA SEÑALIZACIÓN SS7 EN UNA RED MÓVIL................................................... 11

TRANSPORTE DE SEÑALIZACIÓN SS7 SOBRE IP ........................................... 31

3.6.1 Encaminamiento de mensajes........................................................................ 49

DISEÑO DE UNA RED DE TRANSPORTE DE SMS SOBRE IP ......................... 51

COMPARACIÓN ENTRE SOLUCIÓN TRADICIONAL Y SOLUCIÓN

BIBLIOGRAFÍA ........................................................................................................ 123

• 3GPP Third generation partnership project. Grupo normalizador de las

• GSM: Global Switched Mobile Network. Red de conmutación móvil

• MTP Message Transfer Protocol. Protocolo de transferencia de mensajes

• SRI Send Routing Information. Envío de información de

Los operadores móviles están experimentando un importante crecimiento en el

Lo más importante en una red de transporte de señalización es la fiabilidad. Dado

El servicio de mensajes cortos es de tipo “datagrama” y sin requisitos de retardo.

En el momento en que es necesario realizar inversiones en la red de señalización,

En un futuro cercano, las redes de telefonía móvil de tercera generación utilizarán

2.1 QUÉ ES LA SEÑALIZACIÓN

En una Red de Conmutación, se entiende por señalización el intercambio de

El Sistema de Señalización SS7 es un medio que utilizan los elementos de la red

2.2 ARQUITECTURA DE LA RED SS7

El sistema SS7 consiste básicamente en una red de transporte de mensajes cuyos

Figura 1. Esquema de Red SS7 en una red GSM.

2.2.1 Puntos de Transferencia de Señalización (STP)

Un STP es un conmutador de paquetes diseñado específicamente para enviar

La disponibilidad de la Red SS7 que interconecta los nodos de conmutación de

2.2.2 Punto de control de servicios (SCP)

Los servicios de telefonía que necesitan de un procesamiento avanzado de las

Un ejemplo de servicio de Red Inteligente puede ser el de llamadas al servicio de

Dependiendo de la importancia del servicio al que atienden, los SCPs se pueden

En general, los SCPs implementan servicios basados en llamadas, no basados en

2.2.3 Punto de Datos de Servicio (SDP)

2.2.4 Registro de localización de usuarios (HLR)

Normalmente un operador con más de un millón de usuarios cuenta con varios

2.2.5 Registro de localización de visitantes (VLR)

2.2.6 Centro de Servicio de Mensajes Cortos (SMSC)

Es el elemento fundamental que permite a los usuarios enviar y recibir SMSs.

Los SMSs se transmiten entre MSCs y SMSCs en forma de mensajes de

2.2.7 Enlaces de señalización SS7

Se entiende por enlace de señalización un circuito de datos bidireccional que

2.2.8 Señalización asociada

En ocasiones, se implementan enlaces de señalización directos entre dos nodos de

Si bien en general es preferible enviar la señalización a través de la red SS7, por su

2.2.9 Señalización cuasi-asociada

Como contraposición a la señalización asociada, la arquitectura en la que se

2.3 CAPAS DEL PROTOCOLO SS7

Lo fundamental en una red SS7 es el protocolo de transferencia de mensajes de

2.3.1 Nivel Físico

En general, en las redes SS7 tradicionales los enlaces de señalización se

Figura 2 Aprovechamiento de la transmisión TDM en una red SS7

Si se dispone de multiplexores TDM, se puede aumentar el aprovechamiento de la

2.3.2 Parte de Transferencia de Mensajes (MTP) – Nivel 2

• Transmisión, recepción y reenvío en caso de error de MSUs.

2.3.3 Parte de Transferencia de Mensajes (MTP) – Nivel 3

Las principales funciones de este nivel son:

• Identificación de todos los nodos de la red.

2.3.3.1 Códigos de Punto de Señalización (SPC)

En MTP los nodos se identifican mediante al menos un código de 14 bits2

El uso del campo NI, según la UIT-T es el siguiente:

• 00: Red Internacional.

De esta forma, un mismo nodo puede usar un identificador nacional para

Así, un SPCs de 14 bits no identifica un nodo. Es necesario especificar además la

• NI=10 (Ámbito Nacional) en binario. 2 en decimal.

Todos los nodos de conmutación de un mismo país deben utilizar el mismo