The fokusOn platform - 24i/fokuson-developer-portal GitHub Wiki

Back

The fokusOn platform

Introduction

fokusOn is a platform that helps operators and content owners deliver and manage the TV and Video on-demand experience on a wide range of devices. Here you can read more information on how the platform is structured and hopefully understand more about the product you are working on.

Product Definition

fokusOn is a service delivery platform (SDP) that PayTV operators can use to manage their TV and Video offerings. It handles:

  • the subscribers and their access to services

  • the definition of services and how they are bundled together

  • the content descriptions or meta data, to assist the end user in using the services

  • the management of the end user experience

  • the gathering of usage data for billing and further improvement on UX and services.

Once, deployed it acts as a hub between BSS and OSS systems, securely connecting your end users to your content and services around it.

Frontend

On the frontend the user interfaces change from operator to operator not just the colours and graphics, but also the navigation and features. In 2008, Nordija introduced the widget concept. A widget is a small independent component which in concert with others make up the frontend application. Every user interface component across all devices can be managed and users can receive differentiated user interfaces based on configuration on the backend. Nordija choose UX Management rather than management of information, traditionally known as web content management.

Backend

On the backend side, integrations with major vendors in the industry required Nordija to build abstractions to CAS, DRM, Streaming servers and other OSS and BSS systems. Today fokusOn offers an extensive set of APIs and integrations also towards the end user devices. Again, utilizing the Widget concept, a small integration layer ensures that widgets run across different devices, making them portable.

Architecture

The system consists of a number of components that individually handles a part of the total solution. These components are shown in the diagram below. Besides the client devices apps and user interfaces, the light blue areas are components delivered as part of Nordija's solution. Since Nordija's solution effectively is the same as a traditional web server, the components appear to be more on the backend.

architectureBig.png]

In the following the components are briefly described.

  • Caching layer Once, the devices boot up they are all instructed to contact the portal server of fokusOn and pull the user interface widgets from the server. These are all cached at the Varnish layer before delivered over http/https to the client devices.

  • EPG cache fokusOn holds the electronic program guide data in a cache to ensure a swift response for all request from the various clients. This info is loaded from the meta data storage of fokusOn, every time the data is refreshed or re-ingested to ensure as accurate information as possible. This component keeps track of what EPG info is needed and when it should refresh. It also understands how to answer more complex queries without hitting the backend and its database. Finally, it collaborates with the Varnish cache layer to ensure speed.

  • Batch job: Meta data ingestion A batch job is handling the import of EPG and VOD meta data.

  • Batch job: Origin server control Another batch job is handling network recordings.

  • ** Statistics gathering** fokusOn statistical module gathers information about how the user is using the frontends as well as what is being consumed across all client devices. It’s built as a separate service to ensure that gathering of statistics never interferes with the core TV service.

  • Ads Create and control advertisements on the platform. This can be banner ads, Pre-Post Roll and special commercials.

  • Portal The portal service is the component that acts like a web server and delivers the user interface components (i.e. widgets) as well as provide access to all the API calls needed to provide information about the customer, the device, the streams, the channels and what else the customer is entitled to.

  • Admin The management of everything that the customer should have access to as well as the subscriber- and content management functions of the platform is handled through this web interface.

  • Provisioning/API A comprehensive API is providing the information needed to build a custom front-end. Covers all aspect of an advanced TV/Video service: customer, products, recordings, profiles, VOD, EPG, channels, pre-roll, preferences and more.

  • XMPP messaging fokusOn uses a standard chat service XMPP, for some communication between clients and between client and server. The highly scalable Tigase server is installed to handle the routing of messages.

  • MySQL Database To store meta data and all information about subscribers and their services etc. fokusOn uses MySQL. Redundancy is achieved using a circular replication setup with two master server instances which allows for one active at a time and the other is hot standby. Finally, a separate MySQL database can be added to handle the storage from the stats components

  • Event system fokusOn comes with an event pump that besides being used internally it can also be used from external systems to be notified on certain events happening.

  • Execution environments The execution environment is typically Java based on the server side. Many of the services are using a specially tailored JBoss application server which runs on a Java Virtual Machine version 1.8. On the client side, widgets and user interfaces are done in HTML5/CSS and JavaScript combined with what is required to make that run on the operating system in question. fokusOn clients expect a web browser to be present either in the STB vendor’s firmware as with Arris KreaTV stack, or provided by the fokusOn delivered apps as in the case of Android and iOS. AppleTV with its tvOS is a special case. Here the widgets are done using TVML, but with the JavaScript elements reused.

Operation

The following is a description of how fokusOn operates in a sort of “A day in the life of fokusOn”. See the data flows on the picture below. The Head End delivers a number of live channels available as IPTV IGMP multicast and as ABR streams using a combination of encoders, transcoders and streaming servers and made available on the network.

[fokusonBig.png]

The Client Devices consisting of STB’s and/or TVE devices starts up by reaching out to fokusOn in order to first identify themselves and the to pull user interface and to learn what services this device should offer. Once the device has been identified, the customer account information is looked up and a combination of code to drive the device, widget user interface elements and what the user should have access to is delivered along with EPG and VOD meta data describing the content offered. Now and then the device will issue a heartbeat request to the backend, handing over usage information and getting information about any updates to the service, meta data, schedule recordings and widgets. The client device will be following this, silently in the background perform the update if needed.

Finally, when the device is up and running the user can start tv and video consumption from the head end. Should the user have scheduled any recordings then these can either be locally performed or handled by a network recording service. In case of the latter, this typically also means that a number of time-shifting TV and on-demand catch up TV services are available. Here fokusOn acts as a controller of the network recording service informing it what should be kept of all the recordings that has been configured to continuously be recorded i.e. a provisioning of the origin server in the Content Distribution Network is handled as a batch job by fokusOn.

The content providers offer meta data to describe what is available from them and here fokusOn handles the ingestion. This typically delivered as an XML feed of sorts where fokusOn during the ingestion phase will make a transformation to an internal format and store this in the meta data database along with all original artwork. During this transformation process a number of flags controlling the network recording options are imported. These can be used by the content provide to control if sports can be recorded and/or restarted from scratch. Similar rules can also be set up on the channels so the number of days that the user can go back in the EPG to start a previously aired program can be controlled. Also features like fast forward and skip ahead can be limited per channel to ensure no adverts are missed. The PayTV operator can put these channels together in bundles of channels and define network recording services with variations of storage size. Furthermore, they can define video on-demand services with a number of different business models such as TVOD, AVOD, FVOD and SVOD available. Also, in combinations. The VOD meta data can be slides and merged into different VOD shops allowing the creation of themed VOD shops such as Kids Corner, Adult and TVOD for latest movies and SVOD for the rest, as an example. The PayTV operator’s business support systems (BSS) can provision fokusOn with information about customers, subscriptions on channel bundles etc while also pulling the service for billing information delivered in what is known as Video Detail Records or VDRs. fokusOn takes care of the provisioning of some operation support systems (OSS) such as the network recording origin servers, but it can also manage the conditional access services and provide them with entitlement requests such as when a user rents a movie or the BSS provisions a customer with a subscription on a new channel bundle.

Back to Top

⚠️ **GitHub.com Fallback** ⚠️