19 The PRISM On-demand Digital Media Cloud |
329 |
chain for traditional terrestrial broadcasting in the Gridcast project [3]. More recently, we have been working with a wider range of partners1 to demonstrate the use of network-centric applications and cloud infrastructures to create dynamic, highly scalable infrastructures to support the multi-platform digital media infrastructure
In this chapter, we discuss the evolution of our early cloud work within the Gridcast project into the dynamic service cloud that is used to support on-demand content access within the PeRvasive Infrastructure of Services for Media (PRISM) project. The PRISM infrastructure has been in field deployment for over 2 years to support a test consumer group. It provides content access via a set-top box to streamed or downloaded content from the BBC, or streamed content directly to networked enabled devices, such as mobile phones, computers and games consoles. The PRISM infrastructure uses autodeployment and auto-scaling and has no human operators managing the service infrastructure – infrastructure is auto-provisioned when required and failed services are re-deployed automatically when failure is detected. This automation acts as a market of resources that are capable of hosting services and services that need compute resources.
19.2 A Media Service Cloud for Traditional Broadcasting
Traditional terrestrial broadcasting is a complex operation – traditional broadcasters, like the BBC, are usually collections of affiliate or regional broadcasters that operate sometimes to the same broadcasting schedule and sometimes modified versions of a core broadcasting schedule. The infrastructure is most often built to assume the distribution of live content from a controller location. In the simplified example of Fig. 19.1, as discussed later, three of the BBC’s regional networks (BBC Northern Ireland or BBCNI, BBC Scotland and BBC Wales) are fed from a large-scale store of content centralised in London.
Content for the common core, or network, schedule is distributed at its scheduled broadcast time (as-if-live) to the affiliates for distribution to the supported platforms. Broadcast automation manages content delivery to the broadcast platforms that are supported. If content is not being broadcast at the scheduled network time, then it is recorded at the affiliate for time-shifting and that content is managed locally. The core network infrastructure is designed to support live and high-quality video transmission – which will always be an important part of the broadcasting infrastructure requirements.
19.2.1 Gridcast the PRISM Cloud 0.12
The traditional broadcasting infrastructure model, outlined above, gives a robust and reliable infrastructure – however it does reduce the flexibility of the business
1 Partners in the later work included Qinetiq plc and BT plc.
2 The diagrams here depict the services as clouds are from the initial technical discussions with the BBC in the summer of 2003.
330 |
T. Harmer et al. |
Fig. 19.1 BBC nations and regions infrastructure
as it makes customisation and consumer market targeting more difficult for the affiliates. In the Gridcast project, we created a cloud infrastructure to support the traditional broadcasting activities that were deployed and in test use in autumn 2003 – it was written using the Globus Toolkit Version 3, developed initially in GT3 Alpha1 and it tracked GT3 development to an architecture release to coincide with that Globus toolkit release (Fig. 19.2).
The Gridcast infrastructure consisted (from today’s perspective) of a collection of service clouds that provided the outward presence of the affiliate broadcaster and the associate core network control. The services permitted remote technical service sharing and the coordination of content output – one of the early motivations was in line with the grid ideas of permitting resource sharing and optimisation of infrastructure usage.
The support of schedule-based broadcasting is implemented by content being shared from the central repositories or the broadcasters themselves to the point of use. Thus, for example, the scheduling services for BBCNI would request a copy of the content to support its scheduled output – live output, such as for news programmes, is shared using a live network feed. This architecture thus defined a typical IT focused content sharing network with collections of repositories sharing content.
19 The PRISM On-demand Digital Media Cloud |
331 |
Fig. 19.2 (a) Broadcaster Cloud. (b) Broadcaster Services
However, sharing is not just a simple matter of copying content. Content sharing must be performed securely and the Gridcast infrastructure had a role-based security model that used role-annotated X509 digital certificates [5] to denote the rights of a requesting user – and thus all requests for content where made using secure service exchange that validated these user credentials. Each individual content item within the infrastructure could have an associated security policy that defined who could copy the material and indeed where it could be stored and for how long. In practice, the rights to content were defined by a few large-scale content policies based on the genre of the content; for example, a policy that defined news content or one for drama. A content policy could require that content was shared in a rightsprotected fashion and thus demand a key to unlock it for viewing.
In addition to security considerations, content sharing across the Gridcast infrastructure was managed to support scheduled broadcasting – storage within the regional broadcast locations is limited and the content is not required for extended periods by the individual affiliates. The Gridcast content movement was organised by a transport broker that was driven by the broadcast schedule and the quality of service required by that schedule, as depicted in Fig. 19.3.
The Transport Broker is charged with organising content movement within the broadcast organisation to ensure that each affiliate has the content required when it is required and in the correct broadcasting format – if a required format did not exist when requested, then it would be created in time for the required sharing of that content. Within the infrastructure, we integrated a collection of transport types that varied from open source, such as GridFTP [7], proprietary content delivery networks to live switched feed. The selection by the transport broker was made using a market-driven approach – each transport offers its QoS for a transaction and
332 |
T. Harmer et al. |
defines an associated cost of delivering that QoS and the broker chooses based on the required QoS and the cost defined by the requester.
This content-sharing approach brings significant business benefits to the broadcaster and its affiliate broadcaster enabling them to construct reactive schedules tailored to the needs of the target audience. Further, sharing can be from copies of content held across the broadcaster community and not just the central content repositories, enabling load sharing of content requests across the broadcasting infrastructure. The Transport Broker API evolved within the Gridcast infrastructure towards the end of the project (2004) to manage the various content stores within the broadcast infrastructure as a collection of content storage clouds, as depicted in Fig. 19.4a.
Fig. 19.3 A content broker for content sharing
Fig. 19.4 (a) A content cloud. (b) The Gridcast service cloud.