Roch H. Glitho- Ericsson/Concordia University

Transcription

1 Roch H. Glitho, Ph.D. Expert - Service Engineering, Ericsson Canada Adjunct Associate Professor - CIISE, Concordia University, Canada Roch.Glitho@ieee.org 1

2 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. 2

3 Outline Part I - Basics of service engineering and next generation networks Part II - service architectures for next generation networks Part III Emerging trends 3

4 Part I: Basics of Service Engineering and Next Generation Networks Service engineering Next generation networks 4

5 Service Engineering: Concepts A discipline still in childhood Services 2. Service Life Cycle 3. Service Engineering 5

6 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 6

7 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 7

8 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 8

9 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. 9

10 Service Engineering: Legacy architectures A discipline still in childhood Intelligent Networks (IN) 2. Wireless Access Protocol (WAP) 3. Telecommunication Information Network Architecture (TINA) 10

11 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 11

12 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) 12

13 IN: Fundamental Principles Separation of switching software and service logic Main implication: Need for an interaction model between switching and service Functional entities / nodes Protocols And more Standardization of capabilities for building services Main implication: Need for components that can be used in various ways for building services Room for a wide range of services Room for differentiation. 13

14 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 14

15 IN: A Brief History of Capability Sets Capability set 1 (CS1) 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) 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 15

16 IN: A Brief History of Capability Sets Capability set 3 (CS3) 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) 16

17 IN: A four planes conceptual architecture Service Plane Services as seen by end-users. Global Functional Plane Functionality required to build the services (e.g. Service independent building blocks) Distributed Functional Plane Functional entities that make the IN network Physical Plane Physical nodes 17

18 IN: Service Plane Services as seen by end-users are made of features and features are specified in groups Examples 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 18

19 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. 19

20 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 20

21 IN: Global Functional Plane Simplified Free phone Translate SIB (For translating into the Real phone number) Basic call Process. CHARGE SIB (For reverse charging) 21

22 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 22

23 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 23

24 IN: Physical plane An example of physical implementation... INAP - Service control point (SCP). Service switching point (SSP) Service switching point (SSP) Service switching point (SSP) 24

25 IN: Physical Plane... INAP protocol stack Intelligent Network Application Part (INAP) Transaction Capabilities Application Part (TCAP) Application layer. Signalling Connection Control Part (SCCP) Message Transfer Part 3 Message Transfer Part 2 Message Transfer Part 1 Network layer Data link layer Physical layer 25

26 IN: Physical Plane... A simplified INAP message exchange for free phone SSP InitialDP (call id, dialled number, free phone) SCP / SDP Connect (call id, destination id). eventreport (callid, D_Answer, time stamp) Charging Eventreport (call-id, O_disconnect, time stamp) 26

27 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 27

28 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 28

29 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 Raison d etre Limitations of cellular phones( Power, memory, battery) Limitations of today s wireless networks (Scarce bandwidth, unreliable links). 29

30 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) Independence of underlying bearer (e.g. GSM, TDMA, PDC). 30

31 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 31

32 WAP: Basic Architecture Network view Air interface... Client Gateway Application (e.g. cell phone, pager) Server (User domain) (Service provider) (Internet domain) Encoded Request HTTP Request. Encoded Reply HTTP Reply 32

33 WAP: Basic Architecture Protocol stacks (Legacy WAP 1.x stack + WAP 2.0 Internet protocol stack)... Legacy WAP 1.x stack Web server stack. Wireless Application Environment (WAE) Wireless session protocol (WSP) Wireless transaction protocol (WTP) Wireless transport layer security (WTLS) WAE HTTP SSL WAP 2.0 stack Web server stack Wireless Application Environment (WAE) WP - HTTP WP - Transport Layer Security (TLS) WP - TCP WAE HTTP TLS TCP Wireless datagram protocol (WDP) TCP IP IP Bearer (e.g. TDMA, CDMA) IP Bearer (e.g. TDMA, CDMA) 33

34 WAP: Basic architecture... Device architecture. Application Framework (Wireless Application environment, Push, Messaging) Network protocols Content handling Others (e.g. Authentication) 34

