MTP

MTP significa transferencia de mensajes (Message Transfer Part)

Se refiere a las secciones más básicas de la señalización SS7 en capas. Estas capas se refieren a enlace físico, funcionalidad de link y capa de red

MTP Layer 1

Esta capa define la conexión física en la que se transfieren los mensajes desde un nodo a otro.

Esta capa especifica principalmente como se transmiten los bits desde un nodo a otro, sin abarcar su significación u agrupación

En las redes E1 o T1, la capa física puede ser un timesplot del frame E1 o T1

Las interfaces pueden ser frame completo E1 (2048kbps), un canal E1(32 canales de 64kbps), frame completo DS-1 (1544kbps), un canal DS-1 (24 canales de 64kbps), V.35 (64 kb/s), DS-0 (64 kb/s) y DS-0A (56 kb/s)

MTP Layer 2 (MTP2)

Esta capa se encarga de definir la funcionalidad del link entre los nodos mediante distintos controles.

El contenido no es analizado en esta capa sino que simplemente se define un mecanismo con el cual se asegura que el mensaje llego correctamente

- Detección de Errores y Secuencia de Checkeo mediante delimitadores de inicio/fin y protección mediante CRC

- Retransmisión de mensajes desconocidos

Existen 3 tipos de paquetes utilizados en MTP2: Fill-in Signal Unit (FISU), Link Status Signal Unit (LSSU), Message Signal Unit (MSU).

MTP Layer 3 (MTP3)

Esta capa se encarga del enrutamiento dentro de la red SS7.

Funciona del siguiente modo. Cada elemento dentro de la red SS7 posee una única dirección llamada Point Code (PC). Luego en el mensaje se define el punto de destino DPC (Destination Point Code) y se envía dentro de la red. En la red existen elementos llamados STP (Signaling Transfer Point) que analizan el destino y se encargan de encaminar el mensaje (tomando conocimiento cuando algunas rutas están deshabilitadas, utilizar otras)

CDR

Un Call Detail Record o simplemente CDR es un archivo que posee la información detallada de una llamada realizada. Por cada llamada realizada existe su respectivo CDR con la información detallada del sistema que corresponde a esta llamada.

Un CDR puede poseer la información de la celda donde se inicia la llamada y donde termina la llamada, pero sin duda debe poseer la información del número inicio y destino. Por supuesto como todo registro se obtiene una relación del equipo que suministro la información así como fecha/hora.

Principalmente se utiliza el CDR para determinar el cobro en un sistema post-pago, sin embargo también puede darse otros usos. El ejemplo de CDR que tenemos a continuación por ejemplo fue elaborado para un proceso criminal y en este caso sirvió como evidencia.

El CDR es generado una vez finalizado el proceso, es decir, cuando se finaliza la llamada. La plataforma encargada de monitorear y establecer el proceso mantiene en memoria la información necesaria y una vez terminado su ciclo genera el archivo CDR que es almacenado

Como existen más procesos que solo los de llamada, como por ejemplo SMS, RBT, WAP que también requieren de documentación se aplica el mismo proceso extendido a estas plataformas, sin embargo, cada plataforma posee su información correspondiente

En la actualidad, cuando hablamos de CDR no podemos dar fe que este registro es de llamada, sino que puede ser de otro elemento de red el cual cumple con la función de registro

SMSC... continuacion

Ahora que miro la información que corresponde para SMSC  y veo la información la cual suministre ya 2 años atrás, creo podría haber subministrado más información

A fin de continuar con un análisis más profundo y más completo en relación a esta plataforma vamos a verificar los tipos de mensajes de acuerdo a su inicio/destino

Los posibles destinatarios o emisores de mensajes son

Persona: Sería el teléfono que posee todo usuario, es decir, es una línea telefónica destinada para un usuario normal (del cual lo más probablemente tú seas uno)

Aplicación: Los mensajes de aplicación son generalmente emitidos por aplicaciones, tal como puede ser un servidor o plataforma. Los mensajes de campañas de publicidad masivos o mensajes de notificación de llamada perdida por el HLR/RBT pueden verse como mensajes de aplicación

Así podemos clasificar a los mensajes como

