ÍNDICE - dit.upm.esenrique/pub/jbento-Memoria.pdf · • CAMEL Protocolo de Red Inteligente normalizado específico para redes de telefonía móvil

ÍNDICE

- 1 -

Í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

Diseño de una red de señalización SS7 sobre IP para redes de telefonía móvil GSM y UMTS

- 2 -

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

GLOSARIO

- 3 -

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.


- 4 -

• 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.

GLOSARIO

- 5 -

• 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.


- 6 -

• 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.

INTRODUCCIÓN

- 7 -

11

IINNTTRROODDUUCCCCIIÓÓNN


- 8 -

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.

INTRODUCCIÓN

- 9 -

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.

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

- 11 -

22

LLAA SSEEÑÑAALLIIZZAACCIIÓÓNN SSSS77 EENN UUNNAA RREEDD MMÓÓVVIILL


- 12 -

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.


- 13 -

MSC

MSC

HLR

SCP

SMSCEnlaces de señalización

Enlaces de voz

Enlaces de señalización

Enlaces de voz

STPSTP STPSTP

STPSTP STPSTP

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.


- 14 -

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.


- 15 -

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.


- 16 -

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.


- 17 -

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.


- 18 -

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.

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

Sincronismo de trama

Definidoscomo linkset Canales desaprovechados

32 x 64 kbpsSTPSTP STPSTP

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.


- 19 -

• 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.


- 20 -

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.


- 21 -

MSC HLR


Enlaces de voz

BSC

STPA

STPA

STPB

STPB

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

DPC (Destino MTP-3) Linkset de salida Prioridad Bit del SLS de

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


- 22 -

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.


- 23 -

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.


- 24 -

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).


- 25 -

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.


- 26 -

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.

MSCSTPSTP STPSTPHLR

MTP3

SCCP

Red MTP nacional

Red MTP nacional

MTP3 MTP3

SCCP

MTP3 MTP3

SCCP

MTP3

SCCP

Red MTP internacional

Red MTP internacional Red MTP

nacionalRed MTP nacional

GT=ASPC=2-A

GT dest =B → DPC=2-C’ GT dest =B → DPC=0-D GT dest =B → DPC=2-BOPC=2-A OPC=0-C OPC=2-D’

GT=CSPC=2-C’SPC=0-C

GT=DSPC=2-D’SPC=0-D

GT=BSPC=2-B

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.


- 27 -

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).


- 28 -

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.


- 29 -

MSC SMSC

FORWARD SHORT MESSAGE (MO)

FORWARD SHORT MESSAGE (MO) ACK

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.


- 30 -

MSCSMSC

Send Routing Info. for SM

t t

HLR

t

Send Routing Info. for SM- response

Forward Short Message Mobile Terminating

Forward Short Message Mobile Terminating-ack

Figura 6. Transacciones MAP en un mensaje corto terminado

TRANSPORTE DE SEÑALIZACIÓN SS7 SOBRE IP

- 31 -

33

TTRRAANNSSPPOORRTTEE DDEE SSEEÑÑAALLIIZZAACCIIÓÓNN SSSS77 SSOOBBRREE IIPP


- 32 -

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.

IP

SCTP

Capa de adaptación

S7UP/S7AP

Figura 7 Arquitectura de protocolos SIGTRAN.


- 33 -

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


- 34 -

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.


- 35 -

• 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 3

Llamada 2

Llamada 3

Llamada 1

Llamada 2

Llamada 1

Llamada 2

Llamada 3

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.


- 36 -

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.


- 37 -

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.


- 38 -

CABECERA COMÚN

CABECERA CHUNK DATOS

DATOS USUARIO SCTP

24 octetos

16 octetos

Hasta 65520 octetos

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.


- 39 -

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


- 40 -

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.

MTP1

MTP2

MTP3

SCCP

TCAP

MTP1

MTP2

IP

SCTP

M2PA

MTP3

Enlace SS7

IP

SCTP

M2PA

Red IPRed IP

MTP3

SCCP

TCAP

Nodo SS7 Nodo IP

SGW

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.


- 41 -

MTP1

MTP2

MTP3

SCCP

TCAP

MTP1

MTP2

IP

SCTP

M2PA

MTP3

Enlace SS7Red IPRed IP

Nodo SS7

SGW

MTP1

MTP2

MTP3

SCCP

TCAP

Enlace SS7

Nodo SS7

IP

SCTP

M2PA

SGW

MTP1

MTP2

MTP3

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.


- 42 -

IP

SCTP

M2UA

IP

SCTP

M2UA

Red IPRed IP

MTP3

SCCP

TCAP

Nodo IP

MTP3

SCCP

TCAP

Nodo 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.


- 43 -

MTP1

MTP2

MTP3

SCCP

TCAP

MTP1

MTP2

IP

SCTP

M2UA

Traducción

Enlace SS7

IP

SCTP

M2UA

Red IPRed IP

MTP3

SCCP

TCAP

Nodo SS7 Nodo IP

SGW

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.


- 44 -

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.

IPMTP1

MTP2

MTP3

MTP1

MTP2

Enlace SS7

SCTP

M3UA

Red IPRed IP

SCCP

TCAP

Nodo SS7 Nodo IP

SGW

MTP3