35 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). 35

36 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. 36

37 WAP: Simplified Push Air interface... (User domain) Client (e.g. cell phone) (Service provider domain) Gateway Push Initiator. Push Over the Air Protocol (OTA) Encoded Request Encoded Reply Push Access Protocol (PAP) HTTP Post (Content to pushed) HTTP post (Results) Other network nodes (e.g. voice mail) 37

38 WAP: Simplified WTA Air interface... (User domain) Client (e.g. cell phone) (Service provider domain) Gateway WTA Server. Encoded Request Encoded Reply HTTP Request HTTP Response Other network nodes (e.g. SCP) 38

39 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). 39

40 WAP: MMS MM1 interface Air interface... Air interface... User A User B. MMS Server MMS server Wireless Network Wired Network Wireless Network 40

41 WAP: MMS Air interface... (User domain) Client (e.g. cell phone) (Service provider domain) Gateway MMS server. Encoded Request Encoded Reply HTTP Request HTTP Response 41

42 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 - 42

43 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)) - 43

44 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. 44

45 Telecommunication Information Network Architecture (TINA): The first architecture for telephony and non telephony services Introduction 2. Fundamental principles and concepts 3. Service architecture 4. A retrospective 45

46 TINA: Introduction Product of thetina consortium (TINA-C) First phase: Production of specifications by a core team based in same location (NJ, USA) Validation (e.g. prototyping) by associated projects Second phase: 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 46

47 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) 47

48 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 48

49 TINA: Introduction Specifications Distributed Processing Environment (DPE) Business model Network resource architecture Service architecture Many prototypes but very few products. 49

50 TINA: Fundamental principles The separation principle Infrastructure Service Network Service Subscription Access Usage Service usage Business model as starting point for specifications - Roles - Interfaces 50

51 TINA: Fundamental principles Business roles / interfaces. Note: Taken from IEEE Communications Surveys & Tutorials (Reference [x]) 51

52 TINA: Fundamental principles Roles 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 52

53 TINA: Fundamental concepts Service 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) 53

54 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 54

55 TINA: Service Architecture 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 55

56 TINA: Service Architecture 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 56

57 TINA: Service Architecture Access session: Provider agent Initial agent User agent Service factory Access session request Authentication Search for user agent Access session request Access session activation request Get list of available services Start a specific service session Activation of Access session Service session activation request Activation of service session 57

58 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 58

59 A Few References To probe further... IN 1. ITU-T specifications, Q. 12xx series 2. J. Zuidweg, Next Generation Intelligent Networks, Artech House publishers, Fayenberg, L. Gabuzda, M. Kaplan and N. Shah, The Intelligent Networks Standards: Their Applications to Services, McGraw-Hill, R. H. Glitho and Th Magedanz (eds), Intelligent Networks in the New Millenium, IEEE Communications Magazine, June 2000, Vol. 38, No. 6 WAP 4. WAP specifications, 5. WAP 2.0 Technical white paper, 6. M. Van Der Heijden and M. Taylor, Understanding WAP: Wireless Applications, Devices and Services, Artech House publishers, 2000 TINA 7. TINA Specifications, 8. J. Zuidweg, Next Generation Intelligent Networks, Artech House, Y. Inoue et al., The TINA Book, Prentice Hall Europe, H. Berndt, T. Hamada, and, P. Graubmann TINA: Its Achievements and its Future Directions, IEEE Communication & Surveys, 1Q 2000, 59

60 Questions? 60

61 Next Generation Networks 1. Definition/Characteristics 2. SIP, H.323, Megaco/H softswitches 4. 3GPP/3GPP2 Networks 61

62 Definition / characteristics 1. Distinctive characteristics 2. A brief history 3. The protocol jungle 62

63 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) - 63

64 A brief history Milestones Late 70s: First two party voice calls over Internet (Network Voice Protocol (NVP - RFC 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) 64

65 The protocol jungle. 65

66 Session Initiation Protocol (SIP) 1. Introduction 2. Functional entities 3. Messages 4. A simplified call case 66

67 SIP: Introduction A 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 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 67

68 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) 68

