Architecture

As with any complex software system, the NAGRA OpenTV Platform system is made up of several software modules working together. Most of this complexity is hidden from client developers, however, as only some modules are client facing, and all are fronted by an HTTP router.

The purpose of this page is to give some insight into the whole system to better understand how the data flows between modules and the inter-module and system dependencies.

Architecture diagram

Below is a diagram outlining a theoretical system architecture for OpenTV Platform. Deployed solutions typically have a smaller subset of the modules available from Nagra, depending on the service provider's requirements, and the third-party systems they already have in place. 

Where third-party components are typically used, they are also shown as a generic system with some responsibility, rather than a specific third party's system. Other Nagra PU modules are shown for reference.

The diagram shows some of the (simplified) routing details of the architecture. From the perspective of client devices, the IP Network and HTTP routers can be considered transparently, for example, the SDP can be directly queried by a remote client, even though in reality the request will be routed  through the IP Network and HTTP Router. 

Interactivity between third party systems is not shown.

Software descriptions

This section describes the different modules distributed over separate tables that reflect the context in which they are used.

Third-party systems modules

Nagra does not provide every piece of the puzzle in any deployment. For example, it does not provide things like video platforms (encoders/packages), complex SMS/CRM or billing systems, or payment services. This functionality must be fulfilled by a third-party system.

Module Description
Content Provider

The service provider will usually purchase content from a content provider in the form of broadcast channels that are continuously streamed, or on-demand content that must be stored somewhere before being requested by the clients.

Content providers typically provide metadata regarding the content they provide. This is handled by the CMS.

Recommendation Engine

A Recommendation Engine might be requested by a service provider to improve their customer's experience and purchase rate. A recommendation engine can find links between content based on the metadata provided (by the CMS), and also improve these recommendations based on user-generated activity such as ratings and purchases.

The CDG is designed to allow integration to multiple recommendation engines. It hides the complexities of the recommendation engine from the client whilst providing a consistent interface.

Marketing Engine A Marketing Engine can be used to create and manage promotions and deals. It interfaces with the Offer Management System (OMS) nd the CMS to propagate offers to customers.
SMS/CRM

A service provider will always have an SMS/CRM system that they use to manage their customer's accounts. Our OpenTV Platform (SDP module) needs to know the customer and device details to provide functionality around them.

The SDP can also provide reports to the CRM/SMS.

Client signon requests sent from a third party CRM or SMS are authenticated and authorised by the HDM.

Operator's business/operations system The BSM, MLM, and MLDS modules provide APIs that the operator's business and operations system(s) can connect to.
Video Platform

One or more video platforms are always needed to deliver video content to client devices. The content is typically encrypted and the content key protected by a system such as the Media Access (CAS) or PRM.

Actions such as adding or removing content on a Video Platform can be triggered by the CMS and handled by the Workflow Manager.

Content Delivery Network A Content Delivery Network (CDN) can be used to deliver OTT streaming files to client devices.
Recording Management System The recording management system is instructed by the Locker as to which content to record. This system is also used for Long-term catch-up recordings (coming from the CMS).

 

Nagra head-end modules

A central system is often all that's needed in a Nagra deployment. A central head-end system includes all of the necessary modules and is responsible for responding to all traffic that is not routed to a remote head-end. Roaming devices will usually get routed to the central head-end.

Module Description
BSM The Business Services Management module provides reports. It can be integrated with the operator's business and operations system(s).
CAF

The Cloud Application Framework is a generic helper module that allows certain functionality to be implemented in the head end rather than on the client. It is typically used for operations whose results can be cached, which saves repeating the same operation for each client call. 

For example, CAF can be used to check if a VOD catalogue is empty. The result is then cached and available for all clients.

CAS

The Conditional Access System (CAS) encrypts content where appropriate and sends the encrypted content, as well as clear content and associated metadata, across the broadcast network.

The CMS synchronises channel and product identifiers with the CAS. This allows the client to receive the same identifiers for content and products from both the Multiscreen system and Media Access (CAS) system.

The SDP can send commands to the CAS SMS interface to manage smartcard and smartcard product data. These commands can be actioned on the basis of using the SDP APIs, such as purchase APIs and device and smartcard management APIs.

CDG