IP

SCTP

M3UA

Traducción ISUPISUP SCCP

TCAP

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.


- 45 -

IP

SCTP

M3UA

IP

SCTP

M3UA

Red IPRed IP

SCCP

TCAP

Nodo IP

ISUP SCCP

TCAP

Nodo IP

ISUP

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.


- 46 -

Red IP redundante

Red IP redundante

SGWSGW

NODOIPRed

SS7/TDMRed

SS7/TDMSGWSGW

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.


- 47 -

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:

Long= 4 oc te tos

O pc iona l

M en sa je M T P

T ipo : A p . R ed

A P A R IE N C IA D E R E D

Long= 4 oc te tosT ip o : R out. C ontx t

R O U T IN G C O N T E X T

Lo ng itudT ipo : D A T O S

M E N S A JE U S U A R IO M T P

O P C

D P C

S I N I M P S L S

4 oc te tos

Long= 4 oc te tosT ipo : C o rre lac ión

ID E N T IF IC A D O R D E C O R R E LA C IÓ NO pc iona l

Figura 17. Estructura de los mensajes de datos de M3UA


- 48 -

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.


- 49 -

IPMTP1

MTP2

MTP3

MTP1

MTP2

Enlace SS7

SCTP

SUA

Red IPRed IP

TCAP

Nodo SS7 Nodo IPSGW

MTP3

IP

SCTP

SCCP

TCAP

SCCPSUA

Traducción

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).


- 50 -

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.


- 51 -

44

DDIISSEEÑÑOO DDEE UUNNAA RREEDD DDEE TTRRAANNSSPPOORRTTEE DDEE SSMMSS SSOOBBRREE IIPP


- 52 -

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].


- 53 -

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.


- 54 -

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.


- 55 -

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.


Enlaces de voz


Enlaces de voz

MSC

MSC

MSC

MSC

MSC...

Acceso Tránsito

Núcleo de Red

BSC

BSC

BSC

BSCBSC

BTSBTS

BTSBTS

.

.

.

Red de Acceso Radio

BSC

STPSTP

STPSTP

Red SS7

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.


- 56 -

MSCMSC

Norte

MSCMSC

MSC

MSC

MSC

MSC

Sur

Centro Este

STPSTP

STPSTP

STPSTPSTPSTP

STPSTP

STPSTP

STPSTP STPSTP

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


- 57 -

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.


Transmisión directa

MSC

Acceso Tránsito

MSC

MSC

STPSTP

STPSTP

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.


- 58 -

MSC

MSC

MSC

MSC



STPSTP

STPSTP

STPSTP

STPSTP

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.


- 59 -

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.


- 60 -

MSCMSC

Norte

MSCMSC

MSC

MSC

MSC

MSC

Sur

Centro EsteHLR

Enlace SS7


STPSTP

STPSTP

STPSTPSTPSTP

STPSTP

STPSTP

STPSTP STPSTP

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.


- 61 -

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.


- 62 -

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 adelanteDistrib. 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+ TotalUsuarios 3.000.000 4.000.000 2.700.000 300.000 10.000.000Usuarios prepago 3.000.000 2.400.000 1.620.000 210.000 7.230.000SMS/día 6.000.000 4.000.000 540.000 0 10.540.000SMS 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.


- 63 -

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


- 64 -

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 STP MSC Acceso HLR SMSC TIPO

Madrid-1 1 1 2 2 1 T1

Madrid-2 1 1 2 2 0 T2

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

Barcelona-3 0 0 2 0 0 A

T arragona-1 0 0 2 0 0 A

Valencia-1 0 0 2 0 0 A

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

Bilbao-2 1 1 2 2 0 T2

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

Sevilla-2 1 1 2 1 0 T2

Málaga-1 0 0 3 0 0 A

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

SUR

Andalucí a + Ceuta y Melilla

CENTRO

ESTE

NORTE

Comunidad Valenciana

Paí s Vasco

Madrid (Comunidad de)

Cataluña


- 65 -

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.


- 66 -

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.


- 67 -

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.


- 68 -

• 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”.

Red IPRed IP

Red IPRed IP

SGW

STP

SGW

STP

SGW

STP

SGW

STP

SGW

STP

SGW

STP

SGW

STP

SGW

STP

SGW

STP

SGW

STP

SGW

STP

SGW

STP

SGW

STP

SGW

STP

SGW

STP

SGW

STP

Figura 25. Conexión de los SGWs a las redes IP de transporte.

SGW

STP

SGW

STP

SGW

STP

SGW

STP

MSC

Red IPRed IP

Red IPRed IP

SMSCIP

HLR

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”.


- 69 -

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.


- 70 -

MSC

Red IPRed IP

Red IPRed IP

SMSCIP

HLR

SRIfSM

SGW

STP

SGW

STP

SRIfSM

FSM-MO

FSM-MO ACK

Otros operadores

Otros operadores

SGW

STP

SGW

STPSRIfSM ACK

FSM-MT ACK

FSM-MT

FSM-MO (+ACK) : 1 x SMS-MO en MSC

FSM-MT (+ACK) : 1 x SMS-MO en MSC

SRIfSM (SMSC->SGW): 1 x SMS-MT

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


- 71 -

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 288FSM-ack 15 158SRIfSM 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 Trá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.