69 SIP: The functional entities User 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 69

70 SIP: The messages Generic structure - Start-line - Optional message body Request message - Request line as start line. Method name. Request URI. Protocol version Response message - Status line as start line. Protocol version. Status code. Reason phrase (Textual description of the code) 70

71 SIP: The messages Request 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 codes 1xx: Provisional 2xx: Success 6xx: Global failure 71

72 SIP: A simplified call case CALLER PROXY A PROXY B CALLEE. INVITE (1) INVITE (2) 100 TRYING (3) INVITE (4) 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) 72

73 H Introduction 2. Functional entities 3. Protocols 4. A call case 73

74 H.323: Introduction An umbrella ITU-T standard including signalling standards: H Q.931 H.245 Others (e.g. H.324 Terminal for low bit rate multimedia communications) Focus in this tutorial: Signalling 74

75 H.323: The functionality entities Terminals - End point - Used for real time two way multimedia communications with another end point Gatekeeper - Control how terminal access networks - Provide address translation Gateway - End point - Used for communications between H.323 terminals and terminals in the PSTN Multipoint control unit - Provides centralized conferencing functionality 75

76 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 Media negotiation 76

77 H.323 signaling: A simplified call case Caller Gatekeeper RAS (admission request) Callee Q.931 (Call set up) H.245 (Media negotiation) RTP. H.245 (Logical channel closing down) Q.931 (Call tear down) RAS (Resource release) 77

78 Megaco / H Introduction 2. Genesis 3. Concepts 4. A simplified call case 78

79 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 79

80 Megaco/H.248 : Introduction Media Gateway controller Media Gateway Media Gateway Media Gateway. 80

81 Megaco/H.248: Genesis A long history starting in 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) 81

82 Megaco/H.248: Concepts Termination 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 82

83 Megaco/H.248: A simplified call case SIP Proxy MGC MG PSTN INVITE ISUP INVITE to PSTN OK ISUP OK to MGC ACK Add RTP stream to context Add PCM stream to context PCM RTP. 83

84 Soft-switches 1. Introduction 2. Overview 3. A simplified call case 84

85 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 85

86 Soft-switches : Overview ISUP H.323 SIP Soft-switch (Media Gateway Controller + Some intelligence) MGC protocols Media Gateway Media Gateway Media Gateway. 86

87 Soft-switches : Overview An example of soft-switch as class 5 replacement Soft-switch Signaling (e.g. ISUP, SIP) Soft-switch MGC protocol MGC protocol Media Gateway (Residential gateway) Media (I.e RTP) Media Gateway (I.e. Residential gateway). 87

88 Soft-switches : Overview An example of soft-switch as class 4 replacement Soft-switch Signaling (e.g. ISUP, SIP) Soft-switch Media Gateway MGC protocol RTP for media MGC protocol Media Gateway ISUP signaling PCM for media PCM for media ISUP signaling Class 4 switch Class 4 switch. 88

89 Soft-switch: A simplified call case (Calling card) Caller Local exchange Soft-switch MG MG Soft-switch Local exchange Call to access number (I.e soft-switch) Info request (e.g. card number, Callee number) Verification (e.g. account, Digit analysis) Call request (e.g. SIP, SIP-T) Call request (ISUP). PCM RTP PCM 89

90 3GPP/3GPP2 Networks 1. Introduction 2. 3GPP networks 3. Overview of the IP Multimedia (IM) portion 90

91 Introduction 3GPP - 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 91

92 3GPP networks Essentials - 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 H.248/Megaco 92

93 IP multimedia portion IP M ultim edia N etw orks PSTN Leg acy mobile signalling Networks Mb Mb PSTN BGCF CSCF PSTN Mk Mk Mm IM S - MGW Mn Mj MGCF BGCF Mg Mw Mi CSCF Cx Dx HSS C, D, Gc, Gr Mb Mr Mw SLF Mb MRFP Mb M p Mb MRFC PDF P Go -C SC F Gm UE IM Subsystem ISC Dh Sh,Si AS 93

94 IP Multimedia portion Some of the functional entities Call 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

