Roch H. Glitho, Ph.D. Expert - Service Engineering, Ericsson Canada Adjunct Associate ...users.encs.concordia.ca/~glitho/Globecom03.pdf · 2004-01-09 · Roch H. Glitho- Ericsson/Concordia

1Roch H. Glitho- Ericsson/Concordia University IEEE Globecom 2003

Roch H. Glitho, Ph.D.Expert - Service Engineering, Ericsson Canada

Adjunct Associate Professor - CIISE, Concordia University, CanadaEmail: [email protected]


Objectives assigned to this tutorial ...

• Introduce the basics of service engineering and next generation networks

• Present today’s service architectures for next generation networks

• Discuss the emerging trends

.


Outline

• Part I - Basics of service engineering and next generation networks

• Part II - service architectures for next generation networks

• Part III – Emerging trends


Part I: Basics of Service Engineering and Next Generation Networks

• Service engineering

• Next generation networks


Service Engineering: Concepts

1. Services

2. Service Life Cycle

3. Service Engineering

A discipline still in childhood ...


Services ...

What are value added services (or simply services)? – Anything that goes beyond two party voice call

• Telephony services (interact will call control)– Call diversion, screening, split charging– dial in/dial out conferencing, multiparty gaming …

• Non Telephony services (Do not interact with call control)

– Web access» Customised stock quotes» Surfing from a cell phone …

• Combination– Call centers


Service life cycle ...

Four phases– Creation (also known as construction)

• Specification, design/coding, and testing– Deployment

• Service logic (or executable) resides on specific node(s) and needs to be deployed there

– Usage• Subscription/billing, triggering, features

interactions– Withdrawal

• Removal from network


Service Engineering ...

Key issue: How to engineer “cool” services– In more academic terms

• Issues related to the support of all the phases of the life cycle.

– Creation– Deployment– Usage– Withdrawal

• These issues are architectural issues– Concepts, principles, rules – Functional entities, interfaces and algorithms


Service Engineering ...

Why is it an important discipline?– Business standpoint

• High quality two party voice call is now a commodity

• Value added services are needed to attract subscribers and generate revenues.

– Engineering standpoint• It is less than trivial• Example: Service creation

– Secure and selective access to network resources is required

– Related issues: Level of abstraction, security framework, service creation tools …etc.


Service Engineering: Legacy architectures

1. Intelligent Networks (IN)

2. Wireless Access Protocol (WAP)

3. Telecommunication Information Network Architecture (TINA)

A discipline still in childhood ...


Intelligent Networks (IN) : The very first service architecture for telephony services

1. Introduction

2. Fundamental Principles and Concepts

3. A Brief History of Capability Sets

4. The four planes- Service plane- Global functional plane- Distributed functional plane- Physical plane

5. Retrospective


Introduction …

The pre-IN era– Service logic embedded in switching software– Standardization of services (I.e. supplementary services)

IN– Has emerged in the ITU-T based on work done at Telcordia (alias

Bellcore), in the late 80s– Basis for:

• AIN (North America - fixed network)• WIN (D-AMPS - wireless network)• CAMEL (GSM - wireless network)


IN: Fundamental Principles

Separation of switching software and service logicMain implication: Need for an interaction model between switching and

service• Functional entities / nodes• Protocols• And more …

Standardization of capabilities for building servicesMain implication: Need for “components” that can be used in various

ways for building services• Room for a wide range of services• Room for differentiation

.


IN: Fundamental Concepts Call model

Phases for setting up and tearing down calls– IN call model or basic call process: call model with the

possibility to invoke service logic» Point of invocation» Point of return

Service independent building blocks (SIB)Components used to build services- Have a logical start and one or more logical ends- Are chained to build services

Capabilities set- A set of potential services- A given call model- A set of SIBs- A set of functional entities- A protocol


IN: A Brief History of Capability Sets

Capability set 1 (CS1) - 1992– Most widely deployed– Developed in the context of state monopoly fixed networks operators

• Little/no support for internetworking and mobility– Focus on two party call call related services (e.g. call forward, call

screening)• No support for multiparty, multimedia

– Used in the rest of this tutorial to illustrate IN

Capability set 2 (CS2) - 1997– Much less deployed– Developed in the context of deregulation and mobile telephony– Much more complex than CS1. E.g.

• Call party handling for conferencing (e.g. call leg, connection point)

• Call unrelated functions


IN: A Brief History of Capability Sets

Capability set 3 (CS3) - 1999– No known commercial deployment – Attempt to correct the numerous mistakes / ambiguities in CS2– A few new features: number portability

Capability set 4 (CS4) – 2001 (The end of the road)– No known commercial deployment – Very high level of ambition

• Object oriented components• Videoconferences• And much more

– Too little in terms of output– Emergence of alternatives (e.g. Parlay, JAIN)


IN: A four planes conceptual architecture

.

Service Plane

Global Functional Plane

Distributed FunctionalPlane

Physical Plane

Services as seen by end-users

Functionality required to build the services(e.g. Service independent building blocks)

Functional entities that make the IN network

Physical nodes


IN: Service Plane Services as seen by end-users are made of features

and features are specified in groupsExamples of CS1 Feature groups – Charging

• Split, reverse– Routing

• Call forward– Restriction

• Originating call screen, terminating call screening– Numbering

• One number, abbreviated dialling, private numbering plan– User interactions

• Originating user prompting, destination user prompting– Other features

• Call transfer, call hold


IN: Service Plane Examples of services made of specific features

Free phone– One number (800 in North America) feature– Reverse charging feature

Calling card- Charging feature- Originating user prompting

.


IN: Global Functional Plane

Components (I.e. SIBs) used to build the services

Examples of SIBs from CS-1– Basic call process

• Basic SIB– Point of invocation– Point of return

• Passes the call data (e.g. caller / callee) to the first SIB in the chain)

– Screen– Charge– Compare– Translate– Service data management


IN: Global Functional Plane …Simplified Free phone

.

Basic call Process

Translate SIB(For translating into the

Real phone number)

CHARGE SIB(For reverse charging)


IN: Distributed Functional Plane ...The functional entities

– Service Control Function (SCF): the entity that contains the service logic

Usually implemented as a separate node - The Service Control Point (SCP)

– Service Switching Function (SSF): the entity that implements the call model – Enables the switching between “switching software and service logic)

– Call Control Function (CCF): the entity that contains the switching software - Knows at any given time the call state (e.g. busy, ringing)

SSF and CCF are usually implemented in a separate node – The Service Switching Point (SSP)

- Service data point (SDP): data base that keeps service data such as number translation tables

Usually integrated with SCP- Service management function (SMF): subscriber management and

service management- (SRF): Functions such as announcement playing, conference bridging


IN: Physical Plane ...

Functional entities can be grouped in nodes as manufacturers wish

The Intelligent Network Application Protocol (INAP) is used for communications between nodes.– Request / Reply application level protocol– Messages transported over SS7 – SS7

• Overlay packet switched networks• Used for outbound signalling• Made of

– Message transport part– Application part


IN: Physical plane An example of physical implementation ...

.

Service control point(SCP)

Service switching point(SSP)



INAP-



.

Intelligent Network ApplicationPart (INAP)

Transaction CapabilitiesApplication Part (TCAP)

Signalling Connection Control Part (SCCP)

Message Transfer Part 3



Application layer

Network layer

Data link layer

Physical layer

INAP protocol stack



A simplified INAP message exchange for free phone

.

SSP SCP / SDPInitialDP (call id, dialled number, free phone)

Connect (call id, destination id)

eventReport (callid, D_Answer, time stamp)

Eventreport (call-id, O_disconnect, time stamp)

Charging


IN: Retrospective ...

A revolutionary concept– Separation between service logic and switching software– Standardisation of service capabilities instead of services

With mixed results– Reasonable installed basis, but– Lack of openness

• Standardised building blocks (e.g. SIBs) did not open telecommunication networks to third parties

– Components are not interfaces– Too many “proprietary” SIBs

– Service creation and deployment remain relatively slow– Immaturity of methodologies and tools– New service logic in SCPs often required “adjustments” to call model

in SSP


Wireless Access Protocol: The very first architecture for Internet wireless access

1. Introduction

2. Fundamental principles and concepts

3. Architecture

4. Beyond Internet wireless access

5. I-mode

5. A retrospective


Introduction

Product of an industry consortium, the WAP forum- First release 1998 (WAP 1.0)- Second release 2002 (WAP 2.0)- Now transferred to the the Open Mobile Alliance (OMA)

Main objective: bring non telephony services to wireless users ...– Web browsing– Email

Raison d’etre– Limitations of cellular phones( Power, memory, battery) – Limitations of today’s wireless networks (Scarce bandwidth, unreliable

links)

.


Fundamental principles

Optimal usage of “scarce” air interface resources - Implications

- Less bandwidth hungry protocols- binary encoding instead of text encoding

Optimal usage of “limited” terminal capabilities– Implications

• New description language(s)• New browser(s)

– EmailIndependence of underlying bearer (e.g. GSM, TDMA, PDC)

.


Fundamental concepts

WAP Micro browser- Browser adapted to limited terminal capabilities

WAP proxy/gateway– Gateway between the Internet and operator’s domain

• Protocol gateway• Content adaptation • New description language(s)• New browser(s)

Application framework- Application development / execution environment

- APIs- Mark ups- Scripting


WAP: Basic Architecture Network view

.

Client Gateway Application(e.g. cell phone, pager) Server(User domain) (Service provider) (Internet domain)

Encoded Request

Encoded Reply

HTTP Request

Air interface ...

HTTP Reply


WAP: Basic ArchitectureProtocol stacks (Legacy WAP 1.x stack + WAP 2.0 Internet protocol stack) ...

.

Wireless ApplicationEnvironment (WAE)Wireless session protocol(WSP)

Wireless transaction protocol(WTP)Wireless transport layersecurity (WTLS)

Wireless datagram protocol(WDP)

