NFV (Network Function Virtualization)

y si los equipos de telecomunicaciones fueran como una notebook o una pc de escritorio... o... como una maquina virtual 

En telecomunicaciones tenemos experiencia de trabajar con equipos los cuales pueden realizar tareas de conmutación de paquetes, conmutación de circuitos, operaciones de tasación, radiobases emisoras de ondas electromagnéticas entre otras plataformas o nodos con funcionalidades únicas que requieren tiempo y dedicación a fin de ser conocidas.

Cada área en las telecomunicaciones tiene sus equipos y conocimientos, tales como los nodos de acceso (bts, nodoB, enodeB), transmisión (ipran, dwdm, sdh) y core network (ggsn, sgsn, mgw, msc, ims) que poseen características y hardware específicos para realizar sus tareas. Son para nosotros estas plataformas herramientas incuestionables con hardwares específicos únicos para estas tareas, que, si bien se realizan upgrades de software de versión con mínima o nula modificación de hardware, es difícil verlos como una CPU+Placa Madre+Memoria RAM.

Sin embargo, supongamos nuestros equipos de telecomunicaciones son como computadores simples, como una notebook o una pc de escritorio. Y, supongamos tenemos una habitación llena de computadores con distintos sistemas operativos y distintas capacidades para proveer la función de telecomunicaciones. Debido a que se tendrá una gran cantidad de equipos, con distintos sistemas operativos, con distinto hardware y capacidades se requerirá de un gran equipo técnico y especializado en cada rama de plataformas. Además, si se desea implementar una nueva función se necesitara de un nuevo computador.      

En un mundo muy cercano, y muy conocido, ya ha ocurrido este escenario. Los ingenieros de IT ya se han encontrado con esta situación y han avanzado a un escenario más eficiente con la virtualización de plataformas. Esto seria, utilizar un gran computador el cual simule la función de varios computadores. No quisiera ahondar en virtualización, pero el beneficio directo es la facilidad de trabajar en un solo equipo y la complejidad es que este equipo se comporte como varios. Al entrar en detalle, tal vez no sea exactamente este el escenario para todos los casos, pero, mantengamos el concepto simple.

Ahora, utilizare este link https://en.wikipedia.org/wiki/Network_function_virtualization a fin compartir en forma sencilla sobre una base técnicamente fuerte.

El primer paso para el NFV(Network Function Virtualizacion) es identificar la función que realiza una plataforma, y, convertir a esta función en apta para correr sobre una plataforma virtualizada. Esta sería una Virtualized Network Function (VNF)

Posteriormente la infraestructura sobre la cual corre el VNF, al cual se lo llama NFVI. Esta infraestructura responde al hardware y software sobre la cual corren los VNF.   

Por último, cuando hablamos de sistema virtualizados, existe un administrador de todas las implementaciones en un servidor, la memoria que consumen, orquestación entre otros roles que forman parte de la tecnología que hace posible la virtualización. El encargado de esta tarea es el NFV-MANO.

En su conjunto, logran la tecnología VFN

En adelante, los beneficios deberían apuntarse a experiencias de sistemas virtualizados. Sistema distribuidos, distribución de datacenters, expansión o recursos compartidos que son beneficios de la virtualización (estos beneficios muchas veces nos hacen perder el foco de que es un NFV e incluso se confunden con otras implementaciones, pero el concepto debe siempre girar en torno a la virtualización)

Ahora, ¿qué equipos pueden virtualizarse? Por el momento tenemos casos de SBC, firewalls, y otros. En general las plataformas de VAS tienen una fuerte relación IT y posee tendencia a la virtualización, pero el termino NFV no es habitual en ellas. Una opinión, pero, no puedo fundamentarlo, es que se están trabajando sobre tecnologías o plataformas relacionadas al futuro y en constante desarrollo como IMS, pero, aun no hay mucho avance en relación a tecnologías de circuitos (MSC, MGW) o tecnologías vigentes maduras y críticas en el mercado (MME, PGW) – este comentario por supuesto sujeto a corrección y espero puedan compartir al respecto.