95 To probe further... Next Generation Networks in General - H. Schulzrinne, Converging on Internet Telephony, Special issue, IEEE Network / IEEE Internet Computing, May/June A. Moderassi and S. Mohan, Advanced Signaling and Control in Next Generation Networks, IEEE Communications Magazine, October 2000 SIP H ITU-T specification Megaco - IETF/ITU-T specification Soft-witches F.D. Orthman, Soft-switch architecture for VoIP, McGraw, GPP / 3GPP2 networks - 3GPP / 3GPP2 specifications - Lieve Bos, Suresh Leroy, "Toward an all-ip-based UMTS system - architecture", IEEE Network, no. 1, January/February

96 Questions? 96

97 Part II: Service Architectures for Next Generation Networks Legacy based architectures Signaling protocol specific architectures Signaling protocol neutral architectures 97

98 Legacy based architectures Expectations and Legacy based architectures. A big gap 1. Re-using IN 2. Inter-working with IN PINT SPIRITS 98

99 Re-using IN 1. Introduction 2. Issues and tentative solutions 3. A retrospective 99

100 Introduction: IN again... INAP - Application protocol running on top of SS7 - ASN.1 based SS7 outbound signaling network. Service switching point (SSP) - Switch implementing IN call model (e.g. when to stop and give control to the SCP) - Call models are standardized and come with capability set Service control point (SCP) - Contains service logic - service logic is based on capability set Service switching point (SSP) Service switching point (SSP) 100

101 Introduction: History and motives History - Approach popular in the early days of NGN. Several IETF draft standards. A few initiatives in ITU-T Motives Business: Re-use of IN infrastructure Technical: Internet telephony standards emerged without credible service engineering components IN principles are well known 101

102 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. 102

103 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. 103

104 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 104

105 Inter-working with IN: PINT 1. Introduction 2. Benchmark services 3. Architecture 4. Simplified example 5. Pros / cons 105

106 Introduction PSTN/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 106

107 Benchmark services Click 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. 107

108 Architecture NGN PSTN PINT Protocol PINT Client (Subscriber IP host) PINT Server / Gateway Outside the scope Of standardization Service Control Function. 108

109 Architecture PINT 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 109

110 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 110

111 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. 111

112 Inter-working with IN: SPIRITS 1. Introduction 2. Benchmark services 3. Architecture 4. Pre-SPIRITS (proprietary) implementations 5. Pros / cons 112

113 Introduction Services 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 113

114 Benchmark services Internet call waiting (ICW) - Being informed of incoming PSTN calls while line busy because of Internet 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 114

115 Architecture NGN PSTN SPIRITS Server (Subscriber IP host) SPIRITS Protocol NGN side SPIRIT Gateway SPIRITS Protocol PSTN/IN side SPIRIT Client Service Control Function. Service Switching Function / Call Control Function 115

116 Architecture Protocol 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 116

117 Pre-SPIRITS implementations A very wide range A few described in detail in an IETF RFC - Korea Telecom - Lucent - NEC - Telia / Nortel 117

118 Korea Telecom implementation Functionality - 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) 118

119 Korea Telecom implementation ICW client (Subscriber IP host) SIP ICW Server (SIP Proxy) SIP Gateway to NGN Service Control Point (SCP). Next Generation Networks Intelligent Peripheral (IP) INAP Service Switching Point (SSP) PSTN / IN 119

120 Korea Telecom implementation SIP 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). 120

121 Korea Telecom implementation A simplified call flow ICW client ICW server SCP REGISTER (Notify that client is connected To the Internet) OK REGISTER OK Incoming call detected INVITE INVITE. User decides to accept incoming call ICW clears Internet connection OK OK SCP instructs SSP to establish call 121

122 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. 122

