ICEBERG Release

1
ICEBERG Release
Version 0
The ICEBERG Team
Summer 2000 Retreat
2
Overview

• Background
• Components in the release
• Feature set
• Interfaces
• APIs for extension
• Limitations
• Plans for next release

3
ICEBERG Goals Potentially Any Network Service
Same service in different networks Service
handoff between networks
2-way Paging
PSTN
GSM/CDMA

• Extensible network environment
• Addressing access-device and access-network
  heterogeneity

IP
IAP
WIP
High BW IP core Diverse access links
4
ICEBERG Goals Personal Mobility
Speech-to-Text Speech-to-Voice-Attached-Email Call
-to-Pager/Email-Notification Email-to-Speech All
compositions of the above!
Policy-based Location-based Activity-based
5
ICEBERG Goals

• Go beyond 3rd generation cellular
• Infrastructure for hybrid services
• Work in the wide-area
• Ease of deployment
• Robust signaling, high availability
• Secure billing issues

6
ICEBERG Architecture An Overview
Access Network Plane
PSTN
GSM
Pager
ICEBERG Network Plane
SF iPOP
NY iPOP
NY iPOP
SF iPOP
Clearing House
ISP Plane
ISP1
ISP2
ISP3
7
Components in the Release
Client IAPs
Outgoing calls
Call Agent (CA)
ICEBERG Access Points (IAPs)
Preference Registry (PR)
Automatic Path Creation Service (APC)
Incoming calls
Name Mapping Service (NMS)
Server IAPs
ICEBERG Point of Presence (iPOP)
8
Components in the Release
VAT IAP
VAT
GSM
GSM IAP
Testbed
CA
Jukebox IAP
Ninja
PR
Jukebox
Pref. Mgr. GUI
MediaManager IAP
APC
Voice-Mail IAP
MediaManager
NMS
Service
Mail-push Client IAP
iPOP
Voice-Mail
Mail-store
9
Requirements

• Ninja 1.5
• iSpace for service platform
• NinjaRMI for communication
• Hardware
• Linux cluster
• Scaling not too good
• Use of NinjaRMI
• Process-per-operator-per-path model for APC

10
Capabilities Any-to-Any Communication
Calls from friends
Anonymous callers
Emails from important business associates
Calls during office hours
Read email through MediaManager
Preference-based redirection
Device-type and name independence
11
Capabilities Service Handoff
12
Capabilities Service Handoff
13
Capabilities Adding new IAPs
H.323 IAP
Stock Quotes IAP
Push
iPOP
Access
Yahoo Calendar IAP
14
Capabilities Adding to APC
Front-end
Back-end
APC
Operators Connectors
PCM
GSM
RMI
PCM
MP3
UDP
PCM
Text
RTP
PCM
G.723
15
Overview

• Background
• Components in the release
• Feature set
• Interfaces
• APIs for extension
• Limitations
• Plans for next release

16
Interfaces between Components
NMS1
NMS2
PR1
PR2
CA 1
CA 2
IAP 1
IAP 2
APC 1
APC 2
NinjaRMI
Soft-state signaling for session maintenance
17
Interfaces with Specific Services

• APC Service
• int createPath(source, destination) ? returns
  pathID
• Source and Destination description
• Machine address
• Connector specification RMI/UDP/HTTP/RTP
• void destroyPath(int pathID)
• void changePath(int pathID, newSrc)
• MediaManager Service
• String getFolders(username)
• MediaMessage getList(username, folder,
  num-msgs)
• ContentObject getMsgContent(contentID, int type)
  ? returns one of
• text transcript, text summary, audio summary
• multiple audio formats possible

18
APIs for Extension Adding IAPs
Setup(), Terminate(), DTMF(), ServiceHandoff()
CA
Setup(), Terminate(), DTMF()
APC
Device- or service-specific part
Generic part
StartConnection(), CleanUp()
Extend IAPWithCA Implement IAPIF
19
APIs for Extension Adding Operators

• Specify I/O types
• Specify ADU size
• For process-based operators
• Java-wrapper around executable
• I/O in STDIN/STDOUT
• Specify executable
• G.723 codec added in 2hrs

APC
Operator 1
New Operator
Operator 2
Operator 3
Extend Operator Implement OperatorIF
20
Overview

• Background
• Components in the release
• Feature set
• Interfaces
• APIs for extension
• Limitations
• Plans for next release

21
Limitations in v0

• No heart-beat between IAP and CA
• require iPOP in a vSpace cluster
• IAP stub communicates with periodic state updates
  (keep-alive messages)
• APC supports only UDP connectors between
  operators

22
Limitations in v0 (Continued)

• APC issues
• ties operators to specific connectors
• process per operator model (scaling problems)
• pipes for communication (huge delays due to
  buffering)
• path restricted within a cluster
• Issues with path control
• hard-state protocol for setup and tear-down (easy
  to fix)
• no flow control (more difficult to fix)

23
Limitations in v0 (Continued)

• Naming service not distributed
• Soft-state update not enough for user-level
  signaling between end-points
• need reliable propagation
• need instantaneous propagation
• e.g., DTMF

24
Plans for Next Release

• Port to vSpace
• fault-tolerant communication between the IAP and
  the CA
• inherit scaling features
• Fix (some of) APC issues
• remove process-per-operator model
• remove coupling between operators and connectors
• soft-state for path maintenance

25
Feedback

• Evaluation strategy
• Security issues
• Things to fix in next release
• Thoughts on more IAPs
• Deployment issues

Questions...
http//iceberg.cs.berkeley.edu/release/