e-Campus – an overview rodger lea

1. e-Campus – an overviewrodger lea

2. What is it • … a unique testbed for large scale ubiquitous computing systems deployment and experimentation. The overall aim of e-campus is to create a large-scale facility that provides ubiquitous computing applications for all staff, students and visitors to the university campus.

3. why • Interface metaphors for public displays • Eg, how can one user access a public display without reducing the utility for others • Impact of pervasive computing technology on university population • Eg, does knowing what is happening where lead to better space usage • Support for rapid content creation • Eg, how can users quickly create and deploy content centric apps/services • Context and information provision • what context aware services are of value to a large campus population • Privacy in sensor rich environments • Eg, can we tailor information and still protect privacy

4. Approach and Timeline • E-Campus is an ambitious project • Complex infrastructure and deployment issues • Wide range of research questions and research disciplines • Start – March 2004, 2 year program • ‘Vision’ calls for 4 year development • Initial 2 phase approach • Phase 1: 5 small scale prototypes – understand key issues • May 04 through to Jan 05 • Phase 2: initial deployment of campus wide infrastructure • Jan 05 through to March 06

5. Initial prototypes - Underpass • Interactive media wall in underpass • Aims: • Understand deployment issues for projectors • Understand Content creation for e-Campus • Initial prototype • Interactive art piece – sensor based • Deployed Oct 2005

6. Initial prototypes - spine • Interactive panels on public walkway • Aims: • Develop canonical ubicomp appl • Explore interaction models • Develop core software infra • Initial prototype • Planned to follow underpass • Possible reuse of core software • Creation of affiliated project – steerable projectors

7. Initial prototypes • InfoLab21 Navigation • Navigation system using displays and doorplates • Aims: • Explore message based communication in semi wild environments • Use of displays to foster community • Technology and ethnography tracks • Investigations in office as well as domestic environments • Folded into Hermes project and evolving into CASIDE • CASIDE – situated displays • Original timeline: May 04 – Dec 04 • Status (Oct05): Small scale Hermes deployment in InfoLab • (Hermes has carried out a set of external deployments/test)

8. Initial prototypes • Fairy Lights • SMS driven display prototype using low cost lights • Aims • Viability of low cost display technology • Network issues in deploying low cost ‘addressable’ lights • Original timeline: May 04 – Dec 04 • Status (Oct05): In progress, prototype under construction, Demo target Dec 05. Patent application underway

9. Initial prototypes • Library info system • Display campus wide computing lab status in library • Aims: • Provide real-world (and useful) data to campus population • Explore bluetooth for local interaction • Original timeline: May 04 – Dec 04 • Status (Oct05): • Basic system deployed in library since Oct • advanced system in final prototyping at Bark farm. • Exploration of blue-zone concept

10. Status Oct 2005 • 4 of 5 prototypes deployed • 3 in use on daily basis • Underpass generated significant publicity • Involved interesting art collaboration • Fairy-lights potentially a spin-off/start-up • Two e-Campus inspired research grants • Caside – communications and co-ordination using public displays • Visiting research fellow – Content management in ubicomp environments • General feeling that interesting lessons have been learned

11. Interim research results • Experience • Significant deployment and prototype experience • Underpass/spine related efforts have led to a new emphasis on content management • Better understanding of content needs and tool requirements • Publications?

12. Infrastructure evolution • Infrastructure has iterated based on a series of prototypes culminating in the underpass demo • Other projects have fed in requirements • Scheduler • manage requests for resource • provide fair and deterministic scheduling • Event heap • tuple space model • main synchronisation point for applications

13. Infrastructure evolution • Modified platform deployed in March 2005 (?) • Event heap proved difficult to use • ordering, sematics and performance • Stateless • replaced by Elvin • Smiley • ad-hoc solution to state management

14. Infrastructure evolution Video switch Audio switch • Underpass deployment • Significant hardware and software extensions to brewery 3 projectors Single or multi screen 4 Macs 3 sound channels PC 3 XGA Movement Sensors (IR) 2 live cameras

15. Current Infrastructure features • High level System model • General purpose event model for basic communications between system entities (Elvin) • ‘media centric’ content programming model • Media presentations, referred to as ‘applications’ • Media streams and time line plus event generation • Media presentation devices – ‘displays’ • Display + computation element + screen management • System state change managers – ‘handlers’ • Policy modules that sit between applications and displays • Basic model is that applications use events (within transactions) to secure resources, schedule media and perform interaction. • Applications currently hand crafted – plan to provide tool or extensions to existing tools

16. Infrastructure – future plans • Initial trials led to a number of observations • Content management a key system issues • Provisioning, versioning, meta-data management, workflow etc • Event model needs more flexibility • Better support for state and state persistence • Flexible ordering schemes, ie lightweight • Proposed approach • Use content management system as core of infrastructure • Augment with event management component • Currently under development

17. Other infrastructure • ISS experimenting with Domino and Sharepoint • Simple content management/portal infrastructure • Hermes/CASIDE using in-house infra • Testbed group keen for reuse

18. Observations • ‘stolen time’ is ok for initial investigation but not acceptable for full scale deployment • Project severely hampered by lack of resources • stay focused on research – it can get lost within development and deployment • Research goals need to be clearly articulated and pursued • document and discuss – sharing knowledge key to looser collaboration • Process seems weak within e-campus • Testbed versus infrastructure – did you get this right?

19. Next Steps • Significant amount of ‘internal’ learning • This needs to be shared and analysed • What are long term goals for e-Campus • Is the e-Campus ‘vision’ still valid – and feasible? • Is e-Campus still planning a shared infrastructure? • Or is e-Campus simply an umbrella for a set of loosely related projects? • Infrastructure evolution needs to be revisited • What are requirements • From existing and future work, eg CASIDE • What are research issues and what can be used ‘off the shelve’

20. Infrastructure - observation • No strong appetite for common infrastructure • Complex user base • Simple web and RSS feed for day to day university needs • Bluetooth interactive • CASIDE has separate needs • Interactive art/technology/media requirements • Perhaps better to deploy a basic simple infrastructure (commercial?) designed to meet common needs, eg campus info, socs, faculty stuff etc • Parallel research infrastructure used just for e-Campus research experiments