The Content Discovery Gateway (CDG) is a gateway service that provides access to recommendations and user activity reporting. It enhances the recommendations retrieved from configured recommendation engines with metadata pulled from the MDS. It also stores reported user activity in the UAV, as well as sending the information to any configured recommendation engine as appropriate.

The CDG is designed to allow integration to multiple recommendation engines. It hides the complexities of the recommendation engine from the client whilst providing a consistent interface and provides response data in the same format as MDS.

CMS

The Content Management System (CMS) is a central to many of the modules within the Head-End. The CMS is responsible for aggregating content metadata provided by content providers for both VOD and BTV content, and provides a GUI for operators to manage the content metadata. It also enables operators to manage workflows (via the WFM) to allow actions to be taken on the metadata or the content itself (for example, image processing, content encryption, time-shifting, and CDN deployment).

The CMS synchronises channel and product identifiers with the CAS.

HDM

The Home Domain Manager (HDM) is responsible for executing service provider-specific workflows during authentication and authorisation. These workflows typically involve the creation or update of account, user, device or product subscription data on the SDP

The HDM acts as a proxy in front of the SDP by fronting signon requests from client devices whilst requesting authentication from a third-party CRM or SMS.

HDM Name Change: The HDM might soon be renamed to Authentication Broker or Authentication and Authorisation Manager.
HTTP Router

The HTTP Router is responsible for client authentication and routing. On successful signon to the SDP, the router will return a token to the client that it can then use to access all other systems. Each module is responsible for authorising the request to itself against the token content.

The HTTP router analyses the address requested in the request and forwards the request to the appropriate service in the local network. The services that the HTTP router can route calls to include:

The router allows the whole system to appear as a single IP to the client. In deployments where remote head-ends exist, a remote HTTP router will route requests to the central head-end where a local remote module is not present.

The HTTP router can also be configured to block or throttle some services, as well as act as a reverse proxy cache. This is most useful when querying the MDS, as requests are user agnostic and so can be very similar.

Apps (static files): If any web applications reside on the remote app servers, the HTTP router can also route traffic to them as appropriate.

IMGP The Image Processor (IMGP) module resizes images (e.g., poster images) for use in various different player UI contexts.
LKR

The Locker service is used for persisting Network PVR recording data. This data is then used by the locker to instruct the network recording management system which content to record.

The locker is designed to be integrated with multiple recording systems. It persists recording requests from clients, sends the request on to the recording system, then persist the response information for retrieval by client devices.

MDRMM

The Multi-DRM Manager is a service that abstracts the DRM server implementation and authorisation systems from client devices or other systems. It provides integration to multiple DRM providers, including Nagra PRM. 

Its APIs support the two modes of license retrieval:

  • Direct mode - in direct mode a client requests licenses directly from the DRM system. The DRM system then requests authorisation to the MDRMM, which in turn requests authorisation from a third-party system or the SDP.
  • Indirect mode - in this mode, the client requests licenses from the MDRMM or a third-party system. After authorisation, the MDRMM then requests the license from the DRM system, and then returns it to the client.

These modes apply only on PRM use cases. For other DRMs the behaviour might vary, although the principles are the same.

MDS

The Metadata Server (MDS) is responsible for providing a scalable platform for the client to retrieve broadcast and VOD metadata. The MDS denormalises the metadata, including any associated products, exported from the CMS for more efficient use by client devices.

The MDS also requests promotion metadata from the OMS to add to its product data.

MLDS The MediaLive Deployment Service (MLDS) is responsible for managing deployment and configuration of modules and upgrades.
MLM The MediaLive Monitoring (MLM) module allows the operator to monitor the operational status of all of the OpenTV Platform's software and hardware components. MLM provides both a GUI and also the capability to forward information to an external operator platform.
MSCS The Multi-screen Capture Service (MSCS) captures recording jobs from Locker and is responsble for telling the encoder what to record.
Nagra Media PRM

As with the CAS, the CMS can manage workflows relating to the Persistent Rights Management (PRM) server. This involves things like retrieving or pushing DRM Ids or triggering content encryption.

The SDP has direct integration support with Nagra PRM for some of its functionality, including device initialisation, license retrieval, and license transformation. In these use cases, the SDP preauthorises the request before it is sent to the PRM server.

The MDRMM provides integration to multiple DRM providers including Nagra PRM. When client devices use direct mode, Nagra PRM serves their request and obtains authorisation from MDRMM, which in turn requests it from a portal such as SDP. In in-direct mode, the MDRMM preauthorises the request from a portal, then sends the request to Nagra PRM.

