Service Encapsulation in ICEBERG

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."
Access Networks Cellular systems Cordless
(DECT) Bluetooth DECT data Wireless LAN Wireless
local loop Satellite Cable DSL
3
ICEBERGs Goal Potentially Any Network Service
(PANS)
Cellular Phone
Text to speech
Email repository
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
9
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
im_at_cs.berkeley.edu
Sanctio
PCM-ULAW ? Sun au ? Text
Instant Messaging Service
674
GSM ? PCM-ULAW ? Sun au ? Text
13
Illustrating Extensibility
jukebox_at_cs.berkeley.edu
PCM-ULAW ? PCM-UB ? MP3
529
GSM ? PCM-ULAW ? PCM-UB ? MP3
14
Illustrating Extensibility
jukebox_at_cs.berkeley.edu
529
G.723 ? PCM-SW ? PCM-UB ? MP3
3012
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

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!