1. Design Decisions / Lessons Learned
Monday 21 August 2000
10: :35 Top-level design decisions
Rationale for IP-based approach
Why an infrastructure based approach?
Leveraging cluster-computing environments: Ninja vSpace
10: :00 Design of the ICEBERG components and capabilities
Signaling protocol for flexible multi-party communication
Service creation model
Clearing House for resource reservation
13: :00 Design of the ICEBERG components and capabilities
Automatic Path Creation service
Naming service
Preference Registry and Preference Manager
Personal Activity Coordinator
Universal Inbox for personal mobility and service mobility

2. Choices for Service Integration
ICEBERG’s goal: Potentially Any Network Service
It should be “easy” to introduce communication services
Hybrid services spanning heterogeneous networks are crucial
Introduction and integration of novel services should be possible in shorter time-scales
What are the options?
Integration based on IP-technology
Use SS7 network and components for functionality
IN-based approach

3. IN-based Integration: Advantages
Global network, scalable
Engineered well for 2-way voice communication
Highly robust
Replication of components for fall-back
Pervasive monitoring infrastructure
Connection-oriented approach suited for applications requiring Quality of Service
Trunk allocation part of call-setup

4. IN-based Integration: Disadvantages
Closed model of operation
High cost of entry
Little opportunity for innovation
Intelligence in the network
Inflexible for introducing new services
Large, sophisticated components
Incremental scaling is a problem
Connection-oriented approach
Not suited for packet-oriented applications

5. Internet-based Integration: Advantages
Open service model
Intelligence at the edges, simple network
Rapid development and deployment of services
Example: web-based services – Napster, Gnutella
Well-developed client-proxy-server model
Good for addressing heterogeneity
Components can be incrementally provisioned and scaled
Computational resources are cheap
General-purpose PCs can be used for implementing functionality
Example: IP-PAD in our GSM testbed replaces costly ZAK/TRAU

6. Internet-based Integration: Challenges Addressed by ICEBERG
Scaling services to a large user-base and to the wide-area
Leverage cluster-computing platforms: Ninja
Robustness and fault-tolerance issues
Soft-state model
Resource provisioning for Quality of Service
Clearing House architecture