Solution Overview

The technical solution includes transcoding of signals to unicast streams,  encrypting unicast and HLS streams and delivering these streams in the operator network, recording unicast and HLS streams, storing and streaming of recorded and VOD content to the end users as well as providing user interfaces on the end user devices to control and consume interactive TV services.

The process of delivering TV service from the TV center to the end users includes the following:

  • Video signal, either satellite and/or terrestrial, is received using antenna system. Video signals travel via splitters to the IRD or receivers. Usually, IRDs are combined together with the transcoders as one system component.
  • IRDs receive video signals, decodes it and send to the video transcoders, either using unicast, SDI or ASI interface. The preferred option is using IP interface with unicast as it simplifies configuration and physical connections between component. The preferred edition, the video signal can be also received from external sources in a format of the unicast stream.
  • Transcoders do the transcoding of the video signals to the required format and send it out, either as a unicast stream for managed network delivery, or HLS chunks. Usually, streams should be encrypted, so they go to the DRM.
  • Unicast streams from the transcoders/transcoders are received by the DRM components, where they are encrypted.
  • For HLS content, either Live TV or VOD, content is encrypted on the OTT transcoders, but encryption keys are exchanged between DRM components and transcoders.
  • For HLS Live streams, after transcoders/transcoders do the segmentation and encryption, HLS chunks are served to the streaming servers, from where it can be delivered to the end users.
  • User devices are accessing our Centre server to authenticate for the service, get the user interface and request specific TV services, such as EPG or request recording of the TV show.
  • When end user device starts to play encrypted content, it requires proper encryption key from the DRM server. DRM server checks the subscriber


Our OTT MW includes server part and different client applications, providing UI, EPG, Catch up TV, nPVR, and other TV functionality to the end users on STB, mobile devices and PC. Proposed client applications are:

  •  OTT STB client
  • OTT mobile client
  • OTT PC client, at a later date

Server  part  consists  of  several  logical  components  that  can  be  installed  on  same  or several servers, based on the capacity requirements:

  • Our Centre Server: responsible for business logic and for providing TV services to client applications. It also interacts with other components such as our Recording Server and DRM to provide end to end TV service.
  • Load Balancing server: It is used to guarantee high availability of the Centre servers if multiple of our Centre servers are used and to provide a common entry point for our OTT clients in some configuration. Load Balancing server is forwarding incoming requests to the active  Centre server and provides failover mechanism in case of active Centre server failure. It is an optional component as usual redundancy of the our Centre is realized with using virtualization on the VMWare platform.
  • Our Message Queue server: It is used for pushing event driven messages from Centre server to the OTT client applications.
  • Our Recording Server: It is used for controlling and executing the nPVR service. If there is no Catch-up TV, ReTV, and nPVR service, The Recording server is not required. Based on the configuration, it can stream the recorded content as well, using HTTP protocol.
  • Storage server: Component for storing recorded or VOD content, that is streamed from a Streaming  server.  Usually,  separate  Storage servers,  VOD Storage and Recording Storage servers are used for the recorded content, and for VOD content.