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

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
Access Networks
Value added
Value added
Value added
service
service
service
providers
providers
providers
Content
Content
Content
providers
providers
providers
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
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
[email protected]
PCM-ULAW  Sun au  Text
674
GSM  PCM-ULAW  Sun au  Text
Instant
Messaging
Service
Illustrating Extensibility
[email protected]
PCM-ULAW  PCM-UB  MP3
Jukebox
Service
529
GSM  PCM-ULAW  PCM-UB  MP3
Illustrating Extensibility
[email protected]
Jukebox
Service
529
G.723  PCM-SW  PCM-UB  MP3
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
IAP
IAP
Tel. No:s
IP-Addrs
Pager no:s
Email-addrs
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 endpoints in our testbed has shown the flexibility of
our architecture
• See the demo in the afternoon!