- 72 -

Ecuación 1. Tráfico total en los SGW

( ) [ ]º º ( ) ( )º / ( )

ºº / Nº total SMS originado y terminado en red propia ( )

º Nº total SMS MOº Entrante

Trafico total en SGW N SMS MO s N SMS MT s Tamaño FSM Tamaño FSM ackN SMS MO s Tamaño SRIfSM

N SGWN SMS MO s Tamaño SRIfSM

N SGWN SMS

= + × + +

× +

× × +

( )s desde interconexion /

º con interconexionTamaño SRIfSM resp

sN SGW

×

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.


- 73 -

• 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.


- 74 -

Red IPRed IP

Red IPRed IP

SMSCIP

HLR

SRIfSM

SGW

STP

SGW

STP

SRIfSM

SGW

STP

SGW

STP

SRIfSM ack

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 redTrafico en HLR ( ) ( )Nº total de HLRs

Tamaño SRIfSM Tamaño SRIfSM response= × +

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:


- 75 -

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


- 76 -

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.

MSC

Red IPRed IP

Red IPRed IP

SMSCIP

HLR

SRIfSM

SGW

STP

SGW

STP

FSM-MO

FSM-MO ACK

SGW

STP

SGW

STP

FSM-MT ACK

FSM-MT

FSM-MO (+ACK) : 1 x SMS-MO en MSC

FSM-MT (+ACK) : 1 x SMS-MO en MSC

SRIfSM (SMSC->SGW): 1 x SMS-MT=1 x SMS-MO

SRIfSM-ACK (SGW o HLR->SMSC): 1 x SMS-MT=1xSMS-MO

SRIfSM ack

SRIfSM ACK

Otros operadores

Otros operadores

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.


- 77 -

Ecuación 3. Cálculo del tráfico en SMSC.

[ ]Trafico total SMSC=Nº SMS-MO 2 ( ) 2 ( - ) ( ) ( - )Tamaño FSM 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”.

MSC1

MADRID 1

ROUTER

SS7/TDM

ROUTER

SIGTRAN

SMSCIP

MSC3

MSC2

HLR1

HLR2

Red IPRed IPRed IPRed IP

SGW

STP

SGW

STP

Figura 30. VLANes SIGTRAN en Madrid-1


- 78 -

MSC1

MADRID 2

ROUTER

SS7/TDM

ROUTER

SIGTRAN

MSC3

MSC2

HLR1

HLR2


SGW

STP

SGW

STP

Figura 31. VLANes SIGTRAN en Madrid-2

MSC1

BARCELONA 1

ROUTER

SS7/TDM

ROUTER

SIGTRAN

SMSCIP

MSC3

MSC2

HLR1

HLR2 SGW

STP

SGW

STP


Figura 32. VLANes SIGTRAN en Barcelona-1


- 79 -

MSC1

BARCELONA 2

ROUTER

SS7/TDM

ROUTER

SIGTRAN

MSC3

MSC2

HLR1

HLR2


SGW

STP

SGW

STP

Figura 33. VLANes SIGTRAN Barcelona-2

MSC1

BILBAO 1

ROUTER

SS7/TDM

ROUTER

SIGTRAN

MSC3

MSC2

HLR1

HLR2


SGW

STP

SGW

STP

Figura 34. VLANes SIGTRAN en Bilbao-1


- 80 -

MSC1

BILBAO 2

ROUTER

SS7/TDM

ROUTER

SIGTRAN

MSC3

MSC2

HLR1

HLR2


SGW

STP

SGW

STP

Figura 35. VLANes SIGTRAN en Bilbao-2

MSC1

SEVILLA 1

ROUTER

SS7/TDM

ROUTER

SIGTRAN

MSC3

MSC2

HLR1

HLR2


SGW

STP

SGW

STP

Figura 36. VLANes SIGTRAN en Sevilla-1


- 81 -

MSC1

SEVILLA 2

ROUTER

SS7/TDM

ROUTER

SIGTRAN

MSC3

MSC2

HLR1


SGW

STP

SGW

STP

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) 45FSM-MO 6,3 288 SMSC-Barcelona 1 Barcelona-1 15

FSM-MT-ac k 28,2 158 SMSC-Madrid 1 Madrid-1 (interno) 36FSM-MT-ac k 20,9 158 SMSC-Barcelona 1 Barcelona-1 26

SRIfSM 1,2 182 Madrid-1 HLR-1 Madrid-1 (interno) 2SRIfSM 1,2 182 Madrid-1 HLR-2 Madrid-1 (interno) 2SRIfSM 1,2 182 Resto HLRs Emplazamientos T1 y T2 2

SRIfSM a c k 2,4 187 Madrid-1 HLR-1 Madrid-1 (interno) 4SRIfSM a c k 2,4 187 Madrid-1 HLR-2 Madrid-1 (interno) 4SRIfSM a c k 2,4 187 Resto HLRs Emplazamientos T1 y T2 4


- 82 -

Tabla 16. Tráfico originado en Madrid-1 SMSC-1

SMSC (SMS MT) / s

Madrid-1 147,6