123 To probe further... Re-using IN 1. I. Slutsman et al., Framework and Requirements for the Internet Intelligent Networks (IIN), Internet Draft, March 2000, Work in progress 2. T-C Chiang et al., IN Services for Converged (Internet) Telephony, IEEE Communications Magazine, June 2000, Vol.38 No6, pp E. Evloguiva and R. Glitho, Plugging IN Service Control Points in SIP Networks, IEEE IN Workshop 2000, Cape Town, May C. Gourraud, IPVAS: an IN Based Value Added Service Architecture for IP Telephony, International Conference on Intelligence in Network (ICIN), Bordeaux, January 2000, pp 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 Inter-working with IN 1. S. Petrack and L. Conroy, The PINT service protocol: Extending SIP and SDP for IP Access to Telephone Call Services, RFC 2848, June I. Faynberg et al., Service in the public switched telephone network / intelligent network (PSTN/IN) requesting Internet services (SPIRITS): Protocol requirements, RFC 3298, August I. Faynberg et al., Pre-SPIRITS Implementations of PSTN-initiated services, RFC 2995, November

124 Questions? 124

125 Signaling protocol specific architectures 1. H.323 specific architectures 2. SIP specific architectures 125

126 Signalling Protocol Specific Architectures Does the gain in specifics offset the loss in generality??? 126

127 H.323 specific architecture: The supplementary service approach Specifying services instead of building blocks!!! 127

128 H.323 Supplementary services 1. Introduction 2. The services 3. The architecture 4. Beyond supplementary services 5. Pros and cons 128

129 Introduction Architecture based on pre-in and PBX thinking: Standardization of services (instead of services capabilities) H Recommendation General principles H.450.X Roughly 1 per service Main architectural principle Overlay dedicated network for realizing services Functional entities Messages. 129

130 The services... Services standardized by the end of 2001 Call transfer Call diversion Call hold Call park and pick up Call waiting Message waiting indication Name identification Call offer Call intrusion. 130

131 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. 131

132 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 132

133 Call diversion service (H.450.3) Terminal 1 Gatekeeper Terminal 2 Terminal 3 (Re-routing entity) (Diverting entity) Set up Set up. Facility (Call re-routing request) No reply Detect that call should Be re-directed to Terminal 3 Facility (Call re-routing answer) Release complete Set up 133

134 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 messages Annex 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. 134

135 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. 135

136 The SIP specific tools/ architectures. 1. SIP CGI 2. SIP Servlet API 3. 3GPP SIP Application Server 136

137 SIP CGI 1. Introduction 2. HTTP and HTTP CGI 3. SIP CGI 4. Example 5. Pros and cons 137

138 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 138

139 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 139

140 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. 140

141 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). 141

142 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) 142

143 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 143

144 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. 144

145 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. 145

146 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. 146

147 SIP Servlet API 1. Introduction 2. HTTP servlet API 3. SIP servlet API 4. Examples 5. Pros and cons 147

148 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 148

149 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) 149

150 HTTP servlet API... 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 150

151 HTTP servlet API... Pros Address most HTTP CGI shortcomings - Performance - Can keep data base connections open - Scalability - Servlet containers can be accessed remotely Cons Language dependence 151

152 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. 152

153 SIP Servlet container... A container collocated with a proxy server servlet servlet requests Servlet Container SIP Proxy Server requests responses responses 153

154 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 154

155 SIP servlet request response hierarchy... Request-response Hierarchy -. ServletRequest ServletResponse Javax.servlet SIPServletMessage SIPServletRequest SIPServletResponse Javax.servlet.sip 155

156 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 156

157 SIP servlet Response interface... SIP specific Response handling methods (Based on both core SIP and SIP extensions): doprovisionalresponse dosuccessresponse doredirectresponse doerrorresponse 157

158 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) 158

159 SIP servlet Message interface... SIP specific message handling methods (Access to message content): getcontentlength setcontentlength getcontenttype getcontent getrawcontent setcontent 159

160 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 the setheader. 160

161 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.. 161

162 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. 162

163 3GPP SIP Application Server 1. Introduction 2. Interactions between SIP AS and S- CSCF 3. S-CSCF service control model 163

164 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. 164

165 Interactions SIP AS as terminating user agent (e.g. call screening). Application Server From: X To: Y Call-ID: Z SIP leg #1 SIP leg #1 S-CSCF From: X To: Y Call-ID: Z 165

