The transport broker’s role is then to provide a simple and implementationindependent view of available content – effectively the broker gives the view that it had access to all content and in any format that was required, and its underlying services moved content to support this view and external technical services enable content processing when required, Fig. 19.4b. This cloud implementation enabled automatic load balancing of content transfers and also the pre-emptive format conversion and placement of content to satisfy predicted content requests.

This (as we view it now) cloud approach also extended to the organisations and the technical services within the broadcasters – effectively creating a locationindependent collection of broadcaster clouds. A broadcaster cloud managed the output for a particular broadcaster and cooperated with its affiliates. This approach enabled the broadcasting cloud’s role to be changed dynamically. Thus, all broadcasters could act independently, or act to the same schedule or to change the role as to which broadcaster was managing the core schedule – bringing resilience to the broadcast infrastructure. A more detailed discussion of the architecture, the supporting broadcasting services and a broadcasting service management infrastructure can be found in [3, 9].

19.3  An On-demand Digital Media Cloud

Gridcast was focused on issues internal to a broadcaster – the sharing of content and technical services that enabled the broadcaster to fulfil its business role. This is still a significant issue to a broadcast and indeed any technical organisation. However, as discussed earlier, a mainstream broadcaster must manage this traditional broadcasting role along with managing access via satellite, digital terrestrial broadcasting and increasingly on-demand content access – each of which places different requirements on the broadcast infrastructure.

In addition, the broadcasting economy has changed significantly over the last 3 years. The broadcaster would have once expected in-house resources to manage the content workflow from commissioning through to delivery to the consumer; today, the broadcaster must interact with an increasingly diverse collection of service providers, each delivering one component of the final product (e.g. post-production, subtitle, playout, etc.) Each of these service providers must be integrated within the content workflow and be part of the broadcast content management infrastructure. In essence, there is a content economy, as depicted in Fig. 19.5, where content is traded and shared across broadcasters and service providers.

It is commonplace for broadcasters to cooperate in sharing technical resources and content. Basic technical services might be contracted to third-party specialist media companies, delivery of content to platforms might be managed by a broadcast company, such as Red Bee in the UK who provide playout services for a number of broadcasters, and web content managed by a web streaming specialist. This diverse economy places significant emphasis on managing relationships between economy members.

Fig. 19.5  A media economy

In Fig. 19.6, the high-level service architecture for the PRISM infrastructure is depicted. At the core of the architecture is a cloud store that manages all content within the infrastructure – this cloud store is a development of the one used within the Gridcast infrastructure and is a managed, loosely coupled collection of individual cloud stores that provide a single view of all available content. The user has a collection of devices on which content may be accessed. These devices use commercial gateway providers to provide content for a user – so a satellite box is necessary for access content from satellite transmissions, a broadband network box provides access to the Internet, etc. The role of the infrastructure is to enable managed access to the content that is available to the user enabling multi-platform content access.

Within a broadcaster, broadcast control staff interact with the content cloud to manage the availability of content – for example, broadcasting schedulers managing content release or legal specialists reviewing and commenting on content prior to its release. The content cloud is supported by local in-house and third-party service providers that enable content to be prepared and refined for release – for example, providing content conversion or specialist quality control services.

To the broadcaster, a platform is managed by a content provider that has an established (and often contractual) relationship with that broadcaster to provide content to users – this relationship will define when content will be made available, for how long it is available and in what form it is provided by the broadcaster and by the provider to the user. The exchange of content may also require the exchange of supporting metadata to enable the content to be indexed and classified by the provider – for example to enable its designation to be suitable for particular age groups or to enable user searches for locating particular content.

The traditional ways to manage this type of business relationship would require human control of the transfer or (more recently) using automated content management workflows as part of content development lifecycle management. In the PRISM infrastructure, the focus is on automation and fine-grained control of behaviour and the approach is to control behaviour using content policies that focus on individual content management and expected behaviour given operations and events on that content. A content policy is a Security Access Mark-up Language (SAML) [10] document that specifies who exercises control over content, the operations that can be performed and by which type of user, and any consequent action that should be performed if an operation succeeds or fails. Each user and service within the infrastructure is identified by a security credential that identifies

Fig. 19.6  Content provider infrastructure

them and their role within the infrastructure – for example, specifying an individual as a scheduler for particular content. Individual content can have a specific content policy and extend, restrict or relax generic content policies for the group or genre of content it belongs to. Thus, a global broadcast policy might be defined, which is refined by an affiliate broadcaster; this in turn is refined by its genre and specialised