FSM-MT 28,2 288 SGW-1 Madrid-1 Madrid-1 (interno) 65FSM-MT 28,2 288 SGW-1 Madrid-2 Madrid-2 65FSM-MT 18,4 288 SGW-1 Barcelona-1 Barcelona-1 43FSM-MT 18,4 288 SGW-1 Barcelona-2 Barcelona-2 43FSM-MT 12,1 288 SGW-1 Bilbao-1 Bilbao-1 28FSM-MT 12,1 288 SGW-1 Bilbao-2 Bilbao-2 28FSM-MT 15,1 288 SGW-1 Sevilla-1 Sevilla-1 35FSM-MT 15,1 288 SGW-1 Sevilla-2 Sevilla-2 35

FSM-MO-ack 19,4 158 SGW-1 Madrid-1 Madrid-1 (interno) 25FSM-MO-ack 19,4 158 SGW-1 Madrid-2 Madrid-2 25FSM-MO-ack 0,0 158 SGW-1 Barcelona-1 Barcelona-1 0FSM-MO-ack 0,0 158 SGW-1 Barcelona-2 Barcelona-2 0FSM-MO-ack 24,2 158 SGW-1 Bilbao-1 Bilbao-1 31FSM-MO-ack 24,2 158 SGW-1 Bilbao-2 Bilbao-2 31FSM-MO-ack 30,2 158 SGW-1 Sevilla-1 Sevilla-1 38FSM-MO-ack 30,2 158 SGW-1 Sevilla-2 Sevilla-2 38

SRIfSM 18,4 182 SGW-1 Madrid-1 Madrid-1 (interno) 27SRIfSM 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


SRIfSM ack 4,9 187 SMSC-Madrid 1 Madrid-1 (interno) 7SRIfSM ack 4,7 187 SMSC-Barcelona 1 Barcelona-1 7

HLRs (SRIfSM) / s

Madrid-1 HLR-2 9,7


SRIfSM ack 4,9 187 SMSC-Madrid 1 Madrid-1 (interno) 7SRIfSM ack 4,7 187 SMSC-Barcelona 1 Barcelona-1 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 Tráfico originado en SGW (kbps) T ráfico originado en SMSC (kbps) T ráfico originado en HLRs (kbps) Total (kbps)

Madrid-1 - - - -

Madrid-2 12 117 0 129Barcelona-1 53 70 14 137Barcelona-2 12 70 0 82Bilbao-1 12 86 0 98Bilbao-2 12 86 0 98Sevilla-1 12 100 0 112Sevilla-2 6 100 0 106


- 83 -

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


FSM-MO 19,4 288 SMSC-Madrid 1 Madrid-1 45FSM-MO 6,3 288 SMSC-Barcelona 1 Barcelona-1 15

FSM-MT-ac k 28,2 158 SMSC-Madrid 1 Madrid-1 36FSM-MT-ac k 20,9 158 SMSC-Barcelona 1 Barcelona-1 26

SRIfSM 1,2 182 Madrid-2 HLR-1 Madrid-2 (interno) 2SRIfSM 1,2 182 Madrid-2 HLR-2 Madrid-2 (interno) 2SRIfSM 1,2 182 Resto HLRs Emplazamientos T1 y T2 2

SRIfSM a c k 2,4 187 Madrid-2 HLR-1 Madrid-2 (interno) 4SRIfSM a c k 2,4 187 Madrid-2 HLR-2 Madrid-2 (interno) 4SRIfSM a c k 2,4 187 Resto HLRs Emplazamientos T1 y T2 4

Tabla 20. Tráfico originado en Madrid-2 HLR-1 y HLR-2

HLRs (SRIfSM) / s

Madrid-2 HLR-1 9,7


SRIfSM ack 4,9 187 SMSC-Madrid 1 Madrid-1 7SRIfSM ack 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 Tráfico originado en SGW (kbps) Tráfico originado en HLRs (kbps) T ráfico total (kbps)

Madrid-1 93 14 107Madrid-2 - - -Barcelona-1 53 14 67Barcelona-2 12 0 12Bilbao-1 12 0 12Bilbao-2 12 0 12Sevilla-1 12 0 12Sevilla-2 6 0 6


- 84 -

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 0,0 288 SMSC-Madrid 1 Madrid-1 0FSM-MO 45,0 288 SMSC-Barcelona 1 Barcelona-1 (interno) 104

FSM-MT-ac k 18,4 158 SMSC-Madrid 1 Madrid-1 23FSM-MT-ac k 40,3 158 SMSC-Barcelona 1 Barcelona-1 (interno) 51

SRIfSM 1,2 182 Barcelona-1 HLR-1 Barcelona-1 (interno) 2SRIfSM 1,2 182 Barcelona-1 HLR-2 Barcelona-1 (interno) 2SRIfSM 1,2 182 Resto HLRs Emplazamientos T1 y T2 2

SRIfSM ac k 2,4 187 Barcelona-1 HLR-1 Barcelona-1 (interno) 4SRIfSM ac k 2,4 187 Barcelona-1 HLR-2 Barcelona-1 (interno) 4SRIfSM ac k 2,4 187 Resto HLRs Emplazamientos T1 y T2 4

Tabla 23. Tráfico originado en Barcelona-1 SMSC-1

SMSC (SMS MT) / s

Barcelona-1 142,2


