Service Encapsulation in ICEBERG Bhaskaran Raman ICEBERG, EECS, U.C.Berkeley Presentation at...

Post on 30-Mar-2015

217 views 2 download

Tags:

transcript

Service Encapsulation in ICEBERG

Bhaskaran RamanICEBERG, 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."

Subscriber user

Servicebroker

Servicemgt.

Accessnetworkoperator

Corenetworkoperator

Value addedservice

providers

Value addedservice

providers

Value addedservice

providers

Contentproviders

Contentproviders

Contentproviders

Access NetworksAccess Networks

Cellular systemsCellular systemsCordless (DECT)Cordless (DECT)

BluetoothBluetoothDECT dataDECT data

Wireless LANWireless LANWireless local loopWireless local loop

SatelliteSatelliteCableCable

DSLDSL

ICEBERG’s Goal: Potentially Any Network Service (PANS)

TextTexttoto

speechspeech

CellularPhone

Emailrepository

Devices Services

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

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– MediaManager (for

access to email)– MP3 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

Instant Messaging Service

im@cs.berkeley.edu

674

PCM-ULAW Sun au Text

GSM PCM-ULAW Sun au Text

Illustrating Extensibility

jukebox@cs.berkeley.edu

529

PCM-ULAW PCM-UB MP3

GSM PCM-ULAW PCM-UB MP3

Jukebox Service

Illustrating Extensibility

Jukebox Service

G.723 PCM-SW PCM-UB MP3

3012

jukebox@cs.berkeley.edu

529

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

IAP

IAP

IAP

IP-Addrs

Tel. No:s

Email-addrsPager 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:

• MP3 PCM-UB (mpg123)• 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 MP3 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 end-points in our testbed has shown the flexibility of our architecture

• See the demo in the afternoon!