166 Interactions SIP AS as originating user agent (e.g. wake up call). Application Server SIP leg #1 From: X To: Y Call-ID: Z S-CSCF SIP leg #1 From: X To: Y Call-ID: Z 166

167 Interactions SIP user agent as a proxy (e.g. call forward). Application Server SIP leg #1 From: X To: Y Call-ID: Z SIP leg #1 From: X To: Y Call-ID: Z SIP leg #1 From: X To: Y Call-ID: Z S-CSCF SIP leg #1 From: X To: Y Call-ID: Z 167

168 Interactions SIP AS as third party call control. Application Server SIP leg #1 From: X To: Y Call-ID: Z SIP leg #2 From: P To: Q Call-ID: R SIP leg #1 From: X To: Y Call-ID: Z S-CSCF SIP leg #2 From: P To: Q Call-ID: R 168

169 Service control model. Application Server AS-ILCM AS-OLCM ISC ILCM OLCM Incoming Leg Outgoing Leg ILSM OLSM Model S-CSCF Call R ecords 169

170 To probe further... H.323 specific approaches ITU-T specifications: H.450.x series, recommendation H 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 SIP specific approaches IETF RFCs: SIP CGI - RFC J. Rosenberg, J. Lennox and H. Schulzrinne, Programming Internet Telephony Services, IEEE Network, May/June 1999, Vol.13, No3, pp R. H. Glitho, Advanced Services Architectures for Internet Telephony: A Critical Overview, IEEE Network, July 2000, pp Java Developers Community draft JSR W. Leekwijck and D. Brouns, SIPlets: Java Based Service Programming for IP Telephony R. Glitho, R. Hamadi and R. Huie, Architectural Framework for Using Java Servlets in a SIP environment, ICN2001, July GPP TS , , 170

171 Signaling protocol neutral architectures 1. Parlay 2. JAIN JCC/JCAT 3. CPL 171

172 Signalling Protocol Neutral Architectures Protocol neutral API: A least common denominator or a sound service architecture??? 172

173 OSA/PARLAY 1. Introduction 2. Business model 3. APIs 4. Case Study 6. Pros and cons 173

174 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 174

175 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) 175

176 Introduction PARLAY 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) 176

177 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 177

178 The business model Enterprise Operator (Subscriber) (2) Service Subscription Framework Operator (Retailer) (1) Service Registration (3) Service Usage Client Application (End User ) 178

179 The APIs Client Applications Parlay/OSA APIs Framework APIs Service APIs Resources interfaces Resource Resource Resource Figure 2 Parlay APIs interfaces 179

180 The APIs Some 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 180

181 Service API: Give access to network capabilities Call control User interactions Generic messaging Mobility Terminal capabilities Connectivity management Account management Charging service Data session control Presence and availability management Integrity management 181

182 Framework API: Make the use of the service APIs secure and resilient Trust and security management Event notification Service discovery Service registration Integrity management 182

183 An example of Service API: Call control Multiparty call control service Generic call control service Multimedia call control service Conference call control service 183

184 The call control API Call 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 184

185 The call control API Generic 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 185

186 A case study on PARLAY/OSA and SIP: Run For Your Life game 1 - Introduction 2 - Game 3 - Architecture 4 - Mapping 186

187 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. 187

188 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?. 188

189 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. 189

190 The game

191 Architecture... GAME SERVER. TCP/IP PARLAY / SIP GATEWAY PARLAY TCP/IP Signaling Control Unit Media Megaco/H.248 based Control API Unit SIP RTP SIP RTP Game client Game client 191

192 Architecture... Signaling Control Unit Media Control Unit Parlay handler MEGACO/H248 Media Manager. PARLAT/SIP Glue Media Handler Media Handler Media Handler SIP Handler RTP Handler 192

193 Dial in... A p p lic a tio n G a te w a y P 1 P 2 P 3 createc onference() getsubconferences() IN V IT E partyjoined() A C K. partyjoined() IN V IT E A C K IN V IT E partyjoined() A C K m o v e C a lll e g m ovec allleg release() B Y E B Y E B Y E Figure 5 - Mapping for dial-in