FSM-MT 17,8 288 SGW-1 Madrid-1 Madrid-1 41FSM-MT 17,8 288 SGW-1 Madrid-2 Madrid-2 41FSM-MT 40,3 288 SGW-1 Barcelona-1 Barcelona-1 (interno) 93FSM-MT 40,3 288 SGW-1 Barcelona-2 Barcelona-2 93FSM-MT 4,7 288 SGW-1 Bilbao-1 Bilbao-1 11FSM-MT 4,7 288 SGW-1 Bilbao-2 Bilbao-2 11FSM-MT 5,2 288 SGW-1 Sevilla-1 Sevilla-1 12FSM-MT 5,2 288 SGW-1 Sevilla-2 Sevilla-2 12

FSM-MO-ac k 0,0 158 SGW-1 Madrid-1 Madrid-1 0FSM-MO-ac k 0,0 158 SGW-1 Madrid-2 Madrid-2 0FSM-MO-ac k 45,0 158 SGW-1 Barcelona-1 Barcelona-1 (interno) 57FSM-MO-ac k 45,0 158 SGW-1 Barcelona-2 Barcelona-2 57FSM-MO-ac k 9,5 158 SGW-1 Bilbao-1 Bilbao-1 12FSM-MO-ac k 9,5 158 SGW-1 Bilbao-2 Bilbao-2 12FSM-MO-ac k 10,4 158 SGW-1 Sevilla-1 Sevilla-1 13FSM-MO-ac k 10,4 158 SGW-1 Sevilla-2 Sevilla-2 13

SRIfSM 17,8 182 SGW-1 Barcelona-1 Barcelona-1 (interno) 26SRIfSM 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


SRIfSM ack 4,9 187 SMSC-Madrid 1 Madrid-1 7SRIfSM ack 4,7 187 SMSC-Barcelona 1 Barcelona-1 (interno) 7

HLRs (SRIfSM) / s



SRIfSM ack 4,9 187 SMSC-Madrid 1 Madrid-1 7SRIfSM ack 4,7 187 SMSC-Barcelona 1 Barcelona-1 (interno) 7


- 85 -

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 116Madrid-2 12 67 0 79Barcelona-1 - - - -Barcelona-2 12 176 0 188Bilbao-1 12 49 0 61Bilbao-2 12 49 0 61Sevilla-1 12 51 0 63Sevilla-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

Barcelona-2 45,0




SRIfSM 1,2 182 Barcelona-2 HLR-1 Barcelona-2 (interno) 2SRIfSM 1,2 182 Barcelona-2 HLR-2 Barcelona-2 (interno) 2SRIfSM 1,2 182 Resto HLRs Emplazamientos T1 y T2 2

SRIfSM ac k 2,4 187 Barcelona-2 HLR-1 Barcelona-2 (interno) 4SRIfSM ac k 2,4 187 Barcelona-2 HLR-2 Barcelona-2 (interno) 4SRIfSM ac k 2,4 187 Resto HLRs Emplazamientos T1 y T2 4

Tabla 27. Tráfico originado en Barcelona-2 HLR-1 y HLR-2

HLRs (SRIfSM) / s




HLRs (SRIfSM) / s




Tabla 28. Tráfico total originado en Barcelona-2

Emplazamiento destino Tráfico originado en SGW (kbps) T ráfico originado en HLRs (kbps) T ráfico total (kbps)

Madrid-1 35 14 49Madrid-2 12 0 12Barcelona-1 167 14 181Barcelona-2 - - -Bilbao-1 12 0 12Bilbao-2 12 0 12Sevilla-1 12 0 12Sevilla-2 6 0 6


- 86 -

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




SRIfSM 1,2 182 Bilbao-1 HLR-1 Bilbao-1 (interno) 2SRIfSM 1,2 182 Bilbao-1 HLR-2 Bilbao-1 (interno) 2SRIfSM 1,2 182 Resto HLRs Emplazamientos T1 y T2 2

SRIfSM ac k 2,4 187 Bilbao-1 HLR-1 Bilbao-1 (interno) 4SRIfSM ac k 2,4 187 Bilbao-1 HLR-2 Bilbao-1 (interno) 4SRIfSM ac k 2,4 187 Resto HLRs Emplazamientos T1 y T2 4

Tabla 30. Tráfico originado en Bilbao-1 HLR-1 y HLR-2

HLRs (SRIfSM) / s

Bilbao-1 HLR-1 9,7



HLRs (SRIfSM) / s

Bilbao-1 HLR-2 9,7



Tabla 31. Tráfico total originado en Bilbao-1


Madrid-1 83 14 97Madrid-2 12 0 12Barcelona-1 40 14 54Barcelona-2 12 0 12Bilbao-1 - - -Bilbao-2 12 0 12Sevilla-1 12 0 12Sevilla-2 6 0 6


- 87 -

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




SRIfSM 1,2 182 Bilbao-2 HLR-1 Bilbao-2 (interno) 2SRIfSM 1,2 182 Bilbao-2 HLR-2 Bilbao-2 (interno) 2SRIfSM 1,2 182 Resto HLRs Emplazamientos T1 y T2 2

