Which additional aspects could be of interest for WG2? © 2002, Sony International (Europe) GmbH, BWTR Advanced Technology Center Stuttgart Which additional aspects could be of interest for WG2? 6th WWRF Meeting, London, 2002 Ernö Kovacs, Fritz Hohl , Amen Hamdan Sony International (Europe) GmbH Heinrich-Hertz Str. 1 D-70327 Stuttgart e-Mail: {kovacs, hohl, hamdan}@sony.de SONY

The Youngster Mobile Service Platform Terminal MSP Terminal Rendering Terminal Perso- nalisation App. Step App. Step Application uses various context to produce or adapt output uses terminal capability data to render the correct format Context System Personal Assistant Event Monitor Admin Directory Service Per- sistence gathers users preferences Config- uration Logging Accoun.& Billing Content Mgmt. uses context to select the appropriate content uses Context System events in order to monitor complex events uses user preferences to adapt the application output

The Trivial Context System sensor Context System API application context graph sensor attribute Access Control application Sensor Management context graph sensor attribute Event Mgmt. application sensor context graph attribute application sensor Context Graph Mgmt. Context System

The (New??) Aspects competing services on all levels system infrastructure should scale to a wide range of device types support of static and dynamic combination of existing services into new services not only sensing information from the real world, but also modifying it support of spatial data

Competing services on all levels i.e. applications & infrastructure components why? allowing competition helps user (see 4thG.communication) need for a central administrative party can be avoided a system can develop incrementally when any party can provide partial functionality in ad-hoc networks, the infrastructure needs to be settled dynamically anyways how? infrastructure needs to be designed with this goal in mind services as first-level objects, i.e. elements that can be provided by using a hosting component services and applications should be defined in our vocabulary (it does not so much matter which definition to use, but we have to name things!)

System Elements API O API O O O API O O O O API Accounting service sensor API Accounting service O application API Entity Access service O O O API Service Find service O O application O service API Spatial Query service O entity application actor applications: programs that allow users to get a certain functionality services: programs that allow applications and other services to get a certain functionality objects: entities representing real world elements like users, rooms, cars, etc. and virtual elements like virtual post-its or virtual devices

System infrastructure should scale to a wide range of device types i.e. a participating device should be able to host none, a few or all infrastructure services why? we want to support everything from a dumb sensor to a high-end server how? it is easy also for small devices to use the infrastructure services hosted on other devices -> low overhead access means extensible micro-kernel service architecture architecture consists of a very small set of required components and a way to combine them services can then created and accessed scalability can be achieved by a domain model

Support of static and dynamic combination of existing services into new services why? horizontal combination (federation) allows to use a unified view on services of the same type but a limited domain vertical combination (virtual services) can be realized that provide services even if they are not offered as such how? could be based on dynamic service graphs as in the Ninja/Iceberg project, but: might need adaptation to system characteristics, e.g. lack of central control and provision of services by 3rd parties

Not only sensing information from the real world, but also modifying it why? we‘ll have something like managing sensors (gateway digital world -> real world) as a system component, so it would be logical to have something like this also for actors (reverse gateways) in principle, we want to do these things anyways, but without system support the applications have to manage these things themselves how? model-wise this is covered by the object definition offering a similar systen support like for sensors

Support of spatial data for buildings, streets, areas, etc. why? spatiality is an important aspect of the user‘s experience new applications are possible how? model-wise this is covered by the object definition object might have also spatial attributes component-wise a „spatial query“ component can be used