Architecture

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.

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.

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.

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.

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.

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.

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.

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.

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.

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:

• HDM
• CDG
• MDS
• Locker
• MDRMM
• SDP

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.

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.

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.

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.

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.

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.

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.

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).

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.

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.

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.