SRIfSM ac k 2,4 187 Bilbao-2 HLR-1 Bilbao-2 (interno) 4SRIfSM ac k 2,4 187 Bilbao-2 HLR-2 Bilbao-2 (interno) 4SRIfSM ac k 2,4 187 Resto HLRs Emplazamientos T1 y T2 4

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 97Madrid-2 12 0 12Barcelona-1 40 14 54Barcelona-2 12 0 12Bilbao-1 12 0 12Bilbao-2 - - -Sevilla-1 12 0 12Sevilla-2 6 0 6


- 88 -

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) 2SRIfSM 1,2 182 Sevilla-1 HLR-2 Sevilla-1 (interno) 2SRIfSM 1,2 182 Resto HLRs Emplazamientos T1 y T2 2

SRIfSM ac k 2,4 187 Sevilla-1 HLR-1 Sevilla-1 (interno) 4SRIfSM ac k 2,4 187 Sevilla-1 HLR-2 Sevilla-1 (interno) 4SRIfSM ac k 2,4 187 Resto HLRs Emplazamientos T1 y T2 4

Tabla 36. Tráfico originado en Sevilla-1 HLR-1 y HLR-2

HLRs (SRIfSM) / s

Sevilla-1 HLR-1 9,7



HLRs (SRIfSM) / s

Sevilla-1 HLR-2 9,7



Tabla 37. Tráfico originado en Sevilla-1


Madrid-1 100 14 114Madrid-2 12 0 12Barcelona-1 43 14 57Barcelona-2 12 0 12Bilbao-1 12 0 12Bilbao-2 12 0 12Sevilla-1 - - -Sevilla-2 6 0 6


- 89 -

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




SRIfSM 1,2 182 Sevilla-2 HLR-1 Sevilla-2 (interno) 2SRIfSM 1,2 182 Resto HLRs Emplazamientos T1 y T2 2

SRIfSM ac k 2,4 187 Sevilla-2 HLR-1 Sevilla-2 (interno) 4SRIfSM ac k 2,4 187 Resto HLRs Emplazamientos T1 y T2 4

Tabla 39. Tráfico originado en Sevilla-2 HLR-1

HLRs (SRIfSM) / s

Sevilla-2 HLR-1 9,7



Tabla 40. Tráfico total originado en Sevilla-2


Madrid-1 100 7 107Madrid-2 12 0 12Barcelona-1 43 7 50Barcelona-2 12 0 12Bilbao-1 12 0 12Bilbao-2 12 0 12Sevilla-1 12 0 12Sevilla-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.


- 90 -

Tabla 41. Matriz de tráfico SIGTRAN entre los emplazamientos de la red

Madrid-1 Madrid-2 Barcelona-1 Barcelona-2 Bilbao-1 Bilbao-2 Sevilla-1 Sevilla-2

Madrid-1 - 107 116 49 97 97 114 107Madrid-2 129 - 79 12 12 12 12 12

Barcelona-1 137 67 - 181 54 54 57 50Barcelona-2 82 12 188 - 12 12 12 12

Bilbao-1 98 12 61 12 - 12 12 12Bilbao-2 98 12 61 12 12 - 12 12Sevilla-1 112 12 63 12 12 12 - 12Sevilla-2 106 6 57 6 6 6 6 -

Des

tino

Origen

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


- 91 -

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.

Fijo red SIGTRAN Emplazamiento VLAN Nodo

8 bits2 bits 7 bits

Color

3 bits12 bits

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.


- 92 -

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-1, VLAN-1, HLR-2 00001010 00010100 00001001 00000100 10.20.9.4 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, HLR-1 00001010 00010100 00010001 00000010 10.20.17.2 Red "Azul", Madrid-2, VLAN-1, HLR-2 00001010 00010100 00010001 00000011 10.20.17.3 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, HLR-2 00001010 00010100 00011001 00000100 10.20.25.4 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", Barcelona-2, VLAN-1, HLR-1 00001010 00010100 00100001 00000010 10.20.33.2 Red "Azul", Barcelona-2, VLAN-1, HLR-2 00001010 00010100 00100001 00000011 10.20.33.3 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, HLR-2 00001010 00010100 00101001 00000011 10.20.41.3 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", Bilbao-2, VLAN-1, HLR-1 00001010 00010100 00110001 00000010 10.20.49.2 Red "Azul", Bilbao-2, VLAN-1, HLR-2 00001010 00010100 00110001 00000011 10.20.49.3 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, HLR-2 00001010 00010100 00111001 00000011 10.20.57.3 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 Red "Azul", Sevilla-2, VLAN-1, HLR-1 00001010 00010100 01000001 00000010 10.20.65.2


- 93 -

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, HLR-2 00001010 00011000 00001001 00000100 10.24.9.4 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", Madrid-2, VLAN-1, HLR-1 00001010 00011000 00010001 00000010 10.24.17.2 Red "Roja", Madrid-2, VLAN-1, HLR-2 00001010 00011000 00010001 00000011 10.24.17.3 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-1, VLAN-1, HLR-2 00001010 00011000 00011001 00000100 10.24.25.4 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, HLR-1 00001010 00011000 00100001 00000010 10.24.33.2 Red "Roja", Barcelona-2, VLAN-1, HLR-2 00001010 00011000 00100001 00000011 10.24.33.3 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-1, VLAN-1, HLR-2 00001010 00011000 00101001 00000011 10.24.41.3 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, HLR-1 00001010 00011000 00110001 00000010 10.24.49.2 Red "Roja", Bilbao-2, VLAN-1, HLR-2 00001010 00011000 00110001 00000011 10.24.49.3 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-1, VLAN-1, HLR-2 00001010 00011000 00111001 00000011 10.24.57.3 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, HLR-1 00001010 00011000 01000001 00000010 10.24.65.2 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.


