En este segundo artículo de la serie BSS/OSS vamos a hablar de los sistemas OSS. Aquí voy a intentar explicar nuestra forma de afrontar este tipo de desarrollos con el último estado del arte de la tecnología. El modelo de negocio de red neutra que se está llevando a cabo en España se apoya en la compra masiva de pequeños y medianos operadores. Este tipo de operaciones se conocen como M&A, de merges (fusiones) y adquisitions (adquisiciones). Este proceso de fusiones y adquisiciones junto al dinamismo del sector de las telecomunicaciones presenta una serie de desafíos. Por citar algunos de ellos: migración de los clientes del sistema del comprador al vendedor, redimensionamiento de la red del comprador para adaptarse a los nuevos requisitos u homogeneización de los sistemas.
Una vez planteado nuestros problemas vamos a ver qué soluciones podemos encontrar implantando un sistema OSS.
OSS se define como los «Sistemas de soporte a las operaciones» (Operational Support Systems) y hacen referencia a sistemas de información empleados por las empresas operadoras de telecomunicaciones. El término OSS por lo general describe a los «sistemas de red» que están directamente vinculados a la red de telecomunicaciones misma, por ejemplo: procesos de soporte para el mantenimiento del inventario de red, servicios de aprovisionamiento, configuración de los elementos de red y software para la gestión de fallas.
Cómo podemos leer en la definición anterior extraída de la wikipedia, se hace mención a una serie de subsistemas. En este artículo me centraré en alguno de ellos por la criticidad que tienen en el modelo de negocio que se está llevando a cabo en España.
Provisioning
El primer sistema que vamos a analizar es el sistema de aprovisionamiento. Para no complicar excesivamente el escenario vamos a hablar de redes FTTH. Aunque se puede dar el caso que la red adquirida estuviera implementada con otra tecnología como wifi. Cuando afrontamos un proceso de M&A esta será una de las primeras decisiones que deberemos abordar. Los problemas habituales que podemos encontrar en esta parte del proyecto son ausencia de documentación, sistemas propietarios, gran variedad de modelos de ONT, etc…
A estos problemas de tipo técnico se unen problemas de tipo logístico, ya que la migración de los clientes se debe producir sin pérdida del servicio. El último componente de complejidad puede ser el sistema de negocio que esté fuertemente acoplado al sistema de red. A continuación voy a describir algunas soluciones técnicas.
En el caso del aprovisionamiento es interesante contemplar el sistema de aprovisionamiento como software en vez de hardware. Para ello utilizamos técnicas de Netdevops. La dinámica de los fabricantes tiende a ofrecer «Zero touch provisioning». Los protocolos a considerar en esta parte serían OMCI, TR069, etc.. En nuestro caso en entornos heterogéneos con mucha variedad de ONT, preferimos el uso de TR069. Esta decisión nos permite hacer menos dependiente las configuraciones del hardware.
Los servidores ACS exponen el sistema a través de webservices y se puede incluir entonces la configuración dentro de los procesos de CD/CI. Este proceso de automatización es importante cuando nos enfrentamos a migraciones de miles de clientes. Otro aspecto a tratar cuando estamos en un escenario de red neutra con tamaños considerables, entre 100 000 y varios millones de unidades instaladas (uuii’s), es cómo gestionamos el almacenamiento de las configuraciones.
En el caso de redes del tamaño mencionado anteriormente nos podemos encontrar con cientos de OLT’s. En algunos casos con diversas marcas y modelos conviviendo en la red. Para el caso de las configuraciones es interesante acercarse a la configuración como elementos dentro de un control de versiones. Utilizar git y python nos facilita la automatización de este control de versiones. Si estamos hablando de equipos de red el uso de yang y netconf permite incluir los dispositivos de red dentro del flujo CD/CI.
Otro aspecto importante a tratar en el modelo neutro es cómo se van a ofrecer esta provisión de los equipos a los operadores que van a explotar la red neutra. Cuando diseñamos los servicios rest o gRPC, que van a servir como interfaz con nuestro sistema a los operadores, hay que definir un modelo de estados. Este modelo de estados tiene que contemplar eventos como la ausencia de recursos y otro tipo de eventos. Además estos servicios devolverán valores de monitorización de las ONT’s.
Acceso L2
Otra configuración a tener en cuenta a la hora de diseñar la red neutra es el servicio de acceso L2 que se va a proporcionar a los operadores que exploten la red. En este punto hablamos de C-VLAN y S-VLAN. En estos diseños se tienen varias alternativas. Por un lado el modelo de VLAN dedicada (1:1 VLAN) y por otro lado el modelo de VLAN compartida (N:1). La utilización de tipo de tráfico según VLAN influye directamente en el modelo de negocio que se ofrece, siendo habitual tener varios tipos de tráfico con tarifas diferentes y dando la posibilidad de ofrecer tráfico garantizado. Es una práctica habitual asociar el precio de un servicio a un tipo de tráfico y a un ancho de banda. El ancho de banda se puede ofrecer con diferentes capacidades y es el operador el que adapta esas capacidades a sus servicios. Hay que tener en cuenta que estas redes serán utilizadas por operadores mayoristas que ya ofrecen servicios en otras partes del territorio.
Como podéis apreciar en el artículo el diseño de una red neutra plantea desafíos importantes. En próximos artículos intentaré explicar otras partes importantes en el diseño de una red de estas características.
Referencias:
https://tools.ietf.org/id/draft-ietf-netconf-zerotouch-19.html
