Service Encapsulation in ICEBERG Bhaskaran Raman ICEBERG EECS

Service Encapsulation in ICEBERG Bhaskaran Raman ICEBERG, EECS, U. C. Berkeley Presentation at Ericsson, Sweden, June 2001

The Case for Services "Service and content providers play an increasing role in the value chain. The dominant part of the revenues moves from the network operator to the content provider. It is expected that value-added data services and content provisioning will create the main growth. " Service broker Service mgt. Subscriber user Access network operator Core network operator Value added service providers Content providers Access Networks Cellular systems Cordless (DECT) Bluetooth DECT data Wireless LAN Wireless local loop Satellite Cable DSL

ICEBERG’s Goal: Potentially Any Network Service (PANS) Devices Services Cellular Phone Text to speech Email repository

Extensibility is Important • New device: should be able to access existing services • New service: should accessible from existing devices • Any-to-any capability: – Unique to ICEBERG – Existing commercial products for service integration do not talk about this

ICEBERG: A Middleware Approach • Middleware components: Naming service, APC, IAPs, Preference Registry • Naming service: provides device/service name independence • APC: device/service data type independence • IAPs: provide network independence • Preference Registry: for personalization of incoming communication (for a end user)

Two kinds fo services • Communication services (personal mobility) • Service end-points (service mobility)

Personal Mobility • Person is the communication end-point, not the device • Enabled through the preference registry (acts as a redirection agent) • Example services built: – Redirection – Filtering – Service handoff

Preference Registry GUI

Service Mobility: Devices and Services in ICEBERG • Devices – GSM cellular phones – Desktop phones (VAT) • Using GSM audio • Using PCM audio – PSTN phones • Services – Media. Manager (for access to email) – MP 3 Jukebox (from Ninja) – Instant messaging (from Ninja) – Voice-mail service

PANS and Extensibility • All services accessible from all devices • All devices can communicate with one another • Extensibility: services and devices were added incrementally, not all at once

Illustrating Extensibility im@cs. berkeley. edu PCM-ULAW Sun au Text 674 Instant Messaging Service GSM PCM-ULAW Sun au Text

Illustrating Extensibility jukebox@cs. berkeley. edu PCM-ULAW PCM-UB MP 3 Jukebox Service 529 GSM PCM-ULAW PCM-UB MP 3

Illustrating Extensibility jukebox@cs. berkeley. edu Jukebox Service 529 G. 723 PCM-SW PCM-UB MP 3 3012

Adding a new device/service endpoint • Add an IAP • Add entries to the Naming Service • Add operators (transformation agents) to the APC service IAP IAP Tel. No: s Email. IPaddrs Addrs IAP Pager no: s

Adding a service end-point: Example • Jukebox service – IAP: interface to the Ninja Jukebox service • 800 lines of Java code – Adding naming entries for the Jukebox service: trivial – Operators added: • MP 3 PCM-UB (mpg 123) • PCM-UB PCM-ULAW (sox)

Adding a device end-point: Example • PSTN phones – – – Interface through a H. 323 gateway Device specific part of IAP: 15, 000 lines ICEBERG specific part of IAP: 900 lines Adding naming entries: simple Operators added: • PCM-UB PCM-SW (sox) • PCM-SW G. 723 (lbccodec) • G. 723 PCM-SW (lbccodec)

Adding new IAPs • Device specific part may be very complex – H. 323 gateway, GSM cellular-phones • ICEBERG specific part is quite simple – a few days of coding • Importantly, once the IAP is implemented and deployed, it can be used for all services

Adding new operators • Operator itself could be very complex – G. 723 codec, GSM codec, Text-to-speech • But, once they have been implemented and deployed, they can be reused for multiple purposes – E. g. , the MP 3 PCM-UB operator

Future Directions • Service composition in the Wide-Area • Examples: – – Email to voice Video-on-demand over PDA Ad insertion in video stream Others: storage, redirection… • Independent service providers deploy services: portal providers compose them • Issues: – Performance sensitive choice of service instances – Fault-tolerant maintenance of session when service instances fail

Conclusions • ICEBERG: Middleware approach to enabling services • Extensible PANS through – Network independence (IAP) – Name independence (Distributed naming service) – Data type independence (APC) • Implementation of several device and service endpoints in our testbed has shown the flexibility of our architecture • See the demo in the afternoon!