- 94 -

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.


- 95 -

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.


- 96 -

Tabla 45. Encaminamientos MTP3 en las MSCs

MSC origen DPC linkset salidaBIT SLS usado para reparto de

carga (0 a 3)

Valor BIT reparto carga

Madrid-1 STP/SGW 3 0








Barcelona-1 STP/SGW 3 0








Bilbao-1 STP/SGW 3 0








Sevilla-1 STP/SGW 3 0








Mitad MSCs Sur

Madrid-1 SMSC

Barcelona-1 SMSC

Madrid-1 SMSC

Barcelona-1 SMSC

Mitad MSCs Norte

Madrid-1 SMSC

Barcelona-1 SMSC

Madrid-1 SMSC

Barcelona-1 SMSC

Madrid-1 SMSC

Barcelona-1 SMSC

Madrid-1 SMSC

Barcelona-1 SMSC

Madrid-1 SMSC

Barcelona-1 SMSC

Madrid-1 SMSC

Barcelona-1 SMSC

Mitad MSCs Centro

Mitad MSCs Este

Mitad MSCs Norte

Mitad MSCs Sur

Mitad MSCs Centro

Mitad MSCs Este

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.


- 97 -

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.


- 98 -

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.


- 99 -

Tabla 46. Asociaciones SCTP en SGWs de la “Red Azul”

SGW Asociación SCTP 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 SCTP 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.


- 100 -

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.


- 101 -

Tabla 48. Configuración M3UA en SGWs

SGW Routing context Routing key Nodo destino SCTP 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




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



T odos

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.


- 102 -

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 GTs de otras redes DPC Madrid-1 STP/SGW DPC Madrid-2 STP/SGW


Grupo 3 de GTs 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.


- 103 -

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.


- 104 -

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.


- 105 -

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.


- 106 -

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 SCTP Asociación SCTP 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

Madrid-1 STP/SGW 1 n (n=[0..7]) (n MOD 8)+1


Barcelona-1 STP/SGW 3 n (n=[0..7]) (n MOD 8)+1


Bilbao-1 STP/SGW 5 n (n=[0..7]) (n MOD 8)+1


Sevilla-1 STP/SGW 7 n (n=[0..7]) (n MOD 8)+1


T odos

DPC=MSC Centro

DPC=MSC Noreste

DPC=MSC Norte

DPC=MSC Sur


- 107 -

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






- 108 -

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 SCTP 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 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 SCTP 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 SMSC 10.24.9.2 8+1 8+1

12 Barcelona-1 SMSC 10.24.25.2 8+1 8+1

Todos (IP origen de la "Red Azul")

Todos (IP origen de la "Red Roja")


- 109 -

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.


- 110 -

Tabla 54. Configuración M3UA en HLRs

HLR Routing key Nodo destino SCT P Asociación SCT P salida Valor SLS decimal Stream salida









9 n (n=[0..7]) (n MOD 8)+1

10 n (n=[8..15]) (n MOD 8)+1

11 n (n=[0..7]) (n MOD 8)+1

12 n (n=[8..15]) (n MOD 8)+1

T odos

Madrid-1 SMSC

Barcelona-1 SMSC

DPC=MSC Centro

DPC=MSC Noreste

DPC=MSC Norte

DPC=MSC Sur

DPC=Madrid-1 SMSC

DPC=Barcelona-1 SMSC

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

- 111 -

55

CCOOMMPPAARRAACCIIÓÓNN EENNTTRREE SSOOLLUUCCIIÓÓNN TTRRAADDIICCIIOONNAALL YY SSOOLLUUCCIIÓÓNN SSIIGGTTRRAANN


- 112 -

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.

MSC

MSC

MSC

MSC

Centro Este

Enlace SS7


STPSTP

STPSTPSTPSTP

STPSTPSMSCSS7

SMSCSS7

Madrid-1

Barcelona-1

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.


- 113 -

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

STP Madrid-1 2048 0 0

STP Madrid-2 2048 5 10

STP Barcelona-1 2048 620 1.240

STP Barcelona-2 2048 620 1.240

STP Madrid-1 2048 620 1.240

STP Madrid-2 2048 620 1.240

STP Barcelona-1 2048 0 0

STP Barcelona-2 2048 5 10

T otal 4.980

SMSC Madrid-1

SMSC Barcelona-1

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.


- 114 -

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 A n c h o d e b a n d a ( k b p s ) D i s ta n c i a ( k m ) M b p s x k m

M a d r i d - 1 - 0 ,0 0 ,0

M a d r i d - 2 129,0 5,0 0 ,6

B a r c e l o n a - 1 137,0 620,0 82,9

B a r c e l o n a - 2 82,0 620,0 49,6

B i l b a o - 1 98,0 395,0 37,8

