Problem Statement

1
Problem Statement
Communication devices
Communication services

• Requirement
• Service integration and personalization
• Goals
• Any-to-any capability
• Extensibility ease of adding new end-points
• Scalability global scale operation
• Personal mobility and Service mobility

2
State-of-the-Art

• Commercial services
• Concentrate on functionality
• No any-to-any capability
• Research projects
• Mobile People Architecture Personal Proxies
• Telephony Over Packet networkS
• UMTS
• Issues not addressed
• Infrastructure support for network integration
• Extensibility
• Scalability
• Personal mobility Service mobility

3
Key Ideas

• Infrastructure components for network integration
• Components in the Internet open model, can
  leverage proxy and cluster architectures (Ninja)
• Identification and separation of components
• Name Mapping Service (NMS)
• Automatic Path Creation service (APC)
• Preference Registry (PR)
• ICEBERG Access Points (IAP) to proxy for
  communication end-points
• Advantages of separate infrastructure components
• Reusable pieces
• Extensibility is easier just add to the piece
  that requires extension

4
Any-to-any Communication
Name Mapping Service
800-MEDIA-MGR UID mediamgr_at_cs.berkeley.edu
510-642-8248 UID hohltb_at_cs.berkeley.edu

2
3
1
IAP
Preference Registry
Barbaras Desktop
hohltb Prefers Desktop mediamgr Cluster locn.
IAP
Bhaskars Cell-Phone
3
Automatic Path Creation Service
IAP
IAP
MediaManager Mail Access Service
5
Universal Inbox Personal Mobility and Service
Mobility in an Integrated Network

• Bhaskaran Raman
• ICEBERG,
• EECS, U.C.Berkeley

6
Extensibility

• Name-space
• Hierarchical
• New name-spaces added by creating a new sub-tree
  at root
• Automatic Path Creation service
• Operators can be plugged in
• Old operators are reusable
• Set of IAPs
• New IAPs can be added independent of existing
  ones
• All old IAPs are reachable from the new one

IAP
IAP
IAP
IAP
7
Implementation Experience

• Testbed with GSM cell-phones and VoIP end-points
• Components on top of Ninja 1.5 (iSpace)
• Examples of extension
• IAP for Ninja Jukebox
• Allow service access from voice-enabled
  end-points
• 700 lines of Java
• Also required addition of operators to APC
  service MPEG-3 to PCM
• IAP for MediaManager
• Allow access to the MediaManager service
• Similar code-size and effort
• No other component had to be touched
• Operators for G.723
• Getting codec to work required effort
• But, adding to APC was two hours of work (?
  simple API for adding operators)

8
Further Plans

• Extend to PCM end-points
• PSTN phones, via H.323 gateway
• Build IAP for interfacing
• Hypothesis all existing end-points and services
  should interoperate without modification (e.g.,
  Jukebox, MediaManager, Two way call with
  Cell-Phone, VoIP, etc.)
• Inside department deployment
• Make system more usable
• Extend to more services and end-points
• Scaling and latency issues
• Services on vSpace
• Leverage cluster-computing features

9
Summary

• Universal Inbox metaphor for any-to-any
  communication and service access
• Personal mobility
• redirection by preference registry
• Service mobility
• result of the any-to-any capability
• Architecture viable for global operation
• IAPs can be developed and depoyled by independent
  service providers
• Extensibility
• Made easy by the separation and reuse of
  functionality
• Open Questions
• Security issues
• Billing issues