194 Dial out... A p p lic a tio n G a te w a y P 1 P 2 P 3 createc onference getsubconference createc allleg route() IIN V IT E 200 O K. attachm edia() createcallleg() A C K route() IN V IT E 200 O K attachm edia() A C K createcallleg() route() IN V IT E 200 O K attachm edia() A C K M ovecallleg() M ovecallleg() re le a s e () B Y E 200 O K B Y E O K

195 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 s specification 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. 195

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

197 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 197

198 JAIN JCC/JCAT 1. Introduction 2. Key features 3. Pros and cons 198

199 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. 199

200 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

201 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 201

202 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. 202

203 Pros and cons... Pros Service driven approach Cons: Work seems to have lost momentum Relatively low level of abstraction Language dependence. 203

204 The Call Processing Language 1. Introduction. 2. Requirements 3. Constructs 4. Example 5. Pros and cons 204

205 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. 205

206 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

207 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 207

208 Constructs for an XML Based CPL... Switches Choices the script can make Address, string, time, priority Signaling operation Cause signalling events in underlying protocol Proxy, redirect, reject Location modifier Add/remove location 208

209 Simplified example from the RFC... Location: Proxy Time switch: Mon. Fri From 9am to 5pm Sat-Sun From 9am to 10pm Location: Location: Redirect Otherwise Location: 209

210 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. 210

211 To probe further... PARLAY: PARLAY specifications, http: // A.J. Moerdijk and L. Klostermanns, Opening the networks with Parlay/OSA: Standards and Aspects behind the APIs, IEEE Netowork Magazine, May/June 2003 S. Bessler, A.V. Nisanyan, K. Peterbauer, R. Pailer and J. Stadler, A Service Platform for Internet-Telecom Services Using SIP, SmartNet S. Desrochers, R. Glitho, K. Sylla, Experimenting with PARLAY in SIP Environment: Early Results, IPTS, Atlanta, July N. Edwards, SIP Support in PARLAY, Btexact, N. 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/JCAT JSR R. Jain et al. Java Call Control and Session Initiation Protocol (SIP). IEICE Transactions on Communications, December 2001 CPL RFCs. 211

212 Questions? 212

213 Part III: Emerging Trends Web services Mobile agent based architectures 213

214 Web services.. A key for stimulating NGN service development by developers from the IT/Internet world. 1. Web services basics 2. Emerging telecoms standards 3. A case study 214

215 Web services basics 1. Introduction 2. Architecture. 3. Technologies 4. Application areas 215

216 Introduction: Evolution of the Web Today Publication of documents Human interaction XML Technology Proprietary ad-hoc interfaces Tomorrow Publication of reusable business logic Automated P2P interaction Industry standard interfaces 216

217 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 217

218 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 218

219 Introduction: Standardization Some of the involved standards bodies / Consortia Application to specific areas Telecom - Parlay - Open Mobile Alliance (OMA) Digital images - International Imagery Association 219

220 Architecture: Entities Broker (Human + agent) Requestor (Human + agent) Provider (Human + agent) 220

221 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 221

222 Architecture: Interactions Service 2 Description Service 1 Description Find Service Broker/ Registry Publish Service 1 Description Service 2 Description Service Requestor Bind Publish Service Provider 2 Service 1 Service Provider 1 Service 2 Service 2 Description 222

223 Technologies UDDI UDDI WSDL SOAP Service Publication and Discovery Service Description XML-Based Messaging Security Management QoS HTTP, FTP, SMTP, MQ, IIOP, etc Network 223

224 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 224

225 Technologies: WSDL XML 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 225

226 Technologies: WSDL The 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 226

227 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 227

228 Technologies: SOAP SOAP Envelope SOAP Header SOAP Header Block SOAP Body SOAP Header Block SOAP Body Block SOAP Body Block 228

229 Technologies: UDDI SOAP 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 229

230 Architecture and Technologies WSDL Service 2 Description WSDL Service 1 Description WSDL Service 2 Description Service Requestor Service Registry UDDI Find WSDL, UDDI/SOAP Publish WSDL, UDDI/SOAP Publish WSDL, UDDI/SOAP WSDL Service 1 Description Service 1 Service Provider 1 Bind Service Provider 2 Service 2 WSDL Service 2 Description 230