De por si la técnicas de virtualización en los sistemas, o, lo que exploraremos en un posterior articulo SDN (separación de control y flujo, centralización de control), no son prácticas nuevas. Se han aplicado en menor escala y bajo otras figuras a fin de lograr un mejor rendimiento. Sin embargo estamos en una corriente de re ingeniería de las tecnologías a fin de lograr una aplicación más global, estandarizada y general de estas arquitecturas.

Creo que una pregunta se nos viene a todos a la mente: Donde está la línea que separa a las telecomunicaciones de  IT?

Diferencias entre HSS y HLR

Cuando inicialmente analice este tema busque algún artículo en el cual basarme. En general se mencionan a estos los elementos como muy similares en funcionalidad, siendo uno la evolución del otro. En mi experiencia puedo decir que las redes 2G y 3G requerían de un HLR (Home Location Registe) para funcionar, y con la llegada de LTE se requirió un nuevo elemento llamado HSS (Home Subscriber Server)

No tengo el acercamiento técnico que poseía cuando inicie este blog, situación que uno siempre extraña, pero realizare mi mejor intento por diferenciarlos. Tengo la certeza que no proveeré una buena diferenciación, así que cordialmente les pido puedan enriquecernos con sus comentarios.

Primeramente parto de él porque estos elementos son equivales, cuál es su punto en común.

a-     Autenticación del Usuario: Todos los usuarios mobiles tienen simcards (aquí en Paraguay los llamamos comúnmente chips) los cuales tienen una numero serial (IMSI). Con ese número de IMSI es con el cual uno intenta ingresar a la red, y es el HLR o HSS quien se encarga de aceptarlo o rechazarlo. Por ejemplo, supongamos tenemos una simcard de AT&T en nuestro teléfono e intentamos registrarnos a la red de Verizon. El HLR o HSS es quien recibe esta IMSI y verifica este número no está dentro de su lista, por lo cual rechaza el intento de ingreso. El intento a la red AT&T sin embargo seria exitoso

b-     Individualización del Usuario: Para información relativa al usuario que no sea crédito (o como en Paraguay lo llamamos saldo) el HLR o HSS es quien se encarga de manejarlas. Por ejemplo el número de teléfono (ej: +595 931 123456) se define en el HLR o HSS. Esta plataforma es la encargada de guardar una gran cantidad de información relativa del usuario y en cierto modo la relaciona al simcard mediante el número IMSI. A la información que se relaciona al usuario se llama perfil del usuario

c-      Autorización del Usuario: Toda red tiene servicios, y voy a explicar el concepto que se maneja de servicios con ejemplos debido a que personalmente siempre me confundió. Existen servicios tan básico que olvidamos incluso que se llaman servicios los cuales son servicio de voz, servicio de internet LTE, servicio de internet EDGE/3G (diferenciamos internet de distinta tecnología, no es lo mismo ojo). Otros servicios un poco menos generales son buzón de voz, desvió de llamadas, roaming internacional. Es en el HLR o HSS donde se habilita que servicios puede utilizar el usuario. Ejemplo: para un módems USB podrían habilitarse solamente los servicios de internet y deshabilitarse los servicios de Voz.

d-     Información de Red: De modo a establecer más rápidamente la comunicación se guarda información de red de la última acción del dispositivo. Por ejemplo, en el HLR se guarda la celda donde se realizó la última acción y es en esa celda donde se inicia su búsqueda cuando se origina un proceso de llamada

Palabras más, palabras menos, estas son las funcionalidades similares del HLR o HSS. Pero, como la experiencia lo dicta, son elementos que responden a tecnologías distintas lo cual hace que sean equipos distintos.  LTE responde a una red plenamente paquetizada, y 2G/3G tiene su dualidad circuitos y paquetes.

En los links abajo puede verse que información se guarda en cada una de las plataformas

HSS: http://www.in2eps.com/fo-sdata/tk-fo-sdata-hss.html

HLR: http://www.in2eps.com/fo-sdata/tk-fo-sdata-hlr.html

