1. 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 Stuttgart
{kovacs, hohl,
SONY

2. 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

3. 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

4. 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

5. 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!)

6. 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

7. 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

8. 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

9. 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

10. 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