B i l b a o - 2 98,0 395,0 37,8

S e v i l l a - 1 112,0 540,0 59,1

S e v i l l a - 2 106,0 540,0 55,9

M a d r i d - 1 107,0 5,0 0 ,5

M a d r i d - 2 - 0 ,0 0 ,0

B a r c e l o n a - 1 67,0 620,0 40,6

B a r c e l o n a - 2 12,0 620,0 7,3

B i l b a o - 1 12,0 395,0 4,6

B i l b a o - 2 12,0 395,0 4,6

S e v i l l a - 1 12,0 540,0 6,3

S e v i l l a - 2 6,0 540,0 3,2

M a d r i d - 1 116,0 620,0 70,2

M a d r i d - 2 79,0 620,0 47,8

B a r c e l o n a - 1 - 0 ,0 0 ,0

B a r c e l o n a - 2 188,0 5,0 0 ,9

B i l b a o - 1 61,0 620,0 36,9

B i l b a o - 2 61,0 620,0 36,9

S e v i l l a - 1 63,0 1.046,0 64,4

S e v i l l a - 2 57,0 1.046,0 58,2

M a d r i d - 1 49,0 620,0 29,7

M a d r i d - 2 12,0 620,0 7,3

B a r c e l o n a - 1 181,0 5,0 0 ,9

B a r c e l o n a - 2 - 0 ,0 0 ,0

B i l b a o - 1 12,0 620,0 7,3

B i l b a o - 2 12,0 620,0 7,3

S e v i l l a - 1 12,0 1.046,0 12,3

S e v i l l a - 2 6,0 1.046,0 6 ,1

M a d r i d - 1 97,0 395,0 37,4

M a d r i d - 2 12,0 395,0 4,6

B a r c e l o n a - 1 54,0 620,0 32,7

B a r c e l o n a - 2 12,0 620,0 7,3

B i l b a o - 1 - 0 ,0 0 ,0

B i l b a o - 2 12,0 5,0 0 ,1

S e v i l l a - 1 12,0 933,0 10,9

S e v i l l a - 2 6,0 933,0 5,5

M a d r i d - 1 97,0 395,0 37,4

M a d r i d - 2 12,0 395,0 4,6

B a r c e l o n a - 1 54,0 620,0 32,7

B a r c e l o n a - 2 12,0 620,0 7,3

B i l b a o - 1 12,0 5,0 0 ,1

B i l b a o - 2 - 0 ,0 0 ,0

S e v i l l a - 1 12,0 933,0 10,9

S e v i l l a - 2 6,0 933,0 5,5

M a d r i d - 1 114,0 540,0 60,1

M a d r i d - 2 12,0 540,0 6,3

B a r c e l o n a - 1 57,0 1.046,0 58,2

B a r c e l o n a - 2 12,0 1.046,0 12,3

B i l b a o - 1 12,0 933,0 10,9

B i l b a o - 2 12,0 933,0 10,9

S e v i l l a - 1 - 0 ,0 0 ,0

S e v i l l a - 2 6,0 5,0 0 ,0

M a d r i d - 1 107,0 540,0 56,4

M a d r i d - 2 12,0 540,0 6,3

B a r c e l o n a - 1 50,0 1.046,0 51,1

B a r c e l o n a - 2 12,0 1.046,0 12,3

B i l b a o - 1 12,0 933,0 10,9

B i l b a o - 2 12,0 933,0 10,9

S e v i l l a - 1 12,0 5,0 0 ,1

S e v i l l a - 2 - 0 ,0 0 ,0

T o ta l 1.280,8

S e v i l l a - 2

B a r c e l o n a - 2

B i l b a o - 1

B i l b a o - 2

S e v i l l a - 1

M a d r i d - 1

M a d r i d - 2

B a r c e l o n a - 1


- 115 -

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.


- 116 -

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.


- 117 -

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.


- 118 -

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.


- 119 -

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.


- 120 -

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

emplazamientos

En media la mitad que en la

solución tradicional.

El doble que la solución SIGTRAN.

Coste de los SMSCs Plataformas más baratas. Plataformas más caras.

Coste de la red Necesario ampliar hardware y

adquirir routers y switches.

Utiliza hardware ya instalado en

STPs. Coste menor.

Flexibilidad de la plataforma Plataformas abiertas. Muy

flexible.

Soluciones cerradas. Poco flexibles.

Capacidad de la Red Gran ancho de banda.

Encaminamientos dinámicos.

Ancho de banda más limitado. Sólo

encaminamientos estáticos.

Comportamiento ante congestión Es posible descartar tráfico en

función de distintos tipos.

Descarta paquetes sin distinguir tipo

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

con una red de transporte de

tráfico de control sobre IP.

A largo plazo tenderá al desuso.

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.


- 121 -

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.

BIBLIOGRAFÍA

- 123 -

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. Disponible en: http://www.ietf.org/rfc/rfc2960.txt. [Consulta: 9 de febrero 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.


- 124 -

Disponible en: http://www.ietf.org/rfc/rfc3057.txt. [Consulta: 9 de febrero 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]

Documents

ÍNDICE - dit.upm.esenrique/pub/jbento-Memoria.pdf · • CAMEL Protocolo de Red Inteligente normalizado específico para redes de telefonía móvil