P2P (Persona a Persona): Envío de un mensaje de una persona a otro (el mensaje de texto más común)

P2A (Persona a Aplicación): Envío de mensaje de una persona a una aplicación dentro de la red. Un ejemplo son las subscripciones a sorteo que en lo general son enviar un mensaje a un numero corto (“auto” al 611)

A2P (Aplicación a Persona): Envío de mensaje de una aplicación a una persona. Un ejemplo es el envío de mensaje de notificación del HLR cuando se llamó al usuario y este tenía el teléfono apagado.

Como comente en el post anterior, el proceso de envío de mensajes consta de dos parte: A)el envió del mensaje del inicio a la SMSC B) La remisión del mensaje de  la SMSC al destino

El primer paso es MO (Mobile Origination) y MT(Mobile Terminating)

La sección MO funciona del siguiente modo

Al partir el mensaje del usuario A el mensaje llega a la red de acceso (puede ser BTS/BSC o NodoB/RNC) del mismo modo como lo realizan todos los mensajes hasta la MSC. La MSC es quien discrimina que tipo de mensaje es enviándola a la plataforma que se encarga de los mensaje, la SMSC.

Aunque no es parte del proceso de mensajes, es necesario que el usuario este registrado en la red. De este modo el MS(Mobile Station) debe haber procedido al Access Request y Autenticación necesaria para cualquier usuario en la red.  Se realiza en un procedimiento el cual involucra al MS y VLR, donde el VLR tiene el perfil del HLR en su memoria (en caso de no tenerla, hace un pedido al HLR)

Posteriormente el terminal envía el SM mediante un Message Transfer al MSC que a su vez se comunica con el VLR para interrogar al mismo si el usuario posee los servicios necesarios para el envío de mensajes mediante un sendInfoFor-MO-SMS.

De aquí en más, el mensaje se encamina a la SMSC del abonado. Para lle SMSC se pasa por una SMS-IWMSC que luego envía un Message Transfer.

En este punto se debe pasar de una red a la otra mediante interconexión entre las SMSC. Es decir, el mensaje que posee una de las SMSC debe ser transferido a la SMSC del abonado B

Podría ser un nube SMPP, o conexión directa.

De aquí en más la SMSC de destino debe determinar donde debe continuar el envío del mensaje

En base a esto se realiza un requerimiento de ruta al HLR mediante un SRI_SM, el cual se responde con la información de ruta

Finalmente el mensaje es enviado a la MSC/VLR al cual está registrado el abonado de modo a entregar el mensaje

IMS – Plano de Control

La funcion principal del Plano de Control es el establecimiento de sesiones entre usuarios. IMS es una arquitectura que responde al protocolo SIP y la mayoría de los elementos pueden verse como una evolución del SIP Proxy Server, cada uno de ellos tomando una regla del procesamiento de mensajes SIP. Los servidores de SIP llamados CSCF(Call Service Control Funtion) son definidos en tres elementos: P-CSCF(Proxy), I-CSCF(Interrogating) y S-CSCF(Serving)

De modo a mantener los principios escenciales del protocolo SIP se separan los planos de control y de media . En IMS es necesario que los terminales (UE User Equipment) poseean su propia IP para traficar, que a su vez será el modo de establecer la conectividad IP requerida por el IMS.

El P-CSCF es un único punto de contacto con el Plano de Control del IMS para todos los IMS User Equipment (IUE). Toda los mensajes SIP enviado del IUE deben pasar por el P-CSCF hacia otro elemento del Plano de Control. El P-CSCF funciona como un firewall para tanto autenticación como QoS. El UE debe ser poseer una dirección P-CSCF antes de poder registrarse al dominio del IMS. Esto puede darse manualmente o estableciéndose dinámicamente mediante procedimientos DHCP/DNS o durante la creación de un GPRS context. En el proceso de registro, el UE establecerá una conexión segura con el P-CSCF para la señalización SIP

El I-CSCF es el punto de entrada para el dominio administrativo. Cada requerimiento inicial perteneciente a este dominio será recibido por el I-CSCF. Esto significa que un DNS público debe configurarse con el I-CSCF para cada dominio con punto de entrada preferido SIP. Como el I-CSCF será publicado en un servidor DNS interno, este nodo puede ser de acceso externo al dominio. Tener en cuenta que este primer contacto con este dominio podría implementar features adicionales como THIG(seguridad),ALG(Aplication Level Gateway), etc. En este caso, puede reverenciarse al mismo como un elemento IBCF (Inner Border Gateway Control Function)