OMS

The Offer Management System (OMS) allows an operator to define promotions for products defined in or imported into the CMS. These promotions are then delivered to the clients via the MDS. At purchase time, promotions are validated by the SDP.

SDP

The Service Delivery Platform (SDP) is mainly responsible for account and device data management within the multiscreen system, client purchase workflows, and CAS SMS worflows. It can also provide other functionality such as content metadata management and device user data persistence, but this functionality has been taken over by other modules.

The SDP can send commands to the CAS SMS interface to manage smartcard and smartcard product data. These commands can be actioned on the basis of using the SDP APIs, such as purchase APIs and device and smartcard management APIs.

The SDP requires product information from the CMS to facilitate purchase management.

The SDP has direct integration support with Nagra PRM for some of its functionality, including device initialisation, license retrieval, and license transformation. In these use cases, the SDP preauthorises the request before it is sent to the PRM server.

The SDP does not have direct integration to all DRM systems and all their APIs. In some cases, where the SDP exposes an API that requires functionality not provided by direct integration, it uses MDRMM to implement it, for example to retrieve LCM licenses to allow whole-home PVR functionality.

SRM The Session Resource Manager (SRM) is responsible for allocating resources for streaming sessions. For cable, this means allocating frequenecies, while for OTT, it means applying concurrent streaming session limits.
TNG The Thumbnail Generator (TNG) generates thumbnail images from a video stream, which can be used for preview on seek. It can do this for both VOD and live content. (Only seek backwards is supported for live.) The TNG can generate thumbnail images at various different sizes and as a mosaic for mobile use (to reduce the number of requests required).
UAV

The User Activity Vault (UAV) is a persistence and data analytics service that allows clients to report user activity to it as it occurs. Examples could be purchase activity, viewing activity, and ratings, but fundamentally it can store any user-related data. The client can then retrieve this data if needed, for example to show the previous rating values of the current user.

The CMS can pull ratings data from the UAV to enrich the metadata provided to the MDS with content average ratings.

The CDG can be used to push user activity data to the UAV (whilst also pushing data to a recommendation engine).

UGDM The Upgrade Manager (UGDM) handles upgrade queries from client devices. It works with the Nagra PRM's Rollout Manager to provide this functionality. To spread load, the UGDM supports segmentation of devices into groups according to various parameters (e.g., geographic location).
WFM The Workflow Manager (WFM) handles asset workflows from the Video Platform and Recording Management System based on the definitions sent from the CMS and the Locker

 

Customer home modules

The customer home will have one or more devices that connect to the OpenTV Platform head-end. These devices might or might not have some components that are supplied by Nagra.

The home network will have connectivity to the IP network, typically via a router.

Module Description
Nagra Media Player

The Nagra Media Player (NMP) is a media playback application that can play back content secured by Nagra PRM. As well as consuming content delivered over the internet (OTT), it can also play back content transcoded and streamed from an OpenTV 5 gateway, such as recorded content, live tv and VOD. In this scenario it can also act as a companion device to the gateway. NMP is also able to control the gateway remotely.

NMP can currently run on iOS, Android, Apple Mac and Windows PC.

OpenTV 5 Gateway

The OpenTV 5 Gateway middleware is supplied on home gateway Set Top Boxes (STB), which, as well as providing typical STB functionality, provide additional functionality such as wifi access point or routing, and DLNA Digital Media Server capabilities including streaming content to other STBs and transcoded content to companion devices.

OpenTV 5 STB

The OpenTV 5 STB middleware is supplied on Set Top Boxes that typically provide services such as live broadcast browsing, VOD services, and PVR capabilities, when the hardware supports it. These devices can also play back content from a OpenTV 5 gateway. 

White Label Application The NAGRA White Label Application (WLA) is a pre-built application that provides much of the functionality typically required in customer applications, and uses the JSFW. Customers often use the WLA as a starting point for building their own applications.
JSFW (Not shown) The Javascript Framework is a JavaScript library provided by Nagra that provides a helpful wrapper layer to ease integration for applications using the OpenTV Platform head-end, OpenTV OS, or OpenTV Player. As well as abstracting some of the integration complexities away from the application developer, it also provides some UI helper functionality to aid in the rapid development of STB and Companion device apps.