231 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) 231

232 Emerging Telecoms standards 1. Introduction. 2. Parlay-X 3. Others 1. ECMA CSTA applications 2. OMA 4. A quick assessment 232

233 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) 233

234 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). 234

235 Parlay X Web services Architecture Parlay X Applications. Increasing abstraction Parlay APIs Parlay Applications Parlay Gateway Parlay X Web Services Parlay X APIs Network Protocols (e.g. SIP, INAP etc) Network Elements 235

236 Parlay X Web services The services in 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. 236

237 ECMA CSTA Web services - Introduction ECMA - Industry association created in 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. 237

238 ECMA CSTA Web services -Simplified architecture Web services Web services Special. Computing Resource Function Function Switching Function 238

239 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). 239

240 OMA Web services - Introduction OMA - Industry association created in 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) 240

241 OMA Web services Common functions Common functions are key to interoperability Requirements - Common supporting technologies XML 1.1 SOAP 1.1 WSDL 1.1 HTTP Common supporting functions Security Billing Service Management. 241

242 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 242

243 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 general 3. OMA - Tackle critical issues such as common functions - Integration of existing standards may take longer than planned 243

244 A case study on presence enabled chat 1 - Introduction 3 - Features 4 - Architecture and mapping 5 - Some lessons 244

245 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 245

246 Features Presence enabled User may be: Online Offline Update user s presence in every ten seconds Rajesh is offline Rajesh is online now 246

247 Features - Conference Management Four operations provided: Initiate a conference Terminate a conference Add a user to conference Remove a user from conference 247

248 Features - Sub-Conference Management Five operations provided: Initiate a subconference Terminate a subconference Add a user from main conference to subconference Remove a user from sub-conference to main conference Move a user from one sub-conference to another 248

249 Architecture - Overview Presence Enabled Chat Application HTTP/SOAP HTTP/SOAP HTTP/SOAP CORBA/IDL WS Presence SIP Servlet gateway Service to Parlay Parlay SIP gateway Parlay SIP gateway 3G Networks 249

250 Conferencing Web service.... boolean initiateconf( String[] addresses,string mediatype, String conftype, int duration, int expectedusers, String confid); boolean endconf( String confid); boolean adduser( String useraddress, String confid ); boolean removeuser(string useraddress, String confid ); boolean initiatesubconf( String[] users, String ConfID, String subconfid ) boolean endsubconf( String ConfID, String subconfid ) boolean moveuser( String user, String ConfID, String OriginSubConfID, String DestinationSubConfID) 250

251 Mapping onto Parlay.... W eb Service Function Call InitiateC onf endconf adduser Parlay Gateway to/from # times per W S function Function Call GW call createconf to 1/ function call createcallleg to 1/ party in conference routecallleg to 1/ party in conference attachm edia to 1/ party in conference release (sub-conference) to 1/ sub-conference in conference release (conference) to 2/ function call calllegended from 1/ party in conference createcallleg to 1/ function call routecallleg to 1/ function call attachm edia to 1/ function call release (callleg) to 1/ function call rem oveu ser calllegended from 1/ function call createsubconference to 1/ function call initiates ubc onf m ovecallleg to 1/ party in subconference release (sub-conference) to 1/ function call EndSubConf calllegended from 1/ party in subconference m oveuser movecallleg to 1/ function call 251

252 A lesson learned Web service does make life easier to application developers A footprint measurement Conferencing part of application using Web Service. About 350 lines of code Same part using Parlay.. About 1300 lines of code 252

253 To probe further... On Web services W3C specifications ECMA specifications Parlay-X specifications OMA specifications - 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 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 ICC04 R. Karunamurthy, F. Khendek, R. Glitho, Web service for presence: Interfaces, Implementation and performance analysis, submitted ICC

254 Questions? 254

255 Mobile Agents Based Architectures Mobile agents 2. Mobile agents and service engineering 3. Architectures 4. A Case study 255

256 Mobility is vital... - If it it weren t for mobility, we would still be trees G. Cybenko (Comments at a mobile agent workshop) 256