FTTR (fibra hasta la habitación) está pasando de piloto a despliegue en un número creciente de mercados. La arquitectura es sencilla: la fibra continúa más allá de la ONT hacia el interior del hogar, donde una unidad maestra alimenta unidades esclavas — normalmente una por habitación — sobre fibra dedicada en lugar de backhaul inalámbrico. En hogares donde un solo gateway nunca iba a ofrecer cobertura uniforme, funciona.
Lo que suele pasarse por alto durante la evaluación de proveedores es el efecto de FTTR sobre la cantidad de dispositivos administrados. Un hogar que antes presentaba un gateway ahora presenta una unidad maestra más tres o cuatro unidades de habitación, cada una con sus propias radios, firmware, configuración y modos de falla. FTTR no reduce la carga de gestión: la multiplica.
El problema del silo. FTTR se vende habitualmente como un stack integrado, y cada proveedor entrega su propio controlador, su propia vista de topología y su propia aplicación para el suscriptor. Es una propuesta razonable para un operador estandarizado en un único proveedor de extremo a extremo. Muy pocos lo están. Una red residencial típica opera ONTs de un proveedor, gateways de otro, decodificadores de un tercero — y ahora FTTR de un cuarto. Cada consola adicional es otro inventario que reconciliar, otra integración con el OSS/BSS y otra herramienta que el área de soporte debe aprender.
Integrar, no reemplazar. Un operador no debería tener que elegir entre el hardware FTTR de un proveedor y una capa de gestión neutral. Conserve la tecnología FTTR que eligió por sus méritos técnicos — y adminístrela en el mismo lugar que todo lo demás en el hogar.
Para eso está construido CONTROL. Es agnóstico al proveedor por diseño, y habla TR-069 y TR-369/USP sobre el modelo de datos TR-181, que hoy contempla sistemas Wi-Fi multi-AP. Así, las unidades maestras y de habitación FTTR pueden aprovisionarse, configurarse y monitorearse mediante los mismos flujos de trabajo que el operador ya utiliza para el resto de su parque:
- Aprovisionamiento sin intervención — las unidades maestra y de habitación se configuran solas en la primera conexión, aplicando SSID, seguridad y parámetros de servicio de forma consistente en todo el hogar.
- Un único flujo de firmware — campañas programadas y control de versiones sobre las unidades FTTR y todos los demás tipos de dispositivo, en lugar de un proceso distinto por proveedor.
- Topología normalizada — árboles de parámetros propietarios mapeados a conceptos comunes: hogar, gateway, unidad maestra, unidad de habitación, backhaul, cliente.
- Aseguramiento de Wi-Fi — calidad de señal, utilización de canal, interferencia y experiencia del cliente evaluadas por habitación, con el motor de automatización reconfigurando dispositivos a medida que se cruzan los umbrales.
- Integración con OSS/BSS — una sola API REST que cubre dispositivos FTTR y no FTTR por igual.
El beneficio operativo se ve en la mesa de soporte. Cuando un suscriptor llama, la pregunta rara vez es si el servicio está caído: es qué eslabón de la cadena está degradado. Con las unidades FTTR en el mismo inventario que la ONT y el gateway, un agente puede distinguir una falla de PON de un backhaul degradado hacia una habitación, o de interferencia alrededor de una sola unidad, sin recorrer varias consolas para reconstruir el panorama.
FTTR no es una razón para alejarse de la gestión de dispositivos basada en estándares. Es un argumento a favor: más dispositivos por hogar, más proveedores por red y más necesidad de una única vista operativa sobre todos ellos.