El S-CSCF puede jugar el roll de registro SIP o interfase del Call Server con el Plano de Servicios y el servidor de aplicaciones. Como registro, debe autenticar a los usuarios y almacenar su dirección de contacto SIP de modo a identificar a los UE públicamente. Con Call Server, debe asegurar el establecimiento del dialogo SIP e invocar los servicios correspondientes a la subscripción del usuario.

Por definición, I-CSCF y S-CSCF están localizados en el dominio administrativo del usuario mientras el P-CSCF puede localizarse en la red visitada por el usuario (esto en situación de roaming). El S-CSCF es dinámicamente asignada a un usuario en el proceso de registro por el I-CSCF, de acuerdo a los criterios de la base de datos central.

Además de los servidores SIP se encuentran la base de datos central que provee información de usuarios. Esta base de datos es referida como HSS y puede ser vista como una evolución del HLR. La información relacionada a permiso de establecimiento de sesiones, autorización y autenticación están contenidas en el HSS. El HSS ayuda al I-CSCF en el proceso de asignación S-CSCF para un usuario entregando las capacidades requeridas al servidor.

Aun SIP es el protocolo para creación de sesiones, otros nodos de la red acceden al HSS utilizando Diamete, el cual es una evolución del Radius.

IMS - Capas

El IMS es una arquitectura relacionada a la telefonía móvil y fija, donde el fin es converger tanto las telecomunicaciones como la transmisión de datos más estrechamente. La convergencia es llevar los circuitos conmutados a una tecnología relacionada a IP, donde el pico de iceberg actualmente es el IMS.

Para analizar el IMS podemos dividirlo en planos. Un plano de Servicios, un plano de Control y un plano de Media. Los planos de Media y Control se comunican mediante un plano Media Control plan basado en protocolos como MEGACO o H.248.

El plan de Media apunta generalmente a transportar un flujo de RTP y se compone principalmente de equipamiento IP (así como routers, switches o gateways).

El plan de Control permite el establecimiento de protocolo SIP y tiene acceso a la información de todos los usuarios a modo a proveer autenticación y service’s accouting.

El plan de Servicios maneja como claramente lo indica su nombre a los servicios, y contiene todos los servicios de la plataforma IMS. La evolución en esta capa o plan nos lleva a una reducción de complejidad en la infraestructura permitiendo un menor tiempo de integración.

El IMS poseería el control de los distintos tipos de acceso donde la real convergencia depende en gran parte de la adaptación basada en la red de acceso actual y las capacidades de terminal del abonado.

Como abonado, el gran beneficio del IMS es la capacidad de la red de proveer los mismos servicios cualquiera sea la red de acceso utilizada. Esto es posible debido a la centralización de procesos de ejecución. El Call Server del plano Control (llamado S-CSCF: Serving Call Service Control Funcion) es el responsable de invocar el servicio de aplicación basado en los criterios relacionados base de datos central. El S-CSCF obtiene estos criterios (llamados Inicial Filter Criteria) durante el registro del abonado a la red IMS. Lo que es notable aquí es que el servidor esta siempre alocado en la Home Network (en la red origen del abonado) lo cual garantiza servicios de roaming pueden accederse en forma transparente.

Festividades = Congestión

Es un clásico en las fiestas de Año Nuevo y Navidad poseer alta congestión. Es tan normal atravesar esta fase de congestión que ya enviamos saludos y felicitaciones horas antes del pico de trafico el cual apunta a la medianoche… aún así, siempre existe esa necesidad de llamar por lo menos a esa persona especial a las 12 y por supuesto se manifiesta la congestión. Navidad y Año Nuevo no son los únicos casos, toda conglomeración de llamadas genera congestión. Ej: En grandes conciertos de rock en celdas en la zona.

