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

2. 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." Subscriber user Service broker Service mgt. Access network operator Core network operator Value added service providers Value added service providers Value added service providers Content providers Content providers Content providers Access Networks Cellular systems Cordless (DECT) Bluetooth DECT data Wireless LAN Wireless local loop SatelliteCableDSL

3. ICEBERGs Goal: Potentially Any Network Service (PANS) Texttospeech Cellular Phone Email repository DevicesServices

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

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

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

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

8. Preference Registry GUI

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

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

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

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

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

15. Adding a new device/service end- point Add an IAP Add entries to the Naming Service Add operators (transformation agents) to the APC service IAP IP-Addrs Tel. No:s Email-addrs Pager no:s

16. 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: MP3 PCM-UB (mpg123) PCM-UB PCM-ULAW (sox)

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

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

19. 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 MP3 PCM-UB operator

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

21. 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 end- points in our testbed has shown the flexibility of our architecture See the demo in the afternoon!