Bearer(e.g. TDMA, CDMA)

Wireless Application Environment (WAE)

WP - HTTP

WP - Transport Layer Security (TLS)

WP - TCP

IP

Bearer(e.g. TDMA, CDMA)

WAE

HTTP

SSL

TCP

IP

Legacy WAP 1.x stack Web server stack WAP 2.0 stack Web server stack

WAE

HTTP

TLS

TCP

IP


WAP: Basic architecture ...Device architecture

.Application Framework

(Wireless Application environment, Push, Messaging)

Networkprotocols

Others (e.g. Authentication)

Contenthandling


WAP: Application Environment ...Wireless Application Environment

- Mobile profile of W3C XHTML (XHTLMMP) as mark up language for content description, in addition to:

- Wireless Mark up Language (WML) of WAP 1.x- Subset of XML- Kept in WAP 2.0 for backwards compatibility reasons

- Other types of content (vCard, vCalendar)

.


WAP: Beyond Internet wireless access ...Push

- Information pushed to wireless device instead of the classical Internet pull model

- Notifications (e.g. voice messages waiting to be retrieved)- News, traffic information

Wireless Telephony Applications - Enhancements to call control services

- Call initiation using an electronic agenda- On-line selection of how to handle a call (accept, reject, forward)

Multimedia messaging- Interface between the client and the messaging server

.


WAP: Simplified Push

.

(User domain) (Service provider domain)Client (e.g. cell phone) Gateway Push Initiator

Air interface ...

(PAP)Push Access ProtocolPush Over the Air

Protocol (OTA)HTTP Post (Content to pushed)

HTTP post(Results)

Encoded Request

Encoded Reply

Other network nodes (e.g. voice mail)


WAP: Simplified WTA

.

(User domain) (Service provider domain)Client (e.g. cell phone) Gateway WTA Server

Air interface ...

HTTP Request

HTTP Response

Encoded Request

Encoded Reply

Other network nodes (e.g. SCP)


WAP: MMS

Multimedia Messaging Service– Service for sending and receiving multimedia message

• Multimedia = Text and/or audio and/or video• Being standardized by the third generation partnership project

(3GPP)– Some of the interfaces

• MM1: User agent / MMS server (WAP based)• MM7: Third party value added service provider / MMS server

(HTTP based)• MM4: MMS server / MMS server (SMTP currently)

.


WAP: MMS

MM1 interface

.

Wireless Network

Wired Network

MMS

Server

MMS server

User A

User B

Wireless Network

Air interface ... Air interface ...


WAP: MMS

.

(User domain) (Service provider domain)Client (e.g. cell phone) Gateway MMS server

Air interface ...

HTTP Request

HTTP Response

Encoded Request

Encoded Reply


WAP: Imode ...

Imode in a few words:- Has emerged in Japan in 1999:

- Product of a specific service provider (DoCoMo)

- As WAP, aim primarily at Internet wireless access

- Huge commercial success

-


WAP: Imode ...

Imode vs. WAP: Main differences- Business model

- Integrated model (DoComo collects payments)- Technical differences

- Relies on DoComo packet network (9.6 Kbps) - Reliance on DoComo packet data networks- cHTML (A sub-set of HTML) for content description- Protocol stack (transport layer Protocol (TLP) + Application Layer Protocol (ALP))

-


WAP: Retrospective ...

A revolutionary concept– Bring non telephony services (e.g. browsing) to telephony users

With mixed results– Slow take off

• Initial charging model (circuit switched telephony model)• Limited range of services due to connection speed

– Less and less critical in the future with more and more bandwidth at the air interface and more and more powerful terminals

.


Telecommunication Information Network Architecture (TINA): The first architecture for telephony and non telephony services ...

1. Introduction

2. Fundamental principles and concepts

3. Service architecture

4. A retrospective


TINA: Introduction

Product of theTINA consortium (TINA-C)

– First phase: 1993 - 1998• Production of specifications by a core team based in same

location (NJ, USA)• Validation (e.g. prototyping) by associated projects

– Second phase: 1998 - 2000• Special projects• Results promotion in various standards bodies

– 2000: Mission considered accomplished and dismantling of consortium

• Note: Many of the first phase participants did not join the second phase


TINA: Introduction

The context in the early 90s

– Emergence of new technologies• Object oriented technology• Distributed processing

– Open Distributed Processing (ODP) specifications: View points» Business» Information» Computation

– Emergence of standards relying on different principles• Intelligent Networks (IN)• Telecommunications Management Network (TMN)


TINA: Introduction

TINA aims at:– Integrated set of specifications for:

• Network architecture• Network management• Service architecture

– That rely on:• Emerging technologies

– Object orientation– Distributed processing (ODP)

– And reconcile: • IN• TMN


TINA: Introduction

Specifications– Distributed Processing Environment (DPE)– Business model– Network resource architecture– Service architecture

Many prototypes but very few products …

.


TINA: Fundamental principlesThe separation principle

– Infrastructure• Service • Network

– Service • Subscription• Access• Usage• Service usage

Business model as starting point for specifications- Roles- Interfaces


TINA: Fundamental principlesBusiness roles / interfaces

.

Note: Taken from IEEE Communications Surveys & Tutorials (Reference [x])


TINA: Fundamental principlesRoles

– Consumer• End-user: Actual user of the service• Subscriber: Entity having the business agreement for service

usage– Retailer

• One stop shop• Entity which provides the services and which has the business

agreement with the subscriber• Can provide own services or services subcontracted from third

parties– Third party service provider

• Has business agreement with retailer and no direct business agreement with subscribers

– Communication/connectivity provider: “Pipe” provider– Broker: Ensure fair information distribution to all parties


TINA: Fundamental conceptsService life cycle

– Construction– Deployment– Usage– Withdrawal

Session– Generalization of the call model concept– Access session:

• Activities involving consumer and retailer for selecting, and initiating the use of a service (e.g. subscription, authentication)

– Service session• Activities involving consumers and retailer for the actual usage of

the service – Keep track of the parties involved in the usage of a service and the connectivity between them (e.g. feature interactions)

– Communication session• Activities involving the actual usage of network resources (e.g.

QoS)


TINA: Service Architecture

1. Support for a wide range of services

2. Rapid service creation and deployment

3. Tailored services

4. Independent evolution of network and service infrastructure

5. Support for multiparty environment

6. Service manageability

7. Universal access

8. Inter-working with legacy



Architecture made of:- Computational objects accessible via CORBA interfaces

- No protocol

Computational objects in the consumer domain:– Provider agent (PA): Proxy through which the retailer makes service offer

to the consumer

– Service session user application part (ssUAP): Service control interface in the terminal



Computational objects in the retailer domain:– User agent (UA): Represents the user in the retailer domain

– Initial agent (IA): First point of contact for a consumer in a foreign network

– Peer agent: Establishes connection between two retailers

– Service factory (SF): Creates services instances

– Service session manager (SSM): runs the actual service



Access session:Provider agent Initial agent User agent Service factory

Access session request

AuthenticationSearch for user agent

Access session request

Access session activation request

Activation of Access sessionGet list of available

services

Start a specific service session

Service session activation request

Activation of servicesession


TINA: Retrospective ...

A seminal service architecture– Many sound concepts (e.g. service life cycle) and principles (e.g.

separation of concerns) widely re-used– A sound business model widely re-used

But, a commercial failure– Lots of prototypes and trials, but very very few commercial

deployment due to a wide range of factors• Too far ahead its time• Complexity• Too high level of ambition (e.g scope encompasses everything

from networking to service engineering)• Too little weight to other important technological developments

(I.e. Internet)• Too little consideration to installed basis


A Few References To probe further ...IN1. ITU-T specifications, Q. 12xx series2. J. Zuidweg, Next Generation Intelligent Networks, Artech House publishers, 20023. Fayenberg, L. Gabuzda, M. Kaplan and N. Shah, The Intelligent Networks Standards:

Their Applications to Services, McGraw-Hill, 19974. R. H. Glitho and Th Magedanz (eds), Intelligent Networks in the New Millenium, IEEE

Communications Magazine, June 2000, Vol. 38, No. 6

WAP4. WAP specifications, http://www.wapforum.org/5. WAP 2.0 Technical white paper, http://www.wapforum.org6. M. Van Der Heijden and M. Taylor, Understanding WAP: Wireless Applications, Devices

and Services, Artech House publishers, 2000

TINA7. TINA Specifications, http://www.tinac.com/8. J. Zuidweg, Next Generation Intelligent Networks, Artech House, 20029. Y. Inoue et al., The TINA Book, Prentice Hall Europe, 199910. H. Berndt, T. Hamada, and, P. Graubmann TINA: Its Achievements and its Future

Directions, IEEE Communication & Surveys, 1Q 2000,•


Questions?


Next Generation Networks …

1. Definition/Characteristics

2. SIP, H.323, Megaco/H.248

3. softswitches

4. 3GPP/3GPP2 Networks


Definition / characteristics

1. Distinctive characteristics

2. A brief history

3. The protocol jungle


Distinctive characteristics …Loosely used to refer to:

– Internet Telephony– 3G– 3G and Beyond

Distinctive characteristics

- Packet switching (instead of circuit switching in today’s 2G networks)- QoS enabled (unlike the Internet best effort)- Voice + data (unlike today’s 2G networks which focus on voice)-


A brief history …Milestones

