Esquemas de entrega de contenido de IPTV



En nuestro blog, nos centramos en las publicaciones en Internet, el trabajo de los operadores de telecomunicaciones y todo lo relacionado con esto. Sin embargo, en este mont贸n de informaci贸n variada, hicimos una estupidez completa olvidando por completo la Televisi贸n Digital, que se ha convertido en una parte integral de las actividades de los operadores de telecomunicaciones sin la cual el proveedor ya no estar谩 completo. En este art铆culo, hablaremos sobre los conceptos b谩sicos de la organizaci贸n de IPTV y, en particular, tocaremos los principales m茅todos para entregar contenido a los consumidores.

Los proveedores son conscientes de que la organizaci贸n de su propia IPTV es un negocio costoso y, adem谩s, afecta a muchos intereses de otras personas. Al mismo tiempo, muchos proveedores no desean utilizar los servicios de los proveedores OTT, pero todos quieren obtener un servicio decente en sus redes que proporcione una competencia decente entre los proveedores peque帽os y grandes.

Las razones de la falta de voluntad para asociar sus actividades con operadores OTT son bastante obvias:

  • El negocio no pertenece al proveedor de Internet, lo que significa que no est谩 controlado por 茅l: puede quedarse sin un servicio de televisi贸n en cualquier momento.
  • El usuario no est谩 vinculado al proveedor de servicios de ninguna manera: el prefijo del proveedor OTT (si el contrato implica el uso de solo STB de marca) se puede conectar a cualquier fuente de Internet.
  • Ser谩 extremadamente dif铆cil cambiar el proveedor OTT si es necesario: su decodificador de marca ya no es adecuado para nada (esto no es un problema si el software est谩 instalado en un equipo arbitrario). En la mayor铆a de los casos, incluso la marca de software no est谩 disponible.

A menudo, los operadores tienen una idea de d贸nde obtendr谩n el contenido, muchos de ellos incluso tienen acuerdos con canales de televisi贸n (por ejemplo, operadores de KTV), lo que significa que solo necesitan una plataforma que pueda proporcionar la funcionalidad necesaria. Y lo primero que debe hablar sobre los dispositivos de suscriptor: en las realidades modernas, la desviaci贸n de los costos de capital es el elemento de costo principal en el presupuesto de la plataforma.

Hay una gran cantidad de plataformas diferentes que proporcionan el nivel de servicio m谩s diferente para los clientes. Las plataformas m谩s desarrolladas, que proporcionan la m谩xima funcionalidad posible y "caracter铆sticas adicionales", le permiten aumentar ARPU, tanto como sea posible en las condiciones actuales.

Consideremos la situaci贸n utilizando un ejemplo de una plataforma con la m谩xima funcionalidad, de IPTVPORTAL, que permite al operador de los sistemas Middleware y CAS recibir tanto localmente como desde la nube, y como dispositivo suscriptor, la familia de decodificadores digitales Vermax UHD que son totalmente compatibles con la plataforma IPTVPORTAL, incluido un sistema condicional certificado Acceso IPTVPORTAL CAS.

De acuerdo con los requisitos de la ley rusa, los sistemas de acceso condicional utilizados en la televisi贸n digital deben pasar el procedimiento de certificaci贸n. A juzgar por la tendencia establecida de los "pernos de apriete", esto se convertir谩 en un problema urgente en el futuro cercano.

Considere algunos patrones de uso t铆picos, incluido el uso de la tecnolog铆a en la nube. Y lo m谩s importante, la interacci贸n con los propietarios de contenido.

Esquema 1: trabajar con el agregador de contenido a trav茅s de la red



Esencia: no hay una estaci贸n central propia, no hay un servidor MW propio, consolas propias.

Esta es una opci贸n t铆pica para principiantes. No requiere que el operador obtenga una licencia para televisi贸n por cable y concluya acuerdos con canales, no requiere inversiones en la infraestructura de la cabecera. Todas estas funciones las realiza el agregador de contenido. El operador act煤a como un agente.

A diferencia de trabajar con empresas OTT, el operador posiciona el servicio como propio (y gestiona y controla completamente la transmisi贸n de se帽ales en su territorio), es decir, promociona su producto. Si la base de suscriptores crece y desea cambiar el proveedor de servicios o implementar su propio proyecto, puede hacerlo sin ning煤n problema.

Contras:

  • Parte de la forma en que el tr谩fico se entrega fuera de la zona de control del proveedor, respectivamente, depende de otras compa帽铆as.
  • En presencia de todas las desventajas y riesgos de la subcontrataci贸n.
  • La propuesta para el empaque del canal est谩 determinada por el agregador de contenido (y este es el principal inconveniente).

Pros:

  • El servicio de cabecera est谩 en el agregador de contenido.
  • Movimientos corporales m铆nimos, como todo el trabajo contractual con los canales ya ha sido realizado por el agregador.
  • El pago m铆nimo para el agregador de contenido es mucho m谩s bajo que el pago m铆nimo para los titulares de derechos de autor, que a menudo ofrecen comprar otros canales e imponen un n煤mero m铆nimo de suscriptores por los que a煤n tiene que pagar (por lo general, el umbral de requisitos m铆nimos fluct煤a alrededor de 500 y 1000).
  • No es necesario crear su propia infraestructura tolerante a fallas para administrar consolas,
  • Si es necesario usar CAS, su servicio es proporcionado por otra compa帽铆a y, al mismo tiempo, dicho servicio es econ贸mico.