Si bien inmediatamente se identifica que la información guardada en si es distinta, también puede identificarse que los elementos de red a los cuales se conecta son distintos así como también los protocolos.

Incluso al ser redes distintas, los servicios que se proveen son distintos por lo cual los campos de autenticación del perfil del usuario serán distintos.

Con todas estas diferencias fue lastimosamente irreconciliable reutilizar al HLR y se optó por una nueva plataforma llamada HSS. Aun así, como es muy común tener redes 2G/3G/4G desplegadas simultáneamente existen plataformas que proveen las funcionalidades de HLR y HSS en el mismo equipo.

Quisiera cerrar este artículo denotando una diferencia en particular. Las redes 2G/3G poseían redes de circuito por lo que para las llamadas se relacionaba un número de teléfono. Las redes LTE son redes solamente de paquetes (siendo brutamente claros, son redes para internet) que no permiten el tráfico de voz. Mediante un protocolo llamado SIP se crea un escenario de llamadas de voz en una red de paquete, y la forma de identificar un usuario en SIP es mediante una URI con el siguiente formato "sips:user@example.com". El HSS incluye es su base de datos este nuevo campo necesario para la identificación del usuario en SIP y a su vez debe relacionarlo con un número telefónico a fin de mantener el formato de comunicaciones telefónicas.

OTT (Over the Top)

Cuando hablamos en telecomunicaciones de servicios la respuesta para el pasado era muy simple: Llamadas y SMS

Posteriormente, con la llegada del GPRS, se podía comenzar a navegar (2G / EDGE) a velocidades que eran relativamente aceptables para la época, donde existían varias limitantes: una de ellas si el teléfono soportaba el formato

Actualmente, en una operadora, existen muchos servicios que se ofrecen al consumidor final: Ring Back Tone, Miss Call Alert, Video Voice Mail, entre otras (mas y menos convencionales de acuerdo a la región).

Todos estos servicios representan elementos dentro de la red que el operador maneja y sobre el cual tiene beneficios: El RBT viene asociado con contenido el cual genera ganancias para el operador y el proveedor de contenido

Todo este modelo que mencione arriba ha cambiado drásticamente en los últimos años debido a las aplicaciones OTT (Over The Top)

Las aplicaciones OTT son aplicaciones que funcionan por encima de la red, que no representan ningún elemento de red y no están ligadas directamente a la red. Debido a esta denominación están vinculadas directamente a conexiones por internet.

OTT son Skype, Whatsapp y Viber que proveen servicios (muchas veces competencia del operador) pero mediante los recursos de una red externa, donde solo se utiliza la conexión a internet (actualmente lo suficientemente robusta para proveer servicios que requieren gran ancho de banda)

La ventaja de un OTT es que no posee costos de infraestructura grandes, es decir, solo pone un servidor por el cual provee las aplicaciones. Esta facultad es la que le permite proveer servicios incluso gratis para atraer abonados. Tampoco está ligado a una estructura de red, lo cual lleva a ofrecer servicios entre lugares distantes (incluso interconexiones internacionales) indistintamente… para el OTT, es lo mismo.

La desventaja es que se requiere de un teléfono de última generación (un smathphone) para acceder a las aplicaciones, donde la aplicación no puede garantizar que el servicio sea entregado en forma debido a que no existe ningún tipo de control de calidad (ya que los servicios están fuera de la red). Se requiere también de cierto conocimiento para la instalación de algunas aplicaciones y nuevas costumbres

La actualidad es que los servicios OTT están llevándose gran parte del mercado de las aplicaciones debido a estos factores 1) Proveen servicios sin costo 2) Conexión (ya sea operador o Wifi) incluso utilizando como input el número de teléfono 3) Aplicaciones globales

Es este el momento en el cual los Operadores ven nuevos desafíos frente a los OTT y queda reaccionar ante tal amenaza. Son estos los tiempos que definen cual será el nuevo rumbo a seguir en las telecomunicaciones: Serán los “Operadores” los proveedores de servicios o solo un tubo que los conecta al proveedor final?

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.