– Late 70s: • First two party voice calls over Internet (Network Voice Protocol

(NVP - RFC 741 - November 1977)

– 80s: • Emergence of proprietary systems for Internet Telephony

– 90s:• Emergence of standards (e.g. SIP, H.323)

– 00s:• Backing by telcos (e.g. 3GPP specifications)• Backing by other new players (e.g. cable industry)


The protocol jungle …

.


Session Initiation Protocol (SIP)

1. Introduction

2. Functional entities

3. Messages

4. A simplified call case


SIP: IntroductionA set of IETF specifications including:

– SIP core signalling:• RFC 2543, March 1999• RFC 3261, June 2002 (Obsoletes RFC 2543)

– SIP extensions (e.g. RFC 3265, June 2002 - Event notification)– QOS related protocol (e.g. RSVP)– Media transportation related protocol (e.g. RTP - RFC 1889) – Others (e.g. SDP - RFC 2327)

A set of standards adopted as basis for third generation telecom networks (e.g. 3GPP, 3GPP2)

Focus in this tutorial: SIP core signaling– The functional entities– The messages


SIP: Introduction

SIP core Signaling– A signalling protocol for the establishment, modification and tear down

of multimedia sessions– Based on HTTP

A few key features– Text based protocol– Client/server protocol (request/response protocol)


SIP: The functional entitiesUser agents

- End systems- Initiate requests (e.g. a party that invites to a session)- Final recipient of requests (e.g. a party that is invited to a

session)Proxy servers

- Application level routers- Forward requests and responses

Redirect servers- Receive requests and return to the sender the

address to which the request should be sent- May consult a location server to get the address

Registrars- Keep tracks of users within their domain


SIP: The messagesGeneric structure

- Start-line- Optional message body

Request message- Request line as start line

. Method name

. Request URI

. Protocol versionResponse message

- Status line as start line. Protocol version. Status code . Reason phrase (Textual description of the code)


SIP: The messagesRequest messages

- Methods for setting up sessions. INVITE. ACK. CANCEL. BYE

- Others. REGISTER (Registration of contact information). OPTIONS (Querying servers about their capabilities)

Response message- Examples of status codes1xx: Provisional2xx: Success6xx: Global failure


SIP: A simplified call case •

.

INVITE (1)INVITE (2)

INVITE (4)100 TRYING (3)

100 TRYING (5)180 RINGING (6)

180 RINGING (7)

180 RINGING (8) 200 OK (9)

200 OK (10)200 OK (11)

ACK (12)

MEDIA SESSION

BYE (13)

200 OK (14)

CALLER PROXY A PROXY B CALLEE


H.323

1. Introduction

2. Functional entities

3. Protocols

4. A call case


H.323: Introduction

An umbrella ITU-T standard including– signalling standards:

• H.225.0• Q.931• H.245

– Others (e.g. H.324 Terminal for low bit rate multimedia communications)

Focus in this tutorial: Signalling


H.323: The functionality entitiesTerminals

- End point- Used for real time two way multimedia communications

with another end pointGatekeeper

- Control how terminal access networks- Provide address translation

Gateway- End point- Used for communications between H.323 terminals

and terminals in the PSTNMultipoint control unit

- Provides centralized conferencing functionality


H.323 signaling: The protocols Key features

- ASN.1 based messages- Wide range of messages

The three protocols- Registration Admission and Status (RAS)

- Transaction oriented protocol- Signaling between end-points (terminal or gateway

and gatekeeper)- Call set up and tear down

- Q.931 (PSTN signaling variant) subset- Easy inter-working PSTN/ISDN and H.323

- Media negotiation


H.323 signaling: A simplified call case

.

Caller Gatekeeper CalleeRAS (admission request)

Q.931 (Call set up)

H.245 (Media negotiation)

RTP

H.245 (Logical channel closing down)

Q.931 (Call tear down)

RAS (Resource release)


Megaco / H.248

1. Introduction

2. Genesis

3. Concepts



Megaco/H.248: Introduction

Primary motives for decomposing gateways between PSTN and next generation networks:– Scalability– Specialization– Opening up of market to new players

Side-effect– Possibility of using the part of the decomposed gateway for call

control• Soft-switches


Megaco/H.248 : Introduction

.

Media Gateway controller

Media Gateway Media Gateway Media Gateway


Megaco/H.248: Genesis

A long history starting in 1998- Simple Gateway Control Protocol (SGCP)

- Text based encoding, limited command set- IP Device Control Protocol (IPDCP)

- A few more features to SGCP- Media Gateway Control Protocol (MGCP)

- Merge of SGCP and IPDC- Media gateway Decomposition Control Protocol (MDCP)

- Binary encoded- Megaco / H.248 (Joint IETF / ITU-T specifications)

- A compromise- Both text based and binary encoding- A wide range of transport protocols(e.g. UDP, TCP, SCTP)


Megaco/H.248: ConceptsTermination

– Source or sink of media– Persistent (circuit switched) or ephemeral (e.g. RTP)

Context (mixing bridge)– Who can hear/see/talk to whom – May imply conversion (RTP stream to PSTN PCM and vice versa)

Stream– Specific media type

Commands– What can be done with Megaco/H.248– Mostly context related

• Adding / subtracting a termination to/from a context• Moving from a context to another context


Megaco/H.248: A simplified call case

.

SIP Proxy MGC MG PSTN

INVITEISUP “INVITE” to PSTN

OKISUP “OK” to MGC

ACK

Add RTP stream to context

Add PCM stream to context

PCM

RTP


Soft-switches

1. Introduction

2. Overview



Soft-switch: Introduction

A “side effect” of media gateway decomposition- Aggressively promoted by the soft-switch consortium, now known

as the International Packet Communication Consortium (IPCC)- Adoption of existing standards (e.g. SIP, H.323, MGCP, Megaco)

- Gateway controller (plus some additional features) acts as a switch

- Switching in software instead of hardware- Can act as local exchange (class 5) or toll centre (class 4)

- Lower entry costs for new incumbents- New local telephony networks and “by pass” for long distance call

providers- Soft-switches vs. classical switches debate

- Scalability- Reliability- QoS


Soft-switches : Overview

.

Soft-switch (Media Gateway Controller +

Some intelligence)

Media Gateway Media Gateway Media Gateway

ISUP H.323 SIP

MGC protocols



.

Soft-switch

Media Gateway(Residential gateway)

MGC protocol

Soft-switch

Media Gateway(I.e. Residential gateway)

MGC protocol

Media (I.e RTP)

Signaling (e.g. ISUP, SIP)

An example of soft-switch as class 5 replacement …



.

Soft-switch

Class 4 switch

MGC protocol

Class 4 switch

MGC protocol

Signaling (e.g. ISUP, SIP)

An example of soft-switch as class 4 replacement …Soft-switch

Media Gateway Media Gateway

PCM for mediaISUPsignaling PCM for media

ISUPsignaling

RTP for media


Soft-switch: A simplified call case (Calling card)

.

Caller Local exchange Soft-switch MG MG Soft-switch Local exchangeCall to access number(I.e soft-switch)

Verification(e.g. account,Digit analysis)

Call request (e.g. SIP, SIP-T)

Call request (ISUP)

PCM

RTP

PCM

Info request (e.g. card number, Callee number)


3GPP/3GPP2 Networks

1. Introduction

2. 3GPP networks

3. Overview of the IP Multimedia (IM) portion


Introduction3GPP

- Established in 1998 as collaboration agreement between several standards bodies (e.g. ETSI, CCSA, ARIB,T1)

- Aim at establishing standards globally applicable to third generation mobile networks based evolved GSM core networks

3GPP2- Established in 1998 as collaboration agreement between several

standards bodies (e.g. CCSA, ARIB,TIA)- Aim at establishing standards globally applicable to third generation

mobile networks based evolved IS-95 core networks

Common and distinctive characteristic: Mobility addressed in-depth (unlike the previous NGN)- Terminal mobility- User mobility- Service mobility


3GPP networksEssentials- Made of:

- Legacy- Circuit switched part (GSM)- Packet switched (GPRS)

- Next generation part (IP multimedia (IM))- Inter-working- Some of the functional entities are common to both legacy and NGN

(e.g. Home Subscriber Server)

- Adoption/extension of existing NGN specifications:- SIP instead of H.323- H.248/Megaco


IP multimedia portion

P - C S C F

C S C FM G C F H S S

C x

I P M u l t im e d ia N e tw o r k s

I M S -M G W

P S T N

M n

M b

M g

M m

M R F P

M b

M r

M b

L e g a c y m o b i le s ig n a l l in g N e tw o r k s

C S C F

M w

G o

P D F

M w

G m

B G C FM jM i

B G C F

M k M k

C , D , G c , G r

U E

M b

M b

M b

M R F C

S L FD x

M p

P S T N

P S T N

I M S u b s y s te m

A S

I S C

D h S h ,S i


IP Multimedia portionSome of the functional entitiesCall Session Control Function (CSCF)

- Proxy-CSCF: First contact point in the IM network – Accepts requests and proxies them

- Serving-CSCF: Perform session control for all user entities in the networks including visitors

Home Subscriber Server (HSS)- Master data base – subscription / location information

Multimedia Resource Function Processor (MRFP_- Transcoding, mixing and so on

Multimedia Resource Function Controller (MRFC)- Controls MRFPs

MRFC and MRFP communicate via Megaco / H.248


To probe further ...Next Generation Networks in General- H. Schulzrinne, Converging on Internet Telephony, Special issue, IEEE Network / IEEE Internet

Computing, May/June 1999- A. Moderassi and S. Mohan, Advanced Signaling and Control in Next Generation Networks, IEEE

Communications Magazine, October 2000

SIPhttp://www.cs.columbia.edu/sip/

H.323- ITU-T specification

Megaco- IETF/ITU-T specification

Soft-witcheshttp://www.packetcomm.org/F.D. Orthman, Soft-switch architecture for VoIP, McGraw, 2003

3GPP / 3GPP2 networks- 3GPP / 3GPP2 specifications- Lieve Bos, Suresh Leroy, "Toward an all-IP-based UMTS system- architecture", IEEE Network, no. 1, January/February 2001


Questions?


Part II: Service Architectures for Next Generation Networks

• Legacy based architectures

• Signaling protocol specific architectures

• Signaling protocol neutral architectures


Legacy based architectures …

1. Re-using IN

2. Inter-working with INPINTSPIRITS

Expectations and Legacy based architectures ….

A big gap


Re-using IN

1. Introduction

2. Issues and tentative solutions

3. A retrospective


Introduction: IN again ...

.

Service control point(SCP)- Contains service logic- service logic is based on capability set

Service switching point(SSP) - Switch implementing INcall model (e.g. when tostop and give control tothe SCP)- Call models are standardizedand come with capability set



INAP- Application protocol runningon top of SS7- ASN.1 basedSS7 outbound signaling network


Introduction: History and motivesHistory

- Approach popular in the early days of NGN. Several IETF draft standards. A few initiatives in ITU-T

MotivesBusiness:

Re-use of IN infrastructureTechnical:

Internet telephony standards emerged without credible service engineering components

IN principles are well known


The main issues ...

Communication between NGN switches and SCPs.

– Next generation switches do not support SS7 – INAP is ASN.1 based while some Internet Telephony protocols (e.g.

SIP) are text based

Call models

– IN call models were built explicitly for circuit switched telephony– NGN “call models” were built without IN in mind

.


The tentative solutions The communication issue: three main approaches

- First: Put the burden on the SCP side (e.g. IP transport, support of text based protocol)

- Second: Put the burden on the NGN switches sides (e.g. support of SS7

- Third: Gateways

The call model issue: Two main approaches- Integrated call model- Call models (I.e. H.323/SIP and IN) running in parallel and

interacting

.


A Retrospective ...The initial interest is understandable

– IN principles are well known– IN has a relatively large installed base

However IN cannot fit the bill for several reasons such as– Relatively small range of services can be developed using IN

principles– Third parties are not really allowed in IN world – Creation and deployment are slow

The prospects– The approach is outdated– Main standardisation bodies have given up on it (for Internet

Telephony):• IETF• 3GPP


Inter-working with IN: PINT

1. Introduction

2. Benchmark services

3. Architecture

4. Simplified example

5. Pros / cons


IntroductionPSTN/Internet Inter-working (PINT)

IETF initiative

Build new end user services in NGN/Internet domain based on PSTN capabilities

- Services initiated in NGN/Internet domain but executed in the PSTN domain

Re-use as much as possible the emerging NGN protocols in the architecture

- SIP- SDP

Use a sample of services as benchmarks


Benchmark servicesClick to dial

- Callee and caller given as parameters- Call established in PSTN

Click to fax- A pointer to the content may be given as input parameter

Click to speak / send / play content- A pointer may be given to the content

.


Architecture

.

PINT Client(Subscriber IP host) PINT Server /

Gateway

Service ControlFunction

PINT ProtocolOutside the scopeOf standardization

NGN PSTN


ArchitecturePINT Protocol

SIP messages, but with a different semantics- REGISTER

- Used by a PINT gateway/server to inform a proxy/redirect of the services it can offer

- INVITE- Used by the PINT client to request a specific service

- BYE- Used by the PINT client to cancel a previously sent request

SDP messages, but with a different semantics- Used to specify the request (e.g. call) and carry the pertinent

parameters (e.g. caller, callee)

Subscribe, Unsubscribe and Notify- Used by PINT clients to be informed of the progress/outcome of a

request


Simplified example

.

PINT client PINT server

INVITE PINT server

SDP: request to establish a call between A and B

Subscribe

Notify A busy

Notify B busy

Notify call established


Pros and cons Pros

– Useful set of services– Simple architecture– Fits well in an environment where SIP/SDP is already installed

Cons– Rely on the assumption that SIP/SDP will become quickly widespread

• The assumption does not hold– The use of SIP/SDP become more a stumbling block than a stepping

stone for the widespread usage of the standards– Proprietary implementations become widespread

– May not fit well in a real NGN environment• Calls will be established without using the PSTN

.


Inter-working with IN: SPIRITS

1. Introduction

2. Benchmark services

3. Architecture

4. Pre-SPIRITS (proprietary) implementations

5. Pros / cons


IntroductionServices in the PSTN / Intelligent Network Requesting Internet

Services (SPIRITS)

IETF initiative

Build new end user services in PSTN domain based on NGN/Internet capabilities

- Services initiated in PSTN domain but executed in the Internet domain

Re-use as much as possible the emerging NGN protocols in the architecture

- SIP- SDP

Use a sample of services as benchmark


Benchmark servicesInternet call waiting (ICW)

- Being informed of incoming PSTN calls while line busy because ofInternet connection

- Specify the desired treatment for the call (e.g. accept, reject, forward, play announcement)

- PSTN carries out specified treatment

Internet call id delivery

Internet call forwarding- A pointer to the content may be given as input parameter


Architecture

.

SPIRIT Gateway

Service ControlFunction

SPIRITS Protocol

NGN side

NGN PSTN

Service SwitchingFunction / CallControl Function

SPIRIT ClientSPIRITS Server

(Subscriber IP host)

SPIRITS Protocol

PSTN/IN side


ArchitectureProtocol requirements (NGN side)

- Communications between PINT server and PINT gateway- SIP as basis

- SDP for carrying parameters (or Multi-purpose Internet Mail Extensions (MIME))

- Subscriber / notify- PINT extensions (optional requirement)

Protocol requirements (PSTN/IN side)- Communications between PINT client and PINT gateway- IN related requirements

- CS3 - Conversion between ASN.1 / binary encoded parameters ans text

encoded ones.

The actual protocols have not been specified


Pre-SPIRITS implementationsA very wide range

A few described in detail in an IETF RFC

- Korea Telecom - Lucent - NEC- Telia / Nortel


Korea Telecom implementationFunctionality

- Comprehensive Internet Call Waiting- Flexible activation / de-activation

Network entities- IN side

- CS-1 based entities / protocol - SCP (SCF, SDF, plus a gateway to NGN world)- Intelligent Peripheral (IP)- INAP (SCP/IP communication and SCP/SSP communications)

- NGN side- SIP based entities

- ICW server system (acts as SIP proxy/redirect server)- ICW client system (application running on subscriber PC)


Korea Telecom implementation

.

Gateway to NGNService Control

Point (SCP)

Service SwitchingPoint (SSP)

ICW client(Subscriber IP host)

IntelligentPeripheral

(IP)

INAP

ICW Server(SIP Proxy)

SIPSIP

Next Generation Networks

PSTN / IN


Korea Telecom implementationSIP messages

- REGISTER- Used by the ICW client to inform the SCP of the client connection

status (Online/Offline)- INVITE

- Used by the SCP to inform the ICW client of an incoming call - CANCEL

- Used to cancel previously sent INVITE (e.g. when the calling party releases the call before the called party responds)

.


Korea Telecom implementation

A simplified call flow …

.

ICW client ICW server SCP

REGISTER(Notify that client is connected To the Internet)

REGISTER

OKOK

Incoming calldetected

INVITEINVITE

User decides to accept incoming callICW clears Internet connection

OK OK

SCP instructs SSP to establishcall


Pros and cons Pros

– Useful set of services– Simple architecture

Cons– Too little, too late

• Protocols not fully specified• Large number of deployed proprietary systems• Emerging proprietary systems for taking incoming calls

without disconnecting from the Internet

.


To probe further ...Re-using IN1. I. Slutsman et al., Framework and Requirements for the Internet Intelligent Networks (IIN), Internet

Draft, March 2000, Work in progress2. T-C Chiang et al., IN Services for Converged (Internet) Telephony, IEEE Communications

Magazine, June 2000, Vol.38 No6, pp.108-1153. E. Evloguiva and R. Glitho, Plugging IN Service Control Points in SIP Networks, IEEE IN Workshop

2000, Cape Town, May 2000 4. C. Gourraud, IPVAS: an IN Based Value Added Service Architecture for IP Telephony, International

Conference on Intelligence in Network (ICIN), Bordeaux, January 2000, pp.41-46

R. H. Glitho, Alternatives to Today’s IETF and ITU-T Advanced Service Architectures for Internet Telephony: IN and Beyond, Elsevier Computer Networks 35 (2001), April 2001, pp. 551-563

Inter-working with IN1. S. Petrack and L. Conroy, The PINT service protocol: Extending SIP and SDP for IP Access to

Telephone Call Services, RFC 2848, June 20002. I. Faynberg et al., Service in the public switched telephone network / intelligent network (PSTN/IN)

requesting Internet services (SPIRITS): Protocol requirements, RFC 3298, August 20023. I. Faynberg et al., Pre-SPIRITS Implementations of PSTN-initiated services, RFC 2995, November

2000


Questions?


Signaling protocol specific architectures …

1. H.323 specific architectures

2. SIP specific architectures


Signalling Protocol Specific Architectures

Does the gain in specifics offset the loss in generality ???


H.323 specific architecture: The supplementary service approach

Specifying services instead of building blocks !!!


H.323 Supplementary services

1. Introduction

2. The services

3. The architecture

4. Beyond supplementary services

5. Pros and cons


Introduction

Architecture based on pre-IN and “PBX” thinking:– Standardization of services (instead of services capabilities)

• H.450.1 Recommendation– General principles

• H.450.X – Roughly 1 per service

Main architectural principle– “Overlay” dedicated network for realizing services

• Functional entities• Messages

.


The services ...Services standardized by the end of 2001

Call transferCall diversionCall holdCall park and pick upCall waitingMessage waiting indicationName identificationCall offerCall intrusion

.


The architecture

Entities– Supplementary service control entities

• Reside in H.323 functional entities• Exchange messages for realising services

Messages– Service execution related messages– Activation / de-activation at user level

Entities and messages are defined on service basis

.


Call diversion service (H.450.3)

Flavours– Unconditional– On busy– On no reply within a given period of time

Functional entities– Activating / de-activating end points– Original diverting (served) / last diverting (served) end points

• Points at which the call is diverted– Interrogating end point

• Get information (from diverting end points ) on activation status / number to which to divert and so on ..

– Re-routing end point• Entity that does the re-routing


Call diversion service (H.450.3)

.

Terminal 1 Gatekeeper Terminal 2 Terminal 3 (Re-routing entity) (Diverting entity)

Set up …

Set up

No reply …Detect that call shouldBe re-directed to Terminal 3

Facility (Call re-routing request)

Facility (Call re-routing answer)

Release complete

Set up


Beyond supplementary services: Annexes K and L Annex K

– Cater to additional services such as third party call control• HTTP link for user interactions• Implementation dependent mapping between actions required by

the user and the appropriate H.450.x messagesAnnex L

– Allow the introduction of new supplementary services without upgrading terminals

• New services are introduced in feature server• Stimulus based signalling procedures between terminals, feature

server and gate keeper.


Pros and cons Pros

– More suitable for PBX environment with lower expectations on services

• Fixed set of supplementary services• Easy interoperability due to detailed specifications of messages

Cons– Highly unsuitable for next generation networks, despite of the recent

quick “fixes” (e.g annexes K and L)• Limited range of services• Third parties are not allowed

.


The SIP specific tools/ architectures …

.

1. SIP CGI2. SIP Servlet API3. 3GPP SIP Application

Server


SIP CGI

1. Introduction

2. HTTP and HTTP CGI

3. SIP CGI

4. Example

5. Pros and cons


Introduction ...

Key features– Signalling protocol specific (I.e. applicable to SIP only)– Prime target: trusted parties

• Service providers• Third party developers

– Reliance on HTTP CGI• HTTP CGI is widely used in the Internet world for Web page

development– A tool which relies on it should attract many users including the Web

masters.– A wide range of developers should favour the development of cool

and brand new services

.


HTTP ...Object oriented application level request/reply protocol for

distributed multimedia information systems– Clients

• establish connections– User agents

• Initiate requests– Servers

• accept connection, serve requests and send responses back• Origin servers:

– servers on which resources are created and reside• Resource

– data object or service– Proxies

• act as both servers and clients.


HTTP ...Message• Type: request or reply• Headers

– General header• Applicable to both request and reply (e.g. date)

– Request (or reply) header• Method to be applied to the resource (e.g. GET, POST)• Resource id• Protocol version• Additional information (e.g. host, user agent)• In case of reply: status line

– Entity header: Optional information on body• Body (optional) (e.g. HTML file)• length.


HTTP CGI ...

Creation of dynamic Web content– Script that can work with most programming language– Generate content on the fly

• interface between HTTP GET request and data bases access• HTTP headers (e.g. date, user agent)• Other (e.g. Host name)

.


HTTP CGI ...

Creation of dynamic Web content– Script that can work with most programming language– Generate resource identified in a request on the fly

• interface between HTTP request and data bases• Forms• Dynamic information (e.g. date, number of visitors)

Environment variables allow the script to access- HTTP headers- Non request specific information (e.g. server host name)


HTTP CGI ...

Pros– Programming language independence

Cons- Poor performance

- Scripts are not persistent: connection to a data base needs to be established each time

– Lack of scalability• Scripts need to reside on same server as resource


SIP CGI ...

Examples of adjustments

– Script output is not necessarily the response to send• Case of call forward

– Script will instruct the server to proxy the request to right location– Scripts are persistent

– Several interactions are required between script and server for some services

.


SIP CGI ...

Algorithm implemented by a script for call forward – Get the destination from the SIP request

• Done by retrieving the To_Field from the environment variable HTTP_TO

– Obtain the forwarding address from a data base – Forward the call

• Done by using the CGI-PROXY-REQUEST-TO CGI action

.


Pros and cons ...

Pros– Possibility of creating a wide range of services due to the full access

to all the fields from the SIP Request– Language independence

Cons:– CGI is less and less used in the Web world– SIP CGI is not exactly the same thing as HTTP CGI– Lack of scalability (e.g. scripts need to reside on same server)– Performance issues

.


SIP Servlet API

1. Introduction

2. HTTP servlet API

3. SIP servlet API

4. Examples

5. Pros and cons


Introduction ...

Key features– Signalling protocol specific (I.e. applicable to SIP only)– Prime target: trusted parties

• Service providers• Third party developers

– Very few constraints on what can be done– Reliance on HTTP servlet API

• HTTP servlet API is widely used in the Internet world– A tool which relies on it should attract many users including Web

masters.– A wide range of developers should favour the development of cool

and brand new services

.


HTTP servlet API ...

Creation of dynamic Web content

• Servlet– Java component– Generate content on the fly, just like HTTP CGI

• interface between HTTP request and data bases• Forms• Dynamic information (e.g. date, number of visitors)



Servlet container (also know as servlet engine)

• Servlet container (or servlet engine)– Contains the servlets– Manage the servlets through their life cycle

• Creation• Initialisation• Destruction• Receives and decodes of HTTP requests• Encodes and sends of HTTP responses



Pros

Address most HTTP CGI shortcomings- Performance

- Can keep data base connections open- Scalability

- Servlet containers can be accessed remotely

Cons• Language dependence


SIP servlet API...

Adjustments made to HTTP servlet:

• Initiate requests– Needed for some services

• wake up call • Receive both requests and responses

– Needed for some services• Terminating services (e.g. call forward on busy)

• Possibility to generate multiple responses• Intermediary responses, then final response

• Proxying requests, possibly to multiple destinations– Needed for applications such as intelligent routing

.


SIP Servlet container ...

Servlet Container

SIP Proxy Serverrequests

responses

requests

responses

servletservlet

A container collocated with a proxy server


SIP servlet Request/response hierarchy...

Build on the generic servlet API, like HTTP servlet

- javax.servlet.sip (just like javax.servlet. http)- Container must support

. javax.servlet

. Javax.servlet.sip.


SIP servlet request response hierarchy...

Request-response Hierarchy

-.ServletRequest ServletResponse Javax.servlet

SIPServletMessage

SIPServletRequest SIPServletResponse Javax.servlet.sip


SIP servlet Request interface ...

SIP specific Request handling methods (Based on both core SIP and SIP extensions):

• doInvite• doAck• doOptions• doBye• doCancel• doRegister• doSubscribe• doNotify• doMessage• doInfo


SIP servlet Response interface ...

SIP specific Response handling methods (Based on both core SIP and SIP extensions):

• doProvisionalResponse

• doSuccessResponse

• doRedirectResponse

• doErrorResponse


SIP servlet Message interface ...

SIP specific message handling methods (Access to message header):

• getHeader

• getHeaders (Used when there are several headers)

• setHeader

• addHeader

Note: system headers cannot be manipulated by servlets (Call-ID, From, To)


SIP servlet Message interface ...

SIP specific message handling methods (Access to message content):

• getContentLength

• setContentLength

• getContentType

• getContent

• getRawContent

• setContent


An example of service:

Algorithm for call forward – Get the destination from the SIP request

• Done by retrieving the To_Field by using the GetHeaders– Obtain the forwarding address from a data base – Forward the call

• Done by setting the Request_URI (and not the To_field) using thesetHeader

.


Another example:

Algorithm for a centralized dial-out conference

Assumptions – INVITE is used– URIs of participants are put in the INVITE body

Agorithm used in servlet:• Use GetContent to get the participant’s URIs from INVITE

Request• Use doINVITE to generate and send an INVITE to each

participant.

.


Pros and cons ...

Pros– Possibility of creating a wide range of services due to the full access

to all the fields from the SIP Request– More performance and more scalability– Possibility to create services that combine both HTTP and SIP

Cons:– SIP Servlet is not exactly the same thing as HTTP Servlet– Language dependence

.


3GPP SIP Application Server

1. Introduction

2. Interactions between SIP AS and S-CSCF

3. S-CSCF service control model


Introduction ...

3GPP SIP application server

• Provide value added services• Reside in user’s home network or in a third party location• Interact with serving CSCF via IP Multimedia Service Control

Interface (ISC)– SIP plus some enhancements

• No tool is specified and any SIP specific tool can be used• SIP CGI• SIP servlet API

• State-full models– Incoming call legs– Outgoing call legs

.


Interactions – SIP AS as terminating user agent (e.g. call screening)

.

S-CSCF

ApplicationServer

SIP leg #1

SIP leg #1

From: XTo: YCall-ID: Z



Interactions – SIP AS as originating user agent (e.g. wake up call)

.

S-CSCF

ApplicationServer

SIP leg #1

SIP leg #1




Interactions – SIP user agent as a proxy (e.g. call forward)…

.

S-CSCF

ApplicationServer

SIP leg #1

SIP leg #1



SIP leg #1From: XTo: YCall-ID: Z

SIP leg #1



Interactions – SIP AS as third party call control

.

S-CSCF

ApplicationServer

SIP leg #2

SIP leg #2

From: PTo: QCall-ID: R

From: PTo: QCall-ID: R

SIP leg #1From: XTo: YCall-ID: Z

SIP leg #1



Service control model …

.

A S-ILC M

A p plica tio n S erve r

ILS M O LS M

M odel

S -C S C F

In com ing Le g O u tgo in g Leg

IS C

C a ll R eco rds

ILC M O LC M

A S-O LC M


To probe further ...H.323 specific approachesITU-T specifications: H.450.x series, recommendation H.323

- H. Liu and P. Mouchtaris, Voice over IP Signalling: H.323 and Beyond, IEEE Communications Magazine, October 2000, Vol. 38 No 10

- R. H. Glitho, Advanced Services Architectures for Internet Telephony: A Critical Overview, IEEE Network, July 2000, pp. 38-44

SIP specific approachesIETF RFCs: SIP CGI - RFC 3050

- J. Rosenberg, J. Lennox and H. Schulzrinne, Programming Internet Telephony Services, IEEE Network, May/June 1999, Vol.13, No3, pp. 42-49

- R. H. Glitho, Advanced Services Architectures for Internet Telephony: A Critical Overview, IEEE Network, July 2000, pp. 38-44

Java Developers Community draft JSR 116http://www.jcp.org/aboutJava/communityprocess/review/jsr116/W. Leekwijck and D. Brouns, SIPlets: Java Based Service Programming for IP TelephonyR. Glitho, R. Hamadi and R. Huie, Architectural Framework for Using Java Servlets in a SIP

environment, ICN2001, July 2001 3GPP TS 23.228, 23.002, http://www.3gpp.org/


Signaling protocol neutral architectures …

1. Parlay

2. JAIN JCC/JCAT

3. CPL


Signalling Protocol Neutral Architectures

Protocol neutral API: A least common denominator or a sound service architecture ???


OSA/PARLAY

1. Introduction

2. Business model

3. APIs

4. Case Study

6. Pros and cons


Introduction

PARLAY forum– Created in 1998 as close forum – Open since 2000– Include most major players from telecommunications and computer

industries (e.g. Ericsson, Lucent, Siemens, IBM)– Fourth release of specifications recently released

Relationship of Parlay specifications to 3GPP specifications– API called Open Service Access (OSA) in 3GPP

• Thus Parlay/OSA• Joint development


Introduction

OSA a tool kit of Virtual Home Environment (VHE)

– VHE• 3GPP concept for service mobility

– Access to services from any location and with any terminal (within the limit of the terminal capabilities)

– Include several tool kits:

OSA allow third party to access 3GPP next generation networks- OSA application servers

- reside in third party domains- Access 3GPP network functionality via service capability

servers (SCS) (I.e. gateways)


IntroductionPARLAY main goal: Open up telecommunication networks• Enable new business models • Use open information technology middleware • Make telecommunication network capabilities available for

application development– Two types of APIs – Services APIs

• Expose the network capabilities (e.g. call control, presence)– Framework APIs

• Make the use of the service APIs secure, accountable and resilient (e.g. security, registration, authentication)


The business model• Introduction

– TINA-C inspired business model – Terminology: Services mean network capabilities

• Roles– Client application

• Consume/use the services (e.g. network capabilities)• Equivalent to end users in TINA-C.

– Enterprise operator• The entity that subscribes to the services• Subscriber in TINA-C

– Framework operator• Entity that handles the subscriptions• Equivalent to the retailer in TINA-C


The business model

Enterprise Operator(Subscriber)

Client Application(End User )

Framework Operator(Retailer)

(3) Service Usage

(2) Service Subscription

(1) Service Registration


The APIs

FrameworkAPIs

Service APIs

Resources interfaces

Resource Resource Resource

Client Applications

Parlay/OSA APIs

Figure 2 Parlay APIs interfaces


The APIsSome common characteristics

Specifications include• High level specification in UML (Universal Modelling Language) • API specifications for several IT technologies

– CORBA IDL– WSDL– Java

Two modes of communications • Synchronous• Asynchronous


Service API: Give access to network capabilities

Call controlUser interactionsGeneric messagingMobilityTerminal capabilitiesConnectivity managementAccount managementCharging serviceData session controlPresence and availability managementIntegrity management


Framework API: Make the use of the service APIs secure and resilient

Trust and security management

Event notification

Service discovery

Service registration

Integrity management


An example of Service API: Call control

Generic call control service

Multiparty call control service

Multimedia call control service

Conference call control service


The call control APICall model

- Terminal- End point (Not covered in the current specifications)

- Address- Represents a party in a call (E.164 number, IP address)

- Call- Abstraction of the physical call that occurs in a network

- Call leg- Logical association between a call and a party involved in a call


The call control APIGeneric call control- Two party voice call only- Remain in Parlay for historical reasons

Multiparty call control- Establishment of calls with any given number of users- Root of the inheritance tree

Multimedia call control- Add multimedia (e.g. media negotiation) capabilities

Conference call control- Add conferencing capabilities

- Creation and manipulation of sub-conferences


A case study on PARLAY/OSA and SIP: Run For Your Life game

• 1 - Introduction

• 2 - Game

• 3 - Architecture

• 4 - Mapping


Introduction ...

Run-For-Your-Life• Built from scratch in Ericsson Research lab in Montreal Canada• Demonstrated at several trade shows (e.g. ICIN 2001, Parlay

Munich meeting, Parlay Hong Kong meeting)• Objectives assigned to the game design

– Extensive usage of call control capabilities– Have fun …

.


Introduction ...

Objective of the case study …Aim at helping in tackling two issues:

1. PARLAY Call Control APIs that cannot be mapped onto SIP– What are they?– What is the impact on service creation?

1. SIP semantics that are not visible in PARLAY APIs as per today’s specification– What are they?– What is the impact on service creation?

.


The game ...

A multiparty cooperative game– Group of people trapped in a house with several rooms set to

burn/explode in a given time– Can escape only if password is found– Letters making the password scattered in selected rooms of the house– People ending up in the same room can exchange hints about the

password via audio and chat– Game can be assimilated to a conference with as sub-conference

people ending up in a same room

Requiring a set of well defined conferencing functionality - Conferencing- Sub-conferencing

.


The game ...

.


Architecture ...

.PARLAY / SIP GATEWAY

Megaco/H.248 basedAPI

GAME SERVER

SignalingControlUnit

MediaControlUnit

Gameclient

Gameclient

PARLAYTCP/IP TCP/IP

SIP

SIPRTP

RTP


Architecture ...

.

Signaling Control Unit

SIP Handler

PARLAT/SIP Glue

Parlay handler

Media Control Unit

RTP Handler

MediaHandler

Media Manager

MediaHandler

MediaHandler

MEGACO/H248


Dial in ...

.

Figure 5 - Mapping for dial-in

2 0 0 . . .

A p p l i c a t i o n G a t e w a y P 1 P 2 P 3

c r e a t e C o n f e r e n c e ( )

g e t S u b c o n f e r e n c e s ( )

I N V I T E 2 0 0 . . .

A C K p a r t y J o i n e d ( )

I N V I T E 2 0 0 . . .


I N V I T E 2 0 0 . . .


r e l e a s e ( )

m o v e C a l l L e g

m o v e C a l l L e g

B Y E B Y E

B Y E 2 0 0 . . .

2 0 0 . . .


Dial out ...

.

A p p l i c a t i o n G a t e w a y P 1 P 2 P 3

c r e a t e C o n f e r e n c e

g e t S u b c o n f e r e n c e

c r e a t e C a l l L e g

r o u t e ( ) I I N V I T E

2 0 0 O K

a t t a c h M e d i a ( ) A C K

c r e a t e C a l l L e g ( )

r o u t e ( ) I N V I T E

2 0 0 O K


c r e a t e C a l l L e g ( )

r o u t e ( ) I N V I T E

2 0 0 O K


M o v e C a l l L e g ( )

M o v e C a l l L e g ( )

r e l e a s e ( ) B Y E

2 0 0 O K B Y E

2 0 0 O K B Y E


The mapping ...

PARLAY Call Control Services that cannot be mapped onto SIP– There seems to be none– However the mapping can be done in several ways in some cases

SIP semantics that are not visible in PARLAY APIs as per today’sspecification– There exist a few (e.g. Possibility of a caller to state for instance that

the call should not forwarded)– PARLAY may be extended to cater to these features

.


Pros and cons of OSA/ Parlay: A few cautious statements ...


Pros and cons ...

Pros- PARLAY/OSA allows the creation of a wide range of services

including services that combine different types of network capabilities (e.g. call control, mobility, presence)

- Parlay allow the creation of services that span several network technologies (e.g. Sip, H.323, 3GPP, soft-switches)

Cons- The level of abstraction is still low

- 3N+1 calls were required to create a conference call in older versions of Parlay – The number is now N+1

- Parlay is not easy to grasp by people with no circuit switched telephony/IN background

- Call leg concept


JAIN JCC/JCAT

1. Introduction

2. Key features

3. Pros and cons


Introduction ...

JAIN• JAVA API for telecom products and service development

– Protocol layer API• Give access to specific protocol stack• SS7• SIP • H.323 API

– Relatively low level of abstraction • Not very suitable for service creation

.


Introduction ...

JAIN• JAVA API for telecom products and service development

– Application layer API • Higher level of abstraction• A wide range has been published including

– Presence– Instant messaging

• Focus in this tutorial– Java Call Control API (JCC) – Released in 2001– Java Co-ordination and Transaction (JCAT) – Released in 2001

.


Benchmark services for first release ...

Voice virtual private network (VVPN)- corporate services for private dialling plans

Voice activated dialing (VAD)

Click to dial

Voice recognition based user agent (VRUA)

Meet-me conference


Key features ...

APIs that give access to call control capabilities- Call model

. Call

. Connections

. Address

No capabilities for making the access to the call control capabilities secure, resilient and accountable– Plans to use the Java version of Parlay framework in future releases

Not aligned with Parlay- Plans to align in the future

.


Pros and cons ...

Pros– Service driven approach

Cons:– Work seems to have lost momentum– Relatively low level of abstraction– Language dependence

.


The Call Processing Language

.

1. Introduction

2. Requirements

3. Constructs

4. Example

5. Pros and cons


Introduction ...

Specificities:- Only architecture that aims at service creation by end-users

Prime target: Un-trusted parties– Direct use– Use via a graphical user interface

• Higher level of abstraction• Mapping done by middle ware

.


Introduction ...

Targeting end-users has a few consequences:– Stringent language requirements

– Need to upload scripts to servers• REGISTER has been proposed for SIP• No mechanism has been proposed for H.323

.


Requirements on language (From the RFC).

Lightweight, efficient easy to implement

Easily verifiable for correctness

Executable in a safe manner

Easily writeable and parsable

Extensible

Signaling protocol independence


Constructs for an XML Based CPL ...

Switches– Choices the script can make

• Address, string, time, prioritySignaling operation

– Cause signalling events in underlying protocol• Proxy, redirect, reject

Location modifier– Add/remove location


Simplified example from the RFC ...

Time switch:

Mon. – Fri From 9am to 5pm

Sat-SunFrom 9am to 10pm

01.01.03-15.01.03

Otherwise

Location: [email protected]



Redirect

Location:sip:[email protected]

Proxy


Pros and Cons ...

Highly suitable for service creation by end-users– End-users familiar with scripts / XML– End-users unfamiliar with scripts / XML (via GUI)– Offer required security

However:– Very few end-users are interested in creating service– CPL is highly unsuitable for service creation by providers / third

parties• Range of services that can be created is limited• More powerful tools exist

– Service logic and service data need to reside in the same script.


To probe further ...PARLAY:PARLAY specifications, http: //www.parlay.org/A.J. Moerdijk and L. Klostermanns, Opening the networks with Parlay/OSA: Standards and

Aspects behind the APIs, IEEE Netowork Magazine, May/June 2003S. Bessler, A.V. Nisanyan, K. Peterbauer, R. Pailer and J. Stadler, A Service Platform for

Internet-Telecom Services Using SIP, SmartNet 2000.S. Desrochers, R. Glitho, K. Sylla, Experimenting with PARLAY in SIP Environment: Early

Results, IPTS, Atlanta, July 2000 -N. Edwards, SIP Support in PARLAY, Btexact, www.btexact.comN. Edwards, PARLAY and SIP, Issue 1, British Telecoms plc (2000)R. Glitho, A. Poulin, K. Sylla, and O. Cherkaoui, Using PARLAY for Centralized Conferences

in SIP Environment, ICIN 2001, October 2001

JAIN JCC/JCATJSR 00021 http://www.jcp.org/aboutJava/communityprocess/review/jsr021/R. Jain et al. Java Call Control and Session Initiation Protocol (SIP). IEICE Transactions on

Communications, December 2001

CPLRFCs

.


Questions?


Part III: Emerging Trends

• Web services

• Mobile agent based architectures


Web services …..

.1. Web services basics

2. Emerging telecoms standards

3. A case study

A key for stimulating NGN service development by developers from the IT/Internet world


Web services basics …

.

1. Introduction

2. Architecture

3. Technologies

4. Application areas


Introduction: Evolution of the Web

Today Tomorrow

• Publication of documents • Publication of “reusable business logic”

• Human interaction • Automated P2P interaction

• Proprietary ad-hoc interfaces • Industry standard interfacesX

ML

Tec

hnol

ogy


Introduction: Definitions

“The term Web Services refers to an architecture that allows applications (on the Web) to talk to each other. Period. End of statement”

Adam Bobsworth in ACM Queue, Vol1, No1

The three fundamental principles, still according to Adam Bobsworth:

1. Coarse grained approach (I.e. high level interface)2. Loose coupling (e.g. application A which talks to application B

should not necessarily be re-written is application B is modified)3. Synchronous mode of communication, but also asynchronous

mode.


Introduction: Standardization Some of the involved standards bodies / Consortia

- Architectures and Technologies- World Wide Web Consortium (W3C)

- Interoperable technologies for the Web- OASIS

- Structured information standards that permit interoperability- Liberty Alliance

- Open standards for federated network identities (pertinent to Web service security)

- Application to specific areas- Parlay- Open Mobile Alliance (OMA)- International Imagery Association


Introduction: Standardization Some of the involved standards bodies / Consortia

Application to specific areasTelecom

- Parlay- Open Mobile Alliance (OMA)

Digital images- International Imagery Association


Broker(Human + agent)

Requestor(Human + agent)

Provider(Human + agent)

Architecture: Entities


Architecture: Entities Requestor• Person or organization that wishes to make use of a Web service.• Uses an agent (I.e requestor agent) to exchange messages with both

broker agent and provider agent.Provider• Person or organization that owns a Web service it wants to make

available for usage• Use an agent (I.e provider agent) to exchange messages with broker

agent and requestor agent.• The provider agent is also the software piece which implements the Web

service (e.g. mapping towards legacy)Broker• Person or organization that puts requestors and providers in contact

– Providers use brokers to publish Web services– Requestors use brokers to discover Web services

• Use an agent (I.e broker agent) to exchange messages with requestor agent and provider agent


Architecture: Interactions …

Service Requestor

Service Broker/Registry

Service Provider 2

Service 1 Description


Publish

Publish

Find

Bind


Service Provider 1Service 1


Service 2



Technologies

Network

XML-Based Messaging

Service Description

Service Publicationand Discovery Security

Managem

ent

QoS

UDDI

UDDI

WSDL

SOAP

HTTP, FTP,SMTP, MQ,

IIOP, etc


Technologies: XML The foundation

– Used for message format, but also for service definition – Creation and management of dynamic content

• Documents– Element(s)

» Type» Content

– Structures» Enable the grouping of elements

• Schemas– Enable the validation of instances

• Instances– Actual data


Technologies: WSDLXML schema for describing Web service interfaces

Concepts– Service: collection of related end-points– Binding: concrete protocol and data format specification– Port: End point defined as the combination of a binding and a

network address– Operation: abstract description of an action supported by the

service– Messages: abstract definition of of the data being exchanged


Technologies: WSDLThe three major elements• Service bindings

– Network transport to be used by the endpoints involved in exchange ( so far SOAP, HTTP and MIME)

• Abstract operation– Identification of the type of operations that are supported

• One way• Request / reply

• Data types definitions– Messages– Data types


Technologies: SOAP

Lightweight messaging framework for exchanging formatted XML data

Consists of several parts• Envelope (mandatory): Start and end of message• Header (optional): Optional attributes used in the processing• Body (mandatory): Message being sent• Attachment (optional) : Self-explanatory• RPC interaction (optional) : How to model RPC interactions style with

SOAP Encoding (optional) : How to represent data being transmitted in the message


Technologies: SOAP

SOAP EnvelopeSOAP Header

SOAP Header Block

SOAP Header Block

SOAP Body Block

SOAP Body BlockSOAP Body


Technologies: UDDISOAP APIs XML data model for registering and discovering Web services and info concerning the

business that publishes them:– Business Entity: info about business (name, description,

identifier, contact,…)– Business Service: description, applicable categories, binding

templates– Binding Templates: info on where to find and use the service,

association between business service and service type– Service Type: abstract definition of the service in a tModel

containing name of organization, categories describing the service, pointers to technical information


Architecture and Technologies …

Service Requestor

Service RegistryUDDI

Service Provider 2

WSDL Service 1 Description


PublishWSDL, UDDI/SOAP

PublishWSDL, UDDI/SOAP

FindWSDL, UDDI/SOAP

Bind


Service Provider 1Service 1


Service 2



Application areas Any area that requires program to program

interactions over a network Telecommunications• Applications accessing network capabilities exposed as Web services

– Network capabilities (e.g call control, presence, messaging)– Applications (e.g multiparty gaming, sports key events)– Issues

• Exposing the network capabilities at a high level of abstraction (I.e. coarse grain principle)

• Accessing the Web services in a secure, accountable, and resilient way

Imaging- Automation of manipulation, printing and sharing digital images- CPXe consortium (e.g Kodak, HP, Konica, Olympus and others)


Emerging Telecoms standards …

.

1. Introduction

2. Parlay-X

3. Others1. ECMA – CSTA applications2. OMA

4. A quick assessment


Introduction …

Two goals:

1. Define Web services for making telecommunications capabilities available to applications in same or foreign domain

2. Offer supporting / common functions - Security (e.g. authentication, authorization, non repudiation)- Billing- Service management (e.g. registration, discovery)


Parlay – X Web services – Introduction

1. Specifications available in their first version- White paper + actual specifications- Released as part of Parlay 4.0 specifications

2. Application interfaces- Do not tackle the common functions (e.g. security) issue- Aim at covering all telecommunication capabilities

- Stand alone capabilities (e.g. presence, call control)- Combined capabilities (presence + call control)

3. Use the reference Web service principles (e.g. coarse grained) technologies (e.g. WSDL)

.


Parlay – X Web services – Architecture

.

Parlay Gateway

Parlay X Web Services

Parlay X APIs

Parlay APIs

Parlay XApplications

ParlayApplications

Network Protocols (e.g. SIP, INAP etc)

Network Elements

Increasingabstraction


Parlay – X Web services – The services in 1.0 1. Call control

- Application initiated third party call- Network initiated third party call

- Handling of a set of conditions (e.g. busy, not reachable, no answer) 2. Messaging

- SMS- MMS

3. Payment (e.g. volume charging)4. Account management (e.g. account credit expiration date query)5. User status (online / offline)6. Terminal location

.


ECMA – CSTA Web services - Introduction

ECMA- Industry association created in 1961- Standards for Information and Communication Technologies (ICT)

- Specification pushed in international standards as appropriate- ISO- ETSI

Computer Supported Telecommunications Applications (CSTA) Web service- Computer Telephony Integration (CTI)

- Example: computer answering automatically call and playing announcement on options to select

.


ECMA – CSTA Web services -Simplified architecture

. ComputingFunction

SpecialResourceFunction

SwitchingFunction

Web services Web services


ECMA – CSTA Web services …The services

Interactions between special resource function and computing function- Based on the “low level’ commands that can be given

- Start / stop / suspend

Interactions between computing functions and switching functions- Based on the “low level” functionality of the switch - Almost a direct mapping between functionality and Web services- Very complex and detailed call model

- Reports on calls- Supplementary types of services (e.g. call forward, camp-on, intrude call)

.


OMA – Web services - Introduction

OMA- Industry association created in 2002- Focus on mobile services- Aim at:

- Consolidating standards for wireless services (e.g. 3GPP/PP2, IETF, W3C)- Producing new standards if needed

- Scope- Service enablers

- Interfaces for accessing network capabilities for building specific classes of services- Gaming- MMS- Presence- Others

- Common functions- Functions needed by all enablers (e.g. security, billing)


OMA – Web services – Common functions

Common functions are key to interoperabilityRequirements- Common supporting technologies

– XML 1.1– SOAP 1.1– WSDL 1.1– HTTP 1.1

- Common supporting functions• Security• Billing• Service Management

.


OMA – Web services – Common functions

Service management requirements

– Service Registration: UDDI 2.03 Data Structures schema.

– Service Publication: UDDI 2.04 Publishing API.

– Service Discovery: UDDI 2.04 Inquiry API.

– Service Level Agreement

– Service Delivery

– Service Integrity Management


A quick assessment

1. Parlay-X Web services- True Web services

- Coarse grained approach (unlike WSDL version of Parlay specifications)- Work done “independently” of OMA

- Situation is evolving (e.g. joint meetings are planned)2. ECMA – CSTA- Low level of abstraction

- WSDL version of existing specifications- Highly specialized for CTI

- Not suitable for call control applications in general3. OMA

- Tackle critical issues such as common functions- Integration of existing standards may take longer than planned


A case study on presence enabled chat

• 1 - Introduction

• 3 - Features

• 4 - Architecture and mapping

• 5 - Some lessons


Introduction

Joint work Ericsson / Concordia University (TSE lab)

- Aims- Define Web services for presence and advanced call control (e.g. conferencing,

floor control)- Study mapping issues- Contrast implementations alternatives (e.g. Parlay based gateway vs. SIP servlet

gateway)- Evaluate performance (e.g. overhead induced by Web Web services, Parlay

based alternative vs. SIP servlet based alternative)- Build demo applications

We have assimilated the presence enabled chat to a presence enabled conducted conference


Features – Presence enabled

• User may be:

Rajesh is offline

Rajesh is online now

– Online

– Offline

• Update user’s presence in every ten seconds


Features - Conference Management

• Four operations provided:

– Terminate a conference

– Add a user to conference

– Remove a user from conference

– Initiate a conference


Features - Sub-Conference Management

• Five operations provided:

– Terminate a sub-conference

– Add a user from main conference to sub-conference

– Remove a user from sub-conference to main conference

– Move a user from one sub-conference toanother

– Initiate a sub-conference


Architecture - Overview

Presence Enabled Presence Enabled Chat ApplicationChat Application

WS Presence

SIP Servlet gateway

Service to Parlay Parlay SIP gateway

HTTP/SOAPHTTP/SOAPHTTP/SOAPHTTP/SOAP HTTP/SOAPHTTP/SOAP CORBA/IDLCORBA/IDL

Parlay SIP gateway

3G Networks


Conferencing Web service ...

.

booleaninitiateConf( String[] addresses,String mediaType,String confType, int duration,int expectedUsers, String confID);booleanendConf( String confID);

booleanaddUser( String userAddress, String confID );

booleanremoveUser(String userAddress, String confID );

booleaninitiateSubConf( String[] users, String ConfID,String subConfID )

booleanendSubConf( String ConfID, String subConfID )

booleanmoveUser( String user, String ConfID,String OriginSubConfID,String DestinationSubConfID)


Mapping onto Parlay ...

.

W e b S e r v ic e P a r l a y G a te w a y

F u n c t i o n C a l l F u n c t i o n C a l l t o / f r o m G W

# t i m e s p e r W S f u n c t i o n c a l l

c r e a t e C o n f t o 1 / f u n c t i o n c a l l c r e a t e C a l lL e g t o 1 / p a r t y in c o n f e r e n c e r o u t e C a l lL e g t o 1 / p a r t y in c o n f e r e n c e a t t a c h M e d ia t o 1 / p a r t y in c o n f e r e n c e

I n i t i a t e C o n f

r e l e a s e ( s u b - c o n f e r e n c e ) t o 1 / s u b - c o n f e r e n c e in c o n f e r e n c e

r e l e a s e ( c o n f e r e n c e ) t o 2 / f u n c t i o n c a l l e n d C o n f

c a l lL e g E n d e d f r o m 1 / p a r t y in c o n f e r e n c e c r e a t e C a l lL e g t o 1 / f u n c t i o n c a l l r o u t e C a l lL e g t o 1 / f u n c t i o n c a l l a t t a c h M e d ia t o 1 / f u n c t i o n c a l l

a d d U s e r

r e l e a s e ( c a l lL e g ) t o 1 / f u n c t i o n c a l l r e m o v e U s e r c a l lL e g E n d e d f r o m 1 / f u n c t i o n c a l l c r e a t e S u b C o n f e r e n c e t o 1 / f u n c t i o n c a l l i n i t i a t e S u b C o n fm o v e C a l l L e g t o 1 / p a r t y in s u b C o n f e r e n c er e l e a s e ( s u b - c o n f e r e n c e ) t o 1 / f u n c t i o n c a l l E n d S u b C o n f c a l lL e g E n d e d f r o m 1 / p a r t y in s u b C o n f e r e n c e

m o v e U s e r m o v e C a l l L e g t o 1 / f u n c t i o n c a l l


A lesson learned …

A footprint measurement …Conferencing part of application using Web Service ….– About 350 lines of code

– About 1300 lines of codeSame part using Parlay ..

Web service does make life easier to application developers …


To probe further ...On Web servicesW3C specificationsECMA specificationsParlay-X specificationsOMA specificationshttp://www.webservices.org/- F. Curbera et al., Unraveling the Web services Web: An Introduction to SOAP, WSDL and UDDI, IEEE

Internet Computing, Vol. 6, No2, March-April 2002, pp. 86-93

IEEE Internet Computing Special Issue, Middleware for Web services, January/February 2003

IEEE Computer Magazine, Special issue, Web services computing, October 2003

On the case study:K. Hassan, J. Dasilva, R. Glitho and F. Khendek, Web services for call control in 3G

networks, A Parlay based implementation, submitted ICC04R. Karunamurthy, F. Khendek, R. Glitho, Web service for presence: Interfaces,

Implementation and performance analysis, submitted ICC04

.


Questions?


Mobile Agents Based Architectures ...

1. Mobile agents

2. Mobile agents and service engineering

3. Architectures

4. A Case study


Mobility is vital ...Mobility is vital ...

-

If it it weren’t formobility, we wouldstill be trees …”G. Cybenko(Comments at a mobileagent workshop)


Mobile agents ...

Definition– Autonomous and identifiable program– Can migrate between physical nodes (e.g. have an itinerary)– Not necessarily intelligent (could be very smart or mentally

impaired)

Platform– Environment for mobile agent execution – Key enabling technology: Java– Examples: Jade, Grasshopper


Mobile agents and service engineering ...Motives

– Reduction of network load / response time / CPU consumption at client side for some classes of services

– Hard to meet service engineering requirements• Universal access

– How can end users have access to their services with the same look and feel wherever they roam?

– Mobile agents could carry these services and follow end users.


Mobile agents and service engineering ...

Some road blocks– The advantages do not necessarily offset the cost associated

to mobile agent deployment • Perceived “lack of security”• Interoperability


An example of architecture

TERMINAL

Subscription ManagementUnit (SMU)

SIP server/H.323 GK

Service ImplementationRepository (SIR)

MAPlatform

MAPlatform

MAPlatform

Mobile serviceagent

Mobile serviceagent

Mobile serviceagent


Case study: Multiparty Event Scheduling ... Multiparty event

– events involving more than 2 persons • Social events: (e.g. family gathering)• Business events (e.g. face-to-face meetings) • Electronic multiparty sessions (e.g. teleconferences)

Multiparty event scheduling: State of the Art– Tools based on client/server offered by MS Outlook (You

download from the server(s) the calendars of all participants on your machine and search “manually”)

A Mobile agent based approach– Dispatch the agent(s) in the network. The agent visits the

servers and identify the date(s) locally


Case study: Multiparty Event Scheduling ...

• Multiparty event– events involving more than 2 persons

• Social events: (e.g. family gathering)• Business events (e.g. face-to-face meetings) • Electronic multiparty sessions (e.g. teleconferences)

• Multiparty event scheduling: State of the Art– Tools based on client/server offered by MS Outlook (You

download from the server(s) the calendars of all participants on your machine and search “manually”)

• A Mobile agent based approach– Dispatch the agent(s) in the network. The agent visits the

servers and identify the date(s) locally


Case study: Multiparty Event Scheduling ...

Calendar API

Server Tracking

Calendars

Scheduler Agent

Negotiating agent 1

Support Agent

Negotiating agent 2

Negotiating agent N


Case study: Multiparty event schedulingCommunication cost : event scheduled on day 15

0

100

200

300

400

500

600

700

5 10 15 20 25 30

Number of participants

Am

ount

of d

ata

in k

iloby

tes

plain client-server

mobile agent

optimised client-server


To probe further ...On Mobile agents• D. Chess et al., Mobile Agents: Are They a Good Idea?, IBM Research Report, RC 19887

(88465), 1994• A. karmouch and V. A. Pham, Mobile Software Agents: An Overview, IEEE

Communications Magazine, July 1998, Vol.36, No7On mobile agent based information retrieval applications• Dag Johansen, “Mobile Agent Applicability,” Proc. MA’98: Second International

Workshop on Mobile Agents, Lecture Notes in Computer Science, No. 1477, Springer-Verlag, 1998, pp. 80-98.

• R.H. Glitho, E. Olougouna and S. Pierre, Using Mobile Agents for Information Retrieval: A Brief Overview and an Elaborate Case Study, IEEE Network Magazine, January/February 2002, pp .34-41 –

On mobile agent based service architectures• F. G. Chatzipapadopoulos et al., Mobile Agent and CORBA Technologies in the

Broadband Intelligent Network, IEEE Communications Magazine, June 2000 Vol.38 No. 6, pp. 116 – 124

• D. Stefano and C. Santoro, Agent support for personal mobility, IEEE Internet Computing, Vol.4, No2, March/April 2000, pp. 74-79

• B. Emako, R.H. Glitho and S. Pierre, A Mobile Agent based Advanced Service Architecture for Wireless Internet Telephony: Design, Implementation and Evaluation, IEEE Transactions on Computers, Vol. 52, NO. 6, June 2003

•


Conclusions

There is no silver bullet for service engineering in next generation networks ...