Are You Feeling Lucky?

Abstract

Scheduling content onto pervasive displays is a complex problem. Researchers have identified an array of potential requirements that can influence scheduling decisions, but the relative importance of these different requirements varies across deployments, with context, and over time. In this paper we describe the design and implementation of a lotterybased scheduling approach that allows for the combination of multiple scheduling policies and is easily extensible to accommodate new scheduling requirements.

Scheduling Content in Pervasive Display Systems

“…[37,39,56,65,90]). However, systems to support scheduling are less frequently at the foreground in pervasive display research (for exceptions, see [8,31,62,70,78,83]), and requirements for selecting items for presentation are implicit rather than overtly expressed (for one notable recent exception, see [8]). In order to understand the generalised set of scheduling requirements for future display networks we draw on three distinct sources:…”

“…In our architecture [ Figure 2], this process is handled by a selection manager, receiving the eligible items and reducing them down to a single item. Whilst the selection manager itself could be considered a black box, we incorporate into our architecture recent work by Mikusz et al [62], who propose that lottery scheduling approaches may be well-suited to this problem. Section 5.3 explores lottery scheduling as a solution for Stage 3 in more detail, but our overall architecture folds in core components for lottery ticket storage and allocation.…”

“…Instantiated in 2004, the e-Campus system is the world's longest running and largest public display research testbed, and is in daily use as the main digital signage system at Lancaster University. While aspects of the e-Campus scheduling system have previously been described in [18,21,35,62], this represents the first attempt to describe the components of the e-Campus system in the context of a unified scheduling architecture.…”

“…Contextual events arrive in the form of a combination of metadata (expressing the type of event) and a CDS (should the event include a content schedule request). The incoming event is parsed and stored within Yarely's Context Store -a lightweight SQLite database on the local file system [62].…”

“…Yarely initiates its content scheduling process with its implementation of the Filtering stage. This is realised in the form of a processing pipeline (previously described in [62]): the parsed CDS is passed through a pipeline of independent filtering components which each remove items that are not eligible to be played in the target context. The filters are not executed in parallel, instead each filtering operation generates a CDS result that consists of equal or fewer items than it received as input; this new CDS is passed on to the next filter in the pipeline.…”