Aquí va la pregunta, bueno, ¿porque existe congestión? Y sencillamente porque los sistemas de telecomunicación no están diseñados para masivas llamadas simultaneas. Si lo pensamos bien, todo colapsa, los locales nocturnos colapsan, los taxis son insuficientes, los negocios abarrotados… es decir, ningún sistema esta preparado para una estampida de gente requiriendo servicios.

¿Podría un sistema de telecomunicaciones evitar la congestión de año nuevo? La repuesta es sí, pero no sería rentable

La ejemplificación más clara sería comparar la congestión con un Local Nocturno. Supongamos este Local Nocturno tiene una capacidad de 1.500 personas. Durante el año el promedio de personas que asiste los fines de semanas es 1.000, razón por la que existen espacios y comodidad debido a estar bien dimensionado para suministrar servicios. Ahora, en el Año Nuevo el numero de personas que ingresa al local no son 1.000, no son 1.500… sino son 3.000… teniendo en cuenta existen 10.000 mas afuera esperando se de algo de espacio. Los 3.000 están claramente disconformes pues no se puede dar un buen servicio a tanta cantidad y afuera 10.000 que darían el alma para estar dentro. Ahora, si expandimos al Local Nocturno a 13.000 personas no tendríamos congestión de personas en Año Nuevo, pero durante el año los 1.000 clientes asiduos no ingresarían suficiente dinero para mantener una infraestructura para 13.000 personas. Es así como la congestión en Festividades es algo con lo cual debemos lidiar… o sencillamente dejar a ir a los Locales Nocturnos en Año Nuevo.

Finalmente, si durante el año existe congestión permanente en una zona es signo claro de expansión… pero Año Nuevo, Navidad y Festividades no responden a parámetros de planificación.

Voz Sobre LTE – VoLTE

Voz Sobre LTE – VoLTE

Las especificaciones de la tecnología LTE no se dan de modo a proveer voz sino apuntando hacia datos. Se proyecta de ese modo un servicio de voz ejecutado mediante la tecnología VoIP.

Los operadores sin embargo han visto a la voz por IP como una gran falta en el sistema, en parte por su falta de regulación que desemboca por ejemplo en el servicio de Roaming y SMS. Siendo que en general el 80% del ingreso de los operadores moviles proviene de Voz y SMS, es necesario estandarizar estos escenarios de LTE.

Papel de QoS en LTE

A diferencia de las tecnologías de telecomunicaciones anterior (ej: CDMA, GSM y 3G), LTE no provee un canal dedicado para circuito conmutado de telefonía. LTE es un sistema full IP el cual provee conexiones IP del teléfono móvil al core network. Esta comunicación full IP puede ser dada mediante la estandarización VoIP.

Como IP responde a paquetes donde no se prioriza uno de otro, en general se tienen un flujo de datos randomico para una transmisión. Sin embargo de modo a establecer un canal de voz debe asegurarse una taza de datos, y el asegurar esta taza de datos debe responder a un servicio de QoS(Quality of Service) disponible.

Opciones de Voz Para LTE

Existen desarrollos de modo a proveer a LTE con voz, de los cuales se han delineado los siguientes (3):

1- VoLGA

Esta basado en el estandar 3GPP Generic Access Network(GAN)

2- CSFB (Circuit Switched Fall Back)

Este sistema se enfoca mantener el escenario de llamadas en 2G y 3G, en este caso, cuando ingresa una llamada en LTE el telefono cambia a la tecnología 2G/3G para recibirla.

Esta especificación permite llevar los SMS como se llevan hoy día. Todo esto es posible mediante una interfaz con los SGs y LTE en la que se envían los mensajes.

3- Voice over LTE, VoLTE basics

Esta se basa en las especificaciones de el IMS, adoptando esta solución para integrar un suite de aplicaciones.

Para proveer el servicio VoLTE se debe definir 3 interfases:

User Network Interfase (UNI): Esta interfaz esta alocada entre el equipo del usuario y el operador de red.

Roaming Network Network Interfase (R-NNI): Es una interfaz entre la operadora Local y en la que se realizar el Roaming de modo a establecer una señalización.

Interconnect Network Network Interfase (I-NNI): La interfaz entre operadoras que requieren establecer un canal de voz.

En muchos aspectos VoLTE es una aproximación de alto nivel así como directa, la cual requiere necesariamente de un core IMS.