Esquema 2: trabajar directamente con canales de televisi贸n o agregadores de contenido satelital, despliegue de la cabecera



Este esquema casi siempre implica la construcci贸n de su estaci贸n principal. Y Middleware y CAS se proporcionan desde la nube.

La conclusi贸n: la estaci贸n principal, no hay un servidor propio MW.

Este esquema es 贸ptimo para el inicio r谩pido de IPTV en las redes de operadores que ya tienen una estaci贸n principal y tienen acuerdos con canales de televisi贸n (por ejemplo, operadores de KTV).
A menudo, las cabeceras modernas ya tienen la capacidad de generar tr谩fico de IPTV incluso sin comprar equipos adicionales. O, por ejemplo, es bastante simple formar IPTV desde DVB-C.

Contras:

  • El mantenimiento de la cabecera recae en el operador.
  • Niveles de pago m铆nimos bastante altos (para operadores principiantes) para suscriptores, canales y agregadores satelitales.

Pros:

  • Toda la ruta de tr谩fico en la zona de control del proveedor.
  • No es necesario crear su propia infraestructura tolerante a fallas para administrar consolas.
  • Si es necesario usar CAS, su servicio es proporcionado por otra compa帽铆a y, al mismo tiempo, dicho servicio es econ贸mico.

Esquema 3: cabecera propia, instalaci贸n local de Middleware y CAS



Importante: este esquema difiere del esquema 2 solo en que los servidores de Middleware locales y las claves de codificaci贸n CAS est谩n instalados.

Esencia: todo es tuyo.

Pros:

  • completamente tu negocio;
  • sin dependencia de los canales de comunicaci贸n;
  • Se puede vender.

Contras:

Necesita personal para dar servicio al sistema.

Esquema 4: Recibir una se帽al t茅cnica de los socios (sin construir su propia estaci贸n central)



Importante: El Esquema 4 difiere del Esquema 2 en que no necesita construir y mantener su cabecera. M谩s bien, es incluso una variaci贸n del circuito 1. La se帽al t茅cnica proviene de un socio, un agregador de se帽ales t茅cnicas.

Pros y contras ver arriba.

Es cierto que debe entenderse que la instalaci贸n y configuraci贸n de la cabecera es un proceso bastante costoso y complicado. En primer lugar, debido a problemas con la disponibilidad de personal calificado. Y el lanzamiento de la cabecera es un proceso bastante complicado, repleto de matices cr铆ticos.

En general, el operador tiene mucho para elegir, solo necesita comenzar. El art铆culo no pretende ser exhaustivo, pero, sin embargo, muestra que es posible trabajar sin operadores OTT, incluso si no hay deseo de invertir en CAPEX al construir su red. Sin embargo, est谩s desarrollando tu televisor.

Al mismo tiempo, no se debe negar el hecho de que las soluciones OTT tambi茅n tienen sus ventajas y una zona 贸ptima de aplicabilidad. En el evento de primavera CROS-2.0-17, dedicamos m谩s de 2 horas a estas preguntas (recomendamos ver el video).

Una cuesti贸n separada sigue siendo la elecci贸n del equipo del cliente en cualquiera de estos esquemas. La conclusi贸n es que para la seguridad econ贸mica del operador, debe elegir el equipo que no ser谩 in煤til en caso de problemas. Una inversi贸n in煤til, para ser m谩s precisos.

Por ejemplo, en el caso de un proveedor OTT, el cierre de esta empresa (o problemas de licencia) hace posible solo una salida: reemplazar el proveedor de contenido OTT o cambiar a los esquemas anteriores. En este caso, el dispositivo debe poder configurarse \ tener firmware para admitir otro sistema.

Un ejemplo v铆vido recientemente mostr贸 la inaccesibilidad de las consolas Infomir para aquellos que se sentaron firmemente en la aguja del sistema STALKER, y ahora Ministra, que de hecho, solo admit铆a un tipo de consolas (nativas).

En este caso, podemos concluir que tiene sentido no solo usar consolas que admitan varios middleware econ贸micamente factibles, sino tambi茅n viceversa MW, que admiten varias consolas.

Nikolai Mikhailov proporciona todos los esquemas anteriores de IPTVportal. Solo el sistema que puede admitir m谩s de un dispositivo, uno de los cuales es la consola de su propio dise帽o: la familia de consolas digitales Vermax UHD (y en el futuro cercano UHDX), que, a su vez, no solo admite IPTVportal.
Un punto separado es el soporte del sistema CAS, y espec铆ficamente los sistemas CAS certificados en Rusia, pero, de hecho, este es el tema de un art铆culo separado sobre "apretar los tornillos" y nuestras perspectivas.

Source: https://habr.com/ru/post/es410471/


All Articles