Next Generation Intelligent Networks

Next Generation Intelligent Networks For a listing of recent titles in the Artech House Telecommunications Library, t...

Author: Johan Zuidweg

142 downloads 2300 Views 4MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

Next Generation Intelligent Networks

For a listing of recent titles in the Artech House Telecommunications Library, turn to the back of this book.

Next Generation Intelligent Networks Johan Zuidweg

Artech House Boston • London www.artechhouse.com

Library of Congress Cataloging-in-Publication Data Zuidweg, Han. Next generation intelligent networks/Johan Zuidweg. p. cm. — (Artech House telecommunications library) Includes bibliographical references and index. ISBN 1-58053-263-2 (alk. paper) 1. Computer networks 2. Artificial intelligence. 3. Value-added networks (Computer networks) I. Title. II. Series. TK5105.84 .Z85 2002 004—dc21 2002074415

British Library Cataloguing in Publication Data Zuidweg, Johan Next generation intelligent networks. — (Artech House telecommunications library) 1. Computer networks 2. Artificial intelligence I. Title 621.3’85 ISBN 1-58053-263-2

Cover design by Yekaterina Ratner

© 2002 ARTECH HOUSE, INC. 685 Canton Street Norwood, MA 02062 All rights reserved. Printed and bound in the United States of America. No part of this book may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage and retrieval system, without permission in writing from the publisher. All terms mentioned in this book that are known to be trademarks or service marks have been appropriately capitalized. Artech House cannot attest to the accuracy of this information. Use of a term in this book should not be regarded as affecting the validity of any trademark or service mark. International Standard Book Number: 1-58053-263-2 Library of Congress Catalog Card Number: 2002074415 10 9 8 7 6 5 4 3 2 1

To Ana and Daniel

.

Contents Preface Acknowledgments 1

2

xiii xv

Introduction

1

1.1 The telephone network 1.1.1 The telephone exchange

2 2

1.1.2

Electronic and digital exchanges

4

1.1.3

Signaling

5

1.1.4 Intelligence in the network 1.2 Computer communications 1.2.1 Computer networks

6 6 7

1.2.2

Internetworking

7

1.2.3 Internet versus telephony 1.3 Mobile networks 1.3.1 Cellular networks

9 10 10

1.3.2

12

Issues in mobile networking

1.3.3 Integrating mobile telephony and data 1.4 Text purpose and overview 1.5 Possible reading tracks

13 13 19

Intelligent networks

23

2.1 SS7 2.2 IN standards 2.2.1 Standardization bodies

24 29 29

2.2.2

30

Standardization cycles

vii

viii

3


2.2.3 IN conceptual model 2.3 Service plane 2.4 Global functional plane 2.4.1 SIBs

30 31 33 34

2.4.2 Basic call process 2.5 Distributed functional plane 2.5.1 Functional entities

36 39 40

2.5.2

Half call

42

2.5.3

Detection points

43

2.5.4 Trigger processing 2.6 Physical plane 2.6.1 Physical entities

45 47 47

2.6.2 IN application protocol 2.7 CS-2 2.7.1 CS-2 service plane

50 53 55

2.7.2

CS-2 global functional plane

56

2.7.3

CS-2 distributed functional plane

58

2.7.4 Implementing CS-2 2.8 CS-3 and CS-4 2.8.1 CS-3 features

64 65 65

2.8.2

ETSI improvements in CS-2 and CS-3

66

2.8.3

New additions in CS-4

67

2.8.4 Beyond CS-4 2.9 Implementing IN 2.9.1 Alcatel IN

69 70 70

2.9.2

73

Multivendor IN products

IN and the Internet

75

3.1 IP, the Internet, and the Web: Defining terms 3.1.1 IP

76 76

3.1.2

Routers and gateways

79

3.1.3

Creation of IP standards

81

3.1.4 Connecting to the Internet 3.2 Intelligence on the Internet 3.2.1 Voice, video, and multimedia over the Internet

82 84 85

3.2.2

H.323

86

3.2.3

H.323 and IN

89

Contents

4

ix

3.2.4

SIP

92

3.2.5

SIP clients and servers

94

3.2.6

H.323 versus SIP

98

3.2.7

Media Gateway Control Protocol

99

3.2.8 Soft switching 3.3 Interaction between the Internet and IN 3.3.1 PINT

100 102 103

3.3.2

107

SPIRITS

3.3.3 Web-IN 3.4 Managing services via the Internet 3.4.1 Service management and configuration over the Internet

110 113 115

3.4.2

117

Unified messaging

The mobile dimension

119

4.1 Cellular networks 4.2 GSM 4.2.1 GSM architecture

121 122 123

4.2.2

Mobility management and handover

125

4.2.3

Security

126

4.2.4 GSM connection services 4.3 GPRS 4.3.1 GPRS radio interface

128 129 130

4.3.2

GPRS architecture

131

4.3.3

Mobility management in GPRS

132

4.3.4 GPRS connection model 4.4 CAMEL 4.4.1 CAMEL architecture

133 135 136

4.4.2

Setting triggers in the visited network

138

4.4.3

CAMEL service example: Prepaid subscription with roaming

140

4.4.4

CAMEL standardization

142

4.4.5 CAMEL phase 3 4.5 Internet in the mobile environment 4.5.1 WAP

143 147 147

4.5.2

iMode

149

4.5.3

MExE

150

4.5.4 SIM Application Toolkit 4.6 Mobile-specific services

153 154

x


4.6.1

SMS

154

4.6.2

Location services

156

4.6.3 Mobile payment services 4.7 3G mobile networks 4.7.1 3GPP

162 165 166

4.7.2

UMTS

168

4.7.3

VHE

172

4.7.4

Open service access

References

5

Distributing intelligence

179

5.1 Parlay 5.1.1 Parlay concept

180 180

5.1.2

182

Parlay business model

5.1.3 From Parlay to OSA 5.2 OSA 5.2.1 OSA interfaces

183 185 185

5.2.2

187

General interface structure

5.2.3 OSA call-control interface 5.3 Using OSA 5.3.1 Authentication

189 192 193

5.3.2

195

Service selection and service agreement

5.3.3 Application-initiated call setup 5.4 Implementing OSA 5.4.1 Languages and middleware

197 199 199

5.4.2

OSA configurations

200

5.4.3

Mapping from OSA to CAMEL

202

5.4.4 OSA products 5.5 OSA applications References

6

175 178

Telecommunications middleware

203 205 209

211

6.1 Telecommunications information-networking architecture 6.1.1 TINA-C

212 212

6.1.2

TINA business model

213

6.1.3

From business model to architecture

215

6.1.4

Session model

216

Contents

7

xi

6.2 TINA service architecture 6.2.1 Computational objects

219 219

6.2.2

220

Access session

6.2.3 Service session 6.3 TINA network-resource architecture 6.3.1 Computational objects

221 223 224

6.3.2

226

Connection establishment

6.3.3 Federation 6.4 The future of TINA 6.4.1 Auxiliary projects

228 230 231

6.4.2

The decline

232

6.4.3 The future 6.5 OMG 6.5.1 CORBA

233 233 234

6.5.2 IDL 6.6 TDTF 6.6.1 Control and management of audio and video streams

236 238 239

6.6.2

TCAP-CORBA gateway

240

6.6.3

Telecommunications service access and subscription

240

6.6.4

Open-service marketplace

241

6.6.5

Wireless access and mobility

241

6.6.6

UML for telecommunications

242

Service creation

245

7.1 From SIBs to objects 7.1.1 Linear service logic

246 246

7.1.2

Limitations of the IN model

248

7.1.3

Object-oriented programming

250

7.1.4 Object-oriented service logic 7.2 Java in telecommunications 7.2.1 Java beans

251 253 254

7.2.2

256

EJBs

7.2.3 EJB tool environments 7.3 JAIN 7.3.1 JAIN architecture

258 259 260

7.3.2

JAIN protocol APIs

262

7.3.3

JAIN call control

264

xii


7.3.4

JAIN example: Call forwarding

267

7.3.5

JAIN applications

269

7.3.6

Specification, products, and conformance

271

7.3.7 JAIN and Parlay 7.4 CPL 7.4.1 CPL structure

272 274 274

7.4.2

Example CPL script

276

7.4.3

Deploying CPL

278

7.4.4 IN and CPL 7.5 Feature interactions 7.5.1 Solving feature interactions

280 282 283

7.5.2

Detection

284

7.5.3

Heuristic methods

285

7.5.4

Resolution

286

7.5.5

Complexity of the feature-interaction problem

287

References

8

Evolution scenarios

288

289

8.1 Next generation networks 8.2 Convergence or divergence? 8.2.1 Changes in standardization

290 293 294

8.2.2 A new role for standardization 8.3 IN evolution 8.4 If it ain’t broke, why fix it?

295 296 298

Appendix A: Standards

301

Appendix B: Web sites

313

Glossary

315

Bibliography

329

About the author

331

Index

333

Preface The idea for this book dates back to the fall of 1999, while I was working at the Alcatel Corporate Research Center in Belgium. Intelligent networks sales were reaching a high point, but at the same time, Internet products were staging a coup d’état in a company that had spent almost a century building telephone exchanges. The industry was (and still is) in full technical, commercial, and political evolution. We had the feeling that we were witnessing a new page of telecommunications history being written. One of the few things that one could say for sure was that in the future, telecommunications would be about delivering not only connectivity but, perhaps above all, value-added services. The concept of having intelligence in the network, however vaguely defined, would be crucial for telecommunications products of the future. With the great number of new ideas, concepts, protocols, and standards that were emerging, there was an increasing need for tutorials, seminars, and structured documentation on network intelligence. But to my surprise, there were in fact very few good books on intelligent networks (IN) and on network intelligence in general. And at the speed things were evolving, the few books available were already outdated. Writing a book about intelligence in the network is like shooting a moving target. Between the time I proposed this book to Artech House and the time I actually started working on it, the dotcom crisis had set in and the telecommunications industry was quickly loosing its euphoria. Important changes took place between the time when I started writing the book and the time when I completed it. IN standardization slowed down almost to a halt, and frantic work went into defining OSA and xiii

xiv


Parlay. SIP gained an amazing amount of support, partly at the expense of H.323. Attention to PINT and SPIRITS increased and then seemed to diminish. Parlay and OSA aligned their specifications. This book attempts to capture the state of the art at the beginning of 2002. It no doubt succeeds in providing only a snapshot of an industry that is in full motion. But by focusing on the essence of concepts rather than on hype and products, the discussion seeks to further an understanding not only of today’s technology, but of what will come tomorrow. The text draws heavily upon standards. Although standards may lag somewhat behind proprietary solutions and research, they are the result of a judicious specification process and have a relatively stable life cycle. Nevertheless, we can observe dramatic changes in standardization, and the life expectancy of today’s standards may be only a fraction of their predecessors’. Wherever possible I have tried to use international rather than regional standards. Since I live in Europe and work mostly with European standards, you will no doubt notice some bias toward groups such as 3GPP and ETSI rather than, for example, 3GPP2 and T1. However, I have tried to avoid prejudice wherever possible and focus on concepts that are common to all standards.

Acknowledgments This book would not have been possible without the support of many professional associates and friends. First, I would like to thank my former Alcatel colleagues Coen Daenen, Geert Heeres, Patrick Hellemans, Marcel Mampaey, Johan Mariën, Frank Steegmans, Steven Vermeulen, and Frans Westerhuis for their helpful cooperation. I owe my first encounter with a real IN platform to Michel Genette, Eric Devleeschouwer, and Benoît Quirynen of Alcatel’s IN engineering center in Namur, Belgium. Their product is still one of the best on the market today. I express my gratitude to Ludo Gys and Alan Mottram for teaching me about strategy. I am much indebted to the people of the third-generation consulting group at Telefónica I+D, who provided me with their visions of IN, CAMEL, OSA, and mobile IP. My discussions with José Solana, who leads this group, Julián Perez, Pepe Molleja, Sila Fernández, Arantxa Bergheira, and Carlos Sanz have deepened my understanding of key issues, particularly on the mobile network side. I would also like to mention Rafael San José and Luís Marmisa of Telefónica I+D management for their confidence in this group and for letting me participate in it. My special thanks go out to Tecsidel, and especially to Pedro Artiga, Jordi Galera, José Perez, and Ramon Recio for providing me with the opportunity and the resources to write this book. Tecsidel is the most extraordinary company I have worked for in my career, offering a combination of business vision, technical know-how, professionalism, a pleasant working atmosphere, and strong emphasis on the human dimension. It is an example for others to follow.

xv

xvi


While I was writing this book, a friend and former colleague at KPN Research, Wiet Bouma, passed away in the prime of his life. Wiet continues to be an example for me, not only from an intellectual standpoint, but because of his joie de vivre. There are many others to whom I owe my thanks, but who haven’t been mentioned here. Please know that you have my gratitude. And then there is Ana, who brightens my days with her magic smile, who has the Mediterranean sun in her eyes, and who has reshaped my understanding of IN on more than one occasion. Without her, none of this makes any sense. Any comments that readers might have for improving this book are highly appreciated. I can be reached by e-mail at johan.zuidweg @ieee.org.

CHAPTER

1 Contents

Introduction

1.1 The telephone network 1.2 Computer communications 1.3

Mobile networks

1.4 Text purpose and overview 1.5 Possible reading tracks

Intelligence and the ability to communicate are what define us as human beings. Since the earliest of times, people have communicated over both long and short distances to relay news, conduct business, exchange ideas, and express love. If telecommunication means communicating over a distance, then it has always existed in many different forms. Over the centuries people have used smoke signals, tam-tams, mirrors, flags, pigeons, lighthouses, letters, radios, telegraphs, telephones, and the Internet to bridge the distance between them. Many consider the invention of the telegraph the beginning of modern telecommunications. The idea of the telegraph is as old as the mid-eighteenth century, but it was Samuel Morse who made it practical by inventing a way of sending information over a single line as a sequence of electric pulses of varying length. He represented each character in the alphabet with a unique combination of long and short pulses (dots and dashes), a scheme that we still know today as Morse code. 1

2


Morse demonstrated the first practical implementation of his telegraph in 1838. The U.S. government immediately grasped the importance of this invention and from then on things moved fast. The first public telegraph connection was put in operation in 1843 between Washington and Baltimore, and the first transatlantic telegraph cable was completed as early as 1866. By the end of the 1860s, news was traveling around the world faster than ever before. Even in the early days of the telegraph, people were thinking about ways to send more than just dots and dashes over the telegraph lines. It was Alexander Graham Bell who invented a mechanism that transformed sound into an electric signal, and who demonstrated the first telephone in 1876. The Bell Telephone Company, which Bell helped create in 1877, was to become the world’s most powerful telecommunications company for almost a century. In 1899 it was renamed AT&T.

1.1

The telephone network

For many years the telegram was the surest way to send information quickly over a distance. The telegraph network was essentially a worldwide collection of point-to-point connections between post offices, government buildings, and large companies. For the average person, sending a telegram meant going to the post office and dictating it to a postal service employee. Today the postal service still delivers paper telegrams to the recipient’s doorstep. The telephone was revolutionary in that it almost instantly became part of the household. As early as the beginning of the 1900s, citizens who could afford them had a telephone in their residence. By the 1950s the majority of American and European households had a telephone. 1.1.1

The telephone exchange

Until the end of the nineteenth century, telephone networks were manually operated. All telephones lines terminated in a central office, where operators manually established connections by plugging lines into the appropriate jack. These central offices were operated by many different companies and offered only local service. There were few long-distance connections. Figure 1.1 illustrates the concept of the central office. The explosive demand for telephony soon created the necessity for automated establishment of voice circuits. This led to the invention of electromechanical telephony exchanges (also called telephone

Introduction

Operator

Su

bs cri

be

r li

ne

3

Central office

Figure 1.1

The central office.

1

switches ), which were used for at least half a century. An electromechanical exchange uses a system of electrical relays that respond to the electric pulses made by a telephone’s rotary dial (1 = one pulse, 2 = two pulses, and so on). The demand for telephony over larger distances introduced the need for long-distance carriers, telephone companies that are able to interconnect central offices between cities, regions, and even countries. AT&T was the first such carrier, and remained the most important one until well into the twentieth century. To allow for communications between cities, states, regions, and even countries, central offices were connected to special interconnection exchanges. This eventually led to an interconnection hierarchy with five levels or classes, as shown in Figure 1.2. In this hierarchy, the central office is the lowest level and is called a class 5 exchange. The exchanges at all other levels switch connections only between other exchanges and

1. Since telephone exchanges switch connections between telephones, they are often simply called switches. Throughout this book, we will use the word switch to refer to such exchanges, except where its use might cause confusion.

4


Class 1 Regional

Class 2 Sectional

Class 3 Primary

Class 4 Toll Class 5 Central office Figure 1.2

Hierarchy of telephone exchanges.

have no subscribers attached to them. The lower the class number, the higher in the hierarchy and the bigger the exchange. 1.1.2

Electronic and digital exchanges

By the 1960s the transistor had found its way into switching systems, giving way to a new generation of electronic exchanges. The only mechanical component in these exchanges was a matrix of tiny reed switches controlled by electronic circuits. These electronic exchanges also used tones [dual-tone multifrequency (DTMF)] rather than pulses to dial numbers. The development of the computer led to a new generation of telephone exchanges in the early 1970s. These exchanges were in effect computers controlled by stored programs. In the second half of the 1970s these computerized exchanges became completely digital and no longer had mechanical parts. Rather than physically establishing an electrical voice circuit, digital exchanges convert the voice signal in a series of numbers encoded in 1s and 0s (bits), and send these bit streams electronically from source to

Introduction

5

destination. Multiple bit streams are multiplexed into one high-speed bit stream sent on the trunk line between exchanges and demultiplexed into separate streams again at the other end. Figure 1.3 illustrates this in very simplified form. In the most recent generation of exchanges, even the subscriber line can be digital, by eliminating the analog-to-digital conversion (see Figure 1.3). This integrated digital services network (ISDN) allows a single subscriber line to be used for telephony, fax, and data communications; however, it also allows a digital network termination to be installed in the customer’s premises. 1.1.3

Signaling

The digitalization of exchanges also marked an important evolution in call signaling. Signaling is the communication necessary to set up a call from one subscriber to another. There are two kinds of signaling: userto-network signaling (for example, the numbers dialed to make a call) and network-to-network signaling (the messages that telephony switches need to exchange in order to realize the call). In the early days, signaling was done on the same lines that carried the voice circuits (in-band signaling). This meant that a telephone exchange had to set up a complete connection just to ring the destination subscriber, and tear it down again if a busy signal or no reply was received. It is plain to see that a lot of capacity was wasted this way.

Stored program

Memory

CPU

Multiplexer Demlutiplexer

Analog-to-digital conversion

Switching matrix Figure 1.3

Stored-program digital exchange.

Digital trunk

(To other switch)

6


Engineers at AT&T therefore proposed a new system whereby the signaling was done over separate connections. They called it the common channel signaling system number 7 (SS7). Since digital exchanges are now computers, SS7 is nothing more than a very reliable computer network, built on the principles of packet data communications. SS7 is still the dominant signaling system today, and it has had a profound impact on the evolution of the telephone network since the 1980s. 1.1.4

Intelligence in the network

As telephone exchanges became more and more like interconnected computers, telephone companies realized that they could be made to do much more than just connect subscribers A and B. They could be programmed to forward, block, or transfer calls, reverse the call charges, and record voice messages; in fact, they could do anything that the installed hardware and software allowed them to do. This is how the idea of intelligence in the network was born. In fact, the term network intelligence is somewhat of a misnomer, because it suggests that there is some kind of (artificial) intelligence involved. It would be more accurate to talk of network programmability, because the concept actually refers to the programming of network functions. Nevertheless, the industry seems to have settled for the word intelligence, and we will go along with that. The deregulation of the telecommunications industry in the 1980s and 1990s created the need for telephone companies to differentiate themselves from the competition. They soon realized that competing on price alone leaves too narrow a margin for survival, and began finding ways of competing by delivering value-added services. The need for value-added services led to the standardization of intelligent-network (IN) architecture in the early 1990s and to its large-scale deployment, which continues today.

1.2

Computer communications

Meanwhile, the invention and subsequent development of the computer had led to a new kind of telecommunications, from machine to machine. The network requirements for this type of communications are very different from that of voice communications. Computers process, store, and exchange information in digital form: all information is represented by series of bits (1s and 0s). The loss of a

Introduction

7

single bit can corrupt an entire file, while the loss of half a second of voice generally does not affect a conversation. On the other hand, the transfer of a file is not so time critical, while a second’s delay on a telephone line can make carrying on a normal conversation close to impossible. A voice conversation is typically a more or less constant exchange of words with a clear beginning and end. For this reason it makes sense to establish a connection between the calling parties for the duration of the conversation. Conversations between computers are, however, of a completely different nature. Computers tend to exchange bursts of information that do not necessarily have any relation (sending a keystroke, a screen refreshment, an e-mail, an HTML page, a file). Here it would make much more sense to simply send the information from one computer to another when needed, rather than permanently keeping a connection open. Most data communication techniques therefore break the information up into discrete frames (sometimes called datagrams or packets) and simply send these from source to destination one by one without permanently occupying an electrical circuit or digital channel. 1.2.1

Computer networks

Different computer applications generate different kinds of data. It is easy to imagine that the requirements for a network linking a bank’s automatic teller machines to its computers are different from those of a network of computers that control air traffic or a car manufacturer’s assembly line. In the course of time, a variety of data communication techniques have been developed. Some of the more well-known ones are the IEEE local area networks standards such as Ethernet (IEEE 802.3), Token Bus (IEEE 802.4), Token Ring (IEEE 802.5), DQDB (IEEE 802.6), FDDI, and protocols such as X.25 and ATM. Each of these computer network standards has its own merits and drawbacks and performs best for a certain class of applications. Unfortunately most of them are incompatible: You cannot plug an Ethernet into an ATM network without doing a great deal of adaptation and conversion. 1.2.2

Internetworking

The need for interconnecting data networks became evident in the 1960s, when computers were becoming commonplace in corporations, public administration, and research institutes. In the early 1970s the Defense Advanced Research Projects Agency (DARPA) proposed the ARPANET

8


protocol suite as a solution. ARPANET defined some of the elementary characteristics of today’s Internet protocols, such as protocol layering. In the years that followed, work continued on internetworking protocols, and the Internet Protocol (IP) took its current form around 1978. As the name suggests, IP is meant to interconnect networks. It provides a general format for data interchange that is independent of the different data network technologies. In this way IP allows one virtual internetwork to be created out of several different networks. To connect two networks, a machine that speaks IP must be connected to both, so that data packets can be forwarded from one network to the other. Such a machine is called a router. Figure 1.4 illustrates how an internetwork is formed out of separate networks connected by IP routers. By the early 1980s DARPA was using IP for interconnecting its networks and computers, and required all external networks and computers to use the same protocol. The first networks to be interconnected at the time were universities and research institutions. The number of interconnected networks grew dramatically when in 1983 IP was included as part of the UNIX BSD4.2 operating system (implemented by the University of California at Berkeley) and became the de facto standard for interconnecting UNIX. This was the birth of a worldwide interconnection of IP networks that we call the Internet today. In the second half of the 1980s Internet traffic had become so heavy that the National Science Foundation (NSF) of the United States found it necessary to install a backbone infrastructure, a network of high-capacity

Router Network 1

Network 2

Internetwork

Figure 1.4

Internetworking.

Introduction

9

routers and links specifically dedicated to interconnecting other networks. A second and third backbone were added in 1987 and 1989 to cope with rapidly increasing traffic. Until the beginning of the 1990s voice and data communications remained worlds apart. While connecting computers was an issue in companies, universities, and governments, it was of little relevance to the general public. The personal computer, however, brought computing power into the household. A turning point in the commercialization of the Internet was the invention of applications such as the browser, which much increased the user friendliness of the Internet. The personal computer and the hypertext browser played a decisive role in bringing the Internet to the general public, and in establishing the Internet as a commercial tool. 1.2.3

Internet versus telephony

Although many of us still use the telephone line to connect to the Internet, the telephone network and the Internet are built on completely different requirements, philosophy, and technology. In telephony all control is centralized in the network. Over more than a century the telephone has remained a simple device that requests a connection, terminates a connection, and converts electric signals into sound and vice versa. In the telephone network, the intelligence is in the network, not in the terminal. The Internet, on the other hand, has no centralized control. The Internet is a network of networks, and each of these networks is a grouping of computers with applications and data. The Internet’s terminals (called hosts in Internet terminology) are the computers it interconnects. Each of these computers can run applications of arbitrary complexity. Much of the Internet’s intelligence is in the network periphery.2 Nobody owns the Internet, its applications, or its data. In spite of the differences between the telephone networks and the Internet, telephone companies do take advantage of the Internet to

2. It is often said that the Internet is a dumb network because it only routes packets from source to destination. This view is perhaps too simplistic. One can argue that the Internet has a certain intelligence, because its routers make autonomous decisions about where to send packets. In fact, routers continually learn about the network’s configuration by sending special packets and updating their routing tables accordingly. Whichever way one looks at it, the Internet does not have any centralized point of control, while the telephone network does.

10


deliver better service to their customers. Many operators allow their subscribers to view the status of their telephone bills on-line, and some even let users configure their services, such as call forwarding and call screening, through the Internet. It is even technically possible to send voice communications over the Internet, and there is an increasing number of cases in which telecommunications companies use the Internet for everything, even to carry voice calls. This interweaving of telephony and data networking no longer permits us to treat the two as distinct cases, but forces us to have a coherent vision of network intelligence that applies to both worlds. This book is about understanding the different kinds of network and network intelligence, and about moving a step closer to a coherent vision. Surprisingly, it has been the explosive development of mobile networks that has served as a catalyst for the convergence of telephony and data networks. Mobile networks therefore will also be given special consideration in this book.

1.3

Mobile networks

Advances in computing technology and data communications were responsible for the explosive development of mobile networks that occurred throughout the 1990s. In fact, mobile telephony networks have been around for quite a while. As early as the 1950s, operators played with the idea of providing radio access to their telephone network. In these early days, a mobile telephone was no more than a sophisticated walkie-talkie that connected to a telephone exchange through a radio connection. 1.3.1

Cellular networks

As the demand for mobile service grew, the telephone company had to install many antennas nationwide to provide radio coverage everywhere. The radius covered by each of these antennas is called a cell, and hence these networks are called cellular networks. Figure 1.5 illustrates the concept of a cellular network. Until the 1980s cellular phones were expensive, cumbersome, and not secure. Some of the most important problems included the following: ◗

Capacity. During a call, each mobile telephone occupied two radio channels: one for voice going from network to terminal and one for

Introduction

11

Cell

Telephone exchange

Figure 1.5

Cellular mobile network.

voice in the opposite direction. Radio channels are scarce because only so many of them fit in the frequency band allocated to mobile telephony. ◗

Security. Anybody could eavesdrop on the radio link between the mobile phone and the network antenna.

◗

Power. Early cellular networks used few cells and required the mobile telephones to have sufficient power to reach antennas tens of kilometers away. Early mobile telephones therefore looked like car batteries with a handset.

The digitalization of telephone networks and the advance in data networking led to a new generation of cellular networks in the 1990s. Many of the problems mentioned above were solved by using digital transmission and processing. The voice signal was now translated into a flow of bits, and several connections were multiplexed on a single radio channel. The flow of bits

12


was encrypted to avoid eavesdropping on the radio link. The use of many more smaller cells, optimizing digital signaling and power control, allowed the terminals to operate with much smaller batteries. This generation of digital cellular networks is usually called the second generation (2G) of networks. GSM (Europe), D-AMPS (the United States), and PDC (Japan) belong to this generation of networks. 1.3.2

Issues in mobile networking

At first sight, a digital mobile telephone network appears to be essentially a telephone network with radio access to the switch. The mobility of subscribers and their handsets, however, introduces a few subtle points of complexity: ◗

Identifiers. In normal telephony networks, a subscription is directly associated with a fixed network access point. In cellular networks, this is obviously not possible. It is undesirable to associate a subscription directly with a mobile handset, because this would tie a subscriber to the handset forever and introduce barriers to competition. For this reason, cellular networks need to manage several identifiers (at least one for the subscriber and one for the terminal) and need to maintain the relationship between them in a database.

◗

Security. It is very important to verify the identity of a mobile subscriber requesting service over the radio interface. If the radio interface is not sufficiently protected, anybody can eavesdrop, replay the access procedures, and make calls at other people’s expense. It is obviously also necessary to protect the voice conversation itself from eavesdropping.

◗

Mobility management. If somebody calls a mobile subscriber, the network has to know where this mobile subscriber is. Mobile networks therefore have to keep track of where a telephone is at any time. This gets even more pressing when subscribers are allowed to move between different networks, or even different countries (this is called roaming).

◗

In-call mobility. During a call, it is possible that a subscriber will move out of reach of the antenna to which he or she is connected. The network must be able to reconnect the subscriber as quickly as

Introduction

13

possible to the closest available new antenna without breaking the call. From these points it is evident that cellular mobile networks need intelligence built into them by default, and that this sets them apart from fixed telephone networks. 1.3.3

Integrating mobile telephony and data

Over the last 10 years, people have been struggling with the idea of how to use mobile phones for multimedia services and wireless Internet access. This led to a new generation of mobile networks that are in full development today. The universal mobile telecommunications system (UMTS) embodies the concept of a truly universal cellular network that offers almost any telecommunications service, but it is by no means the only proposed technology. In the previous sections, we saw that telephone networks and data networks are dramatically different. Today we witness how the new generation of cellular networks is forging a convergence of these different telecommunications paradigms. In terms of network intelligence, cellular networks represent the most complex and at the same time most urgent requirements. It is not surprising that the cellular mobile networks industry appears to be devising the roadmap for the evolution of intelligence in the network.

1.4

Text purpose and overview

We live in an age of diversity—of telephones and computer networks, of fixed and mobile networks, of public and private networks. There is an urgent need for software to create, deploy, operate, and manage information and communications services in this diverse environment. The purpose of this book is to give an account of the state of the art in network intelligence in terms of standardization, implementations by manufacturers, and deployment by telecommunications operators. We will study the IN architecture for programming value-added services in telephone networks. We will assess the influence of mobile networks and IP technology on IN. We will look at the way middleware is eliminating the dependence of service logic on the underlying network protocols. We will investigate how service creation is taking onboard distributed objectoriented programming techniques. And, we will attempt to sketch out

14


what tomorrow’s network might look like. After reading this book, you should have a solid overview of the very latest in network intelligence. It should enable you to judge what technology serves your business, where, and how. The following sections give a short summary of the contents of each chapter. The first step toward a feature-rich network was made with the introduction of intelligent networks. The first IN standards came out in the early 1990s, and the deployment of IN is widespread today. The main idea of IN is to separate call logic processing from switching, and to delegate it to specialized service control points (SCPs). The IN architecture also has a model for rapid service creation based on service-independent building blocks (SIBs), and a service management function. IN has been effective in providing value-added services, such as call screening, call forwarding, alternate billing, and prepaid services. IN standards are produced in the form of capability sets. Each describes an incremental set of architectural, protocol, and service features. The initial capability sets 1 and 2 (CS-1 and CS-2) were conceived for enhanced control of point-to-point voice calls. They are based on a call model that describes the stages of setting up a voice call between two parties. IN was not originally intended for connectionless data services and does not deal well with conference type services involving multiple parties and multiple media streams. Capability sets 3 and 4 (CS-3 and CS-4) were intended to address some of these issues, but do not seem to live up to the expectations. New architectures may be necessary in the long run. This chapter includes the following:

Chapter 2: Intelligent networks

◗

A short introduction to SS7 and the birth of IN;

◗

Coverage of the IN architecture: functional planes, service switching point, service control point, service management point, service creation environment, special resource function;

◗

Discussion of IN standards: CS-1, CS-2, CS-3, CS-4, and beyond;

◗

An example of a commercial IN implementation.

IN was born in an era when switched telephony networks ruled the world and the Internet Protocol was still Chapter 3: IN and the Internet

Introduction

15

confined to the interconnection of data networks. But the world has changed. The Internet has become a general public utility. It is now perfectly possible to encode a voice conversation in packets and send these over an IP network. Today we are faced with the challenge of creating value-added services in heterogeneous networks with both circuitswitched and packet-based transmission. The Internet community influences the development of IN by specifying new protocols for Internet telephony, such as SIP, MEGACO, PINT, and SPIRITS. But individual companies are also being creative in finding new ways to combine Internet applications and telephony services. Although in a packet network there are no switching matrixes, there is still a need for nodes that terminate signaling protocols. Today we hear talk of soft switches; these are nodes that terminate signaling and control network resources, but they are not necessarily directly coupled to a switching matrix. The application of IN to soft switches is a hot topic. In this chapter we will examine the forces that the Internet and IN communities exert on one another. Our discussion will touch on the following: ◗

A brief survey of IP networks and protocols;

◗

Protocols for telephony over the Internet: H.323 and SIP;

◗

Combining Internet and IN services: PINT and SPIRITS;

◗

Media gateways and soft switching: MEGACO;

◗

Service control and management via the World Wide Web.

Chapter 4: The mobile dimension As we have seen, mobile networks introduce certain issues that are not applicable to fixed networks. A mobile network must keep track of its subscribers as they move around, and protect them from eavesdropping and fraud. IN was not originally created for mobile networks and therefore did not interwork well with them. The European Telecommunications Standardization Institute (ETSI) therefore standardized an adapted version of IN for mobile networks, called customized applications for mobile enhanced logic (CAMEL). In the United States a similar initiative led to the definition of the wireless intelligent networks (WIN) standard. CAMEL is mostly used to allow subscribers of prepaid services to roam to

16


other networks. The latest version of CAMEL also works with cellular packet networks such as GPRS. Mobile networks are more than just telephone networks with telephones that move around. Mobile terminals are small computers with their own processing power, memory, and input/output devices. MExE, SAT, and iMode take advantage of this by putting intelligence in the mobile terminal. Mobility also creates opportunities for new services such as personal messaging, terminal location, and mobile payments. Of course, the combination of CAMEL and decentralized intelligence in the terminal and in the Internet is far from trivial. Hopes are that UMTS will offer a solution. UMTS unifies the different network functions in its open-service access (OSA) architecture, an object-oriented framework for programming distributed services. Chapter 4 covers the following: ◗

CAMEL as an IN architecture for GSM and beyond;

◗

GPRS and CAMEL: delivering services in packet-based mobile networks;

◗

Internet content and applications in the mobile phone: WAP, iMode, and MExE;

◗

Mobile-specific services: messaging, location, and mobile payment services;

◗

The virtual home environment (VHE) concept for service ubiquity;

◗

An introduction to UMTS OSA.

In today’s network, intelligence resides both inside and outside the network. In IN it is centralized and managed by the network operator. In computer networks, data and processing are distributed over different servers in the network and can reach into end-user terminals. One of the major challenges is dealing with this distribution of control. In 1998 a group of companies created the Parlay group to specify an open interface for external applications to control calls and connections in the network. The Parlay interface is independent of the underlying routing and switching hardware, and does not prescribe any particular architecture or implementation.

Chapter 5: Distributing intelligence

Introduction

17

The idea behind Parlay and OSA, the new programming interface for UMTS services, is very similar. Although OSA has its roots in standardization and Parlay is a private industrial group, they have pledged to completely align their specifications. As the most recent versions of IN and CAMEL have failed to live up to their expectations, the industry has now set its eyes on OSA and Parlay as the future technology for network intelligence. Chapter 5 is devoted to OSA and Parlay and covers the following: ◗

Parlay’s rationale and business model;

◗

The relationship between Parlay and OSA;

◗

The OSA model and interfaces;

◗

OSA suppliers and applications;

◗

An example OSA application.

The telecommunications world is traditionally one of dedicated hardware and protocols. As the influence of IT in telecommunications grows, there is not only an increasing use of off-the-shelf hardware, but also of middleware as an alternative to classical signaling. The common object request broker architecture (CORBA) specified by the Object Management Group (OMG) is already widely used in administration and finance as a way of distributing applications and of making legacy code and new applications interwork. The first use of CORBA in telecommunications was in the realm of network and service management. More recently, the telecommunications world has considered the use of CORBA in connection and call control. Several manufacturers have experimented with IN platforms based on CORBA. The OMG has specified how IN and CORBA can interwork. The telecommunications information networking architecture (TINA) is a new network architecture that replaces signaling with CORBA-based message exchange. The TINA approach to telecommunications takes its inspiration from the IT world and breaks with most of the common telecommunications standards and architectures. TINA is older than Parlay and did much of the groundbreaking work on which Parlay and OSA are based. Unfortunately TINA itself came before its time and failed in trying to revolutionize telecommunications.

Chapter 6: Telecommunications middleware

18


This chapter covers the following: ◗

The business model behind the TINA architecture;

◗

TINA’s session model;

◗

The TINA service architecture and resource network architecture;

◗

An assessment of what went wrong in TINA;

◗

A summary of the OMG and CORBA;

◗

The activities of the OMG Telecommunication Domain Task Force.

One of the key objectives of IN is to be able to create, validate, and deploy new services rapidly. IN has a specific component for the creation of services: the service-creation environment (SCE). In terms of software engineering, an IN service is a script composed out of SIBs. SIBs can be seen as subroutines that perform tasks common to different services, such as connecting a call leg or playing an announcement. The new architectures discussed in Chapters 5 and 6 have in common the fact that they are based on distributed object-oriented software technology. It figures, therefore, that the classical SCE may need some reconsidering. In Chapter 7 we investigate how existing software techniques such as Java beans, Enterprise Java Beans (EJB), and XML can play a role in the service-creation environment of the future. One of the important initiatives for using Java in service creation is Java Applications for Integrated Networks (JAIN), developed within Sun Microsystems’ Java Developer Community program. JAIN takes advantage of Java programming models for creating value-added services. The Internet community created the call-processing language (CPL) to define call processing in SIP servers. CPL is a relatively new scripting language based on XML, with roughly the same expressive power as the IN SIBs. In this chapter we consider the impact of CPL and its relationship with IN service-creation techniques. Chapter 7 also briefly explores the problem of avoiding, detecting, and resolving unexpected and undesirable interactions between services. This chapter covers the following:

Chapter 7: Service creation

◗

The differences between IN SIBs and objects;

◗

The role of Java, Java Beans, Enterprise Java Beans, XML, and CORBA in service creation;

Introduction

19

◗

JAIN initiative and architecture;

◗

The differences and similarities between JAIN and Parlay;

◗

The Internet Engineering Task Force (IETF)’s CPL and its applications;

◗

Feature interactions in telecommunications systems.

The future network will be characterized by a multitude of access technologies (twisted pair, fiber, coax, radio), a backbone based on IP, and a multitude of operators and service providers competing with a large array of value-added services. This heterogeneous environment does not resemble in any way the classical telephony network, where services were simple and control was centralized. In the chapters leading up to Chapter 8 we look at several different architectures that address the heterogeneity of the network. What part of these architectures will be applied where? Will we move toward true convergence, or will there be a multitude of networks connected by gateways and bridges? The final chapter of this book peeks into the future and tries to make some sense out of the trends we see today. It includes discussion of the following:

Chapter 8: Evolution scenarios

1.5

◗

A vision of the network of the future;

◗

Technical issues the industry will have to address in the future: interworking between different call models, a new trust model, distributed subscriber data, federation between service providers, and third-party service creation and deployment;

◗

Changes in standardization: convergence versus divergence;

◗

Changes observed in the industry.

Possible reading tracks

This book is meant to be self-contained and requires only minimal prior knowledge of computers and networks. Nevertheless, a basic understanding of telephony networks, computers, programming languages, object-oriented design principles, the Internet, and CORBA will benefit the reader.

20


There is no correct or incorrect way to read this book. Each chapter is self-explanatory, but the chapters are arranged in such a way that they present a logical sequence. Readers new to the subject might benefit from reading all of the chapters in sequence; informed readers with a particular interest in any one of the topics might want to jump directly to the appropriate chapter. Some possible paths through the material are as follows: ◗

For the novice reader, a tutorial of basic concepts in network intelligence could consist of reading Chapters 2, 3, and 4.

◗

Readers who are specifically interested in the convergence of telephony and IP can read Chapters 2, 3, and Section 7.4. Chapter 5 might also be of interest.

◗

Readers with a special interest in mobile networks can read Chapters 2, 4, and 5.

Tutorial Internet track track

Mobile track

Servicecreation track

API track

Chapter 2 Intelligent networks

Chapter 3 IN and the Internet

Chapter 4 The mobile dimension Chapter 5 Distributing intelligence

Chapter 6 Telecommunications middleware

Chapter 7 Service creation Chapter 8 Evolution senarios

Figure 1.6

Various approaches to the text.

7.4

7.3

Introduction

21

◗

Those who want to read about new trends in service creation can skip from Chapter 2 to Chapter 7, possibly reading Chapter 5 in between.

◗

Readers looking for specific details on new network intelligence paradigms, such as Parlay, OSA, JAIN, and TINA can read Chapters 5, 6, and Section 7.3.

In all cases, those already familiar with IN can skip Chapter 2, although it might serve as a helpful review. Figure 1.6 illustrates the suggested itineraries.

.

CHAPTER

2 Contents 2.1

SS7

2.2

IN standards

2.3

Service plane

2.4 Global functional plane 2.5 Distributed functional plane 2.6

Physical plane

2.7

CS-2

2.8

CS-3 and CS-4

2.9

Implementing IN

Intelligent networks As the majority of switches became digital in the 1980s, vendors and operators saw that, like computers, they could be programmed, making it possible to introduce intelligent services, such as call forwarding, call blocking, freephone, and premium rate numbers, into the network. At first, these services were programmed in assembler-like languages, and had to be installed manually in each switch. Installing a new service meant reprogramming the switch and manually resolving the interactions with the service programs already running on it. The process of defining the service, specifying, implementing, testing, and finally deploying it would typically take between 2 and 4 years. The management of these services was obviously inefficient, as even the smallest patch required going to each switch in turn and reinstalling the new software. It was soon recognized that it would be much more convenient if services could be designed in more high-level language, and could be deployed and managed from one point rather than separately in each switch. 23

24


The introduction of SS7 in the early 1980s was a leap forward. SS7 is a metanetwork for signaling. It provides reliable signaling links that are independent of the bearer connections. The SS7 protocols1 have a high degree of flexibility for supporting new features and are still state of the art today, more than 20 years after AT&T introduced the concept. After the breakup of AT&T, it was Telcordia (formerly Bellcore) that first proposed the advanced intelligent networks (AIN) concept using the protocols of SS7. The purpose of AIN was to allow the regional Bell operating companies (the Baby Bells) to simplify the deployment and management of value-added services in the network by centralizing their control. Based on the success of the Telcordia design, the International Telecommunication Union (ITU) began the process of standardizing INs in the late 1980s. After 4 years of standardization efforts, the first IN standard was published in 1993 as the ITU Q.1200 series. Although numerous improvements and extensions have been made since then, today’s IN standards and products are still largely based on the first ITU standards.

2.1

SS7

SS7 is such an important milestone in the development of switched telephony networks that it would require a whole book to do it justice. In fact, many books were dedicated entirely to this signaling system, which today still rules our telephony network. It is difficult to understand the birth of IN without seeing it in the context of SS7. In this section we take a bird’s-eye view of SS7 and see how it led to the invention of IN. As electronic switches became widespread in the 1970s the need arose for modernizing the signaling protocols. AT&T defined SS7 in 1975, using data network technology. SS7 is a metanetwork for out-of-band signaling, as opposed to in-band signaling systems that use the same

1. In its most general definition, a protocol is a well-defined set of messages and rules to make two or more entities communicate. Protocols are used in hardware as well as in software. Complex systems like computers and telecommunications systems are usually divided up into several components or layers, each with its own set of protocols. This is done because it is easier to design, test, and debug a system with simple protocols for each task than a system consisting of one overarching protocol.


25

connections for voice and signaling messages. SS7 is designed in such a way that it guarantees reliable signaling links. In 1980 the ITU started standardizing SS7, and in 1984 it issued the SS7 standard as the famous red book. Since then, the ITU maintains and updates the standards regularly. Unfortunately, there is not one SS7 standard. The ANSI and ITU versions of SS7 are slightly different, and there are several different versions of SS7 deployed around the world. There are, however, gateways that interface between the different protocols. An SS7 network contains three kinds of elements: 1. Signaling points (SPs): network equipment that can send or receive signaling messages; 2. Signaling links (SLs): links that carry signaling messages (in SS7 they are either 56-Kbps or 64-Kbps data connections); 3. Signaling transfer points (STPs): intermediate nodes that route signaling messages from one place to another. Figure 2.1 shows a typical SS7 configuration for two connected networks. STPs are usually configured in pairs to ensure high reliability. The

SL

SP

STP

STP

SL SL

SL SL

SP

SL SL SL

STP

SL

SL SL

SL

STP

SL SL

SP

SP Bearer connection

Network 1 Figure 2.1

SS7 network elements.

Network 2

26


SS7 protocols ensure that when an STP or SL goes down, the messages are automatically rerouted over links that are still operational. To ensure secure and flexible signaling connections, the SS7 protocol architecture is layered. It roughly follows the seven-layer open-systems interconnection (OSI) model, which was popular when SS7 was defined. The main idea of the OSI model is to make complex telecommunications protocols more manageable by dividing them up into layers. Each layer provides certain services to the layer above it, and uses the services of the layer below. This results in a modular protocol stack in which each layer encapsulates a well-defined set of functions. Figure 2.2 shows the SS7 protocol stack, which is made up of the following protocols:

Mobile Application Part (MAP)

Transaction Capabilities Application Part (TCAP) Signaling Connection Control Part (SCCP) Message Transfer Part (MTP) 3 Message Transfer Part (MTP) 2 Message Transfer Part (MTP) 1 Figure 2.2

SS7 protocols.

Telephony User Part (TUP)

Message Transfer Part 2 (MTP2) is responsible for the secure transmission of messages between two signaling (transfer) points.

ISDN User Part (ISUP)

◗

In Application Part (INAP)

Message Transfer Part 1 (MTP1) represents the physical layer, consisting of hardware and firmware resources such as network cards, transceivers, and cables.

Orientation, Administration, and Management Part (OAMP)

◗


27

◗

Message Transfer Part 3 (MTP3) takes care of routing a message from one point in the SS7 network to another, passing through intermediate signaling transfer points.

◗

Telephony User Part (TUP) describes the signaling messages for the setup of calls and connections in analog telephony networks. This protocol is used in older telephony networks that still use electromechanical or analog electronic switches.

◗

ISDN User Part (ISUP) describes the signaling messages for the setup of calls and connections in digital networks. Despite the name, ISUP is used in all digital telephony networks, not only ISDN.

◗

Signaling Connection Control Part (SCCP) sets up and manages signaling connections, using MTP3 to route messages reliably from one node to another. In fact, SCCP supports both connection-oriented and connectionless signaling contexts. SCCP also carries the information that STPs need to perform global title translation. This translation allows global titles (dialed numbers) to be translated into destination-point codes (network addresses). This is needed for translating 800 numbers, number portability, and other services in which the dialed number must be translated to a different destination address.

◗

Transaction Capabilities Application Part (TCAP) allows signaling nodes to do transactions. Transactions are groups of actions that must be performed as one indivisible action. They are typically used for accessing network databases, for example databases that map 800 numbers to their destination address. A TCAP message contains two types of information: the transaction portion is for starting and ending transactions, and maintains the state of the dialog; the component portion carries the actual protocol queries and responses.

A TCAP message is a kind of container that can carry the signaling messages of other protocols in the component portion. Some of the protocols that have been defined include the following: ◗

Operation, Administration, and Management Part (OAMP). Still only partly defined, this protocol is intended for verifying network routing databases and diagnosing link problems.

28


◗

Mobile Application Part (MAP). The protocol for mobility management GSM networks, it describes the messages that are exchanged between a subscriber’s home and visited network when he or she is roaming. We will discuss MAP in more detail in Chapter 4.

◗

IN Application Part (INAP). This is the protocol defined for IN; we will discuss it in more detail later in this chapter.

The fact that SS7 provides a secure data network for signaling messages meant that it was easy to add special processing nodes in the network for call processing. Telcordia called these processing nodes service control points (SCPs), and this is how IN was born. Figure 2.3 illustrates how SCPs were added in SS7 networks for special call processing. The SCP allows an operator to install and manage services like call forwarding and call blocking more easily than when they had to be programmed in the switch. Consider the example of call forwarding. When a call is made, the call setup signaling message is routed first to the SCP. The SCP looks at the dialed number, and if it is to be forwarded, it substitutes this number with the new destination number. The resulting modified signaling message is then sent on into the SS7 network to complete the call. The introduction of the SCP in SS7 amounted to the first step toward what would be called IN. The next section discusses how IN was further developed and standardized.

SCP SP

SP

STP

STP SP Bearer connection

Figure 2.3

Introduction of service control points in SS7 networks.


2.2

29

IN standards

When Telcordia successfully implemented its AIN architecture in the late 1980s, the idea caught on with the international community and standardization efforts began in the ITU. The ITU took 4 years to publish the first IN standard in 1992, and by that time the first products were already coming onto the market. It comes as no surprise that the early IN implementations, for example those by Telcordia, Ericsson, and Alcatel, were still mostly proprietary and only superficially respected the standards. Today, however, the level of standardization has much improved. The main philosophy behind the ITU standardization process was to standardize service capabilities, but not services. This is very important in understanding the IN architecture. Many people talk about IN services, but it is important to realize that these in fact do not exist. What does exist are services that can be implemented with IN, but there is no such thing as a service standardized by IN. It is a subtle difference, but it matters. 2.2.1

Standardization bodies

IN is a framework for implementing value-added in telecommunications networks. It is not a set of services and it is more than an architecture alone. Today there are several groups involved in the standardization of IN. The most important group is undoubtedly the ITU Telecommunication Standardization Sector (ITU-T). In Europe ETSI is contributing to IN standardization by endorsing the ITU standard and by proposing a number of extensions such as core-INAP and CAMEL. Though not a standardizations body, Eurescom did a great deal of work on IN, both on paper and in prototyping. Eurescom is a cooperative research and development organization founded in 1991 by Europe’s leading network operators; it publishes requirements and feedback on standards as seen from the operator’s viewpoint. In the United States, IN started as a de facto standard promoted by Telcordia. Even today’s ITU-T standards for IN resemble those of the original Telcordia model, but the Telcordia and ITU-T protocols have been diverging over time. The differences between the American and international IN standards manifest themselves more on the protocol level than in concept. Apart from Telcordia, the T1S1 group of the American National Standards Institute (ANSI) has contributed to the American standardization of IN. There are also industrial groups that are not standards bodies, but that

30


do play a role in promoting IN standards. The most significant of these is the Value-Added Services Alliance (VASA). Other industry groups that have relevance to IN are Sun’s JAIN group, Parlay, and the Third Generation Partnership Program (3GPP). In this book we will discuss the contributions of all of these groups. 2.2.2

Standardization cycles

One of the problems that the ITU had to cope with is the standardization of a framework that is by nature expanding all the time, in an environment that is changing all the time. Telephony switches offer more and more features, with every release and new network. Technologies such as GSM and the Internet are constantly changing the environment that IN operates in. The ITU therefore decided to standardize IN in a continuous process, and to freeze the standards at regular intervals. These interval specifications are called capability sets (CSs). As the name suggests, a CS defines a set of service capabilities out of which services can be created. These sets are upward compatible; in other words, each new CS adds new features while the existing ones remain valid. The first CS, standardized in 1992, was CS-1. As IN was new at the time and there were few implementations around to validate the concept, it was necessary to polish the definition in 1995, resulting in the revised CS-1 (CS-1 R). Since then, the ITU has frozen CS-2 in 1997 and CS-3 in 1999. The most recent version, CS-4, was issued in 2001. As explained in the previous section, there are some differences between the U.S. and the international IN standards. The U.S. standards are also defined in releases, but the timing of these is slightly different from that of the ITU CSs. All IN CSs are built on the same foundation, the IN conceptual model. The following section explains this model and how it structures the IN standards. 2.2.3

IN conceptual model

There are several ways to explain what IN is about. One of the ways to look at IN is simply as an add-on to the existing switching architecture. If we look at it this way, then IN is just a collection of dedicated computers that perform special control functions. Another way of looking at IN is to consider it as a software architecture that runs services, much like an operating system runs applications. If we look at it this way, IN is not as much a set of nodes as it is a software framework.


31

The ITU standards combine these different views in an elegant IN conceptual model (INCM). The INCM reconciles the different physical and logical views of the IN architecture. The INCM defines four different views of IN: the service plane (SP), the global functional plane (GFP), the distributed functional plane (DFP), and the physical plane (PP). At first sight it may seem that these four planes are like different protocol layers, but they are not. Many people mistake the INCM for the IN architecture itself. The INCM is however just a convenient way of looking at IN from different angles. The INCM is defined in the ITU recommendations2 Q.1200, Q.1201 to Q.1205, Q.1208, and Q.1290, as shown in Table 2.1. The INCM can be seen as the foundation for IN and provides the structure for defining each CS. Each CS is described in the same way: CS-x is described by recommendations Q.12x0, Q.12x1–Q.12x5, Q.12x8, and Q.12x9, where x = 1, 2, 3, and so on. Table 2.2 shows the numbering scheme for IN CS-x recommendations. In the following sections we will take a closer look at the different planes of the INCM, the foundation of all IN capability sets. After that we can compare the different capability sets.

2.3

Service plane

The service plane is the top plane of the INCM. It describes services from the user’s point of view. The service plane describes what features a Table 2.1 ITU-T Recommendations Defining the INCM

2.

Number

Recommendation

Q.1200

General Series IN Recommendations Structure

Q.1201

Principles of the IN Architecture

Q.1202

IN Service Plane Architecture

Q.1203

IN Global Functional Plane Architecture

Q.1204

IN Distributed Functional Plane Architecture

Q.1205

IN Physical Plane Architecture

Q.1208

General Aspects of the IN Application Protocol

Q.1290

Glossary of Terms Used in the Definition of IN

ITU refers to its standards as recommendations.

32


Table 2.2 Structure of ITU-T Recommendations, Series Q.1200 Number

Recommendation

Q.12x0

Structure of IN CS-x

Q.12x1

Introduction to IN CS-x

Q.12x2

IN Service Plane Architecture for CS-x (not for CS-1)

Q.12x3

IN Global Functional Plane Architecture for CS-x

Q.12x4

IN Distributed Functional Plane Architecture for CS-x

Q.12x5

IN Physical Plane Architecture for CS-x

Q.12x8

IN Interface Recommendations for CS-x

Q.12x9

IN User Guide for CS-x

service is composed of, but not how they are implemented in the network. A feature in the service plane can be seen as a reusable unit of functionality. The freephone service, for example, consists of two features: 1. One-number feature: routes incoming calls to a single external number to different telephones; 2. Reverse charging: reverses charging on calls to the freephone number, so that the owner of the freephone number pays instead of the caller. Figure 2.4 illustrates the IN service plane concept.

Ser e ur

vice

A

1 e ur

B

at Fe

Ser

at Fe

e ur

at Fe

Figure 2.4

IN service plane.

C

vice

2 e ur

at Fe

A


33

The concept of services being composed of features is essential to IN. The key philosophy behind IN is that it standardizes reusable service features rather than services. The composition of services out of features is up to the network operator, and is limited only by the imagination. The main features defined in CS-1 are shown in Table 2.3. In this chapter we will not discuss each feature in detail, since the idea is only to understand how the INCM works. Many of the features shown in Table 2.3 may look familiar, as they are similar to features found in private branch exchanges (PBXs). Of course, in practice the available features determine to a large extent the kind of services that can be deployed. The features defined for CS-1 are few and rather simple. They correspond closely to PBX services and to existing supplementary services, such as call forwarding, that were programmed directly in the switch before IN was introduced. As IN evolves, however, the amount of features increases and with them the possible ways of combining them into new services.

2.4

Global functional plane

Whereas the service plane describes how services are composed from features from the user’s viewpoint, the GFP looks at services from the

Table 2.3 Features Defined in the CS-1 Service Plane Feature Group

Features

Numbering

Abbreviated dialing, one number, personal number, private numbering plan

Routing

Call forwarding, follow-me diversion, time-dependent routing, origin-dependent routing, call distribution

Charging

Premium rate, reverse, split

Access

Authentication, authorization code, off-net access

Restriction

Call limiter, call gapping, closed user group, originating call screening, terminating call screening

Customization

Customer profile management, customer recorded announcement, customized ringing

User interaction

Originating user prompting, destination user prompting, attendant, consultation calling

Other features

Call waiting, automatic call-back, call hold with announcement, call logging, call queuing, call transfer, mass calling, meet-me conference

34


service provider’s viewpoint. The GFP describes the software components that a service provider must deploy in order to assemble services. These components are called SIBs. Depending on what you grew up with, the easiest way to envision SIBs is as LEGO, Meccano, or Tinkertoy parts out of which you can build structures by simply clicking one part onto another. A feature defined in the SP is implemented by one or more SIBs in the GFP. Figure 2.5 illustrates this relationship between the SP and the GFP. 2.4.1

SIBs

SIBs are software components that can be composed into service scripts. Each SIB has one logical starting point and several logical ends. The logical start and ends are where the SIB is connected into the control flow. Multiple logical ends allow each SIB to be used as a decision point in the service script. The SIB acts on call-instance data (CID). This is the call-dependent data, and includes the originator’s address, the dialed number, and the destination routing address. Furthermore, the SIB may need service

Ser re tu

vice

A

1 e ur

B

at Fe

Ser

a Fe

re

vice

2 re

u at

Fe

C

u at

Fe

Service plane

Transla te SIB

BCP Charge SIB

Screen SIB

Queue SIB


Figure 2.5

Mapping from service plane to global functional plane.

A


35

support data, which is independent of the call. Examples of SSD are a call-screening list (black list), a call-forwarding table, or a charging scheme. Figure 2.6 shows the structure of a SIB with its parameters. The global functional plane for IN CS-1 describes a total of 14 SIBs, which are summarized in Table 2.4 (in alphabetical order). As this table shows, the functionality of SIBs is elementary, although the granularity varies somewhat between SIBs. For example, the user interaction SIB is more complex than the screen or algorithm SIB. The IN standard describes for each SIB exactly what the logical start, the logical ends, the SSD, and CID are. Figure 2.7 shows a simplified diagram of the parameters for the screen SIB. This SIB can take the dialed number as CID input parameter, and uses a screening list (typically a black list or white list of telephone numbers) as SSD against which to check the number. Depending on the outcome of this check, the screen SIB returns either at the in-list or the not-in-list logical end. The screen SIB is typically used to implement services such as originating-call screening (OCS) and terminating-call screening (TCS). In the case of OCS, the dialed number is screened at the originating end of the call (as in the screen SIB of Figure 2.7). This service is mostly intended for limiting international calls or calls to premium rate numbers from certain telephones. In the case of TCS, the identity of the calling line is screened at the receiving end of the call. This service is typically used to block unwanted incoming calls, for example malicious calls or calls from telemarketers. Of course, Figure 2.7 is a simplified diagram; in reality the parameters are more complex. The logical ends usually also include an error

Service support data (SSD)

Logical start

Service independent building block (SIB)

Input Output Call instance data (CID) Figure 2.6

A SIB.

Logical ends

36


Table 2.4 SIBs Defined in the CS-1 Global Functional Plane SIB

Description

Algorithm

Applies an algorithm to the CID or SSD (the algorithm to be applied is specified as a parameter of the SIB)

Authenticate

Verifies a user’s privilege to place and receive calls and to access particular service logic and data

Charge

Initiates special charging treatment, that is, any charging different from the standard charging of a call by the SSP; special charging treatment to be applied is a parameter of the SIB

Compare

Performs a comparison of the input parameter against a specified reference value

Distribution

Distributes the treatment of calls on the basis of specified parameters

Log call information

Writes detailed call information into a file; information is intended for off-line use, not within the context of the call

Queue

Queues calls for completion to a specific network address

Screen

Compares the input parameter against a list of data

Service data management

Enables the retrieval, storage, deletion and modification of service data in the database

Service filter

Accepts or rejects calls according to specified parameters; SIB initially called LIMIT in the 1992 version of IN CS-1 because it was mostly used for call limiting (to prevent network overloads)

Translate

Translates input parameter value into output parameter value, based on a specified algorithm or table

User interaction

Allows information to be exchanged between the network and a call party, for example by playing an announcement or by receiving DTMF tones from a party

Verify

Performs a syntactic check on the input parameter, according to a given syntax

Basic call process

Basic SIB which represents the setting up of a point-to-point call

clause for cases in which there is a syntactical error in one of the inputs. Figure 2.7 does not show such details. The important thing for now is to understand the mechanism whereby the SIBs are defined. 2.4.2

Basic call process

Among the SIBs there is one special building block that represents the call itself. This SIB is called the basic call process (BCP). The BCP describes the


37

Service support data Screening list

In list Start

Screen Not in list

Input: dialed number Call instance data Figure 2.7

Parameters of the screen SIB.

phases of setting up a telephone call from one user to another. At each of these phases it is possible to interrupt the call setup process and to start executing a service program. The points at which the call processing can be interrupted are the points of initiation (POIs). When a service is started at a POI, we say that the service is triggered; for this to happen it is necessary to arm a trigger at the POI beforehand so that the BCP knows it must suspend processing. At the time of triggering, the BCP passes the CID to the first SIB in the chain to be executed. The SIBs that make up the service can then change the CID as required by the service. In the case of call forwarding, for example, they can change the destination address. After finishing the processing of the service, the last SIB hands back control to the BCP. The service can order a jump to any point in the BCP call processing; it does not have to be at the same point that the service was invoked. The point at which control is handed back to the BCP is called the point of return (POR), and at this point the BCP can be instructed to handle the call in a specific way. Table 2.5 show the POIs (on the left) and the parameters that can be passed to the BCP with the POI (on the right). To illustrate how a service is described at the global functional plane, we will now consider the example of a call made with a calling card.

38


Table 2.5 POIs and PORs of the CS-1 BCP POIs

PORs

Call originated

Handle as transit

Address collected

Continue with existing data

Address analyzed

Proceed with new data

Call arrival

Provide call-party handling

Busy

Initiate call

No answer

Clear call

Call acceptance Active state End of call

Figure 2.8 shows how this service could be implemented with three SIBs. The example is of course oversimplified, and only serves to further an understanding of how services are defined with SIBs. Figure 2.8 shows only the logical flow of SIBs. All SIB parameters (CID and SSD) have been omitted for simplicity’s sake. According to Figure 2.8, the service could be implemented as follows. Imagine that the user dials a special number corresponding to the calling-card-call service. The following would then take place:

Calling-card service Not OK User interaction (2)

Service data management OK Charge (3) (4)

Address collected

Continue with new data

POI POR

Clear call (5)

Basic call process

(1) Figure 2.8

Calling-card-call service defined at GFP level (simplified).

POR


39

1. At the address-collected POI, the BCP immediately recognizes that the dialed number is special and triggers the calling-card-call service. 2. The first SIB to be executed is the user-interaction SIB. This SIB plays a message to the user: Please enter your card number, PIN code, and the number you want to dial. It collects the DTMF tones from the user and converts them to numbers. 3. The next SIB in sequence, service data management, uses these numbers to look up the calling card for this user and check the PIN code. 4. If the card exists and the PIN code is correct (the OK branch), then the charge SIB starts charging the call to this calling card. After this, control is passed back to the BCP at the same point at which call control was suspended. The POR carries the instruction continue with new data, causing the call to proceed with the destination number input by the user. 5. If the card number or the PIN code is incorrect (the not-OK branch), then the service instructs the BCP to terminate the call immediately by jumping to the clear-call POR. This is of course a simplified example. Real-life services can take up to 1,000 SIBs, although most of the service logic is usually for error handling. Services like the calling card call have to take into account any possible error: wrong card number, incorrect PIN, invalid destination number, time-out of user response, and so on. Service providers say that as much as 80% of the service logic can be spent on error handling.

2.5

Distributed functional plane

Whereas the GFP helps to identify the building blocks out of which to construct services, its view of the network is simplistic. In reality we cannot manage the network as if it were one machine with a single BCP for each call. In practice, the network has a complex layered structure and consists of many specialized elements. Things get even more complicated if we think about calls that start in one operator’s network and end in another’s. The GFP does not give us any clues as to how to actually implement the services in the network.

40


The purpose of the DFP is to provide a more realistic view of the network, reflecting the distribution of functions. In reality, the setup of a telephony call is not a centralized function, as the GFP assumes. It is the result of interactions between switches that use protocols to decide how to route the call from source to destination. To reflect this reality, the DFP distinguishes different functions in the network. 2.5.1

Functional entities

The DFP identifies the different functional entities (FEs) that make up the telephony network. FEs are distributed network functions that run the BCP and the other SIBs defined at the GFP. A single SIB can map onto more than one FE. The DFP also describes the information flows between FEs. They define what information must be exchanged between the different functional entities to implement each SIB. The information flows are specified 3 in the specification and development language (SDL) and with message sequence charts (MSC). Both are ITU-standardized languages for the formal description of distributed systems. Figure 2.9 illustrates how the implementation of SIBs is distributed over FEs. The most important FEs defined in CS-1 are as follows:

3.

◗

Call control function (CCF): keeps the state of a call, such as alerting or terminating line busy;

◗

Service switching function (SSF): takes care of controlling the bearer connections in a call, typically voice circuits;

◗

Service control function (SCF): contains the programs that control services. Such programs are called service logic in IN;

◗

Service data function (SDF): represents the databases that keep the service support data, for example number translation tables or prepaid account credit data;

◗

Service management function (SMF): contains all management functions, such as installing new services, adding or deleting service subscribers, and updating service data;

The SDL and MSC standards are defined in ITU recommendation Z.100.


41

Queue SIB

Screen SIB

BCP

Charge SIB

Translate SIB


SSF SCF

SMF

CCF SRF

SDF


Figure 2.9

◗

Distributed functional plane.

Special resource function (SRF): represents special functions in the network that could be needed to realize services, such as playing announcements, playing tones, generating special ringing patterns, or bridging and mixing of conference calls.

The difference between the CCF and SSF should be noted. It is natural to wonder why there are two separate functions to represent the setting up of telephone calls. From the user perspective, the call and the connection are the same thing: Wouldn’t it be sufficient to have the SSF alone represent the functionality of the switch? Remember that SS7 already separates signaling from connections. In other words, the signaling involved in setting up a call is carried on a different network than the voice connections themselves. Taking this a step further, we could imagine a call as being not just a connection from A to B, but a general concept that associates parties (users placing or receiving the call) with connections and network resources during a delimited period of time.

42


There are important advantages to distinguishing between calls and connections. Such separation allows for the concept of the call to extend naturally to conferences, multimedia communications, and even Internet connections. And it allows service logic programs (like IN) to control the adding and dropping of connections within the context of a single call. It is especially for this reason that IN separates the CCF from the SSF. 2.5.2

Half call

The DFP provides a more detailed representation of the basic call process. The most important refinement is that the DFP takes into account the distributed nature of a call. At the DFP level, the call is no longer seen as a single abstract process, but a distinction is made between call processing for the originating (calling) party and for the terminating (called) party. The DFP introduces the concept of a half call: the BCP is now split into two parts, called the originating basic-call-state model (O-BCSM) and the terminating basic-call-state model (T-BCSM). The O-BCSM describes the procedure for initiating a call, while the T-BCSM describes the process of receiving one. Both the O-BCSM and T-BCSM can trigger services in the SCF, as Figure 2.10 illustrates. It is obvious why the DFP distinguishes between O-BCSM and T-BCSM: There exist IN services that deal with outgoing calls (for example, abbreviated dialing) and services that deal with incoming calls (for example, blocking of malicious calls). Apart from this, the caller and

SCF Trigger

Calling party

Trigger

O-BCSM

T-BCSM

SSF Figure 2.10

The half-call concept as defined in the DFP.

Called party


43

called party are not necessarily connected to the same switch or even to the same network, so one cannot assume that there is one global process that has control over the whole call. 2.5.3

Detection points

The O-BCSM and T-BCSM can both be seen as more detailed versions of (half of) the BCP of the GFP. Both the O-BCSM and T-BCSM are represented as state-transition diagrams that describe the call-processing states and transitions between them. The states are called points in call (PIC), and the transitions are caused by events, such as taking the phone off the hook, dialing a number, putting the phone on the hook, or flashing (swiftly pushing) the hook. An event can have a detection point (DP) associated with it. DPs can be seen as implementations of the POIs defined at the GFP: They are points at which the SSF can suspend call processing and hand over control to the SCF. Figure 2.11 shows the PICs and DPs of the O-BCSM and T-BCSM. Each large dark box in Figure 2.11 represents a PIC. The lines and arrows represent events, and the small lighter boxes represent DPs. The PICs and DPs are rather self-explanatory, apart from a few odd names such as O_Null_and_Authorize_Origination_Attempt, T_Null_and_ Authorize_Termination_Attempt, and Route_Select_Failure. The DPs can imply different courses of action, depending on the kind of service requested and the DP that requests it, as follows: ◗

Trigger detection points (TDPs): set statically at the time of deployment of a service or when a user subscribes to it;

◗

Event detection points (EDPs): set dynamically by service logic during the course of a call.

For example, one would use a TDP for a static service such as freephone, but an EDP would have to be dynamically set to realize a service such as automatic callback on busy. When the O-BCSM or T-BCSM encounters a detection point, two kinds of action are possible: 1. Notification. The BCSM only sends information to the SCF and continues without waiting for a response.

44

O-BCSM

Originating_Attempt_Authorized

T_Exception

O_Null and_Authorize Origination_attempt

O_Exception

O_Abandon

T-BCSM

T_Abandon _T_Null_and_Authorize_ termination_Attempt Terminating_Attempt_Authorized

Collect_Info T_Called_Party_Busy Collected_Info

Analyze_Info

Select_Facility and present call Route_Select_Failure T_No_Answer O_Called_Party_Busy

T_Alerting

Routing & Alerting O_Answer

T_Disconnect T_Active

O_Active O_Mid_Call

Figure 2.11

T_Answer

O_No_Answer

O_Disconnect

BCSMs for originating and terminating sides.

T_Mid_Call


Analyzed_Info


45

2. Request. The BCSM suspends call processing, hands control to the SCF, and awaits a response before continuing, possibly with modified call parameters. The call-forwarding service, for example, can be started only as a request, because call processing must wait for the number to be translated. On the other hand, a televoting service may only need information to be sent to the SCF without suspending the call. Depending on whether a detection point is a TDP or an EDP, a notification or a request, there are four possibilities, as shown in Table 2.6. 2.5.4

Trigger processing

The SSF must have a mechanism for handling DPs when they are encountered during the processing of a call. In practice, this is usually a table that lists which DPs are armed and whether they are TDP-N, TDP-R, EDP-N, or EDP-R. The IN standards also define a function in the SSF that detects and resolves conflicts between different services triggered on the same call, the feature interaction manager (FIM). Figure 2.12 shows an example of the DP processing mechanism in the SSF. It makes no difference in this example whether we are looking at an O-BCSM or T-BCSM, since DP processing is the same for both. Figure 2.12 shows the following sequence of events and triggers: 1. The first DP encountered by the BCSM is not armed, and the BCSM is instructed to continue. 2. The next DP is armed as TDP-N, meaning that only a notification is sent to the SCF, and the BCSM immediately resumes without waiting for a response. Before relaying the TDP-N to the SCF, the FIM checks for interactions with other services activated on the same call. Table 2.6 Detection Point Types Trigger Detection Point Trigger detection Notification point—notification (TDP-N) Request

Trigger detection point—request (TDP-R)

Event Detection Point Event detection point—notification (EDP-N) Event detection point—request (EDP-R)

46

BCSM PIC

DP (1) processing not armed

DP

Featureinteraction manager

Servicelogic program

Resume PIC

(2)

DP

TDP-R!

Check conflicts

armEDP-R

Check conflicts

TDP-R response

(3)

DP Resume PIC

armDP

TDP-R

Process request

(4) EDP R!

DP

Resume

SSF

Figure 2.12

Process notification

DP processing and feature interaction manager.

Process request

SCF


Check conflicts

Resume PIC

TDP-N

TDP-N!


47

3. The third DP encountered is armed as a TDP-R. This time it is a request, so call processing is suspended and the request is sent via the FIM to the service logic. In this example, the service logic responds with a command to arm an EDP-R further on in the BCSM. This command is passed back to the DP processing module, which takes care of arming the EDP-R. Then it instructs the BCSM to resume. 4. The last DP encountered in this example is the one previously armed by the service logic. This is an EDP-R, which means that call processing is also suspended until the SCF returns a response, for example a translated number. In this example, the BCSM resumes at the next PIC. It is important to note that the service logic may instruct an event to be armed at any DP in the BCSM, and that call processing can resume at any point in the BCSM. In other words, it is unnecessary that call processing always resume at the next PIC. For example, in a service in which a PIN code is checked, it makes sense to jump directly to the end of the BCSM and release the call if the PIN is entered incorrectly. From the discussion in this section, it is obvious that the distributed functional plane is significantly more complex than the global functional plane, but also more realistic in its modeling of call processing and the ways in which control can be passed to the SCF.

2.6

Physical plane

The DFP takes into account the distributed nature of the network, but only in a superficial way. The DFP recognizes the difference between the calling and called party, and between service switching and service control, but does not go so far as to allocate functions to physical locations or machines. This is done in the physical plane. 2.6.1

Physical entities

The physical plane allows for different mappings of IN functions onto physical nodes. The simplest mapping simply allocates a distinct node, as follows, for each function:

48


◗

Service switching point (SSP): contains the switch, but typically also holds the CCF and SSF.

◗

Service control point (SCP): contains the SCF.

◗

Service data point (SDP): contains the database or databases that make up the SDF.

◗

Service management point (SMP): hosts the SMF.

◗

Intelligent peripheral (IP): implements the SRF.

Figure 2.13 illustrates this straightforward mapping of functional entities onto physical ones. It is clear that the mapping of Figure 2.13 would require at least four or five machines to implement an IN system. In smaller networks or in cases in which there are few services or few service subscribers, the number of machines can be reduced by colocating certain DFP functions on the same physical node. For performance reasons, the SCP very often also hosts the service databases. In other words, the SCF and SDF are often combined into one SCP. This is shown in Figure 2.14. The configuration requiring the least hardware is one in which the SCF, SDF, and IP are located together on one machine. Such a configuration is often referred to as a service node. Many switch vendors actually

SSF SCF

SMF

CCF SRF

SDP

SDF


SSP

SCP IP

Physical plane

Figure 2.13

IN physical plane.

SMP SDP


49

SSF SCF

SMF

CCF SRF

SDF


SSP

SCP

SMP

IP Physical plane

Figure 2.14

Colocation of SCF and SDF at the physical plane.

combine these functions with the switch itself, and in this case the service node even includes the SSF. Figure 2.15 illustrates the service node concept.

SSF SCF

SMF

CCF SRF

SDF


Service Node

SMP

Physical plane

Figure 2.15

Colocation of IN functions in a service node.

50


In practice, one can find all of these configurations on the market. Obviously it is more difficult to support high throughput with a service node implemented on a single machine than with a multimachine configuration. Service nodes therefore tend to be used in smaller networks, or in networks with few value-added services. Nevertheless, service nodes represent an important market, and some vendors concentrate completely on this business segment. Many manufacturers support a range of configurations and adapt their offer to the operator’s requirements and budget. The INCM allows IN to be built in a modular way, by creating a software module for each FE. This allows the manufacturer to distribute FEs over physical machines according to the customer’s needs. 2.6.2

IN application protocol

The INCM is useful in understanding IN, but in the end, building an IN system comes down to implementing protocols. The protocol used for communications between FEs is INAP. This protocol is called an application protocol because in terms of the seven-layer OSI model, it is situated in the uppermost application layer (layer 7). We will not discuss OSI in any further detail here, because it is of little relevance in understanding IN. Strictly speaking, INAP is not defined as part of the physical plane, but is described in separate documents (Q.1208, Q.1218, and Q.1228). But since INAP is about implementing IN, we will cheat a little and discuss it here. INAP messages contain the information exchanged between functional entities, in particular between the SSF and SCF and between the SCF and SRF. The communication between the SCF and SDF is a special case, since it is not defined by INAP but is based on the Directory Access Protocol (DAP), also specified by the ITU in its X.500 recommendations. INAP is not just a collection of stand-alone messages, but messages that when sent must follow a certain order, called a dialogue. These dialogues implement the information flows defined in the distributed functional plane. Figure 2.16 shows a simple example of such a dialogue for the freephone service. The procedure is as follows: 1. When the BCSM recognizes the number dialed by the user as a freephone number, this triggers a TDP-R.

Collected_Info

(1)

Analyze_Info

TDP-R

SCF

initialDP(call id, dialed number,‘freephone’)

SDF

, requestInfo(freephone DB, dialed number)

(2) (3) connect(call id, destination id); requestReport(O_Answer, O_Disconnect)

requestInfoResponse (destination id) (5)

O_Answer

(6)

TDP-N

(4)

Start reverse charging (7)

TDP-R

eventReport(call id, O_Disconnect, time stamp)

O_Null and Authorize Origination Attempt

Simplified INAP dialogue for freephone service.

Stop reverse charging

51

Figure 2.16

Look up dialed number in freephone database

eventReport(call id, O_Answer, time stamp)

O_Active O_Disconnect


SSF

BCSM

52


2. As a result, the SSF sends an initialDP message to the SCF with the calling line identifier, dialed number, and service identifier as parameters. The meaning of the initialDP message is to start the service processing in the SCF. As explained before, a service is defined as a sequence of SIBs in the GFP. In the DFP these SIBs map to programs in the FEs that communicate by sending messages to each other. 3. In this example, the service program in the SCF first queries the database in the SDF to find out where to route this call. It does this by sending a requestInfo message to the SDF. 4. The SDF looks up the dialed freephone number in the database, finds the corresponding destination network address, and returns it to the SCF in a requestInfoResponse message. 5. The SCF then orders the SSF to connect the calling party to the destination address, using the connect message. The SCF also requests the SSF to be notified when the connection is actually established and stopped. For this it sends a requestReport message to the SSF, indicating the DPs where it wants to be notified (in this case O_Answer when the call is accepted, and O_Disconnect when the call is disconnected). 6. When the destination party answers the call, the SSF sends an eventReport message with a time stamp. As a result, the SCF starts reverse charging the call to the destination address (remember, this is a freephone service; the caller does not pay). 7. Finally, when one of the parties releases the call, the SSF sends another eventReport message to the SCP, causing the SCP to stop charging and terminate the freephone service processing. Of course, this example is oversimplified. In reality the dialogues are much longer and the messages have many more parameters. In fact, the INAP specifications are hundreds of pages long and grow with each capability set. But what is important here is to understand the basic mechanism: dialogues of INAP messages implement the information flows between FEs, which in turn implement the SIBs, the building blocks out of which services are developed.


53

INAP carries only the information directly related to information exchange between IN FEs. It does not take care of the correct transmission of messages, error corrections, or keeping track of the state of a dialogue. All this is taken care of by the SS7 protocols situated below INAP, shown in Figure 2.2 in Section 2.1. INAP messages are transported within TCAP messages. As explained in Section 2.1, TCAP is a protocol for establishing dialogues and keeping track of transaction states. A TCAP message contains two parts: the transaction portion for managing the transaction, and the component portion for carrying protocol messages. INAP messages are carried in the component portion of a TCAP message, as part of a TCAP-managed dialogue. The syntax of INAP is formally specified in the abstract syntax notation 1 (ASN.1). ASN.1 is a complex language and that can be difficult to read, but the bottom line is that the grammar of INAP is unambiguously defined. The standard is also very precise about what data types can be exchanged; for example, a series of digits is different from a number or a string. Now that we are familiar with the basic concepts of IN, in the next section we will look at the extensions that have been made over the years in CS-2 and CS-3.

2.7

CS-2

The first IN standards were defined at a time when telecommunications operators were still mostly state-owned monopolies, the Internet was a tool only for the research community, and GSM was in the embryonic stage. In fact GSM was standardized more or less in the same time frame as IN CS-1 (that is, between 1988 and 1992), but IN and GSM standardization were quite different activities. IN was initially designed for fixed voice telephony networks governed by a single operator. The IN CS-1 standard was powerful and simple, but by the time IN platforms were being deployed in real networks in the 1990s, the world was undergoing radical changes. Telecommunications markets were deregulated and opened to competition. Even within the same country, calls could now initiate in one operator’s network and terminate in another’s. To stimulate competition, many regulatory bodies began requiring number portability, allowing customers to change operators without changing their number.

54


The second half of the 1990s was also the era of the mobile phone and the Internet. All this contributed to a true explosion of complexity in the network. Even in the first years that IN was being deployed, between 1992 and 1995, it became clear that the CS-1 standard was already out of date. Some of the limitations of the CS-1 standard were as follows: ◗

The CS-1 specifications assume that the network is controlled by a single operator and does not provide for adequate mechanisms to provide services over operator boundaries (so-called internetworking services).

◗

CS-1 deals with point-to-point telephone calls and does not offer sufficient features for multiparty and multimedia communications (such as videoconferences).

◗

CS-1 has only limited features for mobility. A particular problem with CS-1 is that user interactions can take place only when a call is set up first. In mobile networks, however, many procedures take place outside the context of a call, for example user authentication or location updating.

The target for CS-2 was to lift some of these limitations while remaining backward compatible with CS-1. The extensions to CS-1 that were made in CS-2 (and maintained in CS-3) can be summarized as follows: ◗

CS-2 allows communications from one SCF to another and from one SDF to another. This means that service logic and data can be distributed and that services can be controlled across operator domains.

◗

CS-2 can handle calls between more than two parties. In technical terms this means that one service logic instance in the SCF can control more than one BCSM at a time.

◗

CS-2 allows user interactions to take place outside the context of a call, by creating a basic call-unrelated process (BUCP) in addition to the BCP in the GFP. Likewise, CS-2 defines a basic call-unrelated state model (BCUSM) at DFP level as a call-unrelated counterpart of the BCSM.


55

◗

CS-2 allows call-related and call-unrelated user interactions to use out-channel signaling connections (i.e., signaling connections that are not related to the call or even the telephony network; for example, a GSM short message or a TCP/IP connection).

◗

CS-2 generalizes the service-creation concept. By refining the concept of SIBs and making it recursive, it becomes more of a true component model.

◗

Service management guidelines are better defined in CS-2 than they were in CS-1.

◗

CS-2 contains guidelines for service-interaction processing, necessary for resolving conflicts between incompatible services.

Straightforward as they may appear at first sight, these points require complex changes in the global functional plane, the distributed functional plane, and in the definition of the INAP protocol. We will now take a closer look at how CS-2 refines the INCM. 2.7.1

CS-2 service plane

The IN service plane was first properly defined in CS-2. Although the INCM was defined with the CS-1 specifications, the service plane was not formally defined for CS-1. According to the Q.1200 series recommendation structure explained in Section 2.2.3, recommendation Q.1212 should define the CS-1 service plane. In reality, this document was never produced. The first IN specifications were an evolution from existing network features that were until then programmed in the switch. These supplementary services were widely known and were not unique to IN, and ITU never bothered to specify them. CS-2, on the other hand, does define a service plane, because it introduces new features that provide for more than the classic switch-based services. It is important to keep in mind that IN does not standardize services. The CS-2 service plane only provides a benchmark for the minimal set of services and features that can be implemented in CS-2. It does not say that these are the CS-2 services, but rather that this is the minimal set of features and services that you should be able to implement in CS-2. The CS-2 service plane is backward compatible with the CS-1 services, but adds features for internetworking, call-party handling (CPH), out-channel user interactions, service management, and service creation.

56


2.7.2

CS-2 global functional plane

An important change in the GFP is the addition of BCUP. This is a special SIB much like the BCP, except that it describes the process of callunrelated user interaction. A typical case of such call-unrelated user interaction is the registration of a user to a network or terminal. Such interactions are common in GSM networks, for example when a user switches on a mobile or moves between radio cells. The BCUP models such authentication and registration procedures outside the context of a call. CS-2 also provides more points of control in a call by extending the BCP with new POIs and PORs. It introduces new POIs for midcall interruptions, like a hook flash or pushing the special R button on the phone. The new PORs are mostly related to the individual handling of connections between call parties. In CS-1 this type of control was not possible. In CS-2 a service process does not have to be a single chain of SIBs as in CS-1, but can involve multiple processes.4 During its execution, a service logic program can create new processes that run in parallel and can communicate between each other by messages. The CS-2 global functional plane redefines some of the CS-1 SIBs and includes a number of new ones. The user interaction SIB is extended so that it also handles out-channel and call-unrelated user interactions. Apart from the special BCUP, the new SIBs are for the following: ◗

CPH: to manage the attachment and detachment of parties within a call;

◗

Process management: to manage the creation and destruction of parallel service processes and the communication between them.

Without going into detail, Table 2.7 summarizes the new CS-2 SIBs and their functions. CS-2 also extends the mechanism by which services are created out of SIBs. CS-1 defined a fixed set of SIBs that cannot be modified or extended. In CS-1, it is not possible to create reusable components out of groups of SIBs, something that can be very useful in practice. CS-1 proved to be too rigid and in practice many manufacturers ended up implementing their own nonstandard SIBs. CS-2 refines the SIB concept by defining a recursive service-creation model: 4.

These processes can be compared with threads in some programming languages.


57

Table 2.7 New SIBs in CS-2 Basic Call-Unrelated Process BCUP

Describes user interactions that take place outside the context of a call (e.g., authentication, registration, location update)

SIBS for Call-Party Handling Split

Detaches one or more call parties from an existing call, and attaches them to another call

Join

Attaches one or more call parties to a call

SIBs for Process Management Initiate service process

Starts a new service process to be run in parallel

End

Ends a service process

Message handler

Sends a message to, or receives a message from, another service process

◗

A SIB operation represents an atomic operation that cannot be divided into smaller components.

◗

A high-level SIB (HLSIB) is a component that can be composed out of SIB operations, SIBs, or other HLSIBs, as illustrated in Figure 2.17.

Logical start

SIB operation

Logical ends

High-level SIB SIB High-level SIB

Figure 2.17

High-level SIB

CS-2 high-level SIB concept.

SIB operation

58


This new definition of SIBs is quite powerful and allows for service components to be specified at any desired level of granularity. To make CS-2 backward compatible with CS-1, the original notion of SIBs was kept in CS-2. This is why the definition of HLSIBs also allows the possibility of including normal SIBs. A CS-2 service logic program can be composed out of any combination of SIB operations, CS-1 or CS-2 SIBs, and HLSIBs. 2.7.3

CS-2 distributed functional plane

The CS-2 DFP describes the FEs and the information flows between them, following the rules of the INCM. It is backward compatible with the CS-1 DFP, so it maintains the CCF, SSF, SCF, SDF, SMF, and SRF and extends them with new functionality. CS-2 also introduces a number of new FEs: ◗

Call-unrelated service function (CUSF) processes events from callunrelated user interactions, and can trigger service processing in the SCF. The CUSF is like the SSF, but for call-unrelated events.

◗

Service control user agent function (SCUAF) represents the call-unrelated user interface that allows a user to communicate with the CUSF. Although the SCUAF does not have a real counterpart in CS-1, one could argue that its function is similar to that of the SRF except for call-unrelated interactions.

◗

Service management access function (SMAF) provides a user interface for external access to the SMF, for example through the Internet.

◗

Intelligent access function (IAF) is an interworking function that allows an SCF to control non-IN equipment.

In addition to these new FEs, CS-2 defines three functions for mobile networks: the call-related radio access control function (CRACF), callunrelated radio access control function (CURACF), and radio control function (RCF). As the control of radio access is not a major concern for CS-2, however, these FEs and their information flows have only an informative status in the standard. Apart from defining new FEs, CS-2 also introduces new information flows between existing FEs that did not exist in CS-1. CS-2 allows SCFs to communicate directly with each other and service control to be distributed. CS-2 also lets data be distributed over SDFs. This is illustrated in Figure 2.18.


59

SDF

CS-2 SDF

CS-1 SCF

CS-2

CS-1 SCF

CS-1 SSF

CS-1 SSF

Network 1 Network 2 Figure 2.18

New relationships between FEs in CS-2.

The possibility of distributing service control and data is particularly useful in cases in which services must be delivered across service provider domains. An example is the international virtual private network (IVPN), in which an international company may have employees and terminals distributed over different networks. The CS-2 O-BCSM and T-BCSM contain new PICs and DPs that are refinements of those defined for CS-1. Table 2.8 shows how the CS-2 PICs relate to the CS-1 PICs shown in Figure 2.11. As Table 2.8 shows, many PICs have remained the same, but some, such as O_Null&Authorize_Origination_Attempt, Routing& Alerting, and Select_Facility&Present_Call were split up in finer PICs. There are two new PICs in CS-2 that did not exist in CS-1: O_Suspended and T_Suspended. These new PICs represent a half call that is neither active nor released (for example, when a party is put on hold). CS-2 also defines new DPs for the new PICs where service logic can be triggered. Apart from the O-BCSM and T-BCSM, CS-2 defines a new BCUSM that represents user interactions taking place outside the context of a call. The BCUSM has a simple structure and is shown in Figure 2.19. The states and transitions of the BCUSM represent the activation and release of a signaling channel for user interaction, and the reception of user data in the form of components. All this takes place outside the context of a call. One of the most important new features in CS-2 is CPH. In CS-1 it was only possible to set up and release a call between two parties. The call

60


Table 2.8 Comparison of CS-1 and CS-2 PICs CS-1 PIC

CS-2 PIC

O-BCSM O_Null&Authorize_Origination_ Attempt

O_Null

Collect_Info

Collect_Information

Authorize_Origination_Attempt

Analyze_Info

Analyze_Information

Routing&Alerting

Route Select Authorize_Call_Setup Send Call

O_Alerting

O_Alerting

O_Active

O_Active

O_Exception

O_Exception

—

O_Suspended

T-BCSM T_Null&Authorize_Termination_ Attempt

T_Null Authorize_Termination_Attempt

Select Facility&Present Call

Select Facility Present Call

T_Alerting

T_Alerting

T_Active

T_Active

T_Exception

T_Exception

—

T_Suspended

and the connection set up as the result of the call were the same thing. In CS-2 it is possible to manipulate the individual parties in a call and their connections. Within the context of a call, CS-2 lets you add or drop call parties and connections. This means that the call and the connection are no longer the same thing: The configuration of connections set up within a call can change as parties are added and dropped. It was necessary to add CPH in CS-2 to control services like conference calls where there are more than two parties involved in the communication. But CPH is also required to realize more elementary services such as call waiting. The addition of CPH makes CS-2 much more complex than CS-1. At the level of the GFP, this complexity is not so apparent; there are only


61

Idle and authorize activation/ association req. Activation received and authorized Activation failed

Component received

Active

Release Association release requested Released Figure 2.19

Release Release

BCUSM.

two new SIBs: split and join. At the network equipment level, the story is quite different: CHP requires connections to be associated to a call, and could involve special resources like audio bridges. One of the most important requirements is that the service logic in the SCF must always have a consistent view of the configuration of the connections in a call. When the SCF loses track of who is connected to the call, the service gets into an inconsistent state and the effect of a join or split operation becomes unpredictable. For this reason, CS-2 defines a formal model for describing the state of connections in a call. This is called the connection view state (CVS) model. The main elements in a CVS are as follows: ◗

Call segment (CS) describes a half call as explained in Section 2.5.2, but in CS-2 a half call can also apply to multiparty calls. A CS is described in terms of legs and connection points.

◗

Connection point (CP) is a joint between two or more legs or between just one leg and the network. The notion of a CP is generic; it can be a switched connection, but it can also be an audio bridge or a media distribution point.

62


◗

Leg represents a part of the communication path between parties in a call. A leg can be controlling or passive, depending on whether service logic was invoked for this leg or whether it receives instructions passively.

◗

Call segment association (CSA) is the group of all call segments that are involved in a given service and that are controlled by the SCF. In principle a call segment can be made out of any combination of legs and connection points, but not all combinations are meaningful. CS-2 identifies 14 specific configurations that are found in the most common services.

The CS-2 standard uses a graphical notation to describe CVS. The diagrams for call segments show a connection point and the legs attached to it. For each leg it is indicated whether it is controlling (indicated by the letter c) or passive (indicated by the letter p). The diagram also shows whether the leg has actually been set up (called joined) or whether it is still in the phase of being set up (called pending). To show how the CVS represents the state of the connections in a call, we will now consider the very simple example of the follow-on call feature. This feature is used for example in credit card calls and allows a user to make several calls without putting the telephone on-hook and entering the credit card details every time. Figure 2.20 shows a simplified version of the information flows between the SCF and SSF for the follow-on call feature, and the resulting CVS. The information flow for the follow-on call leads to the following connection view states: 1. When the user places the first call, the O-BCSM in the SSF detects a trigger and sends the initialDP message to the SCF. 2. The SCF instructs the SSF to connect the originating and destination parties, and requests the SSF to report any midcall events. 3. When the user ends the first call and wishes to make a follow-on call, he or she does not put the telephone on the hook, but simply flashes the hook. This causes a midcall event to be reported to the SCF. 4. As a result, the follow-on call service logic does not terminate the call, but only disconnects the leg to the destination party.

Stable 2-party c p O-BCSM

connect (call id, destination id); requestReport(O_Mid_Call) Joined

Joined

O-BCSM

eventReport(O_Mid_Call, O_Switched_Hook_Flash_ Immediate)

c

disconnectLeg(legid)

O-BCSM

connectToResource(SRF)

Forward connection c O-BCSM

(2)

(3)

(5) prompt&CollectUser Information(messageid)

SRF

prompt&CollectUser Information_Result

1-party Joined

(1)

(4) Joined

Joined

1-party

c

O-BCSM

(7) connect(call id, new destination id)

(8)

63

Connection-state views for follow-on call.

Joined

Joined

Stable 2-party c p

(6)

disconnectForward Connection(SRF)

O-BCSM

Figure 2.20

SCF

initialDP (call id, dialed number ‘freephone’ )

Pending

Joined

Originating setup c p

SSF


Connection state view

64


5. Next, the SCF instructs the SSF to establish a connection to the SRF. 6. The SCF instructs the SRF to play an announcement message and prompt the user to dial the number for the follow-on call. 7. When the SCF has received the digits for the next call, it orders the disconnection from the SRF. 8. Finally, the SCF sets up the connection to the new call destination specified by the user. This scenario was taken from recommendation Q.1229. Of course, the example is simplified; the INAP messages between the SSF and SCF are more complex in reality. What is important is an understanding of the principle: The CVS represents how the SCF sees the connections in the SSF. When a command from the SCF to the SSF changes the connections in a call, the CVS changes accordingly. CVSs can become very complex, and in practice it is difficult to read and interpret them in the standards. This is because IN CS-2 tries to implement multiparty communications by using classic switching technology intended only for point-to-point telephone calls. This is like trying to map a complex three-dimensional model to a two-dimensional picture without losing any detail. 2.7.4

Implementing CS-2

Although CS-2 does not introduce significant new network elements at the physical plane, the new CS-2 functionality does have its impact on the definition of INAP. The most important extensions made to INAP in CS-2 are those for CPH, call-unrelated interactions, and communication between SCFs that share control of a call. CS-2 is significantly more complex than CS-1, both conceptually and in terms of the INAP protocol. As it turns out, the CS-2 standard contains a certain amount of ambiguities and errors that proved a stumbling block for a quick introduction into commercial platforms. For this reason CS-1 has remained the most frequently used capability set even years after CS-2 was published (and it continues to be widely used today). For CS-2 to become truly usable, it was necessary to resolve certain problems with the specifications. Rather than producing a new version of CS-2, these necessary revisions were made during the specification of


65

CS-3. As a result of this, CS-3 should probably be considered more as the updated and extended version of CS-2 than as a new capability set. The CS-3 recommendation respecifies INAP, but does not revise the service plane, global functional plane, distributed functional plane, and physical plane. One could say that CS-3 is to CS-2 what CS-1 R (version 1995) is to CS-1 (version 1992). In the following section, we will take a brief look at CS-3 and its successor, CS-4.

2.8

CS-3 and CS-4

When standardization of CS-3 started, manufacturers and operators were still struggling with the consolidation of CS-2. CS-2 introduced a new level of complexity and with that, new ambiguities and problems with the interpretation of the standards. Many of the necessary refinements and corrections to the CS-2 standards were actually made during the specification of CS-3. As a result, CS-3 should be regarded more as an updated version of CS-2 than as a new capability set in its own right. 2.8.1

CS-3 features

CS-3 does not introduce new concepts in the INCM. For this reason the ITU recommendations for IN CS-3 do not include documents Q.1232–Q.1235, which would have specified the CS-3 SP, GFP, DFP, and PP (see Table 2.2 in Section 2.2.3). CS-3 does improve the CS-2 facilities for interworking with mobile networks, broadband and narrowband ISDN, and the Internet. For this reason the CS-3 standard includes two new documents: 1. Q.1236 is a document that describes a high-level management information model for IN CS-3. In fact, one can hardly speak of it as a standard; it is more of an informative document that presents some considerations on service management. 2. Q.1237 gives a description of the extensions made in CS-3 to support broadband ISDN. The most important part of the CS-3 standard is the redefinition of the INAP protocol in document Q.1238. This document has seven parts, each describing the interaction between specific functional entities.

66


CS-3 provides a couple of new facilities with respect to its predecessor CS-2, such as support for number portability. Number portability means that a subscriber can keep his or her telephone number when changing operators or even when moving to a new geographical location. By now this has been declared mandatory by regulatory bodies in most countries. At first sight number portability does not seem difficult, because it simply involves a number translation. This was possible even in CS-1. The problem is that many operators started with non-IN implementations for number portability. In many countries number portability requires access to an external database managed by the national regulator. CS-3 offers the mechanisms for interworking with such hybrid systems. A new technical feature of CS-3 is to allow multiple points of control. This is a fundamental departure from CS-2, which allows only a single point of control. In CS-2 only one service logic instance can control a call segment at a time, whereas CS-3 allows several service logic instances to control the same call segment at a time. This means that there must be some way to arbitrate between service logic instances that try to execute incompatible requests. An example of a conflict that can arise with multiple points of control is when two SCFs try to join and disconnect the same call leg at the same time. CS-3 describes some mechanisms to detect and resolve such feature interactions, although more work on this is still needed. 2.8.2

ETSI improvements in CS-2 and CS-3

Although the ITU standards can be seen as the master specification of IN, the role of ETSI has proven crucial for the development of CS-2 and CS-3. The ETSI group involved in the standardization of IN was the Services and Protocols for Advanced Networks, Group 3 (SPAN 3). Because the ITU CS-1 and CS-2 standards contain certain ambiguities, many manufacturers ended up implementing IN with their own proprietary version of INAP. In the mid-1990s it was practically impossible to connect one vendor’s IN system to another’s for this reason. The different manufacturers’ protocols simply were not compatible, although they were all called INAP. ETSI recognized this problem and specified core INAP, a simplified version of INAP stripped of unnecessary complexity and a kind of common denominator of the INAPs in the market. Today many manufacturers have core INAP-compatible IN systems. Another important contribution of ETSI SPAN 3 was to specify the entire distributed functional plane of CS-2 and CS-3 in SDL. ITU already


67

described the DFP information flows in SDL, but used the language rather informally. SDL is a formal language that allows for protocols and systems to be specified unambiguously as communicating finite state machines. As such, SDL provides a formal framework for validation, simulation, and conformance testing. SDL can be used at various degrees of formality, however, and the ITU specifications were not rigorous enough to serve as a true conformance framework. ETSI sharpened the SDL specifications to the point where they are formal enough to allow for the automatic generation of test scenarios. ETSI used the SDL models to specify protocol implementation conformance statements (PICS) that can be used as formal references for IN implementations. With this formal approach, ETSI also revealed and resolved a number of ambiguities in the original ITU standards. Although the ITU provided the ignition for the definition of IN, it is fair to say that ETSI made some decisive contributions to IN during the second half of the 1990s. 2.8.3

New additions in CS-4

While time pressure resulted in CS-3 being little more than a revised version of CS-2, many new requirements for IN were delayed to CS-4. Internet, mobile networks, and deregulation were changing the telecommunications scene in a dramatic way, and object-oriented programming was becoming the industry standard in computing. Against this backdrop CS-4 was expected to introduce important innovations in the INCM. CS-4 was to accommodate the communications of the new era: voice, video, multimedia, data communications, possibly involving multiple parties, possibly involving mobile terminals, and using packet-based transmission rather than switched connections. CS-4 was also expected to provide an object-oriented model for services and service components, up-to-date with industry standards. The specification of CS-4 started in the summer of 1999 and was completed in 2001. It has already become clear that CS-4 fulfills only part of its promises. The ITU recommendations for CS-4 are little more than another update of the INAP protocol. The dominant part of the CS-4 standard is recommendation Q.1248, a revision of the seven-volume CS-3 INAP specification. The only part of the INCM updated in CS-4 is the DFP, defined in recommendation Q.1244.

68


The most important new feature in CS-4 is its support for communications over the Internet. The CS-4 DFP introduces the session manager (SM), a new FE for handling voice and multimedia sessions on the Internet. The SM can set up and receive voice and multimedia calls over the 5 Internet using either of the two well-known protocols H.323 or SIP. From the Internet point of view, the SM looks like an H.323 gatekeeper or SIP proxy and communicates with other H.323 gatekeepers and SIP proxies. On the IN side, it looks like a special kind of telephone exchange that can trigger services through the SSF. Figure 2.21 gives a simplified view of the SM in the CS-4 DFP. Figure 2.21 is somewhat simplified with respect to the standard. In reality the standard describes two scenarios, one for H.323 and one for SIP. For simplicity, Figure 2.21 collapses these views into one, and omits FEs such as the CUSF, SMF, and SMAF that were already defined in CS-2 and CS-3. CS-4 also includes protocols for the integration of telephony services and Internet. The most important are the following: ◗

PINT: a protocol to set up IN calls from Web sites;

◗

SPIRITS: a protocol for Internet call waiting, a service that notifies users connected to the Internet of incoming telephone calls.

SDF SIP proxy

H.323 gatekeeper

SCF

SRF

SSF

SM

Internet

SSF IN-IP gateway Figure 2.21

CS-4 distributed functional plane (partial view).

5. See Sections 3.2.2, 3.2.3, and 3.2.4 for details on H.323 and SIP.


69

The PINT and SPIRITS protocols were proposed by the IETF. We will study them in detail in Chapter 3. While the expectations for CS-4 were high, in reality its standardization has been slow and cumbersome. The industry has been unable to come up with an IN that provides simple models for Internet, mobile networks, and object-oriented programming. Instead the CS-4 specifications have been an attempt to stuff more functionality into an already overly complex model. The IN model begins manifesting itself as a telephony-centered corset that resists the modeling of other types of communication and software creation. Even during the specification of CS-4, the industry was experimenting with new, alternative models for delivering value-added services. Some analysts doubt whether CS-4 will ever make it into products. 2.8.4

Beyond CS-4

It looks like CS-4 is the end of the line for IN standardization. The ITU has not expressed any intentions to produce a CS-5 standard, no doubt a consequence of the disappointing results of CS-3 and CS-4 standardization. The Internet, mobile networks, liberalization of the markets, and new programming technologies are challenging the IN concept. A surprising number of ad hoc groups have sprung up in industry, not only to try and solve technical problems but to push certain commercial and strategic interests. Examples of such industry groups and their initiatives are as follows: ◗

JAIN, which promotes a Java framework for implementing valueadded services;

◗

Parlay, which produces interfaces for opening up network control to third-party software;

◗

OSA, 3GPP, and ETSI’s proposed service architecture for thirdgeneration (3G) mobile networks;

◗

TINA, a complete telecommunications architecture built on distributed object-oriented middleware.

This book is dedicated to the forces that are shaping the next generation of network intelligence solutions, and in the chapters that follow we will be taking a closer look at all of these new initiatives.

70


In spite of industry initiatives, IN is alive and kicking and will remain that way for the foreseeable future. Although limited in scope to telephony, IN is a proven concept. No matter how many new industry groups come up with new ideas, there does not appear to be a satisfactory alternative to IN, at least for good old telephony.

2.9

Implementing IN

So far we have been investigating the definition of IN as it appears in the standards. But what do the products based on these standards actually look like? How do Lucent, Alcatel, Ericsson, and other telecommunications manufacturers implement the IN standards? And is it possible to connect an SSP from one manufacturer to an SCP from another? In this section we will consider a practical example: the Alcatel IN platform. The choice of Alcatel is arbitrary; we could have chosen any other manufacturer’s product. The choice is simply motivated by the fact that Alcatel’s product offer is complete, state-of-the-art, and typical of IN products on the market. 2.9.1

Alcatel IN

Alcatel, like most manufacturers, does not have a single IN product, but a line of products that can be configured into many different IN configurations. Alcatel’s IN uses hardware and software that is commercially available from third parties: Compaq and Sun processors, Unix operating system, and Oracle database. An example Alcatel SCP configuration is shown in Figure 2.22. This is a typical configuration sold to customers with high traffic requirements, although if necessary the SCP can be scaled up even further. The Alcatel SCP can consist of several machines. A typical SCP configuration consists of two front-end processors (FEPs) and two to four back-end processors (BEPs). The FEPs are the machines that terminate the SS7 connections and run the SS7 protocols. They are effectively SS7 signaling points. The BEPs run the actual service software and can be considered the heart of the SCP. The FEP-BEP configuration was chosen for three reasons: 1. Performance. Separating the SS7 protocol processing from the service processing gives the configuration better performance. The


71

Memory channel

BEP

BEP

BEP

BEP

Ethernet DB FEP

FEP

Service control point SS7 network

Figure 2.22

Alcatel SCP architecture.

FEPs can also balance the load between BEPs, thus avoiding the possibility that the machines will become overloaded. 2. Scalability. If you need more processing power, you simply add a BEP. 3. Reliability. The FEPs and BEPs are always paired for redundancy. If a machine goes down, the other still guarantees that the system continues functioning. The FEPs and BEPs are interconnected by a fast Ethernet, which can also be duplicated to ensure system reliability. The BEPs contain a database that is kept completely in memory for reasons of performance. The databases of the BEPs are synchronized periodically with a master database on disk, which resides in the SMP. The BEPs can be synchronized between each other by a memory channel, a fast connection that allows memory to be shared among machines.

72


When the IN platform is deployed, the SCPs are usually deployed in mated pairs in hot switchover mode. In other words, if one of the two SCPs goes down, the other automatically takes over. It is easy to imagine that such an IN platform can become very costly: Each SCP can consist of several physical machines plus software and infrastructure. Alcatel offers a range of smaller configurations for different needs. The Alcatel Service Node is intended for the smallest operators and contains all the IN functions in a single physical box: The SSF, SCF, SMF, SDF, and SRF are colocated in one physical node. Alcatel also sells intermediate platforms in which the SCF, SMF, SDF, and SRF are colocated in the same machine, but separate from the SSF. Figure 2.22 corresponds to the full IN solution: SSF, SCF, SMF are all separate machines. These different configurations actually run the same software; they differ only in processing power. It is possible to use the same services developed, for example, for the service node and run them on the full IN platform discussed above, and vice versa. This allows operators to grow with their markets without having to reimplement services. The Alcatel IN platform includes an SCE for producing service logic programs from SIBs. Figure 2.23 shows a screen shot of this SCE: It offers a palette of SIBs and a work area in which the service creator can drag and drop SIBs and connect them together.

Figure 2.23

Screen shot of the Alcatel SCE.


73

The Alcatel SCE (A8695) currently includes more than 100 SIBs, many more than the 14 specified in the CS-1 standard. Many of these SIBs represent functionality that can be reused in different services (for example, time- or origin-dependent routing), but for which no basic SIB exists in CS-1. This strongly illustrates the need for HLSIBs (see Section 2.7.2) that can be composed from more elementary components. Like many other manufacturers, Alcatel effectively splits the servicecreation function in two levels: service engineering and service customization. The screen shot shown in Figure 2.23 comes from the service engineering tool: This tool is normally only used by skilled engineers who know about the network. The service customization tool allows operators to tune their services and can be used by nonspecialists. It lets the user decide how to complete or filter a call depending on its origin, the dialed number, date, and time, but it does not allow the creation of new services. Alcatel calls this tool the light SCE. Other manufacturers, such as Fujitsu, Ericsson, Lucent, Nec, Nokia, Nortel, Siemens, Telcordia, and others, offer similar IN platforms. Most of these share similar characteristics, especially when it comes to the SCE: Most offer rich palettes of tens or even hundreds of SIBs. There is now also a growing business of smaller manufacturers that build service nodes and IN platforms, like Teligent (Sweden) and Comverse (the United States). Recently, Alcatel began using the name Open Service Platform (OSP) for its IN product line, and the company is adding new components that are not exclusively IN. An important extension is the Parlay-OSA6 gateway, which opens the platform to third-party service provisioning. This move is typical (many other vendors are doing the same) and shows that IN CS-3 and CS-4 have failed to keep up with the industry’s requirements. 2.9.2

Multivendor IN products

In theory it is possible to connect an SSP from one manufacturer (for example, Lucent) that speaks standard INAP to an SCP from another manufacturer (for example, Nokia). Unfortunately, in practice this is not the case. Although the syntax of INAP was unambiguously defined in the IN standards, there was much confusion about how to interpret the meaning of the different messages. Many manufacturers also tried to make

6.

More about Parlay and OSA can be found in Chapter 5.

74


their implementation more efficient or more powerful by adding their own messages to the protocol. As a result, an IN system from one manufacturer usually does not understand the messages from another. In the first 5 years of the existence of IN, there were hardly any IN products on the market that completely followed the INAP definitions. There was no hope of interconnecting any two IN systems unless a manufacturer explicitly made the effort to implement the protocol messages of the other manufacturer. Coming back to the Alcatel example, the Alcatel SCP can work with the switching equipment of Ericsson, Siemens, Marconi, and other vendors, but this requires that Alcatel adapt their equipment to the INAP dialects of the other products. This situation improved when ETSI defined core INAP, a more rigorously defined version of INAP that stripped away much of the ambiguous details. ETSI also resolved some of the ambiguities in the ITU recommendations for INAP by specifying all of IN in SDL. Since INAP is far less ambiguous now, manufacturers have also started to respect the standards more than they did previously. One of the consequences is that recently a whole range of small companies have started to build IN platforms. Many of these companies do not actually manufacture switches, but only sell IN systems to be used with other manufacturers’ switching equipment.

CHAPTER

3 Contents

IN and the Internet

3.1 IP, the Internet, and the Web: Defining terms 3.2 Intelligence on the Internet 3.3 Interaction between the Internet and IN 3.4 Managing services via the Internet

The Internet had existed for more than a decade when IN was standardized in the early 1990s. In the early years the Internet was regarded primarily as a network for scientific institutions. This changed in the 1990s when it started becoming a common tool for exchanging data between companies and institutions. The Internet today connects millions of networks and computers. The Internet is built on principles completely different from those of the public switched telephony network. It has its own network intelligence, which is similar to IN in some aspects and very distinct in others. The fast growth of the Internet in the second half of the 1990s caused problems with respect to the definition of IN. When the first IN standards became public in 1993 the Internet was not considered to have any relevance in telephony. The CS-1 standard does not take the Internet into account. Yet the Internet was changing the world at the very moment when the first IN platforms and services were being deployed by operators. Operators and manufacturers soon began thinking of ways to use the Internet in IN. 75

76


By the time CS-3 was specified, it was clear that the Internet had to be taken seriously, and that it could no longer be seen as something isolated from telephony. Many operators and manufacturers already started making their IN platforms Internet ready with proprietary solutions, and standardization bodies began struggling to keep up with the pace at which new ideas to combine IN and the Internet were springing up in industry. The following sections discuss what intelligence means in the Internet, and how IN and the Internet interwork.

3.1

IP, the Internet, and the Web: Defining terms

Considerable confusion exists about what the Internet, the World Wide Web (WWW), and IP are, exactly. Many people tend to use these terms as synonyms. We often hear the Internet and the WWW being talked about as being the same thing. Likewise, the Internet and IP networks are indistinguishable to many people. So, before continuing it may be useful to define a few terms. 3.1.1

IP

IP is a protocol that sends data through the network in the form of packets, or datagrams, as they are sometimes called in IP terminology. These packets consist of two parts: a header containing information about the origin and destination of the packet, and the content of the packet, which is filled by the application. The source and destination of an IP packet are defined by an IP address. An IP address is a 32-bit number, but for practical purposes it is typically represented by four decimal numbers, each between 0 and 255; for example, 194.140.170.11. Although 32 bits allow for the addressing of many networks and computers, the explosion of the Internet has already caused a shortage of addresses. Packets are routed through the network by specialized machines called routers. When a router receives a packet, it looks at its header to determine the destination, and consults a routing table to decide where to route the packet next. The next destination for the packet may be the destination computer, or it might be the next router on the path to the destination. The principle of IP routing is illustrated in Figure 3.1. IP is the protocol used by routers to send data from one point to another, but there are many things that IP does not do. It does not

IN and the Internet

77

123.87.33.1

“source=194.140.170.11 destination=123.87.33.1” Data Packet

Router 2

Header Content 123.87.36.2 Router 1 194.140.170.11

Routing table

Router 3

126.1.2.1 Figure 3.1

Principle of IP packet routing.

determine how to cut application data into packets. It does not recognize which packets belong to which application. It does not even guarantee that packets arrive at their destination. For this reason IP is seldom used on its own, but rather in combination with other protocols that take care of these additional necessities. These protocols are organized in layers, each of which takes care of a particular function. Figure 3.2 shows the IP protocol stack. The network interface layer represents the underlying physical network. It can use virtually any network technology. The only assumption that the other layers make about this layer is that it can transport data from one point to another. It does not have to be reliable, and it does not have to use packets. Examples of network technologies used in this layer are token ring local area networks, Ethernet, asynchronous transfer mode (ATM ) networks, X.25, or even ISDN. The internetwork layer provides a concept of a virtual internetwork consisting in reality of many interconnected networks. It defines IP for sending data through this internetwork. As already stated, IP is a relatively simple protocol that only takes care of routing packets of data from

Transport

Figure 3.2

...

UDP

Ethernet

...

X.25

IP

Internetwork

Network interface

FTP

TCP

ATM Token Ring

Applications

Others


SMTP Telnet

78

The IP protocol stack.

one point to another. It does not establish connections, it does not correct any transmission errors, it does not preserve the order in which packets are sent, and it does not guarantee that data arrives at the other end. There are also a few auxiliary protocols defined at the internetwork layer, such as ICMP, IGMP, ARP, and RARP, but we will not discuss those here. The transport layer provides the end-to-end communication facilities that allow applications to exchange data over the internetwork. The most important transport layer protocol is the Transmission Control Protocol (TCP). Seen from the application, TCP provides a reliable connection for sending a continuous stream of bytes from point to point. The following are some of the things that TCP does: ◗

Multiplexing. TCP ensures that several applications can communicate via IP simultaneously, and that the right data gets sent to the right application. For this, TCP implements the concept of logical ports, and assigns a different port number to each application.

◗

Stream data transfer. From the point of view of an application, it seems as though TCP provides a continuous data connection from one point to another. In fact, TCP cuts the data stream up into packets, which are forwarded to their destination by IP. TCP ensures that the data stream is reassembled in the right order at the receiving end.

IN and the Internet

79

◗

Reliable delivery. Using a system of acknowledgment and retransmission of lost data packets, TCP ensures that all data arrives safe and sound at the other end.

◗

Flow control. TCP makes sure that the sender does not send packets faster than the receiver can receive and process them.

Because IP by itself does not provide these features, it is most often used in combination with TCP. For this reason, many people use the term TCP/IP rather than simply IP. There also exists a protocol called the User Datagram Protocol (UDP), which only makes sure that packets are sent to the right application, but does not provide the facilities for a secure byte stream connection. UDP is more efficient than TCP because it does not have the overhead needed for ensuring that packets arrive at the other end. It is sometimes used by applications that need high transmission speeds but do not depend on the reliable transfer of packets. The application layer contains all the protocols that are specific to applications communicating over IP. There are many application-layer protocols, such as for e-mail (SMTP, POP3), remote login (telnet), file transfer (FTP), distributed object computing (IIOP), security (SSL, IPsec), directory access (LDAP), network management (SNMP), and many, many more. New application protocols continue to be defined. One of the application-layer protocols that has had a dramatic impact on the development of the Internet is the Hypertext Transfer Protocol (HTTP). The hypertext concept (which refers to text with links) was introduced around 1991, and HTTP was designed to send and receive text pages and link text over TCP/IP connections. One of the first browsers to become popular was Mosaic, introduced in 1993. Mosaic was soon followed by Netscape in 1994 and by Microsoft’s Internet Explorer, both of which have undergone continual improvements. 3.1.2

Routers and gateways

The language of the Internet is replete with technical jargon referring to machines, terms such as hubs, bridges, routers, gateways, and firewalls. Unfortunately, these terms are often used in a confusing way. It is not difficult to understand the function of the machines they refer to, if one keeps IP layering in mind. Hubs and bridges are equipment that connect parts of local area networks (LANs) at the network-to-interface layer. This equipment is

80


network specific: In principle you cannot connect an Ethernet hub to an ATM network. Hubs and bridges are not visible at the IP level. In other words, an IP packet will cross a hub or bridge as if it were just a wire. Since hubs and bridges are transparent to IP, they do not usually have IP addresses and you cannot send packets explicitly to them. As explained in the previous section, the router is a key concept at the IP level. A router receives and forwards IP packets according to the address in the packet header. Routers typically connect different networks. They are the glue with which an internetwork may be built out of separate networks using different transmission technologies. A gateway is a machine that connects networks at the application layer. Gateways usually do some kind of translation between addresses or application data. A mail gateway, for example, is used to send mail between two IP networks that use different mail protocols. For IP, a gateway is a machine like any other machine that packets can be sent to. A gateway is not only visible at the IP level, in many cases it is even opaque: you can send IP packets to the gateway but not directly to addresses in the network that lies behind it. Figure 3.3 illustrates the separate roles of bridges, routers, and gateways. A firewall is a special kind of gateway that is used to restrict access to a network from outside. It can use white lists and black lists to block traffic to and from certain addresses, and it typically supports some form of user authentication. Firewalls are commonly deployed to protect corporate networks from security breaches from outside.

Gateway

Router IP link Not visible

Bridge Figure 3.3

Function of bridge, router, and gateway.

IN and the Internet

3.1.3

81

Creation of IP standards

The Internet is simply the interconnection of data networks on a worldwide scale. It is not governed by any national or international regulatory body. There are no laws regulating who can provide what. This is completely opposite to telephony networks, which are regulated by government in almost all countries of the world. Of course, it is impossible to interconnect networks on a worldwide scale without establishing some kind of standard that everybody agrees with. These standards are set by the Internet Society (ISOC). As its name suggests, this organization is not a regulatory or juridical body. The Internet Society is managed by the Internet Architecture Board (IAB) and further consists of the Internet Engineering Steering Group (IESG), IETF, and the Internet Assigned Numbers Authority (IANA). The IESG manages the standards procedure for Internet protocols and is supported by the IETF for technical advice. The IANA assigns the parameter values for protocols and ensures that these values are consistent among all protocols. Assignment of TCP and UDP port numbers for applications is an example. The IETF consists of areas and working groups (WGs). Working groups are responsible for proposing and evaluating new standards. They are created on demand and correspond to specific technical issues. A working group’s life span is finite, and is usually terminated when the task is accomplished or when the issues it covers are no longer relevant. Although the IETF working groups are the main source of new standards, anyone can propose a new protocol. A proposal must be submitted in the form of an Internet draft (ID) document to the IESG, who will study the need for the new protocol, its feasibility and technical soundness. If the IESG reaches a positive conclusion, it publishes a formal request for comments (RFC) for the new protocol. People within and outside the IETF can then comment on the protocol and propose improvements or alternatives. When the revision cycle is complete, the IAB decides on approving the standard. If approved, the standard receives a standard number preceded by STD. Internet protocols can have different degrees of importance. A required protocol must be implemented in all IP equipment and networks. A recommended protocol is not mandatory and should be implemented only if possible. An elective protocol is optional; it may or may not be supported by the network. A limited use protocol is intended only for restricted environments, for example experimental prototypes or

82


highly specialized networks. Table 3.1 shows a few important protocol standards and their status. 3.1.4

Connecting to the Internet

In the mid-1990s, people started connecting to the Internet by subscribing to an Internet service provider (ISP). Conceptually, an ISP network is no different from any other network connected to the Internet, and a PC connected to the Internet over the telephone line is no different from a PC in a company LAN. The only distinction is in the way of connecting and in the transmission medium. Many homes connect to the outside world only via telephone lines, the only possible way that they can then connect to the Internet. A classic telephone line is a twisted pair of copper wires designed for carrying analog signals up to a frequency of 3 kHz, enough to transmit voice. Telephone lines are not made for transporting packets of data, so if we are to transport bits and bytes over the telephone lines, these must be translated into an analog signal. This is done by a modem, which converts bits into tones (modulation) and tones into bits (demodulation). When you connect to the Internet, there are always two modems involved: one connected to your PC and one on the side of the ISP. Analog modems nowadays support transmission speeds of 56 Kbps. Of course, an ISP that has many subscribers must rent many phone lines and have many modems. The group of modems of an ISP is usually called a modem bank, and the modems associated to a particular phone number are called a point of presence (PoP). The ISP network is illustrated in Figure 3.4. Table 3.1 Protocol Standards and Their Status Protocol

Name

Status

IP

Internet Protocol

Required

UDP

User Datagram Protocol

Required

TCP

Transmission Control Protocol

Required

FTP

File Transfer Protocol

Recommended

TELNET

Remote login

Recommended

SMTP

Simple Mail Transfer Protocol

Recommended

POP3

Post Office Protocol

Elective

HTTP

Hypertext Transfer Protocol

Elective

IN and the Internet

83

Point of presence (PoP) Modem

HTTP server

Modem

Modem Telephony network

Modem

TCP/IP

Modem Modem To Internet ISP network Figure 3.4

Connecting to the Internet over the telephone via an ISP.

With the opening of telecommunications markets, many new technologies enabling connection to the Internet have become available. ISDN provides circuit-switched digital connections over the existing telephone wires. An ISDN subscriber line, like a conventional line, is connected to a telephony switch and a connection is set up by establishing a circuit. The difference is that this circuit now carries digital, not analog, signals. It is therefore better suited for data connections. The asymmetric digital subscriber line (ADSL) also uses the existing telephone lines, but off-loads Internet traffic from the telephony network at the central office exchange. ADSL requires a special modem both at the side of the subscriber and at the central office. ADSL is called asymmetric because it was designed for Internet browsing, video on demand, and other applications in which downstream traffic is greater than upstream traffic. It is also possible to use the television cable infrastructure for Internet access. Access via the television cable therefore requires a cable modem at both ends. When using the television cable, all Internet users must share the capacity of a cable segment between themselves and with the television channels. Very-high-rate digital subscriber line (VDSL) and digital home network (DHN) provide high data speeds by using optical fibers up to distribution points close to the home or office. The telephone line is used only

84


for the last stretch. The local multipoint distribution system (LMDS) is the wireless alternative to the local loop. It provides permanent wireless connections between homes and offices and a distribution point. Satellite networks will be competing with earth-based access networks in the very near future. Low-Earth-orbit (LEO) systems such as Skybridge (Alcatel) and Teledesic (Boeing, Motorola, Bill Gates, and others) are expressly targeting the consumer market for Internet access. They promise ubiquitous access to the Internet at high data rates, even in areas where laying copper, coaxial cable, or fiber optics would be infeasible or too expensive. Cellular networks such as GSM, DAMPS, GPRS, and UMTS are also emerging as important mediums for accessing the Internet. They are in fact so important that we will devote Chapter 4 to discussion of them. In the near future, homes and offices will connect to the Internet through new access technologies like the ones discussed above. The speed at which people can interchange data over the Internet will increase. Still, the telephone line will remain the most widely available communication channel for many homes for some time to come.

3.2

Intelligence on the Internet

The Internet differs in many ways from telephony networks. It is not a single network, but rather a network of networks. It is not administered by a central operator. It was invented for data communications, not for voice communications. Communication is not achieved by the establishment of voice circuits, but by the routing of packets of data. IP addresses and telephone numbers differ in format, scope, and in the way that they are assigned. You could say that intelligence is everywhere and nowhere in the Internet, depending on how you look at it. TCP/IP is about routing packets from one point in the network to another. It involves some basic information to route packets from one router to another, but it is fair to say that IP networks are rather dumb. On the other hand, the Internet is very much about interconnecting data networks. These data networks consist of clients and servers that provide information and applications to people and machines. If one looks at it this way, the Internet is very intelligent. In fact, it depends on what level in the IP protocol stack is being considered. IP networks have almost all the intelligence on the application layer.

IN and the Internet

85

The IN conceptual model discussed in the previous chapter was invented for voice telephony networks, and unfortunately it cannot be applied to the Internet in a straightforward way. Yet there are Internet applications that can be regarded as Internet equivalents to IN services. One example is the domain name system (DNS). IP addresses are not easy to understand, so many applications use a friendlier way of addressing servers in the Internet. The most common way is by using domain names, such as artechhouse.com or tecsidel.es. The mapping from domain names to IP addresses resembles the way that an SCF translates an easy-to-remember freephone number [e.g., (800) 123-1234] to a subscriber telephone number. Number blocking services also have equivalents in the Internet. The role of a firewall is to filter traffic coming in from and going out to the Internet based on the IP address, TCP port, or application that the packets come from. Although there are many features of IN that can be recognized in the Internet, there is one important difference. In IN these features are centrally controlled from the SCF. In the Internet they are completely distributed through the network. Each company may have its own firewall, and each ISP can dynamically assign IP numbers. The Internet is essentially distributed where IN is centralized. There are also a few IN features that simply do not make sense in the Internet. One of them is charging features. In the Internet there is traditionally no notion of charging for a connection. So services such as freephone or calling card calls simply do not make sense in the Internet. Another example is a service, such as forward on busy or automatic call back. If there are no calls, then these services are without meaning. All of this, of course, changes when we start using the Internet infrastructure for telephony, and when we define the notion of calls in the Internet. And this is exactly what has been happening recently. 3.2.1

Voice, video, and multimedia over the Internet

The Internet was born as a network of data networks. Even though some LANs are also used for local telephony, the IP protocols were not designed with telephony in mind. TCP/IP was designed for communicating data (files, e-mails, Web pages) between servers and clients. It breaks the data up into packets and routes them to their destination, where they are reassembled and passed to the receiving application. But why should voice or video be different from data? If a voice signal can be translated into bits and cut up into packets, IP routers should

86


be able to deal with it as they do the routing of a file or a Web page. Devices that translate voice signals to bits indeed exist and are called codecs (coder-decoder). There are several standard technologies for voice coding and decoding. Some examples are given in Table 3.2. The codecs in Table 3.2 differ in the quality of the voice encoding, the processing power and delay involved in the encoding and decoding process, and in the suitability for cutting the streams into packets. For example, G.711 is a codec for high-quality voice used in ISDN, while G.729 requires much lower bit rates but also offers lower-quality voice. Similarly, codecs exist for encoding and decoding video, for example ITU-T standards H.261 and H.263. If the Internet is to be used for telephony, then there is also a need for a protocol that sets up a call between two computers or telephones. Why would it not be possible to use SS7? The problem lies in the fact that SS7 negotiates the setup of switched circuit connections. In other words, the SS7 messages are specific to switching, and are not suitable in a packet environment. As SS7 could not be used directly, new protocols were invented for setting up voice calls over the Internet. In the following sections we will discuss the most important three: H.323, SIP, and MGCP. 3.2.2

H.323

H.323 is an ITU-T standard for providing voice and multimedia services over packet networks. Note that we say packet networks and not Internet. H.323 is intended for any packet-based network, whether it be a LAN or the Internet. The first version of H.323 dates from 1996. H.323 is a member of the H.32x family of ITU-T protocols for multimedia communications. Whereas H.323 deals with multimedia over packet networks, other H.32x protocols deal with multimedia over other

Table 3.2 Codecs

Standard

Bit Rates (Kbps)

G.711

64

A-law and µ-law pulse code modulation (PCM)

G.726

32

Adaptive differential pulse code modulation (ADPCM)

G.728

16

Low-delay code-exited linear prediction (LD-CELP)

G.729

8

Conjugate structure algebraic-code-exited linear prediction (CS-ACELP)

Technology

IN and the Internet

87

types of networks. Table 3.3 shows some of the brothers and sisters of H.323. H.323 is not a single protocol but a framework that refers to several other standards for multimedia communications. It is general in nature and can be used for any combination of voice, video, and data communications. H.323 supports both point-to-point and multipoint communications. The most important protocols used within the H.323 framework are shown in Table 3.4. All of these protocols were defined by the ITU-T except RTP and RTCP, which are Internet protocols. An H.323 terminal can be a computer with a sound card and equipped with one of the codecs mentioned in Table 3.4 (G.711, H.261), or it can be a special device such as a telephone equipped with the necessary codecs and protocols. In addition to the terminals, H.323 can involve the following auxiliary components: ◗

Gateways. As explained in Section 3.1.2, a gateway connects two different networks in a nontransparent way and takes care of translating data in the format required in each network. One of the most common gateways used in H.323 is a telephony gateway, which connects the packet network to the switched telephony network. Through the telephony network it is possible to make calls between the packet network and the telephony network.

◗

Gatekeepers. The gatekeeper forms the brain of the H.323 network. It takes care of registration, admission, status, addressing, signaling, and billing. It is not mandatory to have a gatekeeper in H.323, but many networks use them. Whereas gateways have a general meaning with respect to the Internet, gatekeepers are a specific H.323

Table 3.3 H.32x Protocols for Multimedia Communications Standard

Scope

H.320

Multimedia over ISDN

H.321

Multimedia over broadband networks (e.g., ATM)

H.322

Multimedia over LANs with guaranteed QoS (e.g., X.25)

H.323

Multimedia over packet networks (e.g., IP)

H.324

Multimedia over switched telephony networks

88


Table 3.4 Protocols Used in H.323 Protocol

Purpose

H.225

Registration, admission, and status (RAS), call signaling

H.245

Control signaling

H.261, H.263

Video coding

G.711, G.729, G.723.1

Audio coding

T.120

Data conferencing

RTP, RTCP

Real-time streaming

concept. In terms of Internet terminology, a gatekeeper is simply a server like any other. ◗

Multipoint control units (MCUs). MCUs are used in multipoint communications. They negotiate the codecs to be used and take care of mixing and distributing the audio and video streams of the participants.

The simplest case of a H.323 call is when two terminals set up a communication directly between each other without any intermediary node involved. In this case the terminals must know each other’s address, they must be able to access each other directly, and they must use the same media encoding. In many cases, however, an H.323 call will have to be assisted by a gatekeeper. A typical H.323 call-setup procedure involving the gatekeeper goes through the following phases: 1. Call establishment. The terminal that places the call registers with the gatekeeper and requests that the call be set up to the destination. When the destination terminal is notified of the call, it registers with the gatekeeper as well and confirms the connection. 2. Control signaling. Once the two terminals are in contact, they can negotiate which codec and ports to use. Once agreement is reached, the terminals open and connect their logical media channels. Note that these channels are logical because the communication takes place in a packet network. There is no such thing as a physical channel or connection.

IN and the Internet

89

3. Media streaming and control. When the setup phases are complete, the two parties can exchange voice, video, and data. In this phase the two terminals can also exchange RTCP control messages (for example, to adjust transmission speeds). 4. Call release. The communication is ended by an exchange of endof-session commands. Both terminals then deregister from the gatekeeper. The H.323 gatekeeper is an intelligent node that can be compared in many ways with an IN service node. In the following section we will explore this comparison further. 3.2.3

H.323 and IN

The H.323 gatekeeper has a role in signaling and has many intelligent functions similar to that of the SCF in IN. The gatekeeper functions that resemble IN features are as follows: ◗

Address translations. The gatekeeper translates telephone numbers to network addresses and vice versa, in case a call is made across a gateway between an H.323 terminal in a packet network and a telephone in the telephone network.

◗

Admission control. The gatekeeper takes care of RAS of H.323 terminals. ITU-T recommendation H.225 describes the protocol for this.

◗

Call authorization. The H.323 gateway can screen calls based on the identity of the originating or destination party, time, date, and so on.

◗

Accounting and billing. The H.323 gatekeeper can do accounting and billing for communications it controls.

◗

Call management. The gatekeeper keeps track of the calls in progress and calls being set up, and uses this information to process calls. For example, it can redirect call attempts to busy terminals, or redirect calls to terminals that do not reply.

The gatekeeper functions cover most of the IN features mentioned in Section 2.3. Table 3.5 shows which gatekeeper function implements which IN feature.

90


Table 3.5 H.323 Gatekeeper Functions and IN Features Gatekeeper Function

IN Features

Address translations

Abbreviated dialing, one number, personal number, private numbering plan

Admission control

Authentication

Call authorization

Originating call screening, terminating call screening, call gapping, closed user group

Accounting and billing

Calling card call, prepaid call, premium rate, reverse charging

Call management

Call forwarding on busy, call forwarding on no reply, call waiting, call hold, call queuing, call transfer, meet-me conference

Given the close relationship between the functions of the H.323 gatekeeper and the IN SCF, it makes sense that the two should interwork. Figure 3.5 shows how an H.323 gatekeeper and an IN SCF can be interconnected to allow IN control of calls between packet and telephony networks. There is no fixed architecture for interconnecting gatekeepers and SCFs, and several scenarios are possible. In one scenario the gatekeeper can play the role of an SSF by emulating the basic call state models (for originating and terminating calls) and triggering the SCF for the processing of services. This mechanism can be used, for example, for completing calls from packet networks to freephone numbers. H.323 gatekeeper

INAP

SCF

SDF

SSF Internet

Figure 3.5

H.323 gateway

Telephony network

Interworking between an H.323 gatekeeper and IN SCF.

IN and the Internet

91

In an alternative scenario, the SCF delegates control to the gatekeeper. This can be necessary for implementing services such as automatic callback across the gateway. The interactions between the SCF and the gatekeeper can follow the standard INAP dialogues defined in the IN standards. The gatekeeper also has certain intelligent functions that have significance with respect to the Internet but not in telephony networks. A telephony network has a fixed bandwidth per line. This is not the case in packet networks, where the number of packets and bits transmitted per second can be subject to the network load. An H.323 gatekeeper can instruct terminals or gateways to adjust bandwidth use. Note that the gatekeeper does not control the bandwidth itself. This is done in the gateway or in the terminals. Nor does the H.323 standard specify how bandwidth is controlled. It only specifies the messages that can be used to request bandwidth adjustments. The quality of service (QoS) is related, but not equivalent, to bandwidth. QoS depends only partly on bandwidth, and must generally be seen in relation to a particular application. For example, voice communications tolerate some packet loss but do not tolerate large delays. On the contrary, file transfers tolerate delays but do not tolerate packet loss. The parameters that determine the quality of service are different for each service. The issue becomes even more complicated when human perception is taken as the criterion. The QoS is fixed in telephony networks, but not in packet networks. Service level agreements define the QoS that a given user can expect for a given subscription, and specify the compensations when the expected quality is not delivered. Managing the QoS becomes increasingly important as the Internet becomes more commercial. H.323 gatekeepers do not address QoS aspects, but very often manufacturers of gatekeepers and gateways try to include some QoS features as simple extensions to bandwidth management. The telephony network is considered secure because it is managed by trusted operators (although one could argue that in fact it is not secure at all). Packet networks, on the other hand, are in general sensitive to eavesdropping or manipulation of packets. This is especially true for the Internet, where any intermediate router can intercept, investigate, or manipulate traffic. There are many aspects to security, and the H.323 gatekeeper deals only with a few of them. H.323 is a complete standard that supports any kind of multimedia communication over any packet network, in any point-to-point or

92


multipoint configuration. For this reason H.323 is also rather complex. H.323 originated from the telecommunications world (ITU-T) and is often criticized by the Internet community (IETF) as being overly complex for the purpose it serves. IETF therefore came up with a much simpler protocol that they claim is more suitable for use in Internet: the Session Initiation Protocol (SIP). 3.2.4

SIP

SIP originates from the Multiparty Multimedia Session Control WG (MMUSIC) of the IETF and forms part of a group of protocols for setting up multimedia conferences over the Internet. SIP is somewhat younger than H.323. The MMUSIC group put it up as an RFC in March 1999. Since then, SIP has become so popular that the IETF created a special SIP WG to continue work on the protocol. SIP is an application-layer Internet protocol based to a large extent on HTTP. As in HTTP, its messages are plaintext, and the protocol follows the pattern of requests going from client to server, and responses coming back from server to client. SIP uses e-mail-like addresses to identify users. A SIP address takes the following form: sip:[email protected] (e.g., sip:[email protected]). Since SIP is based on HTTP and its addresses are like e-mail addresses, SIP requests can be embedded in Web (HTML) pages. This allows for SIP sessions to be started by clicking on text or pictures in a Web page; e-mails can be sent from Web pages in the same way. One of the strong points of SIP is that its request and response messages are very straightforward. In fact, there are only six main requests in SIP. They are shown in Table 3.6. Table 3.6 SIP Requests Request

Meaning

Register Registers location and capabilities of a terminal to a SIP server Invite

Invites a user to a session

Ack

Final acknowledgment that the session is to be established

Options

Requests information about terminal capabilities

Bye

Terminates a session

Cancel

Cancels the setup of a session

IN and the Internet

93

Response messages follow HTTP format, and are also straightforward. As an example, Table 3.7 shows several responses that are frequently used in SIP. A SIP request has a very simple structure. It consists of a request header followed by a request body. The following example shows a SIP request header for a call from [email protected] to [email protected]. INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 216.112.6.38 From: sip:[email protected] To: sip:[email protected] Contact: sip:[email protected] Call-ID: [email protected]

The first line is the request line; it specifies the type of request, in this case an invitation. The subsequent lines are header lines. The To: and From: lines are self-explanatory. The Contact: line is used if a reply must be sent to an address different from the originating client, as in e-mails. The Call-ID: line provides a unique identifier for the session. If the request is routed via an intermediary server, this server may insert a Via: line (second line in the example above) to record that it has been on the path to the destination. The role of intermediary SIP servers will be explained later in this section. A SIP request body can contain any type of information, including file attachments. It is typically used to transport a description of the session to which a user is invited. Such session descriptions are usually done in the IETF Session Description Protocol (SDP). Using an SDP payload in

Table 3.7 Frequently Used SIP Responses Response

Meaning

Trying

The current request is being processed, but the status of this processing is unspecified

Ringing

The destination user has been located and alerting is attempted

OK

The current request has succeeded

94


the SIP request body, a party can be informed about the parties involved in a session and the media capabilities required. SDP session descriptions are simple lists of lines = that can be used to specify the initiator or owner of the session, the session name, the session start and stop time, the type of media (voice, video, data), the transport protocol used (RTP, H.320, X.25), media coding (H.261, MPEG), the IP address and TCP or UDP port number for the media stream, and even an Internet address where a more detailed description of the session can be found. Table 3.8 gives an SDP session description for the SIP invitation example presented above. 3.2.5

SIP clients and servers

SIP is a protocol that specifies requests coming from clients and responses coming back from servers. There are several types of clients and servers in SIP, as listed below: ◗

User agent client: the software in the terminal that initiates a session initiation request;

◗

User agent server: the software in a terminal that handles incoming SIP requests;

Table 3.8 Example SDP Session Description SDP Session Description

Meaning

v=0

Version number

o=Zuidweg 3321578898 IN IP4 194.140.170.11

Session owner: name, session identifier, and address

s=SIP and SDP course

Session name

i=Teletraining session for SIP and SDP

Information about the session

[email protected]

E-mail address

c=IN IP4 194.140.170.15/127

Connection address

a=recvonly

Media attribute (receive only)

m=audio 49170 RTP/AVP 0

Media description: media name, port number, transport protocol, media format

IN and the Internet

95

◗

Proxy server: an intermediate node that processes SIP requests, and can perform user location, address translations, security screening, or any other type of processing on the SIP request;

◗

Redirect server: a server that translates the destination address for an SIP request and sends the result back to the client;

◗

Registrar: a server that registers terminals.

A proxy server takes an incoming request and forwards it to another server. It can do any kind of processing on the request before sending it onward. It can, for example, translate the destination address (equivalent to call forwarding), or simply refuse the request (equivalent to call screening). It can even multicast the request to several new addresses. The next destination can be a terminal, but it can also be another proxy server or redirect server. What the proxy server does with the request, and where it forwards the request, depends completely on the application that runs on the proxy. Note that a proxy server acts both as a server (to the client that sent the original request) and as a client (to the server to which it forwards the request). A client does not necessarily know that there is a proxy server in between itself and the destination server; in this sense a proxy server can be transparent to a client. The redirect server has a somewhat more specific function. It translates the destination address of an invite request and sends the result back to the requesting client. It is up to the client to decide what to do with the result and how to proceed with the call setup. Because the redirect server sends a request back to its origin, it is not transparent to the client. While proxy servers, redirect servers, and registrars are defined as different functions, they are in practice often colocated in the same machine. It is particularly common to see a registrar and proxy server combined into one. A machine that combines one or more of these server functions (proxy, redirect, or registrar) is often simply called an SIP server. To see how proxy servers and redirect servers cooperate to provide intelligent call processing, consider the example in Figure 3.6. Suppose that user A wants to place a call to sip:[email protected]. The steps to set up this call, as shown in the figure, are as follows: 1. The UAC of terminal A sends the invite request to the SIP proxy of its Internet service provider.

96


Inv

ite

Redirect server

Proxy server

(1)

Inv

ite

(2)

UAC

A Figure 3.6

(3) New destination address

Proxy Invite UAS server (4) B

Example of a SIP call.

2. The ISP proxy server looks at the address, determines that it belongs to the Tecsidel intranet, and sends the invite request on to Tecsidel’s SIP proxy. 3. The Tecsidel SIP proxy first screens the originating and destination addresses for security. It concludes that it is a valid request but observes that sip:[email protected] is an alias that should be routed to different people depending on the time of day. It consults the redirect server for the right translation of the number. 4. When the Tecsidel SIP proxy gets back the answer from the redirect server on where to route the call, it sends the request on to its final destination. This is a very basic example, but it shows the great simplicity and flexibility of SIP. Note that the SIP protocol says nothing about the kind of processing that can be done in a proxy server. A call setup can go through any chain of proxy servers that do any kind of call processing. This means that SIP networks are highly scalable. A SIP proxy can perform any of the IN features, such as those for numbering, routing, charging, access, and restriction, but the mechanism of interaction with the call setup process is different. Figure 3.7 compares

IN and the Internet

97

IN SCF Screen

Translate

Trigger

Response

Call setup

SSF

Call setup

SIP Invite proxy server Figure 3.7

Invite (address screened)

Invite proxy (address server screened)

IN service processing versus SIP service processing.

how a simple service consisting of a call screening followed by a number translation is done in IN and in SIP. In IN the call setup is controlled by the SSF, which delegates control to the SCF for doing the processing. After the SCF has screened and translated, it hands back control to the SSF. In SIP the invite message is routed transparently from proxy to proxy, where each proxy can do a certain part of the processing. If you are familiar with the Unix pipe mechanism, this may look familiar. On the contrary, IN looks more like a remote-procedure-call mechanism. The most important difference between IN and SIP lies in the tightness of control over the call setup signaling. The SSF in IN keeps tight control of the call state through the BCSM. The SSF can delegate control to the SCF to do service processing, but control is always handed back to the BCSM afterward. In SIP there is no central entity that keeps tight control of the call signaling. A request can be routed to a proxy for processing, but the proxy simply sends the request onward after it has done what it has to do. Note that H.323 is somewhat in the middle. It resembles SIP in that calls can be set up directly from terminal to terminal, without intermediate nodes. On the other hand, the H.323 gatekeeper resembles the IN SSF-SCF combination, in that it can provide complete control of access, call setup, and call control.

98

3.2.6


H.323 versus SIP

SIP was intended to be lightweight, especially for use in the Internet. This stands in contrast to H.323, which is a general standard for multimedia conferencing over any packet network, covering a wide variation of protocols for signaling, call control, media control, and coding and decoding. Over the past years, SIP has become somewhat of a rival to H.323. Industry support has been traditionally stronger for H.323 because it is a few years older than SIP, and because Microsoft based NetMeeting on this standard. But now the tables appear to be turning in favor of SIP, which is regarded by some to be more efficient and easier to use. A lively debate has been taking place in industry and academia over whether H.323 or SIP is better for setting up telephone calls and multimedia communications over the Internet. The main differences between SIP and H.323 are summarized in Table 3.9. The first important observation is that SIP is a protocol, whereas H.323 is a framework that consists of several protocols. The most significant difference is that H.323 uses different protocols for signaling (RAS and call setup) and call control (negotiation of terminal capabilities, opening of media channels). SIP covers these functions in a single protocol. Moreover, H.323 contains the standards of the codecs to be used; SIP does not. There is probably no absolute answer to the question of whether SIP or H.323 is better; it simply depends on the environment and the application. It is true that SIP is significantly simpler than H.323. The highly flexible client-server model also makes SIP more scalable than H.323 where the functions of the gatekeeper have been more rigidly defined. On the other hand, H.323 is a more comprehensive standard that also covers gateway functions and codecs. In other words, H.323 is less Table 3.9 Comparison of H.323 and SIP H.323

SIP

Standard

ITU-T

IETF

Signaling

H.225

SIP

Call control

H.245

SIP

Media transfer

RTP

Any protocol

Signaling nodes

Gatekeeper

SIP server

Call management

Tight control, Loose control, keeps state stateless

IN and the Internet

99

restricted to the Internet setting and can support any conference call between different types of networks. H.323 gatekeepers and SIP servers have in common the fact that they can interwork with IN functions. In Section 3.4 we will look at some of these interworking scenarios in more detail. 3.2.7


One of the differences between H.323 and SIP is in the specification of gateways. H.323 describes a gateway as an intermediate node between different networks. SIP does not explicitly include gateways as intermediate nodes. Nor does SIP include MCUs such as those used in H.323 to bridge conference calls to multiple users. While SIP greatly simplifies things, it is sometimes useful to have an explicit model for managing media gateways. The Media Gateway Control (MEGACO) WG of the IETF is seeking to specify a general model for controlling media gateways. This model is the basis for the definition of the Media Gateway Control Protocol (MGCP). Like SIP, MGCP is situated in the application layer of the IP stack. It assumes that the delivery of messages is reliable, so it is most often used with TCP. The foundation for the specification of MGCP is a connection model that describes terminations and contexts. A termination is a point on the media gateway that receives or sends media streams. A point that sends a stream is called a source, and a point that receives a stream is called a sink, in multimedia jargon. A termination can be a physical port such as a telephony line, but it can also be a media stream of temporary nature, such as an RTP stream. In the latter case, the termination is called ephemeral. A termination is described by properties such as the type of media it can accept (for example, the bit rate and codec) and the type of events that it can detect (for example, start flow, stop flow, off-hook, and so on). A context describes how media flows between terminations in the media gateway. A special context called the null context contains all terminations that do not belong to any active context. A termination in the null context is not necessarily inactive, it is just not connected to any other termination. A termination can only be part of one context at a time. Contexts and terminations can be manipulated with MGCP commands. Table 3.10 shows a few of the most important of these. Sometimes it is necessary to group several actions into one indivisible transaction, to ensure consistency of the system state. For this reason

100


Table 3.10 MGCP Commands Command

Description

Add

Adds a termination to a context. If the termination is ephemeral, this command can be used to create the termination. If it is the first termination in the context, the context is implicitly created.

Subtract Disconnects a termination from a context. If it is the last termination in the context, the context is automatically deleted. Move

Moves a termination from one context to another.

Modify

Modifies the properties of a termination.

Notify

Reports events on terminations.

MGCP allows the manipulation of contexts and terminations to be transactional. To see how MGCP can be used to manipulate contexts, consider the example of call waiting, as shown in Figure 3.8. In this example, terminations 1 and 3 represent telephone lines, while termination 2 is an RTP stream. Figure 3.8 shows a typical scenario of a call between a telephony network and an IP network. In the top configuration, termination 1 is connected to termination 2. In other words, the users connected to termination 1 and 2 are communicating. A new call has just come in on termination 3, but it has not been connected to anything yet. The user on termination 1 can now decide to put the call to termination 2 on hold and take the call on termination 3. The resulting change in configuration can be created using the move command, as shown in the figure. There is a striking resemblance between the connection model for MGCP and the connection view state (CVS) of IN CS-2 (see Section 2.7.3, Figure 2.20). This is not a coincidence. MGCP was defined with the purpose in mind of facilitating the interworking between IP and telephony networks. The way MGCP models media stream associations in a gateway strongly resembles the connection view in a switch. 3.2.8

Soft switching

The strong resemblance between the MGCP connection model and the IN CS-2 CSV suggests that one could consider the combination of gateway controller and gateway as a kind of telephone exchange. From a logical

IN and the Internet

Termination 2 RTP stream

101

Context 1

Termination 1 PSTN line Old state

Termination 3 PSTN line

Context 2 Media gateway

move(termination 1, from: context 1, to: context 2)

Media gateway Termination 2 RTP stream

Context 1 New state


Figure 3.8

Context 2


Example of terminations and contexts for call-waiting scenario.

viewpoint there is not really a difference; the distinction is only in physical colocation. A telephony switch typically combines the hardware (a switching matrix), control software, and signaling termination in one box. In MEGACO the gateway control is separated from the gateway, with MGCP as the protocol between them. Figure 3.9 demonstrates how the architectures of a telephony switch and a gateway and gateway controller combination are related. A gateway controller is seldom used on its own. Apart from controlling the gateway it must talk to terminals and intermediary nodes to negotiate the setup of calls. The most common protocol used for this is SIP. But a media gateway controller may also need support H.323 or SS7 protocols if it controls a gateway to a H.323 or telephony network. The functions of media gateway controller and signaling server (whether it be a SIP proxy, H.323 gatekeeper, or SS7 signaling point) are

102


SIP, H.323, and/or SS7

SS7 Signaling termination Switch hardware

Telephony switch Figure 3.9

Media gateway controller MGCP

Media gateway Soft switch

Telephone switch and soft switch.

practically always combined. In comparing the left and right parts of Figure 3.9, one could conclude that a media gateway controller plus signaling termination is really a switch without the hardware. For this reason, it is often called a soft switch. Soft switches are a hot topic. The reason for their popularity is clear: Building a telephony switch required heavy investments in hardware and support for the extremely complex SS7 protocols. On the contrary, a soft switch is only software, and SIP has only a fraction of the complexity of SS7. Many start-up companies are now entering the soft-switch market, forcing the bigger companies to follow suit. Some analysts predict that soft switches mean the end of switching as we know it. A special forum for soft switching called the International Softswitch Consortium (often simply called Softswitch) was created in 1999. The importance of soft switching is demonstrated by the fact that Softswitch had more than 190 members by 2002. Its most important objective is to provide industry support for the soft-switching concept and its key protocols SIP, MGCP, H.323, and even SS7. We will discuss soft switching further when we talk about JAIN in Chapter 7.

3.3

Interaction between the Internet and IN

Up to this point we have seen how the Internet deals with network intelligence and how it compares with IN. In reality, telephony networks and

IN and the Internet

103

the Internet are not separate entities but are completely intertwined. Most of the general public accesses the Internet over the telephone line, as mentioned in Section 3.2. Some operators are beginning to offer telephony services over an IP network, using SIP or H.323 for signaling. It is not likely that switched telephony networks will disappear overnight, however. Telephony and the Internet will coexist for the foreseeable future. In this coexistence, almost any interworking scenario is possible. A call may start in a telephony network and end in an IP network, or vice versa. A call may start in a telephony network, go through an IP network, and end in another telephony network. These scenarios require the use of signaling and media gateways, as explained in Section 3.2.3. At the level of control, the combination of telephony and Internet creates a fascinating array of new possibilities for value-added services. In the following sections we will discuss these new initiatives. 3.3.1

PINT

Imagine the Web site of, say, an insurance company. The Web site will typically contain information about the products that the company offers, conditions and prices, packages and special offers, information about the company itself, and information on how to contact the sales department. If you consulted the Web site and wanted to speak to a company representative to receive more information, you would have to take note of the contact number (usually a free number), pick up the phone, and dial the number. It would be interesting for both the company and its customers if the Web site featured a call button. When the customer clicked on the button, the insurance company would automatically call the customer at its own expense. What is more, if the customer had registered his or her profile with the Web site or accepted a cookie, this information would automatically appear on the operator’s screen so that he or she could refer to the customer profile during the call. There are many ways of realizing such a service using a combination of an IN platform and a Web server. AT&T, Lucent, Nortel, and Siemens, for example, have come up with implementations of this. An IETF WG called Public Switched Telephony Network Internet Internetworking (PINT) has studied these implementations and decided to standardize a protocol for this type of interaction between IN and the Internet. Although PINT specifies an Internet protocol, not a specific service, the PINT work is driven by the following reference scenarios:

104


◗

Click-to-dial, which requests the setup of a telephony call via the Internet. The call example above is an example of click-to-dial.

◗

Click-to-fax, which requests the sending of a fax via the Internet. The content of the fax can be made through a Web page, but it can also be a file or a standard message. For example, a hotel chain might have a Web page in which you can book rooms; in cases where a hotel in the chain does not have Internet access, the reservation could be sent automatically as a fax.

◗

Click-to-fax-back, which is the same as click-to-fax, except that the fax is sent to the requester of the service. For example, when a user books a flight on-line, he or she might want the confirmation to be sent to a personal fax machine.

◗

Voice-access-to-content, which requests a call via the Internet to access voice content. This scenario is like click-to-dial, except that the user is connected to a voice server that reads out information. This service can be used for providing audio information (quotes, sound bites, music) to users on computers without a sound system, but with access to a telephone.

PINT is based on a simple architecture that consists of two elements. A PINT client is the software that requests the telephony service. It is typically a Java servlet or program activated by pushing a button on a Web page. The PINT gateway is a server that translates PINT requests into SS7 commands for the telephony network. The PINT gateway typically connects to the SCF and uses INAP messages to request call setup. The PINT WG however does not impose this architecture. It is also possible that the PINT gateway connects directly to the switch, and it may also use vendor-specific protocols instead of INAP. Figure 3.10 illustrates the most typical setup for PINT services. The PINT protocol is based on SIP, with a few extensions. PINT is a client-server protocol, as is SIP. The functionality of the PINT client is similar to that of the SIP UAC. Likewise, the PINT gateway can be seen as a special kind of SIP server. Although Figure 3.10 shows a direct connection between the PINT client and the PINT gateway, any kind of SIP proxy server and redirect server can be put between the PINT client and gateway. PINT makes extensive use of SDP (see Section 3.2.4) to describe the type of service requested from the telephony network. PINT has extended

IN and the Internet

PINT client

105

PINT protocol gateway Internet

INAP SS7

SCF

Telephony network SSF

Figure 3.10

PINT architecture.

SDP with values and parameters that are specific to telephony networks. Among other things, it defines a new network type, TN (for telephony network) and allows for telephone numbers to be used as addresses. Where an SDP line for specifying a connection address in a normal SIP request would be c=IN IP4 194.140.170.15/127, a PINT request would include a line such as c=TN RFC2543 +34-932923176. PINT also defines various extensions to SIP itself. PINT allows a SIP request to specify a pointer to the data to be used in a click-to request. This data could be a fax to be sent or a message to be read through the telephone. The pointer can be a URL, but it can also be a proprietary address type understood by the IN SCF. PINT requests can also carry the service data in their body. For example, the PINT request can include text to be faxed or content to be spoken over the telephone. The content can be attached as plaintext in the body of the SIP message, or it can be any text-encoded file format (for example, a Word for Windows file or a .wav audio file). PINT defines three new types of request messages: subscribe, unsubscribe, and notify. They are used to keep a client updated of the status of a request. A client that issues a request to a PINT server can subscribe to notifications about the execution of the request. The server uses notify messages to inform the client of the status of the request. Both the client and the server can end the notification by sending an unsubscribe message. Figure 3.11 provides a simplified example of how a client could use subscribe to receive notifications about the request to send a fax. The subscribe request is quite important. Without it the PINT client has no way of knowing if a request was correctly completed or not.

106


PINT gateway

PINT client “click-to-fax” Invite Subscribe

Notify “recipient busy”

Trying Busy tone

Notify “retry”

Retrying

Notify “fax sent”

Success

Unsubscribe Figure 3.11

Subscribe , notify , and unsubscribe requests.

SIP is based on HTTP and uses e-mail-like addresses or universal resource locators (URLs) to identify users. PINT defines two important extensions to these SIP URLs that can be used to request a service. One is that the user portion of a URL can indicate the type of service to be requested. The conventions used are request to call (R2C; click-todial), request to fax (R2F; click-to-fax), and request to hear content (R2HC). Where a normal SIP request may read INVITE sip:presi [email protected] SIP/2.0, a PINT request would typically be something like INVITE sip:[email protected] SIP/2.0 where pintprovider.com is the address of a provider of PINT services. The other important extension is that PINT defines a new URL parameter tsp to specify the network provider to carry out the requested telephony service. If the example invitation above were used to specify that the service must be provided by myfavoritenetworkoperator.com, then the invitation would read INVITE sip:[email protected]; tsp= myfavoritenetworkoperator.com SIP/2.0. PINT defines several other extensions to SIP and SDP that we will not discuss in detail here. The important thing to remember is that PINT is based on SIP and SDP, and that it is used by Internet-based applications to request services from the telephony network. PINT is as simple as SIP; the difficult part is the implementation of the PINT gateway. The PINT gateway must translate PINT requests to the right signaling messages that can be understood by the telephony

IN and the Internet

107

network, for example INAP or ISUP messages. PINT does not say how the PINT gateway is implemented; this is left entirely to the manufacturer. 3.3.2

SPIRITS

In the previous section we looked at a solution for Internet-based applications in requesting services from IN networks. Yet, there are also scenarios in which requests must go in the opposite direction, from the IN network to the Internet. Suppose you are connected to the Internet at home through your only telephone line. While you are surfing the WWW, the telephone line is occupied. Anyone trying to call you while you are connected to the Internet gets a busy tone. This situation can be annoying to both you (you could lose important calls) and to the operator (while you are connected for hours at cheap local or flat rate, no outside calls are completed to your phone). The problem lies in the fact that your phone line is the only resource to connect to the Internet and make telephone calls. Wouldn’t it be nice if you could be notified on your computer of any incoming calls? This may sound simple, but in fact it is not so straightforward. The only way to notify you of the incoming call is if the network operator’s SCF could tell your ISP to display a message on your computer that a call is coming in. Depending on what you want to do with the call, you could decide to simply reject the call, divert it to your voice mailbox, or terminate the Internet dial-up connection and take the call. It may even be possible for you to stay connected, if the call is presented to you on the computer using voice over IP. This feature is called Internet call waiting (ICW). Several telecommunications operators and manufacturers have thought of ways to implement ICW and have come up with different proprietary solutions. The IETF has studied solutions proposed by Korea Telecom, Lucent, NEC, and Telia, together with Nortel. The solutions have several differences, like whether the call-waiting request comes from an SCF, service node, or directly from the switch, where the different functions are located, and whether the call can be completed to the subscriber’s computer using voice over IP. Based on the study of existing solutions, the IETF is working on a protocol for ICW. The WG responsible for this protocol is called Services in the PSTN/IN Requesting Internet Services (SPIRITS). Figure 3.12 shows the architecture that the SPIRITS WG has proposed for ICW. The user’s computer will need to have a PINT client and SPIRITS server installed. These are normally simply embedded in a small ICW

108


Internet PINT protocol

PINT gateway

SPIRITS server

SPIRITS protocol

SPIRITS gateway SPIRITS protocol

User terminal Telephony network SSF

Figure 3.12

ISP

PINT client

SPIRITS client SCF

SPIRITS architecture.

application that the user must download from his or her ISP, and that starts automatically when the PC is powered up. This small application also takes care of pop-up windows on the user’s PC notifying him or her of incoming calls, and retrieving information on what to do with the call. On the side of the ISP, there is a server that hosts the PINT server and a SPIRITS gateway. The SPIRITS gateway is an intermediary node between the SPIRITS client attached to the SCF and the SPIRITS server in the user’s PC. Why does SPIRITS use a gateway, and why does the SPIRITS client in the SCF not connect directly to the SPIRITS server in the user’s PC? The reason is that the gateway provides the ISP with control over the ICW service, allowing the monitoring or even filtering of SPIRITS requests. SPIRITS makes extensive reuse of the SIP and PINT protocols. At the time this book was being written, the SPIRITS protocol was still under definition. It is likely that a typical SPIRITS scenario will look something like the sequence shown in Figure 3.13. This scenario can be deduced from the pre-SPIRITS implementations described in IETF RFC 2995. The SPIRITS gateway is omitted in this example, which shows only the most basic case. The scenario shown in Figure 3.13 consists of the following steps: 1. When the user connects to his or her ISP, the ICW application detects this and the PINT client sends a register request to the

IN and the Internet

109

Internet service provider

User terminal PINT client

PINT gateway

SPIRITS server

SPIRITS Client

(1) REGISTER (IP address, tel.nr.) OK

IN network SCF

Set trigger

(2) Incoming call

INVITE

(4)

Trigger

(3)

(5) Notify user (user decides to divert the call to other number) (6)

seeOther(new tel.nr.) Set up call to new tel.nr ACK

Figure 3.13

(7)

Internet call waiting with SPIRITS.

PINT server of the ISP. In this request, the application notifies the PINT server of the IP address of the user (which is usually dynamically assigned) and of the telephone number. 2. The ISP’s PINT server tells the SCF to set a trigger for any incoming calls to this telephone number. It also sends a confirmation (OK) back to the PINT client to indicate that the registration was successful. 3. When a call comes in to the user’s telephone number, the SCF detects this and notifies the SPIRITS client. 4. The SPIRITS client tells the SPIRITS server of the incoming call. It is most likely that the invite request of SIP will be used for this. 5. The application on the user’s machine now causes a window to pop up on the screen, telling the user that somebody is trying to call. If available, this notification includes the identity of the calling line, so that the user can decide what to do based on who is calling.

110


Normally the user will be given various options, such as reject call, divert call to voice mail, divert call to other number, take call, or even complete call to my computer using voice over Internet. 6. Let us assume that the user chooses the divert-call-to-othernumber option and provides a new telephone number, for example his or her mobile phone number. In response to the invitation, the SPIRITS server now returns a forward message to the SPIRITS client. It is most likely that the SIP seeOther reply will be used for this. 7. The SPIRITS client now instructs the SCF to complete the call to the new number provided by the user and sends an acknowledgment to the SPIRITS server. In this example, the destination of the incoming call is negotiated in real time with the (human) user behind his or her computer. It is also possible that the SPIRITS gateway decides automatically what to do, based on information provided by the user beforehand. The user can leave call completion profiles with the SPIRITS gateway, specifying, for example, if the call is from my boss then take it, otherwise send it to my voice mail. In unspecified cases, the decision can still be referred back to the user. SPIRITS is still under definition. As in the case of PINT, it is likely that it will lean heavily on SIP, because the SIP messages are suitable for conveying information about incoming calls. The SPIRITS scenarios will probably not divert much from the example given in this section. Meanwhile, many manufacturers have already implemented their own version of ICW. In some cases, these use PINT and SIP, and in others they are proprietary. Whichever way, ICW requires a trusted relationship between the ISP and the telephony service provider. 3.3.3

Web-IN

IN and the Internet complement each other with respect to where the intelligence and data are located. In IN, the service logic and service data are centralized in the SCF and SDF, and are administered by the service provider. In the Internet, however, applications and data can be on any machine. HTTP (Web) servers, mail servers, SIP servers, and PINT servers are everywhere and can be anybody’s.

IN and the Internet

111

The culture clash between IN and the Internet is becoming more serious as people begin to use the Internet for telephony. If a call starts in an IN network and ends in the Internet, how can service continuity be ensured? Over the past few years, many researchers have been looking for solutions to this problem. In the previous sections, we considered interworking scenarios between IN and the Internet for specific services: PINT for click-to-dial, click-to-fax, click-to-fax-back, and request to hear content, and SPIRITS for Internet call waiting. Starting from these services one could imagine many more interworking models between IN and the Internet. Many IN services are about the completion of calls according to personal preferences. In other words, a subscriber defines a profile that specifies where to route his calls depending on the origin of the call, date and time, whether the line is busy, or whether there is no reply. At the moment, these profiles that define how to complete calls are stored centrally in the SDF, and the call is processed centrally in the SDF. If a user wants to create or modify a profile, this must be done via the service provider. Wouldn’t it be more logical if the subscriber created and stored its own service profile? In the classical telephony network, this was impossible. The only device the subscriber has is the telephone: a device without any processing capabilities and with a minimal signaling interface. But all this changed with the Internet; now many users store and manage data on-line. So why not store the call profiles in the Internet? This is exactly what Web-IN is about. The term Web-IN was first used by researchers from Hewlett-Packard Laboratories. The idea of Web-IN is that an SCF can refer to data on the Internet to process calls. Another way of looking at this is by considering the SDF not as a physical node of the IN system, but a logical data storage that is in reality distributed over the Internet. Figure 3.14 illustrates the principle of Web-IN. The IN standards describing the interaction between the SCF and SDF are defined in terms of INAP information flows. In Web-IN these interactions are replaced with HTTP requests to HTTP servers that hold the callscreening data for a particular subscriber. This means that the SCF must have the IP address or URL of the server to contact, and must formulate an HTTP request instead of an INAP message. Taking this approach one step further, one could even imagine the service to be completely executed in the remote host. In other words, the SCF does no processing at all, but delegates the complete service

112


HTTP server Subscriber profiles

Internet HTTP request SCF

SSF Figure 3.14

Web-IN principle.

processing to the remote host. Another possibility is that the SCF downloads the service script from the remote host and executes it locally. Figure 3.15 shows the three different Web-IN scenarios. Scenario A in Figure 3.15 is the basic Web-IN scenario. Service execution is done in the SCF, but the SCF refers to an external server for requesting service data. This scenario replaces the SCF-SDF communication by an HTTP query. In scenario B, the SCF completely delegates

HTTP server

Service logic

Service data

Internet

Internet Data request

HTTP server

Service data

Trigger

Instruction

SCF

SCF

A

B

HTTP server

Internet Service logic Service data

Request

SCF

Service logic Figure 3.15

Web-IN scenarios.

C

IN and the Internet

113

control to the remote server where the service logic is executed. This scenario replaces the SCF-SCF communication mechanism in CS-2 by a remote execution in a Web server. Scenario C is a completely new scenario that does not really have its counterpart in current IN standards. In this scenario, the SCF downloads not only the service data but also the service logic from a remote server. In this scenario the SCF is no more than an execution environment for downloaded code. The downloaded service logic would typically be a Java applet, but there are also much more sophisticated mechanisms being studied in the research community. These new technologies involve agents, software objects that have a certain amount of intelligence and autonomy to carry out processing on behalf of a subscriber. Web-IN scenarios are in themselves not difficult to implement; however, there currently exist no standards for them. The main problems with Web-IN are performance, reliability, and security. To ensure acceptable call setup times, an SDF request should not take more than 10 ms or so. When requesting data over the Internet, performance is far from guaranteed. An HTTP request could take seconds to fulfill. Similar problems exist with reliability: The Internet is an unreliable communication medium. Perhaps the most important problem of all is security. By distributing the service data over the Internet, the service provider loses control over its integrity. Service data in the Internet is vulnerable to all sorts of eavesdropping, imposters, and denial-of-service attacks. This problem gets even worse when not only the service data, but also the service logic, is distributed over the Internet (scenarios B and C). Web-IN is a very interesting extension of the IN concept, but a rapid introduction of this technology is not likely until the performance, reliability, and security problems have been adequately addressed.

3.4

Managing services via the Internet

It is clear that operators and ISPs can create exciting new services by combining the strengths of IN and the Internet. The previous sections discussed how international forums are trying to standardize the mechanisms for interaction between the Internet and IN. The Internet plays an increasingly important role in the ITU and ETSI specifications for IN. PINT, SPIRITS, and Web-IN are examples of IN-Internet interworking, but they are not exclusive. There are many levels at which IN

114


functional entities can interoperate with the Internet. Figure 3.16 summarizes these. Interactions between IN and the Internet can be categorized into three main areas: 1. Switching and routing. When the Internet is used as a carrier for voice and multimedia communications, it is necessary to provide for interactions at signaling level. New protocols like H.323 and SIP provide their own network intelligence that can be combined with IN in several ways. 2. Service control. Interactions between the Internet and IN can take place in two directions. Applications like click-to-dial are based on the idea that Internet-based applications can request service logic to be executed in the telephony network (PINT). Conversely, SPIRITS and Web-IN concepts allow IN service logic to consult external applications over the Internet. 3. Service management. One of the early areas of synergy between IN and Internet was in the providing of access to service management functions over the Web. So far we have considered interactions at the switching and routing level (H.323 and SIP) and at the service control level (PINT, SPIRITS, and

Service management

SMF

Service control

Web-based service management

SCF

X.500

SDF

PINT, SPIRITS,Web-IN Internet Unified messaging

Switching routing

SRF SSF

Figure 3.16

H.323, SIP

Levels of interoperation between the Internet and IN.

IN and the Internet

115

Web-IN). In this section, we will discuss the third level at which IN and the Internet can interact: service management. 3.4.1

Service management and configuration over the Internet

An important limitation in IN is the very narrow user interface that the telephone provides. There are essentially only two ways of interacting with the network: by talking or by dialing a number. The only keys on a telephone dial are 0 to 9, *, and #, which makes the user interface of a telephone very poor indeed. Yet many services require some kind of configuration by the user. To use call forwarding, the user must provide the number to be forwarded to. To use call screening, the user needs to provide the numbers to be screened. And these are only simple examples. Setting up a profile to route calls according to date, time of day, and origin is very cumbersome through a normal telephone. To solve this problem, manufacturers of IN platforms thought of ways to configure services over the Internet, using a browser. Rather than creating many small services for call forwarding and call screening, manufacturers now tend to create one generic call treatment service that can be configured by individual subscribers to do the following: ◗

Forward and screen calls according to date, time, and originator of the call;

◗

Put incoming calls on hold or route them to a voice mailbox when the line is busy;

◗

Route rejected calls to a voice mailbox.

A subscriber can customize this service by filling out an HTTP form over the Internet. This form is interpreted by the SMF, translated into service support data, and stored in the SDF. The SCF uses this data as input to the SIBs when a call is received or placed. Figure 3.17 shows a screen shot of the Web service customization interface offered by the Alcatel Open Service Platform. To make the service management functions accessible over the Internet requires a Web server to be integrated with the SMF. This HTTP server can be either implemented as part of the SMF itself, or as a separate machine connected to the SMF. Figure 3.18 shows a typical IN configuration with an SSF, SCF, and SDF, where the SMF is accessible via the

116


Figure 3.17

Service customization using HTTP forms.

SCF

SDF

SMF

Web server

Internet. Most vendors of IN equipment now offer this Internet access to service management. IN CS-1 did not specify how service management could be accessed over the Internet. By the time IN CS-2 was being specified, the need for an external access function was recognized, and so CS-2 defined the

Internet

SSF

Figure 3.18

Service-management access from the Internet.

IN and the Internet

117

SMAF. In practice, the SMAF is typically a Web server, as shown in Figure 3.18. Another common use of Internet access to the SMF, apart from service configuration, is to provide on-line information about the status of prepaid accounts. The subscriber can access information on the current credit and invoiced calls stored in the SDF via the Internet. In some implementations, this interface even lets the subscriber recharge the account by entering a valid credit card number. 3.4.2

Unified messaging

An application that is gaining rapid popularity is unified messaging (UM). It is rather difficult to situate unified messaging, because it is truly on the borderline of IN and the Internet and it has both real-time and non-realtime communication aspects. In essence, UM lets a subscriber receive all types of messages in a single unified mailbox. These messages can be e-mails, faxes, and voice mails. UM truly combines the services of the telephony network and Internet. An e-mail is normally sent over the Internet using the SMTP protocol and stored in mail servers. A voice mail is produced in the telephony network and stored either in the switch or in a specialized voice message relay (VMR) system. The unified messaging center (UMC) combines the functions of a mail server and VMR and makes all messages available through the Internet as well as through the telephony network. For this it is necessary to provide the following translations: ◗

Voice to e-mail. Voice messages can be attached to e-mails as .wav audio extensions, so that they can be listened to on a PC with a sound card. They can also be interpreted by speech-to-text software and converted into a plaintext mail.

◗

E-mail to voice. Conversely, it should also be possible to access e-mails from the telephone. This means that the content of the mail has to be read by text-to-speech software.

◗

Fax to e-mail. Faxes can be attached to e-mails as bit map images and can be viewed by any program that can display bit maps.

◗

E-mail to fax. A UMC usually allows for the possibility to generate faxes from plaintext e-mails or even from e-mails with attachments.

118


◗

Voice to fax. Some systems provide the possibility to dictate faxes, using the same speech-to-text software as is used for converting voice messages to e-mails.

It is possible to implement a UMC without IN as a stand-alone platform that connects to the Internet and to the telephony network. Such a platform can be deployed by anyone who leases a number of telephone lines from a telephony operator and obtains a connection to the Internet. But telephony operators can also implement UM via their existing IN infrastructure. The VMR function is then incorporated as an SRF and combined with a Web server. This is shown in Figure 3.19. The advantage of implementing UM within IN is that the messaging services can be combined with other IN services, for example, call treatment features such as call forwarding and call screening. Operators today build Internet portal sites that incorporate all these features and let users personalize their communications. The CUSF and SCUAF in CS-2 allow the receiving of an e-mail to be treated as a call-unrelated event that can trigger an IN service. This provides virtually unlimited possibilities for new creative features, and that is just what IN and the Internet are all about.

Internet HTTP, SMTP, POP3

Gateway

Unified messaging center

SCF

SRF

SSF

Telephony network

Figure 3.19

Unified messaging solution within IN.

CHAPTER

4 Contents 4.1

Cellular networks

4.2

GSM

4.3

GPRS

4.4

CAMEL

4.5 Internet in the mobile environment 4.6 Mobile-specific services 4.7

3G mobile networks

The mobile dimension When people speak of mobile networks, they are usually referring to cellular networks such as GSM or D-AMPS. Yet there is much more to mobility than just these networks. There are at least three types of mobility in telecommunications: ◗

Terminal mobility: The terminal is connected to the network via a radio interface and can move around freely.

◗

User mobility: The user can move from one terminal to another and register for incoming and outgoing calls to be made to and from this terminal.

◗

Service mobility: The portfolio of services that a user has subscribed to follows the user as he or she roams to different networks.

Almost everybody is familiar with the concept of terminal mobility. It is all around us, in the form of cordless and cellular phones. Cellular networks also support user mobility in the form of SIM cards that associate a subscription with a terminal. The use of

119

120


calling cards can also be considered a simple form of personal mobility, because these cards allow you to use your subscription to call from any telephone. To understand the meaning of service mobility, imagine that you are traveling abroad, and would like to watch your local football team play in a game broadcast on television. Unless your hotel happens to have your local channel on its cable, it is likely that you will miss your favorite game while on the road. Service mobility is the concept of exporting content and services to visited locations, allowing you, for example, to watch your team play anywhere you go. Even when we limit ourselves to terminal mobility, there are many different types of networks; cellular networks are only one type among many. Table 4.1 gives an idea of the variety of network technologies for terminal mobility.

Table 4.1 Network Technologies for Terminal Mobility Network

Technologies

Cordless

CT2, DECT, PHS, PACS

Cellular

GSM, D-AMPS, IS-95, PDC

Satellite

LEO1: INMARSAT, EUTELSAT GEO2: IRIDIUM, GLOBALSTAR, TELEDESIC, SKYBRIDGE

Mobile data

MOBITEX, DataTAC, Datatrak

Private radio

MPT-1327, TETRA, Tetrapol

Public radio

RDS, DAB

Wireless local loop

LMDS

1. LEO satellites circle the Earth in low orbits, in the order of a few hundred kilometers above the Earth’s surface. These satellites circle the Earth in less than 24 hours, and therefore their position relative to the Earth varies constantly. LEO systems typically need hundreds of satellites to give radio coverage of the entire Earth; they also need to implement some kind of mechanism to hand over communications from one satellite to another as a satellite disappears behind the horizon. 2. Geostationary-Earth-orbit (GEO) satellites circle the Earth in exactly 24 hours and their position remains fixed with respect to the Earth. Geostationary orbits are in the order of 36,000 kilometers from the Earth. For this reason, a single GEO satellite covers a large part of the Earth. The downside is that GEO satellites require more power; the distance also introduces a noticeable delay.


4.1

121

Cellular networks

Of the many mobile network technologies that exist, cellular networks have the most subscribers and most resemble telephony networks from the user’s point of view. A cellular network employs many radio cells of limited coverage to cover a large area. The use of many small cells rather than just one or a few big radio stations has several advantages. First, a mobile phone is always close to a network transceiver, and therefore needs less transmission power. Second, channels can be reused in different cells. The capacity of a network increases as the cell size shrinks. The first cellular networks used analog radio interfaces. Simply put, these were walkie-talkies that connected to telephony switches through the closest available network cell. Although there were cellular networks as early as the 1950s, they were low-capacity networks for a very exclusive market. Widespread deployment of analog cellular networks began in the early 1980s. They were characterized by a lack of standardization. Many countries had their own system, for example AMPS in the United States, NMT in the Scandinavian countries, C-450 in Germany, and RTMS in France. Roaming was very limited, eavesdropping was very easy, and as mobile telephony became more popular, these networks quickly ran into capacity problems. In the early 1990s a second generation of cellular networks appeared. These used digital transmission and had significantly higher capacity than the first-generation (1G) networks in terms of subscribers that could be supported. The encrypted digital transmission ensured much better privacy than analog networks could provide. GSM is one of the best-known 2G networks, but there are also other successful technologies such as D-AMPS and IS-95 (United States) and PDC (Japan). Yet the level of standardization was much better than with 1G systems, and roaming to other networks and countries became common. The beginning of the new millennium saw yet another generation of digital cellular networks, featuring multimedia communications and mobile Internet. These new digital networks are called 3G, because they follow the 2G cellular networks like GSM and D-AMPS. Again, there exist different standards, with UMTS one of the most prominent. Figure 4.1 illustrates the different generations of networks.

122


AMPS, TACS, NMT, C-450, RTMS First generation D-AMPS, IS-95, GSM, DCS-1800, PDC Second generation IMT2000, UMTS Third generation 1980

1985

Figure 4.1

1990

1995

2000

2005

2010

Cellular network generations.

Recently there has also been talk of 2.5G cellular networks, in between 2G and 3G. 2.5G networks use the existing frequency bands and radio interface of 2G networks, but offer 3G capacity and services.3 By using different encoding and multiplexing techniques, 2.5G networks squeeze more out of the existing infrastructures. The most important 2.5G technologies are GPRS and EDGE. The cellular networks we will focus on in this book are GSM, GPRS, and UMTS. It is not the author’s intention to ignore the North American and Japanese standards. The European, American, and Japanese cellular networks differ mostly in radio technology, but are otherwise quite similar in their core network aspects. It is therefore not necessary to treat all the world’s cellular networks separately. In this chapter we will discuss the meaning of intelligence in cellular networks and we will consider the impact of IN in this area. In the following section, we will consider the components of a GSM system and what distinguishes a mobile from a fixed network.

4.2

GSM

Work on the specification of GSM started as far back as 1982 in the Groupe Spéciale Mobile of the European Conference of Postal and 3. The contrary also happens: some operators acquire 3G licenses simply in order to have more spectrum for delivering their 2G services. There are even cases in which operators sit on their 3G licenses, to delay the introduction of 3G services as long as their 2G subscriber base is growing.


123

Telecommunications Administrations (CEPT). By 1986 the frequency band for GSM had been allocated. CEPT defined the GSM radio interface as a mix of time- and frequency-division multiple access (TDMA and FDMA) with frequencydivision duplex (FDD). In other words, channels are divided both by frequencies (FDMA) and by time slots (TDMA), while the uplink and downlink channel for a conversation are in separate frequencies (FDD). Figure 4.2 illustrates the GSM radio interface in a simplified way. In 1988 CEPT transferred all GSM standardization activities to ETSI. ETSI kept the acronym GSM but changed the official name to Global System for Mobile Communications. The first commercial GSM call was made in Finland in 1990, and commercial networks began being deployed on a wide scale around 1992. In the course of time, GSM deployment began spreading outside Europe to Asia, Africa, the Americas, and the Middle East. To ensure standardization on a more international scale, ETSI created 3GPP with other worldwide standardization bodies in 1998. Today 3GPP is responsible for all GSM technical specification work, and ETSI adopts these specifications as standards. 4.2.1

GSM architecture

A GSM network consists of three main components: mobile stations (MS), the base station subsystem (BSS), and the network switching subsystem (NSS).

Frequency 0.58 ms

94 1001

93

......

92

0101

1101

1100

1111

1 2 3 4 Time slot

5

6

7

8

1 2 Time

0110

3

4

5

6

7

Mobile 1 sends on channel 93 in time slot 4 Mobile 2 sends on channel 92 in time slot 2 Figure 4.2

200 kHz

.... ..

Channel

GSM radio interface structure.

8

1

2

3

4

...

124


Mobile stations are GSM network terminals. They differ from fixed network terminals in that they connect to the network through a radio interface and require processing power. Although the GSM standard consistently uses the term mobile stations, in this book we will use mobile terminals as a general term. The BSS manages the radio resources. It consists of a base station controller (BSC) and base transceiver stations (BTS), which are the actual transmitters and receivers. One BSC can manage various BTS. The NSS represents the core network part of the GSM network. The key component in the NSS is the mobile switching center (MSC). In essence the MSC is a telephony switch with extensions to handle mobile terminals. Associated with an MSC is a database called the visited location register (VLR), which holds the subscriber data for visiting subscribers. When a subscriber visits another operator’s network, this is called roaming. Each GSM operator has a database called the home location register (HLR), which holds the essential subscriber information, including information about the VLR to which a subscriber is currently attached. Figure 4.3 shows the main components of a GSM network. An MSC is usually connected to more than one BSC, which in turn are connected to several BTS. An MSC can switch connections directly between the mobiles that are connected to it, but it can also forward calls to other

MS

HLR

BTS

BTS

BSC MSC

BTS BTS

To other MSC or other networks

BSC VLR

BTS BTS Base station subsystem Figure 4.3

Network switching subsystem

Main components of a GSM network.


125

MSCs in the same mobile network or switch calls to outside networks. These outside networks can be other GSM networks or fixed networks. An MSC that is connected to other networks is usually called a gateway MSC (GMSC). The HLR and VLR play an essential role in managing the mobility of subscribers in a GSM network. There are three important aspects of mobility to be taken into account: mobility management, handover, and security. 4.2.2

Mobility management and handover

Mobility management refers to the procedures that enable location of a mobile terminal when a call arrives. Since terminals can move around in cellular networks or even from one network to another, the network must have some way of locating and alerting the terminal when a call comes in. To solve this problem, GSM networks were divided into location areas. A location area typically covers several radio cells. Each location area has a unique identifier that is transmitted on a special channel in all the cells it contains. Each mobile monitors this channel. When it detects a change in the broadcast location area identifier (LAI), the mobile terminal knows it has crossed into another location area’s radio cell. At that time, it requests a location update from the network. There are two ways that a location update can take place: 1. If the new location area is served by the same MSC and VLR, then the VLR registers the move. 2. If the new location area is served by another MSC and VLR, then the mobile subscriber information is moved from the old to the new VLR. The HLR is also updated so that it can route all incoming calls to the new MSC and VLR. Figure 4.4 illustrates the second case. The procedure is as follows: 1. The mobile terminal moves into a new cell, notices that the location identifier for this cell is different, and requests a location update. 2. The VLR requests the subscriber information from the HLR.

126


Location area A (4) MSC BSC

VLR (3)

(1)

HLR

MSC BSC

VLR (2)

Location area B Figure 4.4

Location update.

3. The HLR sends the subscriber information to the VLR and registers that the subscriber is now attached to the new VLR. 4. The HLR informs the old network of the move and orders the old VLR to remove the record for this subscriber. It is also possible that a mobile terminal will move from one cell to another while in conversation. A mobile terminal continually monitors the quality of the radio signal from the current cell, but also from surrounding cells. Similarly, the network monitors the radio signals from the mobile terminals. When the network and the mobile terminal perceive a decline in quality of the current connection, the network will look for a better channel in a neighboring cell. The mobile terminal must be detached in real time from the radio channel of the old cell and attached to the new channel in the new cell. This procedure of real-time cell change is called handover or handoff (the latter term is mainly used in the United States). A handover can imply a location update, if the new cell is in a different location area. 4.2.3

Security

Another important issue in GSM is security, because radio connections are sensitive to tampering and eavesdropping. Security in GSM covers both authentication and encryption.


127

A GSM subscription is stored on a small smart card called the subscriber identity module (SIM), which is inserted in the terminal. Each subscription has a unique identifier, the international mobile subscriber identity (IMSI). The IMSI consists of a country code, a network code, and the subscriber identity. The IMSI is, however, not the number one dials to reach a mobile subscriber. The dialed number is called the mobile station ISDN number (MS-ISDN). The MS-ISDN is defined separately from the IMSI to allow a subscriber to keep his or her number when changing operators, and to allow changes in the numbering plan without changing the network internal subscriber identity. The HLR stores the mapping from MS-ISDN to IMSI. A mobile terminal communicates its IMSI to the network only when it switches on or does a location update. At this point the network authenticates the SIM in the mobile terminal using a secret key algorithm. As part of this procedure, the visited network will also request a location update by sending the mobile station roaming number (MSRN) to the HLR. The MSRN is an identifier composed of the IMSI and the LAI of the cell where the mobile terminal is located. The MSRN therefore contains both the identity and the current location of the mobile terminal. With every location update, the HLR stores the MSRN, so it always knows where the mobile terminal is located. After authentication, the VLR assigns a temporary identifier to the mobile terminal that is only locally unique, the temporary mobile station identifier (TMSI). While the mobile terminal stays connected, it uses the TMSI rather than the IMSI for identification. The advantages are twofold: the temporary identifier is much shorter than the IMSI, and it prevents the IMSI from being sent over the air frequently, which would make GSM more prone to security breaches. The VLR stores the relationship between IMSI and TMSI, and also keeps track of the location area of the mobile terminal in the form of the MSRN. Figure 4.5 illustrates where the different identifiers are used in the GSM network. Once a call is established, the exchange of digital voice is encrypted using the same secret key as for authentication, but using a different algorithm. From this section it should be clear that signaling in mobile networks is more complex than in fixed telephony networks. Mobile networks

128


IMSI SIM

TMSI MS

BSC

VLR

HLR

IMSI TMSI MSRN

MS-ISDN IMSI MSRN

MSC

BTS

Visited network Figure 4.5

Home network

Use of identifiers in GSM.

need more identifiers and more security than fixed networks, and also require extensive signaling that is not directly call-related. 4.2.4

GSM connection services

GSM was initially designed as a wireless telephony network. Its main connectivity service is circuit-switched voice, but GSM offers other connectivity services that are fully specified in the standards. The most important ones are listed in Table 4.2. As is evident from this table, GSM is optimized for the communication of voice and short messages. GSM also provides the possibility to communicate data, using the same digital channels as are used for voice. There are, however, two drawbacks with the GSM data service that make it less suitable for Internet access: 1. The connection speed of 9.6 Kbps is too low for most of today’s Internet applications, specifically for Web browsing. A transmission speed of around 56 Kbps, the speed of a telephony modem, is generally considered the minimum for satisfactory Internet access. 2. GSM data connections are circuit switched. GSM sets up a call for the duration of the data connection. A data application must wait for the connection to be set up, and the subscriber will be charged


129

Table 4.2 GSM Connection Services Mode

Description

Basic voice

Voice using 13 Kbps codec

Half-rate voice

Voice using 6.5 Kbps codec (doubles the capacity of the network)

CSD

Circuit-switched data connection at 9.6 Kbps

SMS

Store-and-forward of short text messages of 160 characters

Cell broadcast

Broadcast of text message of 93 characters to all mobile terminals in a cell

USSD

Transfer of service data between mobile terminal and HLR

for the connection no matter whether data is actually exchanged or not. One interesting thing to note is that most voice modems do not work with GSM, because the GSM voice codec interferes with the tone stream that comes from the modem. It is therefore not possible to connect a modem to a GSM phone and connect to the Internet, like in the normal telephone network. To make the GSM networks more compatible with the Internet, 3GPP specified a new packet-based connectivity service that uses the same channel structure as GSM. This technology is discussed below.

4.3

GPRS

Both GSM and the Internet became popular in the second half of the 1990s, and soon people were thinking of combining the two to create a mobile Internet. The general packet radio service (GPRS) allows the GSM radio infrastructure to be used for packet-based data communications. ETSI released the first GPRS specifications in 1997 and published a second more stable release in 1999. The first GPRS networks were commercially deployed in 2000 and 2001. GPRS is typically deployed by operators that already have a GSM network; it is implemented as an extension of the existing GSM infrastructure.

130


4.3.1

GPRS radio interface

GPRS uses exactly the same frequencies and radio technology as GSM, but it uses the GSM channels in a different way. As we saw in Figure 4.2, a GSM voice call occupies a specific time slot for its entire duration. As long as the call is active, the time slot cannot be used for anything else, even when the user is silent and there is no voice transmitted. GPRS occupies time slots only when a packet is sent or received. There is no such notion as a call that occupies a fixed time slot. Figure 4.6 uses the example shown in Figure 4.2, but now with GPRS packet transmissions filling the free time slots in a dynamic way. A GPRS terminal can use any number of the eight time slots in a frequency channel. The more time slots a terminal can use, the higher the data communication rate it provides. The maximum number of time slots that a terminal can handle is called the multislot class of the terminal. It depends on the processing power and radio interface hardware in the terminal. Many terminals are asymmetric in their use of slots, and support more slots for the downlink than for the uplink. This is because Web browsing, the most popular Internet application, requires less bandwidth for the page requests that go from the terminal to the network, than for the page transmissions that go from the network to the terminal.

Frequency 0.58 ms

94 1001

93

......

92

0101

1101

1100

1111

1 2 3 4 Time slot

5

6

7

8

1

2

0110

3

4

5

6

7

Time

Mobile 1 sends on channel 93 in time slot 4 Mobile 2 sends on channel 92 in time slot 2 GPRS packet transmission in free time slots Figure 4.6

GPRS channel usage.

200 kHz

.... ..

Channel

8

1

2

3

4

...


131

In practice, there are few terminals that are of multislot class 8. One reason is that a high multislot class makes the terminal more complex, more energy consuming, and more expensive. Another reason is that very few operators are likely to allow a single subscriber to use all eight time slots in a channel, because this could lead to high network loads. The most typical terminal multislot classes commercially available today are 4 + 1, 3 + 1, 2 + 1, 1 + 1, and 2 + 2 (the first number is the number of slots for the downlink, the second number for the uplink). The data rate not only depends on the number of slots used, but on the coding scheme employed to map the data packets on the channel bit stream. GPRS offers four different coding schemes with different levels of error protection. The most frequently used coding scheme that ensures good-quality connections in most circumstances offers 13.4 Kbps per time slot. This gives a maximum data rate of 8 × 13.4 = 107.2 Kbps if all eight time slots are used. As mentioned before, however, in practice most terminals will not support more than multislot class 4, and so the most common maximum data rate supported will be 4 × 13.4 = 53.6 Kbps. 4.3.2

GPRS architecture

An important advantage of GPRS is that it reuses the existing radio infrastructure for GSM. Installing GPRS only requires software updates in the BTS, MSC, VLR, and HLR. The BSC needs to be extended with a packet control unit (PCU), which takes care of inserting the packet data traffic into the GSM channel structure. GPRS traffic (packet-switched data) is fundamentally different from GSM traffic (circuit-switched voice), and so the GPRS core network is different from the GSM core network. The relationship between the GSM and GPRS networks is shown in Figure 4.7. The GPRS core network contains two new elements: 1. The serving GPRS support node (SGSN), which routes packets to and from the mobile terminals. Its function is similar to that of the MSC in GSM, except that the SGSN is a router rather than a switch. The SGSN handles location updates and handovers, and therefore needs to be connected to the HLR. It is also connected to the MSC and VLR covering the same cells, to allow combined location management for dual-mode terminals with combined GSM-GPRS subscriptions. Several BSC can be connected to one SGSN.

132


MSC

Circuit GMSC switched

PTSN, ISDN, or GSM

VLR BSC

MS BTS

HLR

PCU

SGSN

IP

GGSN

Internet

GPRS-specific infrastructure Figure 4.7

GPRS network.

2. The gateway GPRS support node (GGSN), which acts as the gateway to external packet networks. In almost all cases, the protocol used to communicate with external networks is IP, although GPRS also supports X.25. The most common function of the GGSN is to provide access to the Internet, but it may also connect to private packet data networks (company intranets or ISP networks). Several SGSNs can be connected to one GGSN. The primary function of the GGSN is to manage the addressing of mobile subscribers. The GGSN manages the pool of IP addresses for mobile subscriptions and keeps track of the current SGSN that a subscriber is attached to. Subscribers can have fixed IP addresses, but in most cases IP addresses are dynamically assigned from a pool. This IP address assignment is done by the GGSN. The GGSN routes packets to the right SGSN through IP tunnels. Tunneling means that an IP packet destined for a certain subscriber is put in the payload of another IP packet that has as address the SGSN that the subscriber is attached to. 4.3.3

Mobility management in GPRS

Just as the GSM network is partitioned into location areas to minimize signaling traffic, the GPRS network is divided into routing areas. The


133

rationale behind routing areas is in finding a compromise between notifying the network of each cell change and broadcasting the packets for each subscriber to the whole network. In order to facilitate the interworking between GSM and GPRS, a routing area is always the same as, or a subset of, a location area. This has significant advantages for terminals with dual GSM-GPRS subscriptions, which will eventually be very common. The advantages are as follows: ◗

GSM location updates automatically imply routing area updates. This avoids the need for duplicate location/routing updates and saves signaling overhead.

◗

An incoming GSM call can be paged in the GPRS routing area, which is smaller than the location area. This results in less use of radio resources for paging.

The handover procedure for GPRS terminals is the same as for GSM, except that handover is managed by the SGSN instead of the MSC. 4.3.4

GPRS connection model

As GPRS is a packet network, its connections are of a different nature than the voice circuits in GSM. The GPRS network does maintain the connectivity status of a subscriber for mobility management. A GPRS subscriber can be in one of the states listed in Table 4.3. When switching on a mobile terminal, the GPRS attach procedure causes a transition from idle to ready. Conversely, a return to the idle state is made when the subscriber performs a detach, powering off the

Table 4.3 GPRS Connection States State

Description

Idle

The subscriber is detached from the GPRS network (for example when the terminal is switched off or out of cell coverage). No mobility management is active and the SGSN and HLR have no updated routing information for the subscriber.

Standby

The subscriber is attached to the network but is not sending or receiving packets. The subscriber can receive paging requests and other signaling messages, and routing area updates will be done as the terminal moves.

Ready

The subscriber is sending or receiving data. In this state, moving from one cell to another will involve a handover.

134


mobile terminal or switching to GSM mode. The subscriber moves from standby to ready state when sending or receiving data. Before data can be sent or received, the GGSN must activate a packet data protocol context (PDP context) for the subscriber. The PDP context assigns an IP address for the communication and associates it with the subscriber identity (IMSI) and the address of the SGSN. A PDP context can identify the application that is being used (for example, Web browsing or streaming video), and it can also specify the requested QoS. A subscriber can have several PDP contexts activated at one time. The ready state is guarded with a timer. When no data has been sent or received for a certain time, the subscriber passes automatically to standby. The network can also force a transition from ready to standby, for example when a dual-mode GPRS-GSM terminal receives an incoming GSM call while exchanging data. In this case, the data transmission can be put on hold and can be resumed after the GSM call terminates. Figure 4.8 presents a simplified overview of the GPRS state transitions. The state of a GPRS subscription is maintained both in the terminal and in the network. Looking at it in this way, GPRS can be regarded as a technology for delivering IP to mobile subscribers. GPRS itself has little network intelligence apart from what is needed to maintain PDP contexts, route packets to the right terminal, and do mobility management. In the next section we will see how IN can be applied to both GSM and GPRS, to deliver value-added services in these networks.

Idle Attach

Detach

Ready Time out or force to stand by

Figure 4.8

GPRS state transitions.

Start data transmission Standby

Detach


4.4

135

CAMEL

Standardization of GSM began before the IN concept was published by Telcordia (formerly Bellcore). The first GSM specifications were modeled after ISDN. As in ISDN, the GSM standard predetermined the supplementary services that the network could deliver. By the time the first GSM networks were deployed, IN had also appeared on the scene. Soon operators and manufacturers were thinking of ways to apply IN to GSM networks. The motive, of course, was to standardize service capabilities rather than services, and to create a platform for the rapid creation of new services for GSM. At first sight it appears as though IN can be applied to GSM in a straightforward way. An MSC is in essence a telephony switch. To turn it into an IN platform, it would appear that one could extend it with an SSF that can trigger services, and add an SCF for service logic execution. Unfortunately, things are not quite that simple, because the MSC does more than switching alone; it also manages subscriber mobility by interacting with the HLR and VLR. Being the source of the GSM specifications, ETSI undertook the necessary work to adapt IN to GSM. The resulting ETSI standard is called CAMEL. Putting it in a simplistic way, CAMEL is IN for mobile networks. Why was this work not done in ITU-T, the originators of the IN standards? In fact it was: CS-2 and CS-3 include features to support mobile networks. The BCUP, for example, can be used to allow mobility management procedures to trigger services. One of the problems, however, is that ITU-T specifications must have a worldwide scope and not be biased toward European standards, such as GSM. ETSI found the CS-2 and CS-3 standards insufficiently specific when it came to controlling GSM networks, and decided to propose CAMEL, a version of IN tailored to GSM. Meanwhile in the United States, a similar standard was born for the American cellular networks. The Telecommunications Industry Association (TIA) standards committee TR45.2 specified the WIN standards. The protocol base for this standard is IS-41, the American counterpart of ETSI’s MAP protocol. Although CAMEL and WIN are intended for different cellular networks and are based on different protocols, their architectures are almost identical. As the concepts behind CAMEL and WIN are so similar, we will concentrate primarily on CAMEL in this chapter. An excellent reference to wireless intelligent networking that focuses more on the American standards is the work by Christensen et al. [1].

136

4.4.1


CAMEL architecture

As shown in Figure 4.9, the components of CAMEL are largely the same as those of IN. Call control and connection control are done in the SSF, service logic is executed in the SCF, and the SRF takes care of special user interactions. There are, however, a few important differences between IN and CAMEL. In most uses of IN for fixed telephony networks, the SSF, SCF, and SRF belong to the same service provider. CAMEL distinguishes between the home network of the subscriber, the visited network, and the interrogating network. A CAMEL service is executed in an SCF in the home network of a subscriber, but where the service is triggered depends on whether the mobile terminal places or receives the call. In the case of an outgoing call, the visited network’s MSC triggers the service. An incoming call is first routed to the GMSC of the subscriber’s home network and then diverted from there to the visited network. This is sometimes called tromboning in GSM jargon. Both the GMSC of the home network and the MSC in the visited network can trigger services. Figure 4.10 illustrates the CAMEL control scenarios for outgoing and incoming calls.

Home network

Interrogating network

SCF

P CA

CA P

P

MA

MA

P

HLR

CAP Visited network

SRF

Figure 4.9

SSF

SSF

Gateway MSC

MSC

CAMEL architecture.

VLR


Mobile originated

Figure 4.10

137

Mobile terminated

Home

Home

SCF

SCF

O-BCSM

T-BCSM

T-BCSM

SSF

SSF

SSF

MSC

GMSC

MSC

Visited

Interrogating

Visited

CAMEL control for mobile-originated and mobile-terminated calls.

Newer GSM systems can use optimal routing, by which calls are routed directly from source to destination without passing through the home network. In this case the call may be routed not through the GMSC of the home network, but through that of another network. CAMEL allows for all these scenarios by introducing the interrogating network. The interrogating network is usually the home network, but in case of optimal routing it can also be another network that the call passes through. Another feature that distinguishes GSM from a telephony network is the HLR that stores the subscriber location information. From the IN point of view, the HLR can be seen as a special kind of SDF, and therefore in CAMEL the SCF can communicate with the HLR. GSM defines precisely when the interactions between MSC and HLR take place, for example on power-up of a mobile terminal or when doing a location update or handover. In CAMEL the SCF can query the HLR at any time about the status of a subscription. This feature is called anytime interrogation (ATI) in CAMEL. The protocol used to access the HLR is always MAP. CAMEL uses an adapted version of INAP called the CAMEL application part (CAP) for the interactions between SSF and SCF, and between SRF and SCF. CAP is situated at the same level in the SS7 protocol hierarchy as INAP and MAP.

138


The CAMEL basic-call-state models are almost identical to those of IN shown in Figure 2.11. CAMEL makes a few simplifications to these call models: ◗

The

and Colstates of the O-BCSM are combined into one state in the CAMEL basic-call-state model. O_Null_&_Authorize_Origination_Attempt

lect_Info

◗

The Select_Facility_&_Present_Call and T_Alerting states of the T-BCSM are combined into one state called Terminating_Call_Handling in CAMEL.

◗

There are no

O_Mid_Call

and

T_Mid_Call

events in CAMEL.

CAMEL employs the same kind of detection points as IN, and trigger processing follows the same procedure. 4.4.2

Setting triggers in the visited network

As we saw in Chapter 2, setting a service trigger in practice means arming a detection point in the originating or terminating basic-call-state model. In a mobile setting things are more complicated, because the home network provider of a subscriber usually does not have the privilege of setting triggers directly in the SSF of visited networks. Since the HLR-VLR interaction is well defined in GSM, CAMEL uses the VLR to trigger services. When a user subscribes to a CAMEL service, the HLR sends CAMEL subscription information (CSI) to the VLR of the visited network or the GMSC of the interrogating network, depending on whether the call is incoming or outgoing. The CSI tells the visited network that incoming or outgoing calls for a particular subscriber need CAMEL treatment. When a visiting mobile subscriber places or receives a call, the VLR or GMSC will first check if the home network provided any CSI for this subscriber, and then check the criteria. If the criteria are met, the call needs CAMEL treatment and the SSF will start the O-BCSM or T-BCSM. The three most common types of CAMEL subscription information are given in Table 4.4. When a subscriber requires CAMEL processing for outgoing calls, the HLR sends the O-CSI to the VLR. In the case of services triggered for incoming calls, there are two possibilities:


139

Table 4.4 CAMEL Subscription Information Types Subscription Information Type

Shorthand

Held in

Outgoing CSI

O-CSI

Visited network VLR

Terminating CSI

T-CSI

Visited terminating CSI VT-CSI

Interrogating network GMSC Visited network VLR

1. The service is triggered from the interrogating network; in this case, the HLR sends T-CSI to the GMSC of the interrogating network. 2. The service is triggered from the visited network; in this case, the HLR sends VT-CSI to the VLR. A combination of these is also possible. The contents of the CAMEL subscription information define the DPs to be armed, the service to be invoked, and the address of the SCF of the subscriber’s home network to which the service processing request must be referred. Table 4.5 lists the most important subscription information elements. Apart from the O-CSI, T-CSI, and VT-CSI, there are a few other types of CAMEL subscription information that are used in special cases. An example is the dialed CSI (D-CSI), which does not activate DPs in the BCSM, but triggers directly on special dialed numbers. Other examples are the translation information flag (TIF) and the network CSI (N-CSI), which we shall not discuss in further detail here.

Table 4.5 CSI Contents Item

Description

Trigger-detection-point list

Identifies detection points in the BCSM at which triggers are set

SCF address

SS7 address of the SCF of the subscriber’s home network, which the SSF must contact for service processing

Service key

Identification of the service to be invoked in the SCF when an armed trigger detection point is met

Default call handling

Defines how the call should proceed in case of an error in CAMEL processing (for example, if the home network SCF cannot be reached)

140


4.4.3

CAMEL service example: Prepaid subscription with roaming

The initial driving force behind CAMEL was to give mobile users with prepaid accounts the ability to roam to other networks. Prepaid subscriptions are responsible for a large portion of the growth of GSM in many countries. The service allows GSM to be provisioned to segments of the market with credit constraints, such as young people without bank accounts. Certain subscribers also appreciate the anonymity and the disposability of a prepaid subscription. Many operators implement their prepaid accounts on a service node with a specialized database for the prepaid accounts. When a prepaid subscriber places a call, the MSC consults the service node for a credit check, and the service node will respond by granting a certain connection time based on the remaining credit. If there is no credit, the service node will tell the MSC to refuse the call. Such prepaid implementations based on service nodes or local IN systems do not allow the subscriber to place calls in other networks, because there is no standardized interface that lets the MSC in a visited network consult a service node in the home network. Remember that the only interface defined in GSM for roaming is between the HLR and VLR, for location management. CAMEL provides a solution, because it lets the MSC in the visited network consult the SCF in the home network. Figure 4.11 shows how CAMEL lets a prepaid subscriber make a call from a visited network. The procedure for this is as follows: 1. When the roaming subscriber tries to make an outgoing call in a visited network, the VLR first checks for the presence of O-CSI. 2. If O-CSI is found, the call requires CAMEL treatment and the SSF starts the O-BCSM. 3. The O-CSI contains a trigger for the prepaid service at the Collected_Info detection point. The BCSM encounters this detection point after the user has dialed the destination number, and triggers the prepaid service in the SCF. 4. The service logic program for the prepaid service first checks the current credit of the subscriber’s prepaid account and instructs the SSF to allow the call to proceed for a limited amount of time. The amount of time that the SCF allows the SSF for the call can depend


141

on the visited network location, the destination of the call, and tariff tables for the visited network. 5. The O-BCSM starts a timer and completes the call. Upon expiration of the allowed time, the SSF sends another trigger to the SCF. As a result, the SCF updates the credit of the prepaid account and checks again whether the remaining credit is sufficient. If there is sufficient credit to continue the procedure, steps 4 and 5 are repeated. 6. If there is insufficient credit, as in the example in Figure 4.11, the SCF clears the call. The example presented here is of course oversimplified. In reality the user would first hear a message saying that his or her credit has expired before the call is cleared. To play recorded messages of this kind would involve an SRF, which is not shown in the example. Moreover, Figure 4.11 shows the CAP messages in strongly simplified form.

Subscriber

Visited network SSF

Place outgoing call

Home network SCF

VLR

CAMEL?

(1) O-CSI found (2)

CAMEL

Start O-BCSM Collected_Info (3)

initialDP Credit Check credit sufficient Continue for x sec. (4)

Complete call setup Time expired

Time expired event

(5) Clear call Figure 4.11

Prepaid roaming with CAMEL.

Update credit Credit insufficient (6)

142


But what should be clear is that CAMEL enables service logic in the home network to control resources in the visited network. This provides opportunities for implementing new services that could not be realized with GSM only, like prepaid accounts with roaming. 4.4.4

CAMEL standardization

ETSI started CAMEL standardization in the mid-1990s. Since the creation of 3GPP in 1998, this group now does all CAMEL specification, and its members (among them ETSI) endorse these specifications as standards. ETSI standardizes CAMEL in phases. These phases are somewhat similar to the IN capability sets defined by the ITU-T, although they differ both in timing and in scope. Table 4.6 shows the three CAMEL phases and their characteristics. Soon after its release, CAMEL phase 1 proved too restrictive for practical use. It did not provide an adequate interface for controlling user interactions via the SRF, making it difficult to control the sending of voice announcements and tones to the subscriber, or to capture information input by the subscriber. It also lacked mechanisms to control charging from the SCF. This made CAMEL phase 1 unsuitable for implementing one of the most-desired services: prepaid subscriptions with roaming. These shortcomings were corrected in CAMEL phase 2, and it is expected that this is the phase that most operators will deploy in the short term. CAMEL phase 3 extends the possibilities to trigger services from mobile network events that are not call related, such as location updates, power up and power down of mobile terminals, or the receiving and

Table 4.6 CAMEL Phases Phase

Issue

Characteristics

1

1996

First version based on IN CS-1, anytime interrogation of HLR by SCP

2

1997

Extended call model, in-band user interactions with SRF, charging features, interaction with GSM supplementary services

3

1999

Support for packet-based mobile communications (GPRS), triggering on short messages, triggering on mobility management procedures, USSD connection between mobile terminal and SCF


143

sending of short messages. But most importantly, CAMEL phase 3 was extended for use with GPRS. Section 4.4.5 will go more into detail on these CAMEL extensions. As with IN CS-2 and CS-3, ETSI is providing complete executable SDL specifications of CAMEL phase 2 and 3, against which the conformance of CAMEL implementations can be tested. 4.4.5

CAMEL phase 3

One of the important extensions made in CAMEL phase 3 with respect to phases 1 and 2 is support for GPRS. CAMEL phase 3 enables an SCF in the subscriber’s home network to control GPRS mobility management and the activation of PDP contexts. As in GSM, CAMEL services for GPRS are triggered by an SSF associated with the SGSN that the subscriber is attached to. The existing CAMEL basic-call-state models, however, cannot be applied directly to GPRS, because the procedure for establishing packet communications is different from setting up a GSM call. CAMEL phase 3 therefore introduces two new state models for GPRS: state. This model tracks the mobility management procedures for GPRS and allows the SCF to intervene in them. It is comparable to the BCUSM in IN CS-2, explained in Section 2.7.3, Figure 2.19.

1.

Attach-detach

2.

PDP context state. This model represents the process of establish-

ing PDP contexts for data communication. It is comparable to the O-BCSM and T-BCSM in IN and CAMEL. The GPRS attach-detach state model is shown in Figure 4.12. It distinguishes only two connection states and four detection points: attach, detach, location update, and exception. The location-update detection point (which is rather cumbersomely called change-of-position GPRS session in the ETSI standards) is somewhat special because of their two distinct cases: 1. Intra-SGSN location update: The terminal stays attached and the detection point can only be of the kind EDP-N. This means that the SSF can send only a notification of the event to the SCF, but mobility management cannot be suspended.

144


Detach Detached Exception

Attach Attached

(Inter-SGSN) Routing area update (Intra-SGSN)

Figure 4.12

CAMEL attach-detach state model for GPRS.

2. Inter-SGSN location update: The terminal detaches from the old SGSN and then attaches to the new, and the HLR is notified of the move. In this case the detection point can be a TDP-R, and mobility management can be effectively suspended and controlled by the service logic in the SCF. Before a subscriber can send or receive data, the GGSN must set up a PDP context. As explained in Section 4.3.2, the PDP context maintains the relationship between the subscriber identity (IMSI), IP address, requested QoS, and SGSN. A subscriber can have several PDP contexts active at a time, if he or she uses different IP addresses at the same time. The CAMEL state model for setting up PDP contexts is shown in Figure 4.13. One such state model is started for each activated PDP context. Its states and detection points are straightforward. A request to send or receive data causes a state transition from idle to PDP_context_setup state, passing the PDP context-establishment detection point. When the GGSN has set up the PDP context, it notifies the SGSN that data transmission can begin. This causes a transition via the PDP context-acknowledgment detection point to the PDP_context_established state. It is possible that while the subscriber is sending or receiving data, he or she moves from one routing area to another. This causes a handover and a routing-area update and the change-of-position-context detection point is passed.


145

Idle PDP ctxt establishment Exception

Disconnect PDP_ context_setup

PDP ctxt acknowledgment PDP_context_established Change of position ctxt (routing-area update)

Figure 4.13

CAMEL state model for PDP context setup.

A PDP context can be deactivated either at the request of the subscriber or by the network, causing a state transition to idle via the disconnect detection point. One important thing to note is that the idle state in this model is not the same as the idle state defined for GPRS in Figure 4.8. In GPRS idle means detached from the network. In CAMEL it means there is no PDP context active (in other words, not sending or receiving data). The setting of CAMEL triggers for GPRS works the same way as for GSM. If a GPRS subscription involves CAMEL service processing, then the HLR sends GPRS CAMEL subscription information (GPRS-CSI) to the SGSN. The GPRS-CSI contains the address of the SCF that handles the service, the identification of the service to be invoked (service key), the list of detection points to be armed, and an indication of default handling in case of exceptions. Apart from support for GPRS, CAMEL phase 3 provides a number of other enhancements: ◗

It allows the SCF to control the sending of short messages. All GSM networks nowadays include a short message service (SMS) that allows the sending of short messages between GSM terminals. Short messages are transported on a signaling channel, and do not involve the setup of a call. CAMEL phase 3 defines a state model for the life

146


cycle of a short message (submit message to MSC; store and forward; receive in destination terminal) and allows the SCF to intervene. Section 4.6.1 goes into more detail on SMS and the CAMEL phase 3 facilities for this service. ◗

It notifies the SCF when a GSM supplementary service is started in the MSC. Before CAMEL, GSM supplementary services were programmed directly in the MSC. The GSM standards specify a limited number of such supplementary services, like call forwarding. MSC-based supplementary services can interfere with CAMEL services. CAMEL phase 3 therefore allows the SCF to be notified when such a service is started.

◗

It controls mobility management from the SCF. In CAMEL phase 3 the VLR can notify the SCF of attach, detach, and location-update events for a subscriber. This is similar to what we have just seen for GPRS.

CAMEL phase 3 allows value-added services like prepaid roaming to be provided for both GSM and GPRS. This makes sense, because many subscribers will have dual-mode GSM-GPRS terminals with dual subscriptions. They will be using GSM for voice calls and GPRS for Web browsing, chat, and other Internet applications. And they will expect their services to work with both subscriptions. As pointed out in Section 3.2, however, some services that make sense for voice services do not make sense for data applications. Other services are relevant in both GSM and GPRS but require different interpretation. A good example is billing services. One of the key differences between GSM and GPRS from the subscriber point of view lies in the way services are billed in these networks. The cost of a GSM call is determined by its duration and destination (intranetwork, internetwork, international). In GPRS there is no notion of voice circuits, so it does not make sense to bill for duration. Neither is it logical to bill for the destination of data, because theoretically each data packet can have a different destination. In GPRS it makes much more sense to bill for the data volume that is sent or received, and this is just what most operators will do. The difference in billing between GSM and GPRS can have far-reaching consequences for prepaid communication services, for example. It remains to be seen whether CAMEL phase 3 will be a success in GPRS networks. Skeptics predict that intelligence will move completely


147

out of the network and that GPRS will be used only for routing packets, as over the Internet. In this scenario all intelligence will reside in application servers. Others believe that GSM will disappear and that voice communications will eventually be delivered over GPRS, using voice over IP codecs for transmission and SIP or H.323 for signaling. This is not likely in the short term because of the relatively low data rates offered by GPRS, terminal complexity, and cost. With a massive installed customer base for GSM, it is unlikely that this technology will disappear any time soon. For the foreseeable future we will be using GSM for voice and GPRS for data.

4.5

Internet in the mobile environment

GPRS alone is not sufficient for bringing Internet applications to the mobile subscriber. Another obstacle lies in the terminals. A mobile terminal is not a PC. It has a small screen, a keyboard with few more keys than 0 to 9, ∗, and #, little memory and processing power, limited battery life, and no sophisticated peripherals such as joysticks and mouses. This makes mobile terminals unsuitable for the most popular Internet application, Web browsing. Among the technologies that adapt Internet content and applications to the mobile environment are WAP, iMode, MExE, and SIM toolkit applications. This section considers these technologies. 4.5.1

WAP

Before GPRS was even deployed, people were contemplating the idea of bringing Internet content to mobile phones. In 1997 a group of four companies, Unwired Planet (now known as Phone.Com), Ericsson, Motorola, and Nokia began defining a de facto standard for delivering Internet content to mobile terminals. Early in 1998 they published the first version of the Wireless Application Protocol (WAP). The WAP forum was later opened to participation by others, and two more stable releases were published in 1999, WAP 1.1 and WAP 1.2. WAP is often mistakenly publicized as mobile Internet. This misinterpretation has led to public disappointment and has seriously damaged the reputation of WAP worldwide. Unlike GPRS, WAP does not deliver IP packets to mobile terminals. WAP is an application protocol, designed for bringing content to mobile terminals. In essence, WAP defines two things:

148


1. A set of lightweight protocols for sending pages of text and graphics to mobile terminals; 2. A simple language for designing pages that can be presented on small screens in mobile terminals, and scripts that can run in the mobile terminal’s limited processing environment. The WAP protocols are optimized for delivering small pages of text and graphics to mobile terminals. They are not plaintext like HTTP, but instead use coded requests and responses that save bandwidth on the radio interface. Of course, WAP needs to use a data transmission service in the mobile network to transport its content. WAP protocols can be used with a variety of data services available, including CSD and GPRS, as well as with American and Japanese mobile data formats. It is even possible to use SMS as the transport medium for WAP protocols. WAP pages are called cards, and are described in the wireless markup language (WML). WML is a lightweight language suitable for presenting pages of text and graphics in mobile terminals. It looks a little like HTML, but it is much more compact and allows for less visually rich pages. There is also a scripting language called WMLScript, which provides the equivalent of Java applets for WAP. Of course, its capabilities are more limited than those of Java applets because of the restrictive computing environment in a mobile terminal. WML content can be provided directly by the mobile operator, but most content will be in the Internet. Bringing WML content from the Internet to the mobile terminal requires that a WAP gateway mediate between the Internet and the mobile network. This is illustrated in Figure 4.14. In the simplest case, the WAP gateway acts as a protocol gateway that translates between the WAP protocol and HTTP. Figure 4.14 shows the most common WAP gateway function. The procedure is as follows: 1. A microbrowser in the mobile terminal requests a page by sending an encoded WAP request to the WAP gateway. 2. The WAP gateway translates this into an HTTP request and forwards it to the requested HTTP server in the Internet. 3. The HTTP server sees the WAP gateway as an HTTP client and returns the requested WML page embedded in an HTTP response.


149

(1) Microbrowser Encoded request Mobile network Encoded response (4) Figure 4.14

(2) HTTP request WAP gateway

HTTP server Internet WML content HTTP response (3)

WAP gateway.

4. The WAP gateway encodes the WML page in the WAP protocol format and forwards it to the mobile terminal. Some WAP gateways undertake functions more sophisticated than simple protocol translation. They also translate the content itself, by shrinking HTML pages to WML cards. In practice this translation turns out to be very difficult. Most Web pages today feature rich graphics that cannot be displayed in tiny mobile telephone displays. It is difficult for a gateway to interpret which parts of a page contain essential information that must be translated to WML, and which parts are just filler. One of the most important problems with WAP is that few terminals in the market fully respect the WAP specifications. The WAP forum has defined many parts of the WAP specifications as optional, with the result that different products have different degrees of conformance. In the best-case scenario, this means that WML pages show differently on different terminals, and in the worst case, some pages do not display at all. This lack of conformance has seriously hampered the widespread acceptance of WAP in the market. 4.5.2

iMode

In 1999 Japanese mobile operator NTT DoCoMo commercially launched a technology called iMode (short for information mode) that was similar to WAP. Technically speaking iMode should be compared to GPRS and WAP combined. It is a proprietary technology that is completely integrated with the CDMA One mobile data network in Japan. At first sight there are many similarities between WAP and iMode, but there are also some important differences. These are highlighted in Table 4.7.

150


Table 4.7 Comparing WAP and iMode WAP

iMode

Data technology

Independent; can work with CSD, GPRS, SMS

Works with Japanese CDMA One mobile networks

Data speed

Depends on data service used; typically 9.6 Kbps CSD or GPRS

9.6 Kbps

Standardization

De facto standard

NTT DoCoMo proprietary

Applications

Browsing

Any IP application

Page format

WML; a new language with some similarity to HTML

Compact HTML; a subset of HTML

Browser

Needs WML browser

Can be viewed in normal HTML browser

Billing

Depends on data service used; typically per connection time if used with CSD

Per packet

Perhaps the most significant difference between iMode and WAP is in its market acceptance. While WAP is struggling for commercial survival, iMode enjoys tremendous success in Japan. The difference in billing no doubt plays an important role in this. Until 2000 WAP was mostly implemented on CSD connections, and many users complained about being charged per connection time at the same high tariffs as telephone calls. Another possible reason is that iMode offers a much wider range of Internet services than just browsing, in particular e-mail, and that its compact HTML (cHTML) format is much more compatible with standard HTML than WML. Some critics say that WAP will become obsolete as soon as GPRS is deployed on a wide scale, because GPRS allows the use of plain HTML browsers in the terminal. Others point out that GPRS will actually help WAP become more popular by increasing the data speed and introducing volume-based billing. The debate is very much alive today. 4.5.3

MExE

At the same time that the cellular phone industry was promoting WAP as a de facto solution for bringing hypertext to terminals, the Java programming language was rapidly gaining ground in the computing world. Soon people were wondering whether Java could be used in mobile terminals.


151

There are important similarities between WMLScript and Java applets. Both allow small pieces of application code to be downloaded with hypertext pages and executed in the client. But there are also important differences. Because WAP was invented for mobile terminals, WML scripts have fine-grain control over a mobile terminal’s features, such as manipulating the address book, starting a call, and sending DTMF tones. There was no mobile-terminal-specific Java interface, however. On the other hand, Java has low-level graphics interfaces, which lets the programmer control any pixel on the screen. WML has no alternative for this and is therefore less suited for implementing graphics-intensive applications, such as games. Faced with the question of what to standardize for GSM, ETSI decided on a combination of WAP and Java. The resulting ETSI standard is called the mobile execution environment (MExE), released in its first version in 1999. MExE provides a framework for existing WAP and Java technologies rather than proposing something new. The idea behind MExE is to standardize levels of functionality supported by terminals of different sophistication. MExE defines three such levels, or classmarks. The idea is to guarantee interworking between terminals that support the same classmark. The current MExE specification identifies the three classmarks described in Table 4.8. Classmark 1 provides the basic functionality to download content and scripts from the Internet. It also enables the downloading of classmark 2 or 3 Java scripts embedded in WML pages, but it does not provide the environment to execute them.

Table 4.8 MExE Classmarks Classmark

Based on

Comments

1

WAP

WML and WMLscript

2

Java 2 Standard Edition (J2EE)

Personal Java standard environment for consumer electronics, including Java applets and JavaPhone interface

3

Java 2 Micro Edition (J2ME)

Java environment for restricted runtime environments; connected limited-device configuration (CLDC) and mobile-information-device-profile (MIDP) interfaces

152


Classmark 2 provides a standard Java environment for executing applets, extended with the telephony-specific JavaPhone programming interface. JavaPhone lets an application on the terminal send and receive short messages, set up and answer calls, and even monitor and control the power consumption of the device. Classmark 3 provides a specific lightweight Java runtime environment that allows devices to bootstrap by downloading their configuration profiles from the Internet. MExE terminals can support any combination of these three classmarks, and are required to support at least one. Most terminals will support classmark 1 combined with either classmark 2 or 3. Apart from the classmarks, MExE defines a protocol to negotiate the capabilities of the terminal and the content to be downloaded. This allows the terminal to inform the Web server about its capabilities (for example, screen size, colors, keyboard, tracking device, maximum data speed) and to request a particular content format (graphics, text only, script enabled). MExE also includes a security protocol to make it suitable for security-sensitive applications such as electronic commerce, and to protect mobile terminals from viruses. There are many ways to implement an MExE application, just like in the Internet: ◗

Thin client model. The client in the terminal is only a browser with no or little processing and the application runs in a server in the network.

◗

Applet model. The application is downloaded from the server to the terminal and runs in the terminal. The application can run standalone in the terminal or interact with software on the server.

◗

Peer-to-peer model. Applications on terminals can interact directly with each other. A good example of a peer-to-peer application is music-exchange software such as Napster, Morpheus or LimeWire.

These three models are illustrated in Figure 4.15. They can also be mixed, depending on the application. An important application area for MExE will be games on mobile terminals. Other mobile applications for MExE are personal information management, e-mail handling, audio and video players, and electronic commerce.


Thin client model

153

Applet model

Server

Peer-to-peer model

Server

Servlet

App

Network

Network

Content

Network

Content Applet App

Figure 4.15

4.5.4

MExE application scenarios.

SIM Application Toolkit

Whereas MExE applications run in the terminal, it is possible to run applications in the SIM. A SIM is effectively a smart card with a small processor, memory, and interface. Although it provides a very limited computing environment, small applications can run on it. Smart cards are quite common in banking and security applications, and mobile terminals provide a potentially interesting extension of their use. ETSI recognized this potential and standardized the application programming interface between the SIM card and the terminal. This standard is called the SIM application toolkit (SAT). The SIM toolkit features allow control of several handset functions, as shown in Table 4.9. ETSI started work on SAT before MExE, and the first SAT specifications were published as part of the 1996 release of GSM. Recent versions of SAT also provide possibilities to download small applications from the network. This practice is called over-the-air (OTA) programming.

154


Table 4.9 SAT Control Features Control Category

Features

Man-machine interface

Display text, get user input, play tone

Communication control

Set up call, put call on hold, send short message, request supplementary service (call forward, call screening)

Menu management

Display menu, select item, event notification (key action, incoming call, connect, disconnect)

Accessory management

Controls card in second slot of dual-slot terminal (for example, a credit card)

SAT is commercially available today for GSM and GPRS. It is mostly used to program operator-specific menus and features into the SIM. Some companies also use it to provide SIMs for promotional purposes with small applications such as euro conversion calculators. A growing application area is in electronic banking. Using technology similar to that which already exists in banking, SAT can turn a mobile terminal into an electronic purse or even a credit card.

4.6

Mobile-specific services

Mobile networks have specific characteristics that allow them to offer services that would not be possible in fixed networks. A mobile telephone has become a personal item, something that people carry with them at all times. Calling a mobile telephone is equivalent to calling a person, whereas calling a fixed telephone is calling a location. New services can exploit this feature, and also the fact that mobile terminals can be pinpointed to a specific geographic location. This section deals with three categories of services that are specific to mobile networks: short messaging, location services, and mobile payment services. 4.6.1

SMS

Among the communication services specified for GSM is the transfer of short messages between mobile terminals. SMS was originally thought of as a feature to make GSM terminals compatible with alphanumeric pagers. People initially thought that the new mobile voice services would soon make alphanumeric text transfer obsolete.


155

Nothing turned out to be less true. A couple of years ago, SMS was discovered by the mass market as a convenient complement to the voice service. Whereas voice services are synchronous (the other person has to pick up the phone and talk to you), it is also convenient to have an asynchronous way of communicating (you send a message, and the receiver reads it at his or her convenience). The widespread use of e-mail on the Internet has no doubt added to the success of SMS. Sending an SMS is usually less expensive than calling somebody, and this also makes it an attractive and cheap way of communicating simple messages, such as “See you tonight at eight at your place.” There is now a true SMS culture among youths who use specific abbreviations and shortcuts to convey common facts and sentiments (CU2Nite@8YrPlce). A GSM short message is an alphanumeric message containing a maximum of 160 characters. The mobile terminal sends the short message to the network using a special protocol that encodes the message and transports it in a special channel on the radio interface. The MSC to which the mobile terminal is logically attached takes the message and tries to deliver it to the destination terminal. If the destination terminal is switched off or out of coverage, the MSC will store the message and keep trying for a set period of time. Each short message therefore has an expiration time that determines how long the MSC will store and attempt to send it. It is the operator who defines this expiration time. If the message is destined for a subscriber in another network, the MSC that handles the message sends it to an SMS interworking MSC (SMS IW-MSC), which relays outgoing messages to other networks. A short message that comes in from another network arrives via the SMS gateway MSC (SMS GMSC). The SMS GMSC acts as a gateway for incoming messages. In fact, the SMS IW-MSC and SMS GMSC can be physically combined in the same node; they are only logically different functions. Different networks are interconnected by short message service centers (SMSC), which store and forward messages to their destination. An SMSC is little more than a server with a database for storing messages, and a program for receiving and forwarding messages. Figure 4.16 shows the network elements involved in the SMS. The GSM standard only specifies the protocols for sending messages between mobile terminals and the MSC. The functions of the SMSC are not part of the GSM standard, and there is no single standard for

156


SMS GMSC MSC

SMSC SMS IW-MSC

Figure 4.16

Network elements for the SMS.

interconnecting SMSCs. Almost all mobile operators now deploy SMSC, and there are several de facto standards for exchanging messages between SMSC. One widely used protocol is the Short Message Peer-toPeer Protocol (SMPP). SMS was originally thought of as a service for sending messages from one mobile terminal to another. Today, however, the SMSC is often also used as a means of submitting messages to mobile subscribers from external clients, like Web sites and portals. The SMSC also allows messages to be sent to large groups of subscribers at once, for example, to publicize an event. CAMEL phase 3 offers the possibility of triggering services as a result of messaging events. This facility makes it possible to start CAMEL services as the result of sending a short message. Figure 4.17 shows the CAMEL state model for SMS events. Like the BCSM, this state model runs in the SSF associated with the MSC. Triggers in the SMS state model are activated by CSI in the VLR, just like any other CAMEL service. CAMEL cannot look inside messages and trigger services on the basis of their content; only the raw event of sending or receiving a message can be used as a trigger. But as in the case of a normal call, CAMEL can recognize the originating and destination address of a message and use this as criteria to start a service. 4.6.2

Location services

Mobile telephones have the unique property that they tend to travel with their owner. Instead of having a fixed point of attachment to the network, they connect to whatever radio cell provides best coverage. This means that the network knows approximately where a subscriber is located. This information can be used to create value-added services for mobile subscribers.


157

SMS Exception

SMS Null & Start & Authorize

SMS_Collected_Info SMS Analyze & Routing SMS_Submitted

Figure 4.17

(SMS_Exception)

SMS_Failure

CAMEL call-unrelated state model for SMS events.

The range of location-based services is almost limitless. The following are some examples: ◗

Providing the caller’s location for emergency calls, to get emergency services on the spot more rapidly;

◗

Finding facilities (hotels, restaurants, police stations, gas stations) nearest to the caller;

◗

Location-based charging (for example, offering special home-zone tariffs to stimulate the use of the mobile telephone as replacement for the fixed telephone at home);

◗

Locating friends, children, persons in need of special care, such as the elderly, and even domestic animals;

◗

Tracking vehicles;

◗

Location-based games such as Geocaching (see http://www.geocaching.com).

In a normal GSM or GPRS network, the information about a subscriber’s location is distributed around the network (see also Figure 4.5 in Section 4.2.3), as follows:

158


◗

The HLR of the subscriber’s home network knows the MSC (and VLR) of the visited network to which the subscriber is attached.

◗

The MSC (and VLR) to which the subscriber’s mobile terminal is attached in the visited network knows the location area within which the subscriber is located.

◗

The radio subnetwork knows the radio cell to which the subscriber’s mobile terminal is attached.

The network never has the exact geographic coordinates of a mobile terminal. The best approximation that a network has of the mobile terminal’s location is the radio cell to which it is attached. This is not a very precise, nor a very consistent, indication of a mobile terminal’s whereabouts. Cell sizes vary because they are dimensioned according to the traffic and the nature of the environment. A GSM or GPRS cell in a city typically covers a few hundred meters, but in rural areas a cell can cover more than ten kilometers. Another problem is that GSM and GPRS networks do not offer any protocol to query information about a user’s location. We saw in Section 4.4.1 that CAMEL allows the SCF to interrogate the HLR, but this provides only very coarse information about a mobile terminal’s location. There is no CAMEL mechanism for obtaining the coordinates of the radio cell to which a mobile terminal is attached. The idea of being able to locate a mobile terminal with more precision is very appealing from the point of view of a service developer. For this reason, manufacturers of mobile network equipment have begun developing techniques to more precisely locate mobile terminals. At present there are three main techniques for locating mobile terminals. They are as follows, in order of increasing precision: 1. Cell identifier. The network knows the radio cell that the mobile terminal is attached to. Delivering this information requires no specific measurement equipment in the network, but problems are encountered, as mentioned above. The maximum precision of cell-based positioning is about a hundred meters, but on the average it can be as inaccurate as a kilometer or more. 2. Measurements on the radio interface. This technique can position the mobile terminal to more accurate coordinates within a cell, with a precision of several tens of meters. There are several measurement


159

techniques of varying complexity and precision. Some derive the distance from the mobile terminal to the cell’s antenna from the propagation delay of the radio signal; others measure the angle of the received radio signal. Depending on the approach used, the measurements can be done in the mobile terminal, in the network, or both. All positioning techniques based on measurements on the radio interface require special hard- or software to be installed in the base stations, in the mobile terminals, or both. 3. GPS-assisted positioning. This is the most accurate technique (down to a couple of meters), but it requires that a GPS receiver be installed in the mobile terminal. GPS-based positioning uses signals from special satellites. Calculating the position from the satellite signals can require some time, and it can be difficult or even impossible in buildings or when weather conditions are bad. GPSbased positioning is significantly more efficient if assisted by transmitters in the network with known coordinates that emit GPS support information. The GSM standard now includes generic network functions for all these different positioning techniques. Figure 4.18 shows the main elements of the GSM network (light gray) and the network functions for location services (dark gray). The network functions for location services are as follows: ◗

The location measurement unit (LMU) performs the actual measurements. This function is usually colocated in the BTS.

BSC LMU

GMSC

MSC Lg

SMLC

GMLC HLR Figure 4.18

Location services.

Lh

Le

External External networks client

VLR

160


◗

The serving mobile location center (SMLC) selects the positioning method and calculates the mobile terminal’s position from measurements done in the LMU, and possibly in the mobile terminal.

◗

The gateway mobile location center (GMLC) acts as the point through which client applications can request and receive location information from the network.

Clients request and receive location information from the GMLC over the Le interface. The GMLC can interrogate the HLR using the Lh interface, and can request location information from the SMLC via the MSC, using the Lg interface. There are important ethical and legal problems involved in providing a subscriber’s location information. Such information is clearly sensitive and subject to privacy regulations. For this reason, the HLR can store privacy classes that define how to handle incoming location requests. The GMLC authenticates the client that requests the location information and, depending on the identity of the client, the subscriber’s privacy information in the HLR can authorize or deny the location request. It is also possible that the user could be prompted specifically before providing location information, for example via a short message. To see how location services can be used, we will now consider a simple example of location-based charging. Suppose that a competitive mobile service provider wants to promote the use of the mobile telephone at home, as a replacement for the fixed telephone. The mobile service provider could choose to apply two tariffs: a home-zone tariff, which is similar to fixed line tariffs and valid only when the user is in or near his or her home, and a mobile tariff, valid in all other areas. Figure 4.19 shows how such a service could be implemented.

SCF (2)

(5) (6) (3)

(1)

SSF MSC

SMLC (4) Figure 4.19

Home-zone service.

(4)

GMLC


161

The procedure for home-zone calls is as follows: 1. The mobile subscriber initiates a call. 2. The MSC triggers the home-zone service and transfers control to the SCF. 3. The SCF requests the location of the mobile subscriber from the GMLC. 4. The GMLC directs the request to the SMLC in the network, which determines the position of the subscriber (the identity of the radio cell is usually enough for the home-zone service). 5. The GMLC provides the location information to the SCF. 6. If the subscriber is in his or her home zone, the SCF instructs the MSC to complete the call using home-zone tariffs. If not, the MSC is instructed to use normal mobile tariffs. Mobile location services open a world of possibilities for new valueadded services. Although there are still important technical and legal limitations, many mobile operators have begun deploying location services. Some proprietary solutions do not rely on location information from the mobile network. These solutions are based on proprietary terminals that consist of a GSM and GPS board, and that use proprietary protocols to send their position to the client application. Systems of this kind most often use short messages as the means to send the position of the terminal to the client. They do not require any specific functions from the mobile network other than SMS. Figure 4.20 shows an example of such a proprietary solution, in which the following steps are taken: 1. The application asks the terminal for its position by sending a short message. 2. The terminal determines its position using GPS. 3. The terminal sends back a short message with its coordinates. Systems like the one illustrated in Figure 4.20 are usually employed for vehicle tracking, fleet management, and security operations.

162


(1) (2)

GPS card

(3)

GSM network

External application

GSM card Terminal Figure 4.20

Proprietary location service using special terminals.

The Location Interoperation Forum (LIF) recently created by Ericsson, Motorola, and Nokia has undertaken to align the different location technologies in the industry. LIF proposes a protocol for letting applications interrogate the network about the location of mobile terminals. This mobile location protocol [2] can be used to implement the GMLC’s Le interface mentioned above, but its scope is more general than GSM alone. LIF is also attempting to come up with solutions for locating mobiles across network boundaries, and billing for location-based services and content. 4.6.3

Mobile payment services

A mobile telephone has two characteristics that make it appropriate for making payments: Like your wallet, you always carry it with you, and it is linked to an account, your mobile subscription. The idea of paying for things with mobile terminals is usually referred to as mobile e-commerce. In e-commerce people generally distinguish between micropayments and macropayments. It would be unlikely for anyone to use his or her mobile telephone to pay for a new car, but a mobile telephone would be a convenient means of payment for any transaction that would otherwise be done in cash or by a debit or credit card. There are many ways that mobile terminals can be used to make payments. The standardization community is trying to standardize


163

mechanisms for making electronic payments via mobile terminals, but there are at least as many proprietary solutions. The following types of payment solutions are found in the industry: ◗

Dual-slot terminals. Some manufacturers have proposed mobile terminals featuring a slot for credit cards. This allows for direct on-line verification of the card and execution of transactions, but on the downside, the mobile terminals are by necessity bigger and therefore more expensive.

◗

Bluetooth. This short-range radio technology (http://www.bluetooth .com) allows for transactions between mobile terminals and other devices such as cash registers, vending machines, car washes, and so on. In these types of transactions, the mobile terminal identifies the entity to be charged: the mobile subscription itself, a bank account, or even a chip wallet in the terminal.

◗

IN-based payments. In general, IN-based payments are initiated by calling a special number. This triggers an IN service that can verify the originating mobile subscriber’s number, check credit, and send a short message or call back to confirm the payment.

We will now consider the example of an IN-based mobile payment as shown in Figure 4.21. Variants of this service actually exist today. In this example, a vending machine offers the option of paying for beverages by mobile terminal. Each beverage has a special number associated with it. The procedure is as follows:

(3)

Beverage 1: dial 123445 Beverage 2: dial 123556 Beverage 3: dial 123667

SCF (4)

(5)

SSF (1)

(5) Figure 4.21

(4)

Mobile payment with IN.

MSC

(6) (2)

SDF

164


1. A mobile subscriber dials the number corresponding to the beverage that he or she wants from the machine. 2. The MSC recognizes the special number and triggers the IN service in the SCF that handles the payment. 3. The payment service in the SCF verifies that the user is authorized to use his or her subscription for payments (if it is a prepaid subscription, the SCF also verifies that there is enough credit), and reserves the cost of the beverage on the subscriber’s account. 4. The SCF orders the vending machine to deliver the beverage. In this example, we assume that the vending machine has a mobile terminal built into it. The SCF tells the vending machine to deliver a beverage either by setting up a short data call to the machine, or by sending a short message to the machine. 5. The vending machine delivers the beverage and acknowledges delivery to the SCF (either within the data call initiated by the SCF, or by sending back a short message). 6. The SCF charges the subscriber’s account with the amount due. Steps 3 to 6 form a transaction; in other words, an amount is first reserved, but it is not charged to the user until the delivery of the beverage is confirmed. In payment transactions, it is essential to ensure that payment and delivery are mutually guaranteed. In other words, no payment without delivery and no delivery without payment. This example is somewhat simplified for the sake of clarity. In reality it would also be desirable to get a confirmation from the user that he or she indeed authorized the transaction. This can be done via an automatic voice response system that repeats the order and prompts for a response. It is even possible for the network to take into account the radio cell in which the order is placed, to ensure that the user is actually in the vicinity of the machine and has not dialed the special number erroneously or maliciously. This could be done by allowing triggers only from the MSC that the vending machine is connected to. This way of payment via the network actually exists in different forms today. In Finland it has been used to pay for a car wash without leaving the car, and there also exist implementations with respect to vending machines.


165

The payment methods described in this section are only a sample of the techniques used in practice. There are many variations on these themes; combinations and even new alternatives are being invented. Nevertheless, mobile e-commerce does not yet seem to have reached general public acceptance, and remains a niche application. The problems with using mobile terminals to make payments are not only technical; there are also important legal restraints. Some countries do not allow the mobile network operator to use the mobile subscriptions for payment. By using the mobile account to do payments, the service provider effectively takes on the role of a credit provider or bank. Some governments consider this to be a conflict of interest. There are also important settlement questions: How does the money get from the telecommunications service provider to the retailer? How much of a commission can the service provider take? Who assumes liability in cases of fraud? Mobile network operators in general show little motivation to open their subscriber accounts for mobile payments, as there is simply too much financial risk involved. Many of the mobile payment services today therefore use debit or credit accounts at regular banks, rather than the mobile subscription itself. Mobile e-commerce is a vast topic that would justify a book-length discussion in its own right. In this section we have only touched on some of the possibilities.

4.7

3G mobile networks

Work on defining standards for 3G mobile networks started well before the first GSM network was rolled out. In the second half of the 1980s, ETSI started investigating the concept of the UMTS as the successor of GSM. Around 1987 the European Commission funded a large-scale research project on 3G mobile networks as part of its Research for Advanced Communications Europe (RACE) technology program. This project, called RACE 1043 Mobile, ended in 1992 with a comprehensive description of what such a system could be like. It still left many technical issues unresolved. Around the same time, ITU-T had started working on the future public land mobile telecommunications system (FPLMTS, pronounced “flumts”) that was to become the worldwide 3G mobile network standard.

166


Throughout the 1990s, the standardization process was marred by differences over the radio technology to be used. The initial debate was over whether or not to use code-division multiple access (CDMA), a new multiple access technique, or whether to stick to TDMA, the technique used in GSM. Similar disputes arose on whether to use FDD, like in GSM, or time-division duplex (TDD). The discussions were often fueled by the interests of individual manufacturers holding crucial patents on one technology or another. The climax occurred when Ericsson and Qualcomm got tied up in legal battles over their respective patents for CDMA. This impasse eventually drove ITU-T to define a framework of standards called International Mobile Telecommunications 2000 (IMT 2000), rather than to standardize one 3G mobile network standard. 4.7.1

3GPP

In spite of the differences of interest, there was a strong motivation in Europe to agree on one 3G mobile network standard, to leverage the worldwide success of GSM. UMTS standardization activity in ETSI was converging faster than ITU-T. In 1998 ETSI created the 3GPP to involve other standardization bodies in the standardization of UMTS. 3GPP is a collaboration initiative, not a standardization body. It produces specifications but not standards. The members of 3GPP are standardization organizations: ETSI (Europe), CWTS (China), T1 (United States), TTA (Korea), ARIB and TTC (Japan). It is up to the 3GPP member organizations to convert the 3GPP specifications into standards. Yet any company that is a member of one of the organizations that form 3GPP can participate directly in 3GPP specification work. All 3GPP specification work started from ETSI’s existing GSM standards. For this reason 3GPP specifications closely follow the structure and numbering of ETSI documents. 3GPP also completely aligns with the timing of ETSI standards. Between 1994 and 1999 ETSI produced a new release of the GSM standards every year. 3GPP initially adopted this timing too, but both ETSI and 3GPP abandoned this scheme in 2000. Now there is simply a new release when significant modifications are made in the specifications. Before 1999, the releases of both 3GPP specifications and ETSI standards are therefore numbered by year (R97, R98, R99). After 1999 they are simply numbered consecutively, starting with 4 (R4, R5, and so on).4 3GPP issued the first full UMTS specifications in 1999. From that time onward, each release has contained several kinds of documents:


167

◗

Pure GSM and GPRS specifications (for example, all documents that specify the GSM radio interface and voice codecs);

◗

Specifications that apply to both GSM and UMTS (for example, mobility management procedures);

◗

Specifications unique to UMTS (for example, the multimedia system).

Because there are documents that are common to GSM, GPRS, and UMTS, 3GPP and ETSI completely synchronize the release of these systems. In other words, from R99 onward, every release contains updates of GSM, GPRS, and UMTS. Figure 4.22 compares the GSM time line with that of UMTS. In this figure, R95, R96 … R99, R4, and R5 refer to the ETSI and 3GPP releases of GSM and UMTS. R99 is the first UMTS standard, and from this point onward the standardization of GSM and UMTS has been completely synchronized. A prominent standardization body absent from 3GPP is ANSI. ANSI considered that American standards were too poorly represented in 3GPP specifications and instead founded an alternative partnership program, 3GPP2. The structure of 3GPP2 closely matches that of 3GPP, and the two groups do cooperate. Most standardization organizations are members of both 3GPP and 3GPP2, with the exception ETSI, which is not in 3GPP2, and TIA (United States), which is not in 3GPP. However, both are observers in the other group. 3GPP2 does not follow the same document structuring and releases as 3GPP and has a different technical approach. 3GPP2 adopts WIN rather than CAMEL as the basis for network intelligence in mobile networks, and its 3G mobile core network is heavily influenced by IP and mobile-IP standards from the IETF.

4. The decision to start with 4 rather than 1 was made purely for the purposes of document-version numbering. In both 3GPP and ETSI, a document version has the form x.y.z, with x representing a major release, y corresponding to technical modifications, and z representing nontechnical changes or minor corrections. The UMTS, GMS, or GPRS release to which the document belongs is reflected in x; however, numbers 1 and 2 are reserved for draft and final draft for approval. From there onward x = 3 means R99, x = 4 means R4, x = 5 means R5, and in the future x = i will mean Ri.

168

Next Generation Intelligent Networks First GSM standard (phase 1) Frequency First Foundation of 3GPP allocation and commercial basic radio GPRS networks technology ETSI commercial GSM phase 2 takes over networks chosen standard from CEPT

Start of CEPT Groupe Spéciale Mobile

R95 R96 R97 R98 R99 R4 R5

GSM 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 00 01 02 UMTS RACE1043 project “Mobile”

Start of ETSI UMTS project

Frequency allocation

Foundation R99 R4 R5 of UMTS First UMTS Forum ETSI commercial decides on networks basic radio technology First UMTS standard

Figure 4.22

GSM and UMTS time lines.

In this book we will concentrate on the UMTS standard as it is specified by 3GPP and ETSI. In the following section we will take a closer look at these specifications. 4.7.2

UMTS

Although UMTS builds on the success of GSM and GPRS, it is far more ambitious. The ambitions of UMTS are to provide the following: ◗

Universal mobile coverage. UMTS is not just a cellular mobile network, but it also integrates satellite access and in-house cordless telephony (like DECT). Subscribers can move seamlessly from one environment to another with the same subscription and terminal.

◗

Total mobility. UMTS not only provides terminal mobility, but also personal mobility and service mobility. Service mobility is embodied in the UMTS VHE concept, which is explained below.

◗

Convergence. UMTS is both a fixed and mobile network, supporting voice, data, and multimedia communications.

◗

High data rates. The target for UMTS is to support 2 Mbps indoor, 384 Kbps outdoor, and 144 Kbps in remote areas. This is an order of magnitude higher than for GSM or GPRS.


169

Such an ambitious network will not fall from the sky, and ETSI was quick to recognize the need for an evolution path from GSM and GPRS to UMTS. The first UMTS standard issued in 1999 is little more than a new radio interface for a combined GSM and GPRS network. The new radio interface is called the UMTS terrestrial radio access network (UTRAN), and it substitutes the GSM BSS. The UTRAN uses different frequencies, a different multiple access technique, and different duplexing and coding schemes than those used in GSM and GPRS. In UMTS the base transceiver systems are called node B, and the base station controllers are called radio network controllers (RNC). In the core network it is expected that there will be a gradual transition from a mixed circuit-switched and packet-switched network to a completely packet-based network. To accommodate any evolution scenario, the UMTS standard defines three core network domains that can live side by side: 1. The circuit-switched domain provides circuit-switched communication services, and is optimized for voice. The elements that form the circuit-switched domain are MSC and GMSC, as in GSM. The only difference is that UMTS treats the (G)MSC as a soft switch (see Section 3.2.8) and partitions it in an MSC server and a media gateway (MGW). 2. The packet-switched domain provides generic packet-based communications to and from mobile terminals. It is formed by the same network elements as those for GPRS, the SGSN and GGSN. 3. The multimedia IP domain provides multimedia services using packet communications. This part of the UMTS network is based entirely on the use of SIP signaling (see Section 3.2.4). Figure 4.23 gives an overview of UMTS (the thick lines represent data connections and the thin lines represent signaling connections). Although it is a complex picture, it is still easy to recognize the elements of the GSM and GPRS network as described in Figure 4.3 and Figure 4.7. There are a few things that one observes immediately when looking at UMTS. One is that the packet domain is virtually unchanged with respect to GPRS. The only difference is the addition of a border gateway (BG) function that allows mobile packet networks to interconnect through special interconnection providers. This is important for services

170


Circuit-switched domain MSC server

GMSC server

PTSN, ISDN, or GSM

VLR BSC MGW

BTS

MGW

R-SGW HSS (HLR) RNC

MS

CSCF MGC MRF

MGW

Multimedia domain

GERAN

NodeB Internet

UTRAN GGSN SGSN

GPX Packet switched domain BGW Figure 4.23

UMTS overall architecture.

that require a guaranteed quality of service, because the Internet cannot guarantee QoS. The circuit domain still resembles the GSM network, except that the MSC is now specified as if it were a soft switch. The (G)MSC server only does signaling, while the MGW represents the switching function itself. The ETSI specifications allow the circuit and packet domains to be connected both to the traditional GSM and GPRS radio network (GERAN) and to UTRAN. What is completely new in UMTS with respect to GSM and GPRS is the multimedia domain. The specifications of this domain draw heavily on IETF models for session establishment (SIP) and media gateways (MGCP) that were discussed in Chapter 3. The call-state control function (CSCF) is the central element in the multimedia domain. It takes care of the signaling for setting up multiparty multimedia sessions and maintains the state of these sessions. The CSCF uses SIP for signaling and session control, and can perform the proxy and redirect functions of SIP servers.


171

In future UMTS networks it is expected that the packet domain will carry all communications, in addition to voice. The multimedia domain includes an MGW that adapts voice (and video or any other media) for transmission over IP networks, and that can interface with legacy telephony networks. The MGW is controlled by the media gateway controller (MGC), exactly as we saw in Section 3.2.7. The CSCF negotiates connections with the telephony network through a signaling gateway (R-SGW) that translates between SIP and SS7 messages. The multimedia domain also foresees a special resource function for multimedia-specific functions like video bridging. This node is called the multimedia resource function (MRF). The UMTS contains one element that is common to all three domains: the home subscriber server (HSS). The HSS is an extension of the HLR. It contains all the information of the HLR, but in addition it can also contain subscription data and user profiles for multimedia services. The idea of the HSS is to serve as a central database for subscriptions, profiles, and mobility management, so as to enable roaming between GSM, GPRS, and UMTS. For the sake of simplicity, Figure 4.23 does not show all the additional functions that UMTS inherits from GPRS and GSM, such as the SMSC, GMLC, and most importantly the CAMEL functions (SSF, SCF). In previous sections of this chapter we discussed where these functions are located. Although UMTS is meant to provide universal coverage, its initial deployment will occur only in populated areas where there is a market for high-speed data services. This will probably limit it to big-city centers. Subscriptions and terminals will typically be dual mode, giving the subscriber the possibility to rely on GSM and GPRS where there is no UMTS coverage. Many operators will implement joint mobility management for UMTS, GPRS, and GSM, which is possible because of the compatibility of the HSS with the HLR. In early deployment scenarios, people are likely to use UMTS for data and multimedia, while they continue making voice calls with GSM. However, in the future UMTS is expected to take over completely from GSM and provide all services, even voice over an all-packet infrastructure. Operators and service providers are more than conscious that if they are to make UMTS a serious business, it must be more than just a replacement for GSM. In the introduction to this section it was emphasized that UMTS is an ambitious concept. How will these ambitions be realized? What services will determine the added value of UMTS in the future?

172


ETSI has already defined one innovative 3G mobile network service that we shall discuss in the next section: the VHE. 4.7.3

VHE

2G mobile networks such as GSM offer two types of mobility: terminal mobility and user mobility. While terminal mobility is an intrinsic feature of cellular networks, personal mobility is covered by SIM cards, which contain a user’s subscription and can be exchanged between terminals. 3G networks add an additional dimension: service mobility. The idea of service mobility is that all services that one is subscribed to in the home network remain accessible when roaming to other networks. The name given to the service mobility concept in UMTS is the VHE. What follows is the ETSI definition of the VHE according to [3]: The virtual home environment is defined as a concept for personal service environment portability across network boundaries and across terminals. The concept of VHE is such that users are consistently presented with the same personalized features, user interface customization and services in whatever network and on whatever terminal, wherever the user may be located.

3GPP builds its definition of the VHE on two key features: ◗

Service personalization, whereby the VHE uses subscriber profiles to adapt services to the usage preferences of each subscriber;

◗

Service portability, whereby in roaming situations the VHE adapts services to the capabilities of the visited network.

As the name suggests, the VHE gives a subscriber access to his or her home environment, wherever he or she roams. The home environment is defined not so much as a physical network function, but rather as the collection of all services that a subscriber has access to in the home network. 3GPP does not delimit exactly what is meant by a VHE service. We assume that 3GPP intends for the VHE to apply to the broadest possible definition of a service, from basic connectivity (voice, data) to value-added services (IN, CAMEL), to content (video, games, multimedia, portals). Figure 4.24 illustrates the VHE concept. The home environment (HE) can be seen as the collection of all services that are accessible in the home


173

network. The home environment has access to user profiles to adapt all services to the subscriber’s preferences. The VHE exports the homeenvironment services to the visited network and adapts the services to the visited network. If the subscriber uses terminals in addition to the home terminal, the VHE adapts the service to those terminals as well. Roaming in GSM is simple, because it only involves voice and short messaging. The VHE extends roaming to more complex services, such as multimedia, payment transactions, games, and content. The VHE also makes roaming possible between different networks, for example between GSM and UMTS. So far the VHE is only a concept, described from the viewpoint of the subscriber in rather abstract terms similar to those used in the quote above. It is important to bear in mind that the home environment and VHE boxes drawn in Figure 4.24 are not network elements, but simply concepts. The VHE concept is so broad that it is difficult see how it must be implemented. Is the VHE an Internet portal? Is it a virtual private network? Is it a unified messaging service? Is it an IN service based on personal profiles? The VHE probably means different things in different contexts. In a corporate environment it can be seen as a means to plug into the company intranet, from wherever a user may be in the world. A personal VHE, on the other hand, would be more like a portal that allows the user to store personal data and handle personal communications (e-mail, voice mail, prepaid calling account, and call-completion profile). Table 4.10

Adapt services to network and terminal Personalize services

Deliver services VHE

Visited network Figure 4.24

The HE and the VHE.

Export services

HE

User profiles

Home network

174


Table 4.10 VHE from Corporate- and Private-User Perspectives Corporate User

Private User

Ubiquitous access to company intranet

Worldwide roaming for voice and Internet access

Fixed and mobile access with the same subscription

Portal with personalized content

Ubiquitous access to unified messaging mailbox

Remote surveillance and remote control of the home

Electronic payments via the mobile terminal, billed to the company account

Electronic banking and electronic payments

shows the different perceptions one may have of the VHE, depending on the environment. Because there are different interpretations of the VHE, it is difficult to define it unambiguously. In an attempt to define an implementation that covers the broad meaning of the VHE, ETSI came up with the model shown in Figure 4.25. Following this reference model, a service can be executed in the home network, the visited network, in the terminal, in the SIM card, or in any combination of these four environments. The service itself is implemented by a service logic program (PRG) and

MMI PRG

PRG DAT

ExE UMTS SIM

Figure 4.25

DAT

PRG

DAT

PRG

ExE

ExE

ExE

CoC

CoC

CoC

Terminal

Visited network

Reference for the implementation of the VHE.

DAT

Home network


175

service data (DAT). The service logic is executed in a service logic execution environment (ExE). The model provides an abstract view of connection of control (CoC), which may in reality be circuit switched or packet switched. The terminal also has a simple man-machine interface (MMI) that allows for interactions with the user. Although somewhat simplistic, this model does provide a reference for categorizing the different ways of implementing services, as Figure 4.26 demonstrates. 3GPP and ETSI soon realized that the model drawn in Figure 4.25 was too restrictive. There are many more functions in the network that can be used to implement services, for example SMSCs, SMLCs, WAP gateways, and even external application servers. 3GPP and ETSI therefore sought to define a more general implementation model for the VHE, one that would allow all functions to be represented. 4.7.4

Open service access

The most obvious candidate for delivering value-added services in UMTS is CAMEL, because it is available today and because it is built on the proven concept of IN. But CAMEL and the Internet have completely opposite models for service delivery. CAMEL is based on the IN conceptual model, in which intelligence is centralized in the SCF. In the Internet, intelligence is completely distributed. Any individual can mount an application server in the Internet.

DAT

PRG

CAMEL

DAT

MMI

DAT

PRG

MMI

PRG

MExE

SAT

ExE

ExE

ExE

CoC

CoC

CoC

CoC

SIM

Terminal

Terminal

Visited network

Home network

Figure 4.26

Mapping of different service implementations to reference model.

176


UMTS unifies the features of mobile telephony and Internet, and for this reason it needs a model that accommodates both centralized and distributed network intelligence. The model that 3GPP designed for deliver5 ing intelligent services in UMTS is the OSA. 3GPP did not want to reinvent the wheel and define yet another architecture, but it tried to reuse as much as possible of what was already defined in IN, CAMEL, and the Internet. OSA is defined bottom-up, starting with the functions already provided by the network. OSA calls these existing network functions service capability servers (SCS). The MSC, SGSN, GGSN, CSCF, CAMEL SCF, SMSC, GMLC, WAP gateways, and HSS are all considered SCS in OSA. Each delivers a specific functionality, as shown in Table 4.11. There are many SCS and each is accessible through its own control protocol, for example ISUP and MAP for the MSC, CAP for the SCF, SMPP for the SMSC, and SIP for the CSCF. Many exciting new services for UMTS will derive added value from combining different network functions. It is easy to imagine how much complexity could be introduced when building services that must deal with the protocols of two, three, or even five different SCS. For this reason OSA has a second layer that groups the elementary SCS functions into service capability features (SCF).6

Table 4.11 UMTS Service Capabilities Capability

Function

MSC, GMSC

Call establishment

SGSN, GGSN

Establishment of data connections

HSS, HLR

Subscriber location and status

SCF

Service logic execution

SMSC

Store and forward of short messages

WAP gateway

Access to WML content

CSCF

Session establishment, proxy, redirect

SMLC, GMLC

User geographic location

5. OSA originally stood for open service architecture. The R99 specifications still use this name, but after R4, 3GPP and ETSI use the term open service access. 6. Unfortunately, the acronym for the OSA service capability feature is the same as that for the IN service control function (i.e., SCF). The reader is advised to take note of the context in which these acronyms are used so as to avoid mixing up the two concepts.


177

Just like in the service plane of the IN conceptual model, an SCF is a unit of functionality that can be employed as a reusable building block for services. Examples of features are get subscriber status, send short message, read short message, set up voice call, notification of call to number 0800-123456; there are many more. To make it easier for software developers to create new services out of components, 3GPP defined an object-oriented application programming interface (API) for each SCF. In doing so, 3GPP achieved what ITU-T and ETSI have been trying to do for IN: provide a standard, objectoriented component model for services that is more in line with industry standards in programming than the SIB model. Figure 4.27 gives an overview of OSA. One cannot help but observe that OSA resembles the IN architecture. Just like the old IN SIBs, the service capability features are service components. The difference is that they cover a much broader range of network functions and that they have an object-oriented rather than a procedure-oriented interface. So what does the OSA API look like? While 3GPP wrestled with the problem of defining the OSA, a group of companies headed by BT, Microsoft, Siemens, Nortel, and Ulticom turned out to be working on a very similar problem. This group was called the Parlay group. The first Parlay programming interfaces were published in the same time frame that

Applications Application programming interface

set up call

locate user

send message

....

Service capability features

P r o t o c o l s HLR

SCF

SMSC

Network Figure 4.27

UMTS open service access.

WAP

Service capability servers

178


3GPP was working on OSA. Again 3GPP decided against reinventing the wheel, and used a large part of Parlay in OSA. Ever since their creation, Parlay and OSA have had strong influence on each other. OSA R99 and R4 bear strong resemblance to the Parlay version 2 specifications, although some interfaces are different. Over the last couple of years the relationship between OSA and Parlay grew so strong that 3GPP and the Parlay group decided to align the two from OSA R5 and Parlay version 3 onward. Many people in the industry say that OSA is creating the pathway for the future of IN. Chapter 5 is dedicated primarily to Parlay and OSA.

References [1]

Christensen, G., P. Florack, and R. Duncan, Wireless Intelligent Networking, Norwood, MA: Artech House, 2000.

[2]

Location Interoperability Forum (LIF) TS 101, Mobile Location Protocol, version 2.0.0, November 2001.

[3]

3GPP TS 22.121, Virtual Home Environment (VHE), versions 3.3.0 (release 99), 4.1.0 (release 4), 5.1.0 (release 5).

CHAPTER

5 Contents 5.1

Parlay

5.2

OSA

5.3

Using OSA

5.4

Implementing OSA

5.5

OSA applications

Distributing intelligence Intelligent networks were originally designed for telephony networks. The IN model assumes that the switching equipment and SCFs are all deployed and operated by the network operator. Services are controlled and managed centrally by the network operator. The IN model made perfect sense in the telephony networks of the late 1980s and early 1990s, but the personal computer, the Internet, and deregulation of the telecommunications market have since shaken its foundations. In the 1990s it became clear that IN had to undergo some revision in order to cope with the new requirements. The IN model does not seem prepared to deliver valueadded services in an environment that is becoming increasingly heterogeneous and competitive. Several industry initiatives sought to develop more state-of-the art software architectures for service deployment and operation. Parlay and OSA appear to be the technologies that are leading the way in the

179

180


evolution of IN. The key concept in both Parlay and OSA is the distribution of service control. In this chapter we will take a closer look at these initiatives.

5.1

Parlay

In a move that is typical of the turbulent telecommunications market, the U.K. Office of Telecommunications (Oftel) announced in the second half of the 1990s that British Telecommunications PLC (BT) would have to allow third-party service providers access to its switches. With this move, the U.K. regulatory body meant to encourage competition in the area of service provisioning. The opening of the control interfaces to the switch evidently introduces an important challenge to the integrity and security of the network. Obviously, BT was reluctant to publish these interfaces and allow plain access to them from outside its network. Instead, BT responded to this requirement by teaming up with a number of vendors and starting an initiative to define an open but secure interface to their switches. This is how in early 1998 the Parlay group was born. The first members of Parlay1 were BT, Microsoft, Nortel, Siemens, and Ulticom. The Parlay group’s mission was to publish a first version of its interface as soon as possible. Parlay delivered its first complete interface specification in 1998, only nine months after the group was created. Until 2000 Parlay was a private industrial group, although its specifications were public. In 2000 the Parlay group opened its membership to any party that signs the cooperation agreement and pays the dues. Parlay currently includes approximately 60 full and affiliate members. 5.1.1

Parlay concept

In a conventional telephony network with IN functionality, only the network operator has access to the protocol between the SSF and SCF. No party other than the network operator or the vendor of the intelligent networks platform can deploy new services or modify them. There are some cases in which services are implemented by third-party software developers, but these are extremely rare. In any case, the network

1.

Parlay is not an acronym, but the organization’s given name.


181

provider remains solely responsible for deploying, operating, and managing these services. The idea of Parlay is to open this interface to third parties, so that others besides the network operator can create and deploy services. This is illustrated in Figure 5.1. But the concept of Parlay goes further than just opening up the interface between the SSF and SCF. The Parlay interface also allows access to other network functionalities, such as messaging, charging, QoS negotiation, and mobility management in mobile networks. The set of network functionalities accessible through the Parlay interface is expanding with each Parlay release. A key aspect of Parlay is that it provides an extensive framework of security and service management. Network access to third-party applications is subject to authentication and authorization. The Parlay interfaces allow the network provider to set different privilege levels, depending on the reliability of the third party. While some third-party applications can be allowed to receive only notifications from the network, other more trusted applications can control calls and connections. Parlay also provides facilities for nonrepudiation; applications can be required to digitally sign an on-line agreement for the use of certain features.

Proprietary interface

PSTN operator Parlay concept.

Public interface

SCF

SSF

Figure 5.1

Third-party application

Proprietary interface

Parlay

Intelligent network

SMF

182


5.1.2

Parlay business model 2

Rather than introducing a new architecture, Parlay defines an API for existing network features with a management and security framework. The definition of the Parlay programming interface starts from a business model that specifies which business entities play a role in service provisioning and what interfaces they manage. This model is presented in Figure 5.2. There are three main entities in the business model presented in Figure 5.2: 1. Client application. This is the third-party application that accesses network features through the Parlay interface. The client application is deployed and operated by the enterprise administration, a third-party business entity.

Subscription Enterprise administration Trust and security management Discovery Integrity management Framework provider

Call control User interaction Messaging Mobility

Client application

Parlay framework

QoS Connectivity management

Parlay service

Service provider

Service factory Registration (Not in specified Parlay) Figure 5.2

The Parlay business model.

2. It is important that the reader understand the difference between a protocol and an API. A protocol is a set of messages and rules for communication between two hardware or software entities. An API is a set of procedures or operations offered by an operating system, a programming language, or an application. Object-oriented programming languages usually offer APIs in the form of object libraries: files with object code that must be linked with the application. An API can be used to provide application programs with access to protocols. For example, the Unix sockets API allows applications to exchange data over TCP/IP connections.


183

2. Framework interfaces. These offer all support functions for Parlay, in particular security and management features. The Parlay framework is administered by the framework provider. 3. Service interfaces. These offer access to network features, such as call control, messaging, and mobility management. The Parlay service interfaces are administered by the service provider. Parlay wanted to ensure complete flexibility in mapping Parlay business roles onto real-world physical entities. In many cases the network operator will take on the role of both the framework provider and the service provider. Parlay, however, also allows the provider of the framework interface to be different from the provider of the service interface. In this way the framework interface could be offered, for example, by an independent clearinghouse, while the service interface is offered by the network operator. 5.1.3

From Parlay to OSA

As soon as Parlay had issued its first specifications in 1998, it became evident that there were many issues yet to be resolved before these specifications would be usable in practice. In 1999 Parlay published another major release of its interfaces, version 2.0. In mid-2000 it released the more stable version 2.1, which was generally considered the first practically implementable interface. At the same time that Parlay began gaining momentum, 3GPP and ETSI were working on the OSA interfaces for UMTS (see Section 4.7.4). The initial OSA specifications drew heavily upon Parlay. They were initially a mix of Parlay version 1.2 and 2.1 specifications, with some new additions made by 3GPP. Because Parlay and OSA are so similar, most manufacturers have been combining both interfaces in one product. They soon realized that having one universal specification for both Parlay and OSA would make much more sense. The Parlay group and ETSI pledged to fully align the Parlay and OSA specifications from Parlay version 3.0 and OSA release 5 onward. They published their first joint Parlay 3.0–OSA specification in December 2001 [1]. Parlay 3.0 and OSA R5 are identical except for two interfaces that are part of Parlay but not of ETSI: one for policy management and one for presence and availability (PAM). Figure 5.3 illustrates the relationship between the different versions of Parlay and OSA.

184


Parlay group 1999

3GPP/ETSI

Parlay 1.0 Parlay 1.1 Parlay 1.2

2000

Parlay 2.0

OSA release 99

Parlay 2.1

2001

2002

Figure 5.3

OSA release 4

Parlay 3.0 = OSA release 5 +Policy management +Presence and availability

Relationship between Parlay and OSA releases.

Even though the Parlay and OSA interface specifications have now been aligned, there remains some difference between the two. Parlay specifies only a business model and a set of interfaces. Parlay very explicitly refrains from specifying any requirements on the implementation of the interfaces. OSA, on the other hand, specifies more than just an interface, and must be seen as a service architecture. Unlike the Parlay group, ETSI also makes recommendations for mapping OSA interfaces to network protocols like MAP and CAP. Whereas Parlay is a generic and stand-alone interface specification, OSA is an integral part of the service architecture for UMTS. Nevertheless, the programming interfaces for Parlay and OSA are now identical, except for the two interfaces mentioned above. In the following section we will look in more detail at the OSA specifications and how they allow applications to control resources in the network. Although the discussion in Section 5.2 is explicitly about OSA, it should be understood that this discussion also applies to the Parlay interface.


5.2

185

OSA

Although the idea behind OSA is easy to grasp, the OSA interfaces themselves are rather complex and technical at first sight. Many people are put off by the sheer amount of diagrams, data types, and parameters when downloading the OSA specifications from the ETSI or Parlay site. OSA is really not that complicated if you know how it is structured. You do not have to know all of an interface’s operations and parameters to understand OSA and what can be done with it. In this section we will take a closer look at OSA, placing special emphasis on its structure and applications. We will not explain each interface in detail; the full specifications can be downloaded from the ETSI and Parlay Web sites for free (see the list of Web sites in Appendix B). 5.2.1

OSA interfaces

OSA and Parlay consist of 10 main interface groups, listed in Table 5.1. The framework is a special interface that contains all support functions for OSA, most importantly security and access functions. The other interfaces are service interfaces that allow applications to control specific network resources. Table 5.1 OSA (Parlay) Interfaces Interface

Short Description

Framework

Overall security, integrity, and management framework for OSA

Call control

Setting up, releasing, and managing calls, conferences, and multimedia connections; notifications of call- and connection-related events

Data session control

Setting up, releasing, and managing data sessions

User interaction

Interaction with a user to play or display messages and retrieve user input

Mobility

Notifications of user location and user status

Generic messaging

Sending and receiving messages (e-mails, voice mails, SMS); manipulating mailboxes and mail directories

Terminal capabilities

Interrogating a terminal for its capabilities

Connectivity management

Negotiation and management of QoS and service-level agreements in IP networks

Account management

Creating, deleting, and modifying subscriber accounts

Charging

Reservation and charging of units of volume or money against a subscriber account

186


The Parlay 3.0 interfaces are the same as these OSA interfaces. As observed in Section 5.1.3 however, Parlay offers two extra interfaces that are not part of OSA: 1. Policy management. This allows for the creation and management of policy classes and their parameters; the interface was added to provide application service providers (ASP) with the possibility of defining service-level agreements (SLAs). 2. PAM. This allows subscribers and terminals in the network to exchange information about presence and availability; the interface is typically used for the implementation of services, such as buddy lists and instant messaging. It is based on the API specified by the PAM forum. The OSA interfaces are defined as a set of object types (classes). A class defines the operations (or methods, in object-oriented vocabulary) that can be called on the object and their parameter types. Class definitions follow an inheritance hierarchy. A new class can be derived from an existing one through inheritance of its definition and extension to new data types and operations. OSA interfaces are specified in UML and IDL. Both are specification languages, not programming languages, and ETSI and Parlay have chosen them deliberately so as not to bias any particular implementation of their interfaces. Each of the OSA interfaces is specified in four parts: 1. Class diagrams. These provide an overview of the inheritance structure of the interface, its classes and operations, in UML graphical and textual notation. The class diagrams represent the static structure of the interfaces. 2. Sequence diagrams. These show key examples of use of the interface in the form of UML message sequence charts. The sequence diagrams illustrate the dynamic behavior of the interfaces. 3. Interface specifications. These provide the formal definition of the interface in the OMG’s interface definition language (IDL). 4. Data definitions. These provide formal data-type definitions in IDL.


187

The interface specification and the data definition make up the formal part of the interface definition. The class diagrams and sequence diagrams serve as aids to understand the interface; they are not prescriptive. 5.2.2

General interface structure

All OSA interfaces listed in Table 5.1 follow a more or less similar structure. For each interface, OSA defines two object classes on the network side: 3

is the actual interface that offers operations to control resources in the network. Here is the name of the interface as shown in Table 5.1, such as generic messaging or terminal capabilities.

1.

Ip

2.

IpManager

4

is a management interface that contains the operations to start and manage an instance of Ip. It is also used to request server-related event notifications like overload conditions.

To allow the network to send notifications to the client application, the client application also has to implement two object classes for each interface: is a client-side interface that contains operations for receiving results and notifications from the Ip interface.

1.

IpApp

2.

IpAppManager

is an interface for receiving results and notifications from the IpManager interface.

3. All Parlay and OSA interfaces are prefixed with Ip (as in, for example, IpConfCall). This prefix is rather awkward, suggesting as it does some association with IP; in this context it stands for Interface Parlay. Parlay and OSA use a notation scheme that is common in object-oriented design: Class names always begin with uppercase letters (e.g., IpCall), and operation names always begin with lowercase letters (e.g., routeReq). Names and identifiers are not allowed to contain spaces (e.g., route Req is not a valid operation name) and underscores are not generally used (e.g., route_Req is a valid operation name but not used). 4. In object-oriented terminology, this management interface is usually called the factory interface for IP.

188


Figure 5.4 illustrates the general structure of the OSA interfaces. OSA does not follow this pattern rigidly for all interfaces, but most more or less conform to this structure. Following object-oriented terminology, these client-side interfaces are often called callback interfaces. Why are callback interfaces used on the client application? Just like procedure calls in programming languages such as Fortran and Pascal, operations on objects are synchronous: a client application that requests an operation on an object has to wait for this operation to finish and send back the result. But synchronous communication is not always the most convenient, especially if it difficult to predict when a result will come back or when the result is a periodic notification message. By putting a callback interface on the client it is possible to decouple the delivery of the result from the request. Callbacks are used to allow asynchronous communication with synchronous operations. Since telecommunications are more asynchronous than synchronous, OSA makes extensive use of such callback interfaces on the client. The drawback, of course, is that the client application must then implement part of the OSA specifications. It is not in the scope of this book to discuss each of the OSA interfaces in detail; that would require a separate book-length discussion. Instead, we will take a close-up look at one of the interfaces: the call-control interface.

OSA server

Application

IpManager

IpAppManager Notifications

Creates, manages

Ip

IpApp Notifications, results

Figure 5.4

Common OSA interface structure.


5.2.3

189

OSA call-control interface

OSA in fact does not offer a single interface for call control, but several. Some OSA interfaces, such as those for call control, consist of several classes with an inheritance relation. A new object class is defined in terms of an existing one by inheriting and extending the operations of the parent class. This allows for the reuse of operation definitions between classes, and the definition of hierarchies of classes with different levels of functionality. Figure 5.5 shows the inheritance structure of the OSA call-control interface. It shows only the main classes defined at the server side, not the manager classes or the client-side classes mentioned in the previous section. Figure 5.5 uses UML notation to denote relations between objects. A triangle denotes inheritance from and arrows denote other types of relationships. The cardinality of each relationship is indicated in numbers on the corresponding arrow (an arrow with 1 on the tail and 0…n on the head is a one-to-many relation). There are three main types of calls defined in OSA:

1

0...n

IpMultiPartyCall

IpCallLeg

1

0...n

IpMultiMediaCall

IpMultiMediaCallLeg

1

0...n 0...n

IpMultiMediaStream

1 IpConfCall

1 0...n

1 IpSubConfCall

Figure 5.5

0...n

Call-control interfaces (OSA server side).

190

Next Generation Intelligent Networks 5

1. Multiparty calls: calls with zero or more parties . OSA distinguishes between the call and its connections. The connections set up within a call are represented by call-leg objects. This separation makes it possible to control individual connections within a call, or in other words to connect and disconnect call parties within the scope of a call. 2. Multimedia calls: multiparty calls that allow for multimedia connections between parties. A multimedia call can create and delete multimedia call legs. Each multimedia call leg can have several multimedia streams associated with it and can monitor these multimedia streams. 3. Conference calls: multimedia calls in which there exists the possibility of defining additional relationships between the parties. The party that is appointed chair has privileges to add parties, drop parties, give a party a turn to speak, and interrupt a speaking party. The party that is appointed speaker has the privilege of speaking while other parties listen. It is possible to create subconferences, to split or join subconferences, and to move parties from one subconference to another. Each of the interface classes in Figure 5.5 defines the operations it supports. We will now look at an example: Table 5.2 lists the operations defined for the multiparty call class. An operation definition has the following format: operationName (p1: in t1, p2: in t2, .., pn: out tn): operationType

where operationName is the name of the operation, p1, p2, pn are parameter names, t1, t2, tn their types, and operationType is the output type of the operation. The words in and out indicate whether the parameter is an input or output parameter. If an operation returns no value, then operationType = void.

5. A call with zero parties has not been routed to a subscriber. This could be the initial state for a call or an intermediate state after its participants have left. OSA allows these states to be modeled and controlled explicitly. A call with one party can be, for example, a subscriber connected to a network resouce, such as a voice mailbox.


191

Table 5.2 Operations of the IpMultiPartyCall Class Operation

Description

getCallLegs

Returns a list of references to the call legs attached to the call

createCallLeg

Creates a new call leg, but does not attach it to the call (this must be done explicitly by an operation on the new call leg)

createAndRouteCall Leg

Creates a new call leg and automatically connects it to the call

superviseReq

Allows the call to continue for a set period of time. After the time expires the application is notified (typically used in prepaid calls)

getInfoReq

Allows an application to request that call information be sent after the call is deassigned or released (typically for charging purposes)

setChargePlan

Sets a charge plan for the call

setAdviceOfCharge

Allows an advice of charge to be sent to the parties in a call before connection of the call legs

deassignCall

Disconnects the call from the application, after which the application can no longer control the call, but the call continues in progress

release

Releases a call and all its associated legs

For example, the OSA defines the operation follows:

createCallLeg

as

createCallLeg (callID : in TpSessionId, appCallLeg : in IpAppCallLegRef) : TpCallLegIdentifier

The name of the operation is createCallLeg, its type is TpCallLegIdentifier, and its parameters are calId and appCallLeg. CalId is an identifier for the call that creates the leg and appCallLeg is the client interface where notifications are to be sent (the callback interface, discussed in Section 5.2.2). A normal point-to-point telephone call can be set up as an OSA multiparty call with two call parties. But in a normal telephone call it is not necessary to have control over individual call legs. For convenience, OSA therefore also defines a simpler call control interface, IpCall, which allows the setup only of traditional two-party telephone calls.

192


Instead of the operations createCallLeg, createAndRouteCalland getCallLegs, the IpCall class defines only one operation, routeReq, which automatically creates and attaches the call legs for the originating and terminating party. IpCall does not allow individual manipulation of these call legs. Legs,

5.3

Using OSA

So far we have seen how the OSA interfaces are defined and structured, but not how they are used. The complete cycle for using an OSA service consists of three phases: 1. Authentication. Before using OSA services, the application and the OSA framework authenticate each other. Authentication is part of the OSA framework interface and prevents unauthorized access. 2. Service selection. Once authenticated, the application selects the service interface to be used (in this example, the call-control interface). To ensure non-repudiation,6 the OSA framework can request the signing of a service agreement before allowing the interface to be used. 3. Service use. Only after the authentication, service selection, and signing of the service agreement have been done can the application start using the actual service. Apart from providing security, the authentication and serviceselection process also allows OSA service providers to define permission profiles for different enterprise applications. The amount of privileges can be made to depend on the level of trust awarded to an external application. For example, the OSA service provider can restrict applications from a certain enterprise to receiving only notifications from the network (for example, notifications of calls to a freephone number) while allowing more trusted entities to establish calls. 6.

Non-repudiation is a term used in network security. It refers to mechanisms that prevent people from using a service and then denying that the service was delivered.


193

To demonstrate the use of OSA we will now look at an example. Imagine an Internet portal that mediates between buyers and sellers of, say, vintage cars. When bringing together a buyer and a seller, the portal offers the buyer the option of connecting to the seller by telephone. The Web page contains a button marked call seller, which activates a small Java program on the server (called a servlet). In Sections 5.3.1, 5.3.2, and 5.3.3 we will consider the steps that are necessary for the servlet to request the connection through the OSA interface. 5.3.1

Authentication

Before our vintage car portal can access functionality in the telephone network, it must authenticate itself with the OSA framework. Figure 5.6 shows the steps of the authentication procedure. For the sake of readability, Figure 5.6 sketches the flow of operations without showing the complete class structure. The authentication procedure is as follows: 1. At initial contact, the application requests authentication by invoking the initiateAuthentication operation. The OSA framework replies with an indication of the authentication operation to be used. Note that OSA does not prescribe any kind of authentication operation itself. This is up to the implementation. In fact, an OSA framework provider can support more than one authentication operation. In this case the initiateAuthentication operation serves to tell the application which operation to use. 2. The application requests authentication from the framework. When the framework has successfully authenticated itself, the application acknowledges this with the authenticationSucceeded operation. 3. Once the application has authenticated the framework, the framework requests authentication from the application. In OSA, all security mechanisms are symmetric. Not only does the framework authenticate the application, but the application authenticates the framework. 4. When the OSA framework and application have successfully authenticated each other, the application can request a reference

194

Application (1)

OSA framework initiateAuthentication

authentication method (2) Evaluate authentication response

authenticateFramework authentication response authenticationSucceeded authenticateClient

(3)

authentication response authenticationSucceeded

(4)

Compute authentication response

obtainDiscoveryInterface

Evaluate authentication response

Create

discovery

Interface reference discoverServices Services

Figure 5.6

Authentication and discovery.

Get profile


Compute authentication response

Specify an authentication method (e.g., challenge-response)


195

to the discovery interface. The discovery interface is where the application can browse its permissions to use OSA services. The authentication and discovery procedure shown in Figure 5.6 is the most complete procedure. Depending on the level of trust that exists, the OSA framework can allow for omission of steps 2 through 4. A fully trusted application would not be required to do any authentication at all. Usually an OSA service provider will allow the use of multiple services within one authenticated session. In any case, OSA itself does not prescribe any security policy; the definition of authentication policies and permissions is completely up to the service provider. OSA only provides the message-exchange framework. 5.3.2

Service selection and service agreement

Once authenticated and after discovery of usage permissions, the application needs to select the service its wants to use. Figure 5.7 shows the operations that must be exchanged before the application can start using the service. Again, Figure 5.7 is a simplified version of the actual OSA specifications. The service-selection steps are as follows: 5. The application selects the network service it needs (in our example, multiparty call control). 6. The OSA framework requests that the application confirms the intention to use the service by signing a service agreement. The signing of a service agreement is to ensure nonrepudiation, or in other words to prevent the client application from denying it has used the service. OSA does not prescribe how a service agreement is presented and signed, but this is typically done by digital signature. 7. The application can also ask the OSA framework to sign the service agreement. As observed before, all OSA security mechanisms are symmetric. 8. Once the service agreement has been successfully signed by both sides, the application can start using the service. In our example, the application requests the setup of a call between two parties (the buyer and the seller of the vintage car). As a result, the OSA

196

OSA framework

Application selectService

(5)

Prepare service agreement signServiceAgreement Evaluate agreement

signServiceAgreement

(7)

Signature

Create

IpAppCallControlManager (8)

(9)

Figure 5.7

Service selection and signing of service agreement.

Evaluate agreement

Create

setCallback

IpCallControlManager


(8)

(6)

Signature


197

framework starts up a call-manager object. The application also starts a manager object for the new call. 9. The client application has to notify the newly created call-manager object of its counterpart on the client side, the callback interface. Again, steps 5 through 9 represent the most extensive selection and signing process possible. If a high level of trust exists, the OSA provider can choose to omit the signing of the service agreement in steps 6 and 7. 5.3.3

Application-initiated call setup

Now that the application has gone through mutual authentication, selected the OSA service to be used, and signed the service agreement, it can start using the call-control service. Recall that in this example, the application is a servlet on a Web page that establishes a call between a buyer and seller of a vintage car. In step 8 above, the application and the OSA framework started the call-control manager objects. Figure 5.8 shows the steps the application must follow to request the establishment of the call through the OSA call-control interface. The steps to set up the call between the buyer (party A) and the seller (party B) are as follows: 10. First the application creates IpAppCall, the callback interface for receiving call notifications. 11. Then the application requests the creation of a new call from the OSA call-control manager. The result is the creation of a new IpCall object, but one that does not yet have any connections. 12. Once the new call object exists, the application requests a call leg to be established to party A (in our example, the buyer of the vintage car). As a result, party A is alerted. 13. If party A answers, the call leg is established and the OSA interface notifies the application with the routeRes operation. 14. Now the application requests the setup of a call leg to party B (the seller of the car). As a result, party B is alerted. 15. If party B answers, the connection is complete. The OSA interface notifies the application with the routeRes operation.

198

IpAppCallControlManager

IpCallControlManager

Create (10) (11)

IpAppCall createCall

Create IpCall

routeReq

(12)

Party A rings Party A answers

routeRes

routeReq

(14)

Party B rings routeRes

Party B answers (15)

Figure 5.8

Call setup.


(13)


199

This example shows only a successful call setup scenario. Should party A not answer the call, then the OSA interface would signal this condition with a routeErr operation and the application would not proceed with steps 14 and 15. Now we have seen how OSA is defined, and how it is used to let external applications control the network. In our example we saw the call-control interface at work. There are eight other service interfaces that allow control over a wide range of network resources. Although it is outside the scope of this book to provide examples for each of these interfaces, it is hoped that the example in this section furthers an understanding of the OSA specifications that can be downloaded from the ETSI and Parlay Web sites.

5.4

Implementing OSA

Until now we have discussed the OSA specifications and their use, but we have not talked about how OSA is implemented in the network. In this section we will consider questions such as the following: In what programming languages are OSA applications written? How is OSA configured in the network? How is it accessed by external applications? 5.4.1

Languages and middleware

The OSA interfaces are specified in OMG IDL, which naturally suggests an implementation in terms of distributed CORBA objects. But IDL is quite neutral and OSA does not strictly require the use of CORBA. The OSA specifications do not say how to implement the interfaces; they only specify the interfaces themselves. In this way OSA does not bias any technology or vendor, and allows complete freedom in the implementation of its interfaces. There are several equally valid ways of implementing OSA, including the following: ◗

CORBA. When using CORBA, the original IDL specifications for OSA can be compiled directly into object stubs. This makes CORBA the most straightforward way of implementing OSA. Nevertheless, CORBA also has drawbacks such as its complexity and the price paid in terms of performance.

200


◗

DCOM. DCOM is the distributed object middleware commonly used in Microsoft systems. It is similar in philosophy and structure to CORBA, and the mapping from OMG IDL to Microsoft IDL is relatively easy. In fact, the first versions of Parlay (before it merged with OSA) were also specified in Microsoft IDL. The pros and cons of DCOM are similar to those of CORBA, with the added observation that DCOM is limited to Microsoft-based systems.

◗

Extensible markup language (XML). XML allows a user to define his or her own tags and is often used in messaging systems. The idea of using XML as an alternative to CORBA has been the subject of various studies including [2]. One of the better-known ways to do object communications with XML is by using the simple object access protocol (SOAP) standard proposed by the World WideWeb Consortium (W3C). SOAP encodes object operation calls in XML and uses HTTP for transporting them from source to destination.

◗

Plaintext. The OSA operation calls can also be represented in plaintext messages. Although simple to implement, this requires both the network and the client application to have a parser and interpreter for plaintext OSA messages. The more complex the messages, the more sensitive plaintext is to introduced errors.

◗

SIP. It is even possible to encapsulate OSA messages in the body of SIP messages. This makes most sense in systems where SIP is already used, typically in voice over IP systems (see Chapter 3). SIP messages are plaintext and therefore the drawbacks are similar to those identified in the previous point.

In addition to these, a vendor can choose to use any other standard or proprietary technique. The OSA specifications do not favor or exclude any implementation. CORBA and DCOM are evident candidates for the implementation of OSA because of their close relation to OMG IDL. Nevertheless, SOAP is probably the most promising candidate in terms of simplicity and performance. 5.4.2

OSA configurations

Another question is where to implement OSA in the network. There are two distinct scenarios for this: distributed and centralized. Since OSA


201

consists of a group of independent interfaces, it is possible to map each interface directly to its corresponding network element (or a group of network elements). For example, it makes sense to implement the callcontrol interface directly on a telephone exchange, or to extend an HLR with an OSA mobility interface. This scenario is shown in Figure 5.9. A distributed implementation of OSA like the one shown in Figure 5.9 requires some kind of communication middleware, so that applications can access the interfaces easily without having to determine their physical location. CORBA and DCOM can offer such communication facilities. An application will normally access the distributed OSA framework through some kind of firewall, especially when using nontrusted networks like the Internet. Together with the framework interface, the firewall prevents unauthorized access. It is also possible to implement OSA in a completely centralized manner. In this case the network operator implements all OSA interfaces in one central server, as illustrated in Figure 5.10. The central OSA server must communicate with resources in the network through their respective protocols. For example, the server has to interrogate the HLR using MAP, and request call setup from the exchange using INAP. The central OSA server has the advantage of being easy to install and manage, and does not suffer the communication overhead that normally

Application

Framework

Firewall

Communication middleware

Call control

Figure 5.9

Data session control

Mobility

Connectivity management

SGSN

HLR

Policy router

Distributed implementation of OSA in the network.

202


Application

OSA server

INAP

CAP

MAP

SGSN Figure 5.10

COPS

HLR

Policy router

Centralized implementation of OSA.

comes with middleware. On the other hand, this configuration does introduce a potential bottleneck and single point of failure. 5.4.3

Mapping from OSA to CAMEL

Although Parlay and OSA have exactly the same interface, they differ in terms of implementation. Parlay does not make any recommendations on how to implement the interfaces. The distributed and centralized implementation, and in fact any mixed configuration you might think of, are equally valid. ETSI does make recommendations for implementing OSA, and particularly for mapping the OSA interfaces onto network protocols. These recommendations are made in document TR 129 998 [3]. They are not part of the formal OSA specification and have only an informative status. At present ETSI favors a centralized approach where the OSA interfaces are implemented as a front-end to the CAMEL SCF. This is illustrated in Figure 5.11. So far ETSI has only specified a mapping from OSA to the CAP protocol. CAP is the protocol used between the SCF and the SSF of the mobile exchange (MSC) or mobile router (SGSN). Since CAP’s scope is limited, not all OSA interfaces can be mapped to it. Currently ETSI has defined mappings for the following OSA interfaces:


203

Application

OSA SCP

CAP

Figure 5.11

CAP

SSP

SSP

MSC

SGSN

MAP

HLR

Implementation of OSA as extension of CAMEL SCF.

◗

Call control: maps to CAP messages for communicating with the CAMEL SSF associated with an MSC;

◗

Data session control: maps to CAP messages for communicating with the CAMEL SSF associated with an SGSN;

◗

User interaction: maps to CAP messages for attaching an MSC to an SRF, playing announcements to the user and getting user input;

◗

Mobility: maps to MAP messages for ATI of the HLR.

7

The OSA-to-CAP mappings are still under definition, and in any case provide only a partial mapping for OSA. It is likely that ETSI will propose mappings to additional protocols in the future. 5.4.4

OSA products

Many telecommunications manufacturers, especially those that build mobile network equipment, see OSA as the successor of IN and CAMEL. That is why most IN product lines now include an OSA-Parlay server. Although the market has not yet accepted OSA on a wide scale, operators are conducting serious trials with OSA. 7.

Note that although ATI is used in CAMEL, the HLR is accessed with MAP, not CAP.

204


When looking at the current market, we can distinguish two kinds of vendors of OSA equipment: 1. Telecommunications manufacturers. Most major manufacturers of IN and CAMEL have added an OSA server to their product lines. In the typical case the manufacturer integrates the OSA server with its existing product and uses proprietary protocols to communicate with its equipment. 2. Independent vendors. There are also vendors that do not manufacture telecommunications equipment, and that are offering OSA servers as stand-alone products. In this case the OSA server is built upon a protocol stack that allows communication with network equipment through standard protocols. Figure 5.12 illustrates the difference between the two kinds of vendors. Of course, this classification is somewhat rough, but it does give an indication of the kinds of products found in the market. Telecommunications vendors naturally try to convince clients that already have an IN or CAMEL installed base to extend their configuration with OSA. Their clients are usually incumbent operators and larger competitive operators. The independent vendors generally try to address the market of smaller operators, ISPs and ASPs, but in some cases also try to position themselves as direct competitors to the big manufacturers. Table 5.3 lists some of the vendors active in the market when this book was written. It is only a snapshot of a market that is in constant Telecommunications manufacturer

Independent vendor

OSA server OSA server SCP Protocol stack

Proprietary protocols Figure 5.12

OSA vendors and products.

Standard protocols


205

Table 5.3 Overview of OSA Vendors and Products Manufacturer

8

Product

Alcatel

A8601 Parlay-OSA Gateway

Aepona

Causeway

Ericsson

Jambala Service Capability Server

IpGen

Genovation Multiservices Platform

Lucent

ISG

Nokia

3G Service Creation and Application Platform

Siemens

Parlay @vantage

Ulticom

Nexworx

movement, and the list is not exhaustive. Some important products may be missing or may have changed in the course of time. Alcatel, Ericsson, Lucent, Nokia and Siemens are examples of telecommunications manufacturers that offer OSA as part of their network intelligence product lines. Aepona, IpGen, and Ulticom are examples of independent vendors that build their OSA gateway on protocol stacks. The list of OSA products can be expected to grow as the OSA specifications mature and become more widely accepted.

5.5

OSA applications

In this chapter we have explored the structure and use of OSA interfaces. We looked at an example of an OSA application: a Web site that connects buyers and sellers of vintage cars by telephone. But this is only a simple example that does not justify all the OSA machinery. So what is driving OSA? What will OSA applications of the future look like? It is difficult to build a convincing case for OSA if it is used only as a new way of doing IN. The real potential of OSA lies in areas currently not covered by IN, and in providing the integration framework for IN and other network features such as messaging, positioning, and data communications. In this sense, OSA can bring the following added value:

8. All brand and product names in this table are trademarks of the respective manufacturer.

206


◗

Third-party service control. One of the initial impetuses behind OSA and Parlay was to allow the integration of network features with applications external to the network. To put it in the words of a manager at a major European incumbent operator: “Integrating back-office applications with network services is not our business.” This business will typically be left to third parties, who will need OSA to securely access the network’s features.

◗

Roaming interface. Current roaming agreements require a high level of trust between the roaming partners. In CAMEL, for example, the SCF of the home network directly controls the SSF of the visited network over a trusted interface. It is not possible to provide roaming services to networks with which no prior agreement has been established. OSA can provide a more dynamic alternative to current roaming mechanisms. Since OSA has a security framework, it is possible to offer roaming between parties that do not have an established trust relationship.

◗

Protocol replacement. For some newer network features, there are no standard protocols yet or there exist several competing de facto solutions. For example, there exist several protocols for accessing an SMSC or GMLC. They often depend on the manufacturer. OSA can provide a standard programming interface for these network functions; OSA also provides a framework for features that might be added in the future.

◗

Content billing. Billing for data communications is notoriously difficult. At present most mobile data (GPRS) operators simply bill for volume, but from the subscriber’s point of view the relationship between volume and value often depends on the content. For example, the charge per byte that a subscriber will accept for a 160-byte GSM short message is much higher than for a 3-MB MP3 file download. The OSA charging interface can be used to dynamically establish relations between volume and value.

In the next paragraphs, we will consider an example of an application that exploits both the protocol-replacement and third-party service control aspects of OSA.


207

Imagine a taxi-dispatching company that wants to automate its services. The idea is that when a client calls, his or her mobile terminal is automatically located and a program automatically alerts the nearest taxi. Of course, this also requires location of all taxis. For simplicity, we will discard the possibility that the nearest taxi is occupied, and we will not take into account any confirmation procedures for the customer. To implement this service, the taxi dispatcher subscribes to the following three OSA service interfaces offered by the mobile network operator:

Example: Taxi dispatcher

1. Call control: to automatically notify the taxi dispatcher of requests for taxis; 2. Mobility: to determine the position of the calling customer and the taxis; 3. Generic messaging: to send a notification to the nearest taxi. The taxi dispatcher develops an application that automatically receives a notification when a customer calls, then locates the customer and finds the nearest taxi. The program then sends a short message to alert the taxi to pick up the client. There are two possibilities for locating the taxis. One is to ask for the position of all taxis whenever a customer calls. This will give the most updated location of the taxis, but is also very costly. Another possibility is to have the network send periodic positioning information for each taxi, for example every 5 minutes. OSA supports both ways of locating mobile terminals. Figure 5.13 shows the scenario for automatic taxi dispatching with OSA. The taxi-dispatching-application scenario includes the following steps: 1. A customer dials a special number to request a taxi. 2. The OSA interface notifies the taxi dispatcher application of the customer’s call. This notification identifies the calling-party number. 3. The taxi dispatcher requests location of the calling party through the OSA interface. OSA forwards this request to the mobile

208


Pick up client at Canton Street (6)

taxi taxi taxi

Taxi dispatcher

GMLC (3)

(4)

(2) OSA

MSC (1)

(6)

(3) (6)

Application (5)

SMSC Database Mobile network Figure 5.13

Automatic taxi-dispatching service with OSA.

location center. It is also possible that the taxi dispatcher requests the location of the taxis, depending on the implementation. 4. The network locates the calling party. If requested it also locates the taxis (the alternative is that this is done periodically). 5. When the taxi dispatcher has received the caller’s coordinates, it looks up the geographic location in a database and determines the nearest taxi. 6. The application sends a short message to the nearest taxi through the OSA interface to pick up the customer at the indicated location. Although very simple, this example shows the kind of applications that can be made with OSA. The taxi-dispatcher application must know only the OSA programming interface; it requires no knowledge of network protocols. The OSA framework authenticates the application and ensures secure access. By integrating enterprise applications with network services, OSA opens the door to new ways of conducting business using telecommunications. In the near future we are likely to see many original and new applications such as the taxi dispatcher illustrated here.


209

References [1]

ETSI ES 201 915, Open Service Access (OSA); Application Programming Interface (API), 12 parts, version 1.1.1 (final draft), December 2001.

[2]

Vermeulen, S., et al., “XML Middleware and CORBA: Synergistic or Competitive?” In Lecture Notes in Computer Science, Vol. 1774, Berlin, Germany: Springer-Verlag, 2000.

[3]

ETSI TR 129 998, Universal Mobile Telecommunications System (UMTS) Open Service Access (OSA) Application Programming Interface (API) Mapping for OSA, version 4.0.0 (release 4), March 2001.

.

CHAPTER

6 Contents 6.1 Telecommunications informationnetworking architecture 6.2 TINA service architecture 6.3 TINA networkresource architecture 6.4

The future of TINA

6.5

OMG

6.6

TDTF

Telecommunications middleware Parlay and OSA define an object-oriented programming interface for controlling the network’s resources and set new standards for distributing the intelligence in the network. Distributed object-oriented programming is now the industry standard in computing, and there exists a great amount of tool support. Objects are high-level programming elements that have a significant amount of lower-level processing behind them. To save programmers from dealing with the lowlevel details of communications between objects, there now exists middleware. As the name suggests, middleware is software that runs between a machine’s operating system and the applications. It offers facilities that are common to many applications, such as managing the communication between applications on different machines. Would it not be possible to use middleware in telecommunications? The idea of using object-oriented software and middleware in telecommunications

211

212


is not as new as one might think after reading the discussion in Chapter 5. In the early 1990s Telcordia (formerly Bellcore), the same company that invented IN, experimented with the information networking architecture (INA). The revolutionary concept behind INA was to eliminate the distinction between telecommunications services and computer applications by creating a new kind of service architecture. In the new architecture, traditional switched connections were replaced by a more abstract concept of multimedia streams. This allowed applications to be developed more independently from the underlying network protocols. INA did not set up circuit-switched connections in the usual way with SS7 signaling, but used a top-down mechanism to negotiate packet streams in a LAN. INA regarded terminals as intelligent entities, capable of terminating complex multimedia streams and running applications on their own. Considering that in the early 1990s the Internet was not nearly as widespread as today, INA was far ahead of its time. INA was the precursor to a more broad group of experiments worldwide, all with the intention of coming up with a new object-oriented telecommunications middleware. In this chapter we will look at two of the most significant initiatives: TINA and the OMG Telecommunication Domain Task Force.

6.1 Telecommunications information-networking architecture At the time when Telcordia was working on INA, the same ideas were being developed in an international context. TINA started as a conference in 1990. A couple of years later, in 1992, a group of companies including Telcordia founded the TINA Consortium (TINA-C). From then on TINA-C was a cooperative effort to specify the telecommunications architecture of the future, and about 40 companies eventually joined it. 6.1.1

TINA-C

TINA was organized in two phases. The first phase started in 1993 and ended in 1998, and was dedicated to the specification and validation of the TINA architecture. During these 5 years, TINA-C maintained a core team of some 40 engineers at the premises of Telcordia in Red Bank, New Jersey. The core team consisted of representatives from all TINA members working tightly together in the definition of TINA.


213

At the same time, the members of TINA implemented and validated parts of TINA in auxiliary projects. These projects were not directly managed by TINA-C, but the experience gained in these projects contributed much to the stability of the TINA specifications. The first 5 years of TINA amounted to a remarkable feat of precompetitive cooperation, in which many competing operators and manufacturers invested in joint research and development. At the end of the first phase, TINA delivered its complete set of stable specifications and dismantled the core team. The second phase of TINA lasted only 2 years, from 1998 to 2000. In this phase TINA targeted standardization bodies and industry for adoption of the specifications. Technical work was still carried on, although on a smaller scale, in special interest groups (SIGs). After 2000 the TINA Consortium was officially discontinued, its mission considered complete. In the following sections we will take a closer look at the TINA specifications. 6.1.2

TINA business model

The definition of TINA starts from a model that defines business roles and the interfaces between them. This business model not only defines the value chain for telecommunications services, but in fact serves as an outline for the architecture itself. This underlines the TINA philosophy that the architecture should be defined by the market and not the other way around. The business model is defined in terms of business domains and the reference points between them. In TINA a service is defined as any collection of features offered from one domain to another over a reference point. This definition is very general, and covers anything from a simple telephone connection to networked computer applications and even network-management features. TINA deliberately does not make clear distinctions between applications and services, or between management and control. The TINA business model is made up of the following domains: ◗

Consumer: the business entity that consumes services, but does not provide them. The consumer is located at the end of the value chain. Terminal equipment is typically part of the consumer domain.

◗

Retailer: a one-stop shop for services. The retailer can provide services itself, or it can resell services from third-party service providers. The

214


retailer itself does not provide connectivity, but contracts this from the connectivity provider. The retailer domain typically contains service nodes and special peripherals. ◗

Service provider: the business entity that provides services or content through the retailer. Service providers do not deal directly with consumers.

◗

Connectivity provider: the entity responsible for setting up connections between terminals and network end points. The connectivity provider domain contains switches, routers, bridges, and whatever equipment may be needed to make connections.

◗

Broker: the entity that links providers and consumers of services. This role ensures a completely dynamic service marketplace in which service offers can be created and negotiated on-line.

The core of the TINA business model is formed by the consumer, retailer, and connectivity provider. The service provider and broker are additional roles that may or may not be present in a TINA implementation. TINA makes a conscious division between the retailer and connectivity provider, because this strictly separates service control from the management of transport resources. Figure 6.1 shows the TINA domains and the reference points between them.

Broker RtR

Consumer

Retailer

Ret

3Pty

ConS LNFed Tcon

Connectivity provider CSLN

Figure 6.1

TINA business model.

Service provider


215

Figure 6.1 also shows the reference points between the domains. The reference point between the consumer and retailer domain is the gate through which a retailer offers its services to consumers. The ConS reference point lets the retailer negotiate connectivity for the services it offers to the consumer. It is possible that a domain has a reference point with itself. If this is the case, it means that two different instances of the domain have a business relationship with each other. The RtR reference point allows two retailers to cooperate in delivering a service. This can be relevant, for example, in a mobile context with roaming. Likewise, the LNFed reference point allows the negotiation of an end-to-end path across connectivity providers. The CSLN reference point lets a connectivity provider use the services of an underlying transport network, for example one offering ATM over SDH. Ret

6.1.3

From business model to architecture

The business model effectively defines the outline for the TINA architecture. The separation between the retailer and connectivity provider leads to the definition of two subarchitectures: 1. Service architecture: the part of TINA in which services are executed; 2. Resource management architecture: the part that contains the switching and transport equipment and logic. Figure 6.2 shows the overall structure of the TINA architecture. The resource management architecture encapsulates the technology of the individual network entities and offers a generic API to the service architecture. By doing so, TINA strictly separates service logic from connection control. The separation of service logic from switching and transport has a few important advantages. First, service logic only needs to be aware of an abstract concept of streams and does not have to deal with setting up end-to-end connectivity. This allows service logic to be independent from whether the underlying transport networks are connection-oriented or connectionless, mobile or fixed. Second, the separation of service logic and transport technology allows the two to evolve independently. This means that when the transport technology evolves, the service logic can be reused without

216


Retailer

Terminal applications

Consumer

Service

Service

Service

Service architecture

Resource management architecture

ATM switch

ISDN switch

IP router

Connectivity provider Figure 6.2

TINA architecture overview.

modifications. The opposite is also true; new services can be developed with the latest IT technology (for example, Java Beans) without the entire architecture having to be redesigned. 6.1.4

Session model

The TINA business model and architecture provide a new structure for service delivery, but do not tell us how services are actually implemented and run. The dynamics of services are defined by the TINA session model. A TINA session can be seen as the generalization of the call models used in IN. The session model is one of the pillars of the TINA architecture and can be regarded as perhaps TINA’s most important result. Following the separation of the service architecture and network resource architecture, TINA distinguishes two kinds of sessions: 1. The service session controls a service. It keeps track of the parties involved in a service and the (connectivity) relations between them. A service session also controls value-added service processing. The service session runs in the service architecture.


217

2. The communication session negotiates and sets up the connections for a given service. A communication session runs in the resource management architecture. Normally a communication session is associated with a service session that requested the connections. The distinction between the service session and the communication session enforces the separation between service control and connection control. Another philosophy of TINA is that access to services should be separate from the use of services. TINA views access as a generic procedure that precedes service use, just like logging in to a computer precedes the use of computer applications. For this reason TINA defined a third type of session, the access session. The access session is responsible for establishing and maintaining the relationship between the consumer (end user) and the retailer (network). This relationship can be dynamic and allows for any type of personal or terminal mobility. By doing so TINA effectively defined mobility as an access feature, independent of particular services. Figure 6.3 illustrates the three types of sessions that are involved in the delivery of a service. A consumer must first set up an access session before he or she can use the retailer’s services. The access session is responsible for authenticating the user and for managing the relationship between the user and the retailer. As such, it is similar to a log-in shell on a computer, or an attach procedure in GSM. Once the consumer has access to the retailer, he or she can request the use of a service. This results in the creation of a service session. The service session contains all the intelligence to process a service and request connectivity from the connectivity provider. The service session can be seen as a generalization of the telephony call model. The service session specifies the connectivity requirements only from the viewpoint of the users, and forwards these requirements to the communication session. The communication session sets up the actual physical connections in the network. The access session and service session are implemented by components in the service architecture, while the communication session is implemented in the resource management architecture. In the following sections we will take a closer look at this implementation.

218

User A

User B Access

Access

Session

Session

Service

Service architecture

Communication Session

Resource management architecture

Figure 6.3

TINA session model.

Media streams


Media streams

Session


6.2

219

TINA service architecture

The TINA service architecture consists of software components that implement the access session and service session. The entire TINA architecture is object-oriented and assumes the existence of a distributed processing environment (DPE) that takes care of the communication between distributed objects. TINA does not define any protocols. In TINA, signaling is replaced by communications between distributed objects. The TINA distributed processing environment is based on OMG’s CORBA. CORBA provides a programming-language-independent interface wrapper for objects, and a communications environment that allows objects to communicate with each other without having to be aware of their distribution. If you are not familiar with CORBA, the concept is briefly explained in Section 6.5. 6.2.1

Computational objects

The unit of deployment and reuse in TINA is called the computational object, which is defined as a component that consists of one or more CORBA interfaces. Figure 6.4 shows the computational objects that implement the TINA service architecture, both on the consumer and retailer side.

CORBA interface

IA PeerA

UA

PA

SF

ssUAP

SSM

Connectivity provider domain Figure 6.4

TINA service architecture.

Access session

Computational object

Retailer domain

Service session

Consumer domain

220


It is not within the scope of this book to go into detail on each of the computational objects and their CORBA interfaces. Table 6.1 gives an informal overview of the computational objects and their functions. These computational objects are best explained in terms of their function in the access and service session. In the following sections we will discuss them in this context. 6.2.2

Access session

In TINA, a user must establish an access session before he or she can do anything else. This is not such a strange assumption: users in a mobile network must do an attach (switch on their phones and enter a PIN code) before they can communicate. The procedure for starting an access session is as follows: 1. When the user requests an access session, the PA in the terminal contacts the IA in the network. The address of the IA is always known in any TINA network. Table 6.1 Computational Objects for the Service Architecture Acronym

Computational Object Description

IA

Initial agent

Represents the first point of contact for the consumer in a foreign network. Takes care of authentication, finding the user agent for the consumer, and starting the access session.

UA

User agent

Represents the consumer within the retailer domain. Contains subscription data and user profiles. Runs the access session.

PA

Provider agent

Represents the retailer within the consumer domain. Can be seen as a proxy through which the retailer makes service offers to the consumer.

PeerA

Peer agent

Establishes connections between two retailer domains, if the service implies users in different domains (for example, a video conference between users in different networks).

SF

Service factory

Creates service instances as the result of a service request, and configures the service.

SSM

Service session manager

Runs the actual service session. Keeps track of the parties involved in a service and their relations. Requests connectivity from the communication session (not shown in Figure 6.4).

ssUAP

Service session user application part

Represents the service control interface in the terminal.


221

2. The IA consults the subscription database, authenticates the user, and finds the UA for this user. Note that in a roaming situation, the UA can be in a remote network. 3. The UA activates an access session for the user. The PA in the terminal is linked to the UA for the duration of the access session and the user can start using the services. Once an access session is active in the UA, it acts as the point of interaction between the user and the retailer services. Through the access session, the user can do any of the following: ◗

Request a list of available services. The UA will list the services that the user is subscribed to, but may also cite services that do not require subscription.

◗

Request the start of a service session. The access session is always the window through which services are started.

◗

Receive invitations from other users to join a service session. In TINA, the term invitations is used rather than calls, because the TINA service concept goes beyond telephony. In the case of conferences or chat sessions, for example, it is more correct to speak of invitations rather than calls.

◗

Join a service session that is already active. A user can join service sessions for which he or she has been invited, but can also actively search for service sessions and request to join one (for example, looking for a chat box).

◗

Register remotely at terminals. A user can request to be registered on a remote terminal for incoming invitations to join sessions. This means that the user will be alerted on this remote terminal when an invitation to join a session arrives.

6.2.3

Service session

When the user requests the start of a service—for example a video conference—the UA asks the SF to start an SSM for this service. The SSM is the computational object that runs the actual service session. A service session keeps the state of the service, which is represented by the service session graph. Figure 6.5 illustrates the service session graph.

222


Service session graph Contains

Session member

Session relation

Is-a

Party Figure 6.5

Resource

Is-a

Control relation

Stream binding

Service session graph.

A service session graph is made up of session members and session relations. A session member is either a party (i.e., a consumer involved in the session) or a resource (e.g., a video bridge or voice mailbox). A session relation can either be a stream binding (i.e., a data, voice, video, or multimedia connection between parties) or a control relation. An example of a control relation is a video conference in which one party is the chair and others are participants. The chair has special privileges that normal participants do not have; for example, the chair can disconnect other parties from the conference. The TINA service session offers a number of features that allow parties to modify the session graph. These features include the following: ◗

Basic features: such as starting, stopping, and suspending a session;

◗

Multiparty features: such as adding or dropping a party in a session;

◗

Stream-binding features: for adding or dropping a stream binding to a party in the session;

◗

Voting features: for allowing voting among parties in the session (for example about the permission of a new party to join the session);

◗

Control features: for modifying control relations between parties (for example transferring chairmanship of a videoconference).


223

In addition, a particular service may require service-specific features to be added to the service session. Such features include, for example, video control features (play, stop, rewind, fast forward, pause) for videoon-demand services. The TINA session concept is generic and is used to model a wide range of services. The lifetime of a session can vary from a few minutes (in the case of a typical call) to semipermanent (in the case of continuous chat sessions or video surveillance services, for example). Although the TINA service session manages stream bindings between parties, it is important to keep in mind that these are not physical connections. A stream binding is a high-level, abstract representation of the connection that exists between parties in a session. A stream binding specifies the type, bandwidth, and QoS of a connection in a generic format without determining how this connection is made in the network. As such, a stream binding can be seen more as a connection requirement. The actual connections are delegated by the service session to the communication session, which runs in a separate TINA subarchitecture, the network resource architecture.

6.3

TINA network-resource architecture

The resource-management architecture is dedicated to managing network resources and setting up connections required by services. It deals with the interfaces to physical network equipment and hides these details from the service sessions. The resource-management architecture can set up connections through different networks of heterogeneous technologies and adapt the service to the capabilities of the network and terminal. The way that connections are set up in TINA differs from the connection setup process in telephony networks and the Internet. The TINA resource-management architecture is based on the telecommunications management network (TMN) principles. Rather than using signaling between peer nodes, TINA sets up connections in a top-down fashion, in the way that semipermanent connections are made in a TMN system. This approach was chosen in order to be able to deal with all kinds of transport networks, whether connection-oriented or connectionless, and to be independent of any particular signaling protocol. TINA sets up connections in three main steps:

224


1. Negotiation. The communication session queries all involved terminals and network entities for their capabilities, and selects a set of common capabilities that will allow the connection to be set up. 2. Reservation. The communication session asks all involved terminals and network entities to reserve the selected capabilities. If any of the entities reports unavailability of its capabilities, they are renegotiated. If necessary, the negotiation step is repeated. If it is not possible to reserve all necessary resources, all reservations are rolled back (undone) and the service session is informed of the failure to set up the connection. 3. Commitment. If all involved terminals and networks confirm the reservation of the necessary resources, the communication session will then order them to commit the resources and the connection is set up. The last two steps closely resemble a two-phase commit procedure, which is common in databases and also in network management. The two-phase commit mechanism is used to ensure that no resources are wasted before it is certain that the requested connection can be set up in its entirety. 6.3.1

Computational objects

Like the service architecture, the resource-management architecture is made up of computational objects. The structure of the resource management architecture is hierarchical and recalls the TMN architecture. Figure 6.6 shows the TINA resource-management architecture in simplified form. A service session always requests connectivity from the communication session manager (CSM). Although part of the resource-management architecture, the CSM runs in the retailer domain rather than in the connectivity-management domain. The CSM is in charge of negotiating and selecting the terminal and network capabilities necessary to realize the requested connection. The CSM also maintains the state of the communication session, but it does not set up the physical connections itself. It delegates this task to the connection coordinator (CC). The CC has a bird’s-eye view of the different layer networks, and will determine which layer networks to involve in the connectivity request.1 Layer networks are subnetworks that have a peer-to-peer relation, as opposed to a client-server relation.


Terminal application

Service session

Negotiate

CSM

Consumer

TCSM

Retailer

225

TLA IP

ATM

Reserve and commit LNC IP

Terminal resources Figure 6.6

PSTN ATM

Connectivity provider

CC

Network resources

TINA resource-management architecture.

Each layer network is governed by a layer network coordinator (LNC). The LNC knows about the transport and switching technology used in the layer network. It also knows the network end points within its domain and can negotiate with terminals about addresses, port settings, and so on. The LNC is network and technology dependent. On the terminal side, the terminal communication session manager (TCSM) is the counterpart of the CSM. It negotiates the terminal capabilities and maintains the state of the communication session as seen from the point of view of the terminal. Each communication technology supported by the terminal has a terminal layer adapter (TLA). Although many terminals support only one

1. TINA seems to have adopted the concept of layer networks from ITU-T recommendation G.805.

226


communications mode (for example, GSM or ISDN), the TLAs allow for any type of multimode terminals. The TLA assigns communication end points in the terminal and negotiates technology-specific settings with the LNC on the network side. 6.3.2

Connection establishment

To see how these computational objects interact to set up connections, let us consider the example of the establishment of a connection between two terminals in two different networks. The negotiation phase, illustrated in Figure 6.7, consists of the following steps: 1. The CSM queries the TCSM of each terminal for the terminal’s capabilities. The terminals respond by giving a list of capabilities they can support, for example 4 slot GPRS, G.724 codec, and video camera and screen. 2. The CSM matches the terminal capabilities listed by each terminal, and defines the common set of capabilities that will allow the requested connection to be established. The CSM also takes into account the capabilities of the networks to which the terminals are connected. 3. The CSM tells the TSCM which capabilities are needed and asks the TSCM to select the necessary resources in the terminal. 4. The TCSM asks the TLA to identify the terminal end points that correspond to the requested capabilities. These end points could be, for example, GSM channels or IP addresses. 5. The selected end-point coordinates are propagated back to the CSM. After the negotiation phase comes the actual setting up of the connections, using a two-phase commit procedure that is common in transaction processing. Figure 6.8 shows the reservation phase, which consists of the following steps: 1. The CC contacts the LNC for each subnetwork involved, and asks them to set up the necessary connections within their domain. 2. The LNC asks the terminal to reserve the resources negotiated in the previous steps. The LNC also reserves the necessary network

CSM

TCSM

TCSM

TLA

Query capabilities Terminal capabilities

(1) Query capabilities Terminal capabilities

CSM selects common capabilities


TLA

(2)

Select capabilities (4)

Select end points

(3)

Select capabilities Select end points

TLA selects terminal end points that fit the requested capabilities

(4)

TLA selects terminal end points that fit the requested capabilities

End points End-point address

End points End-point address

(5)

Terminal A Negotiation phase in TINA connection setup.

227

Figure 6.7

Terminal B

228


resources. At this point the terminal can still renegotiate end points, if those selected have become unavailable (this procedure is not shown in Figure 6.8). If necessary, the negotiation phase is repeated. 3. If the selected terminal end-points are available, the LNC asks the TLA to associate them with physical resources in the terminal. 4. The TLA asks the TCSM to link the terminal application to the physical ports in the terminal that will terminate the connection. If all four steps are completed correctly, the next step is the commit phase, in which the CC asks the LNCs to execute the setting up of the connections. If one or more critical resources is unavailable, all pending reservations are canceled and the connection setup procedure is aborted. 6.3.3

Federation

Although we have considered only a simplified version of connection management in TINA, it should be evident that it differs strongly from connection management in conventional switched networks. The TINA resource architecture offers a single model for the establishment of the most complex multimedia connections over different networks. TINA recognizes two levels at which connectivity providers can interwork to provide connections: 1. Horizontal federation occurs if a connection spans two or more layer networks with a peer-to-peer relation. This is, for example, the case with respect to a telephone call that originates in one network and terminates in another. 2. Vertical federation occurs if a network uses the services of a lower-level network to realize its connections. An example of vertical federation is when an IP service provider contracts capacity in an ATM backbone to transport its IP packets. As Figure 6.9 illustrates, the TINA resource architecture can manage connections that involve horizontal as well as vertical relations between connectivity providers.

TCSM

Reserve resources Terminal reserves resources

LNC

(2)

CC

TCSM

LNC

Set up Set up (1) connections connections

(2)

Network reserves resources

Network reserves resources

TLA

Reserve resources Terminal reserves resources


TLA

Terminal end-point settings Terminal end-point settings Associate end points (3)

Associate end points (4)

Associate end points (4)

(3)

Associate end points

The TLA associates end points with terminal ports, and the TCSM links the application to them

The TLA associates end points with terminal ports, and the TCSM links the application to them Ok

Terminal A

Reservation phase in TINA connection setup.

Ok

Ok Network B

Terminal B 229

Figure 6.8

Network A

Ok

230


Service session

Source

Sink

Stream binding

Client-server networks

IP

WDM

IP

Mediation device

ATM

Layer networks Figure 6.9

Federation in the TINA network resource-management architecture.

In this example, the service session requests a stream connection between a source (the origin of traffic; in this case a camera) and a sink (the termination of traffic, in this case a screen). At the network resource architecture level, this stream is implemented as a packet stream that spans two IP networks. Each of the IP networks in reality uses the services of an underlying network. The left network sends the IP packets over a WDM backbone, while the network on the right uses an ATM backbone.

6.4

The future of TINA

TINA enjoyed strong industry support in the first 5 years of its existence, especially from larger operators and manufacturers such as NTT, BT, Telcordia, Alcatel, and Ericsson. The expectations were that TINA could be the telecommunications architecture of the future, and in 1998 TINA-C delivered a complete set of specifications of its architecture.


6.4.1

231

Auxiliary projects

Throughout the lifetime of TINA-C, the architecture has been implemented and validated in auxiliary projects. Some of these projects were carried out by individual companies, others were showcases or research projects involving multiple partners. The European Commission sponsored various TINA-based research projects between 1992 and 2000. Table 6.2 shows just a handful of the projects that implemented, validated, or otherwise used TINA worldwide. Some projects were research-oriented; others were intended as preproducts. Sprint ION is the only commercial implementation of TINA actually deployed by an operator. ION offers a single integrated platform for multiple-access and transport networks. It aims mostly at the market Table 6.2 TINA-Related Projects Companies

Project

Description

Alcatel

Mutris

Multiservice multinetwork multiterminal service framework: a complete experimental implementation of TINA

BT

ESP

Experimental service platform: a service architecture for the Internet based on TINA and Java programming

Deutsche Telekom,

SATIN

Service architecture for TINA and IN services: a service architecture based on IN with TINA features

DEC, Fujitsu, Hitachi, IBM, Iona, NEC, NTT, OKI

TTT

The TINA trial: a trial that shows the application of TINA to video-on-demand, e-commerce, and network management

European Commission

ROSA, DOLMEN, R&D projects, partially funded by the EC, VITAL, SCREEN, that implemented and validated TINA TOSCA, ReTINA, technology REFORM

GlobalOne

TTT

The TINA trial: a trial that shows the integration of telephony and broadband services with TINA

Lucent, KPN, SURFNet, Telematics Institute (Netherlands)

Mesh

Multimedia services on the electronic super highway: a service architecture for broadband services, with applications in health care and distance learning

Sprint

ION

Integrated on-demand network: an accessand transport-independent broadband service architecture

Telecom Italia

WebCentrica

Integration of TINA and H.323-based videoconferencing

France Telecom

232


for broadband services that are accessed through ADSL. Smaller companies such as Starvision and Kabira have tried to market TINA-based telecommunications middleware, with varying success. From these examples it is evident that TINA was taken very seriously by the industry. Why then don’t we see TINA networks all around us? What happened to TINA? 6.4.2

The decline

Beginning in 1998, TINA started losing much of its industry support. Leading companies began pulling out or taking a passive stance. There is probably no single reason for why this happened, but a combination of factors leading to TINA’s decline. The absence of Microsoft in the TINA Consortium has been one of the important handicaps in convincing the IT world of the value of TINA. Microsoft was invited to join TINA, but declined the invitation. One of the possible reasons is that Microsoft saw TINA as too much of a telecommunications group. Another more political reason could be TINA’s choice of CORBA as its foundation. After all, the OMG was considered in its early days to promote technologies that were alternatives to Microsoft. The rise of the Internet in the second half of the 1990s played an important role in TINA’s decline. At first sight it looks as though TINA and the Internet are compatible, because both promote the integration of IT and telecommunications. However, the TINA architecture is operatorcentric where the Internet is not. One assumption of TINA is that operators deploy services. In particular, the resource-management architecture is hierarchical and assumes central control of the network structure. This model turned out to be largely irrelevant in the chaotic Internet, where anybody can mount a server and there is no central control. The IETF has been steadily churning out extremely simple protocols that won great public support in favor of the complex TINA procedures. Much of the industry’s attention turned away from TINA in favor of protocols such as MGCP and SIP. The change of the telecommunications market in the late 1990s may have dealt the definitive blow to TINA. The TINA Consortium was formed in the early 1990s when the industry was still dominated by large operators and manufacturers. The last few years of the twentieth century saw an explosion of Internet companies and startups. These companies tended to build their business on new, proprietary technology or used the IETF fast track to turn


233

their solutions into standards. TINA and indeed the entire old telecommunications order is mostly irrelevant to these companies. And finally, TINA may have simply come before its time. At the moment of truth in 1998, when TINA specifications were complete, telecommunications companies did not have sufficient trust in CORBA to base their entire platforms on this technology. CORBA simply had not proven sufficiently reliable and implementable for large-scale telecommunications applications. TINA proved too revolutionary, as it requires complete reengineering of the telecommunications network. Telecommunications operators are extremely reluctant to make large-scale modifications to their existing installed base of switches, routers, signaling networks, and service nodes. Technological changes in a commercial network are always made very gradually, one small step at a time. The change that TINA proposed required a very big step, one which most operators and manufacturers were simply unwilling to take. 6.4.3

The future

What future is there for TINA? Although TINA’s adversaries are quick to point out where the technology failed, TINA does offer a few strong points. It is a complete, consistent architecture. It has been extensively experimented with. And it offers a service architecture that can work with any access or transport technology. In the long term, we are likely to see aspects of TINA built into new telecommunications systems, although they may not be labeled TINA systems. The TINA session model is particularly powerful, and is likely to resurge in some form in future platforms. Some parts of the resourcemanagement architecture are also very appealing and may be used in network management. Belgian operator Belgacom is reportedly building a TINA-based system for managing ADSL access networks, and other companies may be using TINA components in their architectures. Although the designation TINA will probably disappear over time, the concept lives on.

6.5

OMG

The OMG is a large group of IT and telecommunications companies that promote the development of component-based software development. The objective of the OMG is to create an open component model; in other

234


words, software that uses public nonproprietary standards. The OMG was founded in 1989 by 11 companies; it now has approximately 800 members. Component-based software development has important advantages. It facilitates the reuse of common components between applications, and it also makes communication between distributed applications easier. All OMG specifications are designed for object-oriented software in which applications are composed of objects, individual units of data and logic that communicate between themselves. The OMG develops various standards for distributed object-oriented software that span the entire software-development life cycle, from specification and analysis to implementation and testing. Some of the standards maintained by the OMG are the metaobject facility (MOF) and XML metadata interchange (XMI) for UML, CORBA, IDL, the Internet Inter-Orb Protocol (IIOP), the CORBA component model (CCM), the portable object adapter (POA), and the object management architecture (OMA). Since the mid-1990s the OMG has been trying to bring its component-based software standards to telecommunications. This work is done in the OMG Telecommunication Domain Task Force (TDTF), which promotes the use of CORBA in telecommunications. In the next sections we will take a closer look at CORBA and the work of the TDTF. 6.5.1

CORBA

One of the most important contributions of the OMG in computing has been the CORBA. With CORBA, the OMG tries to do for object-oriented applications what Unix did for operating systems. CORBA was originally created for making new object-oriented applications interwork with legacy applications that were written in languages like COBOL. CORBA allows objects on different computers to communicate as if they were colocated on the same machine. The programmer of the application does not have to take care of the communication between the machines, but can program the objects as if there is no network between them. CORBA takes care of the networking part of the communication between objects. Another important feature of CORBA is that it does not require that objects be written in any particular language. With CORBA, an object written in Java can communicate with another object in C++ or Smalltalk, without actually knowing that the second object is written in


235

another language. The Java object sees only another Java object; CORBA takes care of the translations. Figure 6.10 gives a simplified view of how CORBA takes care of the communication between remote objects. Imagine two objects that run in different machines. An object always runs within a server process, which represents the unit of activation. A server process typically corresponds to an executable, or a Unix process. Each physical computing node has an ORB running on it. This is essentially a daemon process that listens to object requests and takes care of the communication between objects. A remote object is represented on another machine by a stub (sometimes referred to as a proxy). A stub is a dummy object that offers exactly the same interface as the remote object, but that does not do any processing itself. Instead, it forwards requests to the ORB, which then takes care of sending them to the machine where the actual object is. One of the crucial features of CORBA is that the requesting object does not know where the serving object is. It is only aware of the stub, which it sees as the actual object. CORBA allows remote method invocations to be synchronous or asynchronous. In the case of a synchronous invocation, the calling object must wait for the result to come back before it can continue. Speaking in technical terms, the thread that calls the remote object is blocked until

Computing node

Computing node Object

Server process

Server process Interface A

Remote invocation

B Stub

Object request broker

Figure 6.10

CORBA.

Network

Object request broker

236


the method returns a result. In an asynchronous invocation, the calling object simply continues and does not wait for an answer to come back. Although CORBA looks much like a client-server architecture, one has to be careful with this comparison. There is no such thing as a predefined client machine and a server machine. Any object or machine can be a client or a server or both in CORBA. 6.5.2

IDL

How is a CORBA object programmed? Imagine that you are writing a C++ program, and that you want to make reference to a remote object programmed in Java. The interface of CORBA objects is specified in IDL, which is programming-language independent. An IDL specification of an object is relatively easy to write and read, as Figure 6.11 shows. An IDL specification describes an object interface in terms of the methods it supports. Each object method has a type (the result type), a list of parameters, and a list of exceptions that it can generate. Once a programmer has written the IDL specification for the object, an IDL compiler compiles it into two pieces of software: 1. The stub is a piece of code to be linked with the application that wants to do the remote invocation. A stub represents the remote object and is sometimes also called a proxy. 2. The skeleton is the code that accesses the actual object implementation. The programmer must manually implement each of the methods in the skeleton in Java, or link them to some existing object code. On the other side, the programmer must link the stub to the client application. This is illustrated in Figure 6.12. How does the ORB find a remote object? Each object in CORBA has a unique object reference. This is an opaque data type: The ORB can interpret its content, but applications cannot. There is also a dynamic way for objects to find objects to communicate with. If in an application there is no stub available for a remote object, the object can still use the dynamic invocation interface (DII) to find an object that can meet its request. CORBA offers a great deal more facilities that help objects communicate, such as the naming service, the

Interface name and inheritance class interface Basic_StreamCtrl:PropertyService::PropertySet { void stop(in flowSpec spec) raises (noSuchFlow); void start(in flowSpec spec) raises (noSuchFlow); void destroy(in flowSpec spec) raises (noSuchFlow);


Method type and name

boolean modify_Qos(inout streamQoS new_qos, in flowSpec spec) raises (noSuchFlow, QoSRequestFailed); oneway void push_event(in streamEvent event); void set_FPStatus(in Flowspec spec, in string fp_name, in any fp_settings) raises (noSuchFlow, FPError); object get_flow_connection(in string flow_name) raises(noSuchFlow, notSupported);

Method parameters

void set_flow_connection(in string flow_name, in Object flow_ connection) raises (noSuchFlow, notSupported); }

Exceptions Oneway denotes an asynchronous method

Sample of an IDL specification.

237

Figure 6.11

238


IDL interface specification

IDL compiler

Stub

Stub

Figure 6.12

Client application

Remote object implementation

Skeleton

Skeleton

(C++) compiler

(Java) compiler

Excutable

Excutable

Compiling IDL.

trader, the notification service, and transactional facilities. Having seen the essentials of CORBA in this section, we will not go into these services in detail. It is important to know, however, that CORBA offers an entire suite of facilities that help in the writing of distributed object-oriented applications.

6.6

TDTF

The OMG created its TDTF in the mid-1990s when activity in TINA-C was at its height. TINA-C had by then made its choice for CORBA, which was at the time still only in its adolescence. At the time, the companies and even the individuals that participated in the creation of the OMG TDTF were for the most part also TINA-C members. In the first years, the TDTF was mostly concerned with applying CORBA to network management, connection control, and intelligent


239

networks. The application of CORBA to network management is most straightforward, because the TMN standards already modeled networks in an object-oriented way. CORBA turned out to be just the right tool to implement this model. From there, the TDTF also considered getting CORBA into IN and using it for real-time connection and service control. As the TDTF had strong links with TINA, much of its early work was strongly influenced by TINA research. The first specifications it produced outside network management were on the control of audio and video streams, based on the TINA resource-management architecture, and the TCAP-CORBA gateway, based on the TINA service architecture. Later, the TDTF expanded into other areas, such as CORBA for mobile systems, open service architectures, subscriber profile management, and UML for developing services. By the end of the 1990s the OMG had begun upstaging TINA-C. Although some of the OMG specifications were almost directly inspired by TINA, they seemed to receive much more attention and industry approval than the TINA originals. The large member base of the OMG undoubtedly contributed to the high visibility of its specifications as compared with TINA. Larger companies, aware of the duplication of work between TINA and the OMG eventually chose to support the OMG, which had a greater political impact. Many of the TINA specifications now live on as OMG specifications. In the following paragraphs we will look at the activities that the TDTF has initiated since its creation. 6.6.1

Control and management of audio and video streams

In traditional CORBA, there is only one type of object and interface. An interface describes the operations that can be called on the object. These operations are normally discrete in nature: They take a list of arguments and return a result within some finite period of time. The TDTF defined a second type of interface that allows objects to exchange continuous flows of data called streams. A stream interface is the object-oriented equivalent of a network termination in a network. Instead of operations, a stream interface consists of sources (producers) or sinks (consumers) of data of a specific type. When two objects exchange data, they are said to have a stream binding. A stream binding can be likened to a connection in a telecommunications network. The OMG specifications on control and management of streams are strongly influenced by the TINA resource-management-architecture

240


specifications. The OMG published these specifications in 1996 and they were revised in 1998. 6.6.2

TCAP-CORBA gateway

Even in the early stages, the TINA Consortium was aware of the need for an evolution path from IN to TINA. Most people believed that TINA would penetrate into IN from the top down; in other words, starting in the SMP, moving from there to the SCP, and then down to the SSP. Telephone exchanges were generally believed to be the least likely equipment to run CORBA in the short term, because of their proprietary nature and because of the extremely high performance and reliability requirements involved. On the other hand, SCPs are more like generalpurpose computers that can migrate more easily to distributed objectoriented software. The consequence of a phased introduction of CORBA into IN is that there will be an intermediary phase in which the SCPs run CORBA but the SSPs do not. For this reason, the TDTF specified a CORBA representation of TCAP. The equipment that runs this CORBA-TCAP translator is called the CORBA-TCAP gateway. In many ways, this gateway can be seen as a precursor to Parlay: It offers an open CORBA interface to the SSP. Figure 6.13 illustrates the positioning of the CORBA-TCAP gateway in an IN network. It shows how a CORBA-based SCP (at the top left of the figure) can be attached to a standard SS7-based IN network through the CORBA/TCAP gateway. Although a less likely scenario, it is also possible to connect a CORBA-based switch to an IN network in this way (as shown at the bottom left of the figure). The OMG published the TCAP-CORBA gateway specifications in 1998. France Telecom and Deutsche Telecom implemented and demonstrated a prototype of such a gateway in 1998. Alcatel and other vendors did similar work, although CORBA-based SCPs are still not widely available in the market today. 6.6.3

Telecommunications service access and subscription

A large part of the TINA service architecture found its way into the OMG through a working group on Telecommunications Service Access and Subscription (TSAS). This group defined CORBA interfaces for authentication, service access, and service delivery based on subscription profiles. The TSAS specifications are a simplification of the TINA service architecture and also include some elements from Parlay, for example service


CORBA SCP

CORBA-TCAP gateway

241

SCP

CORBA SS7 network CORBA

CORBA SSP Figure 6.13

CORBA-TCAP gateway

SSP

CORBA-TCAP gateway.

agreements and service discovery. The TSAS specification was finalized in October 2000. 6.6.4

Open-service marketplace

The Open-Service Marketplace Group starts from the TINA and Parlay business model and tries to position CORBA in the value chain between consumers, service providers, network providers, and content providers. The OMG decided that it was not necessary for this group to actually specify control interfaces for network capabilities, because this would duplicate work already done in Parlay and JAIN. The nature of this group therefore remains more strategic and less technical than the others. 6.6.5

Wireless access and mobility

Special problems can arise when CORBA is used in mobile terminals, because CORBA was not designed for objects that dynamically change location. The European-sponsored research project AC036 DOLMEN ran straight into this problem when it tried to implement a TINA platform in a mobile network. The TINA architecture requires software to run in the terminal. In mobile networks, terminals change their network access point as they

242


move around and are forced to handover between radio base stations (see Chapter 4). The ORB routes method invocations on the basis of an object reference, which contains information about the server that an object runs in. In CORBA, an object has a fixed location within a server and a network, but this assumption is clearly invalid when the object runs on a mobile terminal. Roaming adds even more complexity. When a user powers up his or her mobile in a foreign network, the CORBA software in the terminal will have to connect to a foreign ORB of which it has no reference, and which may have features different from the home ORB. Finally, mobile networks simply have characteristics that are different from fixed networks. Delays can be longer, and unexpected errors and disconnections are part of life in mobile networks. This can cause problems in ORBs, especially in synchronous method invocations where the client object is blocked while it waits for a response from the serving object. The TDTF Wireless Access and Mobility Group organizes its work according to the level, as described below, at which problems manifest themselves: ◗

Protocol level: problems with delays, disconnection, errors and retransmissions;

◗

Application level: references to mobile objects, connection to visited ORBs, maintaining QoS in remote method invocations.

The work was still ongoing at the time this book was written, but solutions to some of the problems were studied in the project DOLMEN, mentioned above. 6.6.6

UML for telecommunications

Over the last 10 years, the research community has been working on software techniques for creating telecommunication services. The European Commission sponsored several research projects in this area, sometimes with very different philosophies, such as R2017 SCORE, AC227 SCREEN, and AC237 TOSCA. Most of the research work focused on defining a telecommunications-specific software component model, and on generating tools for specific problems such as analyzing interactions between services in the network.


243

In the past, much of the work on telecommunications software engineering centered around SDL, the ITU-T standard language. With the 2000 release of SDL, the ITU-T makes an effort to merge SDL with UML, and it is expected that the two will be completely integrated at some point in the future. The UML for Telecommunications Group takes a rather practical approach, by starting from UML and adapting it for the creation of telecommunications software. At this time of this writing, work in this group was ongoing.

.

CHAPTER

7 Contents 7.1

Service creation

From SIBs to objects

7.2 Java in telecommunications 7.3

JAIN

7.4

CPL

7.5

Feature interactions

In the previous chapters we looked mainly at architectures. We saw how the Internet, mobile networks, and middleware have influenced the evolution of intelligence in the network. Installing the right architecture is certainly important, but the key issue for operators is how to conduct business with these new architectures. Today the telecommunications business is almost entirely determined by the services offered and their price. It is therefore essential for operators to have not only the right technology, but the right tools to create value-added services efficiently. In this chapter we will consider how the methods and tools for service creation have evolved along with the architectures. Service creation is all about software engineering. But what distinguishes service creation from plain software engineering is the specific nature of telecommunications software: It is complex, concurrent, and must be extremely reliable and deliver high performance. Modern software engineering techniques have penetrated into telecommunications only slowly, due to the highly 245

246


specialized nature of the telecommunications software and the reticence of the telecommunications monopolies. Even today, much of the world’s telecommunications software is programmed in procedural languages of the 1970s. The last 5 years have marked an important change, partly because of the liberalization of telecommunications markets and partly because of the enormous advances in software techniques. One of the most important advances in software has been object-oriented design and programming. Objects are now beginning to find their way into telecommunications software on a large scale. And with objects come object-related techniques such as design patterns and extreme programming. Another great advance is Java programming. Although many people contend that Java compilers and virtual machines are not yet telecoms grade, it seems that Java’s march is unstoppable.

7.1

From SIBs to objects

The INCM (see Chapter 2) was defined in the late 1980s and early 1990s. At the time, object-oriented design and programming was beginning to gain ground, but was not yet widespread in telecommunications applications. The INCM recognizes the need for efficient creation of new services. It defines services as compositions of features, which in turn are composed out of elementary building blocks, SIBs. An IN service-creation environment allows even inexperienced service engineers to create services by clicking together elementary building blocks in a plug-and-play fashion. 7.1.1

Linear service logic

The IN conceptual model introduces the concept of service scripts formed out of elementary building blocks. These IN service scripts are in essence no more than linear decision trees. They are not allowed to contain loops, and for this reason IN service scripts have less expressive power than a programming language. Figure 7.1 shows a simplified version of a service script for the calling card service. For the sake of simplicity, Figure 7.1 shows only the SIB flow with comments, but not the SIB parameters (CID and SSD; see Chapter 2).

Service creation

Begin

User interaction

(2)

Service data management

(3)

User interaction

Play announcement Get PIN from user

Compare

Validate PIN against card data

No match Play error announcement (6) Return to BCP: Release call

(4)

Look up calling card in database

Match

User interaction

(5)

Clear call

Simplified service script for calling-card call.

Charge

Continue

Charge communication to calling card Return to BCP: Continue setting up the call

247

Figure 7.1

Play announcement Get calling card ID from user

(1)

248


In essence, this service script performs the following steps: 1. A message is played to the user, asking for the calling card ID, and user input is received in the form of DTMF tones. 2. The calling card data is retrieved from the database using the calling-card ID input by the user in the previous step. 3. A message is played to the user, asking for the PIN code, and user input is received in the form of DTMF tones. 4. The PIN provided by the user is verified against the PIN on the card. 5. If the PIN is correct, the call is charged to the calling card and the call setup continues. 6. If the PIN is incorrect (card number or PIN invalid), an error message is played to the user and the call is cleared. In reality, the implementation of this service is of course more complex. The full service script would typically involve semantic checks on all the numbers input by the user and provide the user with the possibility to try again in the case of wrong input. The purpose of Figure 7.1 is to show that IN service scripts are in essence simple procedural programs without loops. 7.1.2

Limitations of the IN model

Although IN service scripts have a simple structure and are easy to understand, they also pose important limitations to service engineers. One of the problems with the IN conceptual model is the lack of consistency in SIB granularity. At one extreme, there are SIBs such as service data management, which can represent an arbitrarily complex operation on any kind of service data. On the other extreme, there are very simple SIBs, such as compare, which do not do anything more than compare two values. This wide difference in the granularity of building blocks makes it difficult to write and understand a service script. As a consequence, many telecommunications manufacturers end up developing their own SIBs with a more appropriate level of granularity for the services they are meant to implement. The Alcatel example in Section 2.9.1 illustrates this.

Service creation

249

The definition of HLSIBs (see Section 2.7.2) in IN CS-2 provides a solution to this problem, although it can also be seen as simply a fix for the existing situation in which most vendors implemented their own building blocks. Another problem that exists with the IN conceptual model is its centralized view of network intelligence. A service script is a single undividable entity that runs in one SCP. In the computing world, however, processing tends to become more and more distributed. Multithreaded programming, remote method invocations, and client-server architectures are now common practice. CS-2 does provide mechanisms for distributed service scripts, but they are rather complex and do not trivially map onto existing computing mechanisms. In practice, no commercial IN product uses the CS-2 script distribution; all use standard solutions from the computing world. But the most important problem that exists with the IN conceptual model lies in the traditional separation of data and processing. The IN conceptual model is based on procedural programming, where a program and the data it processes are different entities. The IN conceptual model defines how to construct the flow of service logic, but it says virtually nothing about the data that these scripts act on. As operators began deploying value-added services in their networks it became clear that data plays an essential role in almost all services. To illustrate this, Table 7.1 lists a few well-known IN services and the data that they require. As value-added services become more customized, they become increasingly data-centric. The IN conceptual model, however, is vague on the definition and processing of service data, leaving the design of service data up to the manufacturer.

Table 7.1 Services and Their Data Structures Service

Service Data

Calling card

Calling-card database

Call forwarding

Forwarding table

Call screening

Screening table

Virtual private network

VPN configuration database

250


7.1.3

Object-oriented programming

In the computing world almost all development today is object-based. The advantages of object-oriented programming, listed below, have often been stressed: ◗

Object-oriented programs are more modular than procedural programs because an object encapsulates both data and its processing. They are easier to break up into independent subsystems and easier to test.

◗

Good object-oriented programming practice prescribes programming toward object interfaces. This means that an object implementation can be changed without affecting the overall program, if the object interface remains unchanged. This is a big help in the maintenance of programs.

◗

Object-oriented programming favors code and data reuse. A new object type can inherit basic properties from an already existing type, and extend it with new features. Common objects can be reused in many programs.

◗

Over the years, an important collection of design patterns has been developed for object-oriented programs. This means that it is not only possible to reuse modules of code, but entire object-oriented designs.

◗

Object-oriented programs are much easier to distribute over multiple processors, using remote method invocations to call functions on remote objects.

It is not the intention of this book to enter into a discussion of the merits of object-oriented programming as compared with procedural programming or other programming techniques. The only observation to make is that object-oriented programming has become the industry standard and that a universe of methods and tools is commercially available today for object-oriented software development. The object paradigm has an important impact on the IN conceptual model. An object encapsulates a well-defined piece of data and the operations that can be performed on this data, called methods. The data is only accessible through the methods that the object exports externally.

Service creation

251

The ensemble of all methods of an object is called its interface. As in any other programming model, the data in an object and the parameters of its methods are typed. The type definition of an object is called its class. In other words, an object is an instance of a class. 7.1.4

Object-oriented service logic

If we were to implement the calling card service of Figure 7.1 in an object-oriented way, it would probably look something like what is shown in Figure 7.2. The calling card script now consists not of a sequence of SIBs, but of three independent objects that call methods on each other’s interfaces. As objects represent both data and processing, there are three types of objects in this implementation: 1.

CallingCard:

the key object in the implementation. The calling card object contains the card data (card number, PIN, balance), but also the methods that can be called on this data (checkPIN, changePIN, charge).

2.

CallingCardService:

the object that represents the service itself. It calls methods on the appropriate objects to realize the service. The service is started by calling the begin method. SSF

(1)

begin

Interface Object

Callingcard service

(2)

(6) (3) playAnnouncement

getDTMF

User interaction

Figure 7.2

(5) checkPIN

Calling card

Calling-card service implementation with objects.

charge

252


3.

User Interaction: the object that represents the interface to the user. This object has two important methods: playAnnouncement (messageId) plays an announcement identified by the messageId to the user terminal and getDTMF gets DMTF tones from the user and converts them to digits.

The calling card service now proceeds as follows: 1. The SSP calls the begin method on the object, which starts the service.

CallingCardService

2. The CallingCardService object calls the playAnnouncement (get_card_number_message) method on the UserInteraction object, causing an announcement to be played to the user. 3. The CallingCardService object calls the getDTMF method on the UserInteraction object, to get the card number from the user. When the user has input a series of DTMF tones, this method returns a digit string. 4. The same procedure as in step 3 is repeated to retrieve the PIN code from the user. 5. Using the digit string input by the user, the CallingCardService object identifies the CallingCard object to be consulted. The CallingCardService object then calls the checkPIN (digit_string) method on the CallingCard object, where digit_string is the digit string retrieved from the user in step 3. This method returns OK if the PIN is correct and NOT OK otherwise. 6. When the call is completed, the CallingCardCall object calls the charge(amount) method on the CallingCard object, where the amount is the amount to be charged to the card. This method causes the balance attribute of the object to be updated. This example has been simplified for the sake of clarity. The important thing to understand is the difference between this implementation and the implementation with SIBs of Figure 7.1. There is not one unique way to structure a service in objects. The objects chosen in this example are straightforward and suggestive, but by no means uniquely correct ones. Nevertheless, there exist many good

Service creation

253

practice guidelines in the literature on how to devise an appropriate object structure. The incorporation of object-oriented techniques into the IN conceptual model originally fell within the scope of CS-4. This capability set was to offer an object-oriented model for service composition, alongside the existing SIB model for compatibility. CS-4 does not appear to deliver on this promise, however, and the industry is looking for its own objectoriented solutions. In the next section we will further discuss the programming techniques for object-oriented IN services.

7.2

Java in telecommunications

Many object-oriented languages have been invented over the years, some as extensions to existing languages (like C++), and some as purely object-oriented languages from the offset (for example, Smalltalk and Java). Undoubtedly the most-used object-oriented languages today are C++ and Java. Until the end of the 1990s, C++ had the most industry acceptance. This was due to the widespread use and maturity of C, of which C++ is an extension, and simply to the fact that C++ has been around a few years longer than Java. But recently, the tables have turned, and Java is rapidly becoming the preferred language in many application domains. Some of the advantages of Java are as follows: ◗

Java is much simpler than C++. It is easier to learn, Java programs are easier to read, and it is easier to write correct programs in Java.

◗

Java is purely object-oriented, because it was defined as an object-oriented language from the outset. C++ on the contrary is an extension of C. This means that it is possible to write procedural programs in C++, or even to mix object-oriented and procedural programming. Whereas some claim that this is an asset of C++, it adds an important level of complexity and it is often considered a source of bad programming.

◗

Java is built on the virtual machine concept. Java programs are not compiled directly to machine code, as is the case with C++ and most other programming languages, but are translated to an intermediary byte code. This byte code is low-level code for a virtual machine. Java byte code runs on any physical machine that has the byte code interpreter

254


installed, and programs display the same behavior on any such virtual machine. This is why Java is often referred to as the write-oncerun-anywhere language. ◗

A thriving Java community has been developing scores of libraries and tools for Java.

The main area in which Java has not yet started to upstage C++ is in high-performance and real-time applications. This is because the advantages mentioned in the points above have their cost in terms of performance, or at least they did until now. Java must nevertheless be considered a key programming language for the intelligent network of the future. In this chapter we will consider the use in service creation of two specific Java technologies: Java beans and Enterprise Java Beans. Their names are treacherous in their similarity, as they represent two totally distinct technologies. In the following section, we will explain what the names stand for. 7.2.1

Java beans

Java beans are reusable software components that can be combined into programs in a standard way. Java bean software development tools are usually graphical and allow for “programming in Java without programming.” Graphical representations are used for each Java bean, and programs are constructed by dragging these bean icons into a work area and connecting them together. Java beans are connected together by event channels. The execution of a Java bean produces events, special objects that are sent over an event channel to other Java beans that receive and process them. A Java bean may also employ an event filter that lets through only those events that the bean is interested in. Whereas normal communication between objects is synchronous, event channels allow for asynchronous communication between Java beans. This means that a Java bean can send an event through the event channel without waiting for a result to come back or dealing with the actual delivery to the receiving Java beans. Java beans provide an object-oriented alternative for the SIB-based service-creation environment. Figure 7.3 shows what the same example of the calling card service introduced in Figure 7.2 could look like in the form of Java beans.

Service creation

IN service-creation environment File Edit View Insert Format Tools Simulate Draw Window charging announce cards profiles

calling card

script

announce

security mmedia weblink Event Channel event type event name check PIN

Java beans service-creation environment.

255

Figure 7.3

256


There are several manufacturers in the market today offering such object-oriented alternatives to service creation. The advantage of using Java beans technology is that there is a wide variety of Java bean toolkits available from different vendors. And what is even more important, Java ensures a high degree of portability of code; a Java bean application produced with one vendor’s tool will run on another vendor’s platform. 7.2.2

EJBs

One of the problems when using Java in enterprise applications is that such applications are often built around databases that are not objectoriented. Enterprise data is often held in relational databases such as Oracle or DB2, which continue to be the industry standard. Relational databases are the common way of storage in most IN platforms on the market today. EJBs provide a way of integrating non-object-oriented data in a distributed object-oriented computing environment. They are the key concept in Sun’s J2EE package of Java tools and libraries. J2EE promotes the principle of multitier applications, in which data presentation is separated from data processing, and data processing is separated from data storage. J2EE provides tools for each of these layers (presentation, processing, and data). EJBs are the central concept of the processing layer, while Java server pages (JSPs) and servlets are technologies for presentation. In spite of the similarity in name between Java beans and Enterprise Java Beans, these are two entirely different concepts targeted at different application domains. There are two types of EJBs: 1. Entity beans encapsulate data and the operations that can be performed on this data. In most cases, the data represented by an entity bean corresponds directly to an entry in a relational database. In other words, an entity bean hides database access from the rest of the application. 2. Session beans are intermediary objects between the client application and entity beans. They maintain the dialogue between a client application and an entity bean. One session bean is created for each client that requests access to a certain session bean. A client application never directly accesses an entity bean; this is always done through a session bean. Session beans are generally more short-

Service creation

257

lived than entity beans. A session bean is created for the duration of the client application’s request for data processing. Its life span is the dialogue between the client application and the entity bean. Entity beans, on the other hand, are persistent and can exist for as long as the data in the database is needed. EJBs can be applied to intelligent networks programming to combine Java programming with existing relational databases. Figure 7.4 reconsiders the implementation of a calling card service, but this time with EJBs. Assume in this example that the data related to calling cards is stored in a relational database in the SDF. For each calling card that is used in a service, the SCF creates a calling card entity bean. Each calling card entity bean encapsulates access to the data of exactly one calling card, and its interface offers all the operations that can be performed on a calling card: checkPIN, changePIN, charge, and possibly others. Each service request from the SSF results in the creation of a callingcard-service session bean. This session bean contains the actual service script and maintains the dialogue with the SSF. It is important to realize, however, that the calling-card-service session bean does not contain any data used in the service; for data processing it refers to entity beans such as the calling card bean. The calling-card-service session bean only keeps track of the state of service processing, or put in more technical terms, of the INAP dialogue state. Client processes

Session beans

BCSM

Calling-card service script

BCSM


BCSM


SSF Figure 7.4

Entity bean

(Relational) database

Calling card

Callingcard DB

SCF Implementation of calling-card service with EJBs.

SDF

258


There are certain advantages in using this computational model. First, it is possible to change the implementation of the calling card entity bean without affecting the service. As long as the interface of the entity bean is unchanged, client applications are not affected. This makes maintenance of the applications much easier. Another advantage is that the EJB model allows several different services to use the same data. It is possible to use the same calling card bean in a different service, for example one that allows a mobile user to charge the sending of an SMS to the calling card. In other words, EJBs promote software reuse. 7.2.3

EJB tool environments

One of the most important advantages of using EJBs is that they come with an extended set of generic tools. An EJB runs in a controlled execution environment called a container. A container is a unit of failure and persistence, and contains generic facilities for managing the EJBs in it. A container can be programmed, for example, to restart an EJB automatically after failure. Containers also provide facilities for transaction management. Put in a simplified way, a transaction is a combination of operations that have to be executed as one indivisible action. In other words, all operations must succeed, or else the ones that were already executed must be undone (this is called rollback in transaction jargon). Transactions play an important role in areas such as e-commerce, where it is necessary that both payment and product delivery be guaranteed; in other words, no payment without delivery and no delivery without payment. Because EJBs are a general software technology, the use of EJBs in intelligent networks opens up the market to third-party products. In general, EJBs can involve the following different business roles: ◗

The bean provider sells libraries of beans for particular application domains. In our example, the calling card entity bean could be the product of a telecommunications bean provider that works closely with a certain database vendor.

◗

The application assembler develops applications from EJBs. In our example this would be the service creator that builds the calling card service from the calling card entity bean and the calling-card-service session beans.

Service creation

259

◗

The container provider sells generic EJB containers; that is, computing environments for EJBs with facilities for management and transactions.

◗

The server provider sells the hardware and operating systems that run the containers with EJBs.

EJBs, EJB containers, and EJB servers are available from several different vendors in the market today. Although the use of EJBs in IN appears promising, success hinges on the availability of high-performance, highly available EJB containers and servers. At the moment, real carrier grade EJB platforms do not appear to exist in the market, although telecommunications equipment vendors could move their products in this direction.

7.3

JAIN

Up to this point we have seen two ways in which Java could be used to program network intelligence: with Java beans and EJBs. Both Java beans and EJBs are generic Java techniques, not in any way specific to telecommunications. But of course the Java developer community also thought of specific Java tools for telecommunications. Java APIs for programming private branch exchanges (PBXs) have existed for some time. The Java telephone API (JTAPI) provides a generic Java API for programming services on PBXs. The advantage of using JTAPI is that this Java API is generic, independent of the underlying physical PBX hardware and software. This means that a JTAPI application in principle runs on any PBX equipped with JTAPI, much like a normal Java application can run on any machine that runs the Java virtual machine. Many of the services that can be programmed on PBXs bear strong resemblance to IN services: number translations, closed user groups, call screening, call gapping, call waiting, and call queuing are valid in both PBX and IN. So why don’t we use JTAPI for programming services in IN? There are a few important reasons why JTAPI cannot be used directly. First, the public telephone architecture is more complex than that of a PBX. A PBX has global control over all originating and terminating calls, but in the telephony network, this control can be distributed

260


over different switches. The JTAPI call-state model is therefore significantly simpler than the IN O-BSCM and T-BCSM. But perhaps the most important difference is the absence of interexchange signaling in a PBX environment. In essence, a PBX is an intelligent switchboard that can switch connections directly between telephones. Since all the switching is done in a single box, there is no need for signaling to set up calls. This is of course different in the public network, where calls typically involve more than one switch, possibly even belonging to different operators and different countries. Things become even more complicated when we consider that telephone calls are now not only made over the telephone network, but over the Internet and mobile networks. Something more sophisticated than JTAPI is therefore needed to program IN services. In 1998, the Java developer community started work on a set of APIs for programming services in public networks. The resulting specifications are called JAIN. JAIN is part of the Java developercommunity process. As such it is bound by the same rules as the other Java APIs. Sun Microsystems administers the group, but participation in the definition of JAIN is free for anyone who signs the Java specification participation agreement (JSPA), the Java community collaboration agreement. The final specifications are public and freely available. 7.3.1

JAIN architecture

Central to JAIN is the notion of soft switching (see Section 3.2.8). Where JTAPI is an API for programming PBXs, JAIN can be seen as an API for programming soft switches. As we saw in Chapter 3, the main difference between a normal switch and a soft switch is that the latter does not necessarily have switching hardware attached to it. It can be a signaling node that controls network resources remotely. A typical use for JAIN is shown in Figure 7.5. In this case, a Java programmable soft switch controls calls between a telephony network and an IP network with SIP servers. The calls between the two networks pass through a media gateway that does the conversion of voice coding. In order to negotiate calls between the two networks, the soft switch must be able to understand both SIP and the SS7 ISUP protocol. Moreover, it must be able to control the media gateway, for example with MGCP. Programming a soft switch that handles a multitude of different protocols is a difficult task. The idea behind JAIN is to define a Java environment for programming of such soft switches, making use of existing Java techniques such

Service creation

261

Applications

ISUP

JAIN soft switch

SIP

MGCP Media gateway

SIP proxy SIP phone

Telephony network Figure 7.5

IP network

Java-controlled soft switch.

as Java beans. JAIN applies the same principle as all other Java APIs by hiding the protocol complexities behind a generic Java API. This allows JAIN applications to run on any JAIN soft switch, whatever the underlying signaling protocols. To this end, JAIN is structured in the following three layers: 1. Protocol APIs. JAIN defines Java APIs for the most common protocols, in particular TCAP, ISUP, MAP and INAP. This means that applications do not have to access protocol stacks, but instead can interact with Java objects that represent these protocols. 2. Call control and transactions APIs. The Java call control (JCC) API provides a call model that is independent of the network technology used. It represents the generic setup of a call over the Internet, telephony, or mobile networks. Applications can use this model to intervene in the call setup process and control it. At this level JAIN also defines a Java coordination and transactions (JCAT) API for transactions that are not necessarily call related, for example interrogating an HLR in a mobile network. 3. Service logic execution environment (SLEE). JAIN uses Java beans as a high-level language to program services, and provides both a service-creation environment and an execution environment.

262


Figure 7.6 shows the JAIN structure and its layers. JAIN provides a relatively loosely coupled set of APIs. The specification of JAIN is managed on a per-API basis. This means that some APIs may be more mature than others at any point in time. The JAIN architecture is modular in the sense that applications are not obliged to use all APIs or all layers. An application running in the SLEE can directly access the APIs of the lower layers (for example, the SIP or ISUP API), or can use the Java call control API, or both. In the following sections we will take a closer look at the structure of the JAIN APIs and the communication between them. 7.3.2

JAIN protocol APIs

At the moment, there are JAIN protocol APIs for TCAP, ISUP, MAP, INAP, OA&M, MGCP, and SIP, and this list is expected to grow over time. The protocol APIs allow programmers to write applications toward standard APIs rather than proprietary protocol stacks. This reduces the dependence of the code on specific protocol stacks and greatly improves the reusability of application code. JAIN uses the event listener mechanism for communication between the application and the protocol API. The event listener mechanism is the standard way of communication between Java beans. It involves two components: a provider that sends events and a listener that receives events.

Service-logic execution environment (SLEE)

Java soft switch

Applications

Java call control (JCC) TCAP

ISUP

MAP

SS7 Figure 7.6

JAIN structure.

Java coordination and transactions (JCAT) INAP

OAM

MGCP

SIP

IP

Service creation

263

A listener must first register with a provider before it receives events. Once registered, a listener can also filter the events it receives from the provider. Events are sent from provider to listener through an event channel, which makes the communication asynchronous. In standard Java, one provider can send events to more than one listener, but in JAIN the relationship between provider and listener is always one to one. This is done to avoid error-prone situations in which several applications can interfere in the same protocol dialogue. The principle of the event listener model is illustrated in Figure 7.7 for the example of the ISUP protocol API.1 The ISUP API in Figure 7.7 provides an interface for the following:

Application

Event

Event channel

Listener

Method call

Provider JAIN ISUP SS7 stack

ISUP messages

SS7 network

Figure 7.7

Event listener pattern.

1. The ISDN user part (ISUP) protocol is one of the SS7 application-layer protocols, generally used for signaling between telephone exchanges. In spite of its name, the use of ISUP is not limited to ISDN. See Section 2.1 for more details on SS7 and ISUP.

264


◗

Receiving ISUP messages. An ISUP event coming from the SS7 network is first translated into a Java event by ISUP API software. The event is then passed to the provider, which sends it through the event channel to the listener registered to receive the events. When the listener receives the event, it can forward it directly to the application (push) or store it and wait for the application to get the stored events (pull). This is up to the implementation.

◗

Sending ISUP messages. When the application wants to send an ISUP message, it directly calls the corresponding method on the API. In this case the communication is synchronous.

The event listener model is used to make the communication from the protocol API to the application asynchronous. This avoids having the API call synchronous methods on the application, which can overload or crash the application in extreme situations. Note that in the reverse direction, from application to API, there is no need to make the communication asynchronous because there is no risk of affecting the application. 7.3.3

JAIN call control

Central to JAIN is the definition of a generic API for call control. This API is the same whether the underlying network is a telephony network, an IP network with SIP servers, or a mobile network. This adaptability allows service logic to be completely reusable between JAIN soft switches. As explained in the introduction to this section, JAIN is inspired by the JTAPI programming interface for private branch exchanges. JTAPI offers a call-control API based on a simple call model. The JTAPI call model is not sufficient to be used for JAIN because it does not contain all the states that call setup goes through in the public telephony network. It does, however, provide a good basis, and part of the JAIN call model is based on JTAPI. The remaining part draws upon the IN basic call-state models explained in Chapter 2. JAIN defines two call interfaces, a structure designed to formalize the relationship with JTAPI: 1. Java call processing (JCP) is a simple call-control API that serves as a common root for both JTAPI and JAIN. Both the JTAPI and Java call-control APIs inherit from this common root class. 2. JCC is a more fine-grain call model that resembles the IN basic call-state models.

Service creation

265

The relationship between JCC, JCP, and JTAPI is shown in Figure 7.8. Note that the JAIN JCAT interface in turn inherits from JCC and from JTAPI. We will not go into detail on JCAT here. JCC uses the following objects to model the structure of a call: ◗

Provider: represents the JAIN process that manages calls. This is not to be confused with the event listener provider of Figure 7.7.

◗

Call: represents the temporary logical and physical association of connections and end points.

◗

Address: represents a logical end point in a call, for example an SS7 telephony address or an IP address.

◗

Connection: represents the connection of an end point in the call.

The provider creates a call object as a result of a call attempt. A call object can create address objects and connection objects for originating and terminating call legs. The communication between these objects and the application uses the same provider-listener pattern as described above. Figure 7.9 shows the relationship between the provider, call, connection, and address objects, and how they communicate with the application. For the sake of simplicity, this figure does not show the event

Java call processing

JTAPI

Java call control

Java coordination and transactions Figure 7.8

Relationship between JCC, JCP, and JTAPI.

266


Provider

Figure 7.9

tho

Connection listener

Events

dc all

Events

Call listener

Me

dc all tho Me

Events

Provider listener

Method call

Application

JCC API

Connection

Address

Connection

Address

Call

JCC objects.

provider objects associated with the provider, call, connection, and address objects. The connection object keeps track of the state of connection set up with the finite state model shown in Figure 7.10. As explained above, there are two versions: the JCP and the JCC model. JCP has a very simple structure and only describes the main call setup states such as idle, in-progress, alerting, connected, and disconnected. JCC inherits these simple states from JCP but adds new states that roughly correspond to IN trigger detection points, such as authorization of call attempt, address collected, address analyzed, call delivery, and suspended. Figure 7.10 shows the main difference between the two models: the in-progress state of the JCP model is expanded in the JCC model by more fine-grain states, and JCC adds the new suspended state. For the sake of clarity, the models are slightly simplified in Figure 7.10. Some arrows were omitted: In JCP it is possible to skip any state moving from idle downward. In JCC it is possible to skip directly from idle to alerting or connected. From authorize call attempt, it is possible to skip to address analyze, call delivery, or alerting. There are connections to and from unknown from all other states except failed and disconnected. In spite of these simplifications, Figure 7.10 adequately illustrates the call states of JCP and JCC.

Service creation

267

Failed

Idle

Auth call attempt

In-progress

Address collect

Unknown Alerting

Connected

Call delivery

Disconnected

Suspended

Java call processing Figure 7.10

Address analyze

Java call control

JCC call-state model.

The JCC call model strongly resembles the IN basic call-state models discussed in Chapter 2. This is not a coincidence, of course. JAIN tries to follow as closely as possible the existing IN call-control model and can be seen as the Java version of the IN basic call-state model and the IN mechanism for triggering services. 7.3.4

JAIN example: Call forwarding

To see how JAIN allows Java applications to control call processing, we will now consider the example of call forwarding. To keep things as simple as possible, we will refer only to the relevant call control beans. We will not include any feature beans or protocol beans. Figure 7.11 shows the interactions between the call control objects in the case of call forwarding. The process is as follows: 1. Before the application can process any calls, it must register its listener with the provider, as explained in Section 7.3.2. 2. At some time after this, a call comes in and the provider receives an incoming call event from one of the protocol APIs.

268

Application Connection listener

Provider

addConnectionListener (1)

Register listener Incoming call

(2) New (3)

Call New (4)

Connection

connectionAlerting getAddress (6) Translate B->C (7)

A,B routeCall(C,A) New (8)

(9)

Figure 7.11

Call forwarding with JAIN.

Release X

Connection

Talk


(5)

event

Service creation

269

3. The provider creates a call object for the incoming call. 4. The call in turn creates a connection object corresponding to the incoming call leg. 5. Since this is an incoming call, the connection object generates an alerting event over the event channel to the listener on the application side. Note that this happens because the application had previously registered for connection-related events. 6. The application requests the address information from the actual connection. The connection responds that it connects A and B. 7. The application translates the destination number B to C and instructs the call to (re)route the call from A to C. 8. The call object creates a new connection object to address C. 9. The application finally orders the old connection to B to be deleted. This example was taken in simplified form from the original JCC documentation [1]. The use of objects introduces some overhead that may look exaggerated for a simple service such as call forwarding. In the case of more complex services, however, this pays off in the form of a highly structured approach. 7.3.5

JAIN applications

One of the important drivers for JAIN is to take advantage of the complete arsenal of Java-based software development tools in service creation. The entire computational model of JAIN is based on the use of Java beans. Java beans are used at all layers of the JAIN architecture of Figure 7.6. This means that a JAIN application is assembled out of Java beans that connect to JCC or JCAT Java beans, which in turn use protocolrelated Java beans. This is illustrated in Figure 7.12. At the level of the service logic execution environment, JAIN defines three libraries of Java beans: 1. Application primitive beans correspond to basic network functionality, such as set up connection between A and B or get mobile user status.

270


Application beans

Application feature beans Utility beans Application primitive beans JAIN call control API Call control beans

Protocol beans TCAP Figure 7.12

ISUP

INAP

OA&M

MAP

SIP

MGCP

Assembling JAIN applications out of Java beans.

2. Application feature beans represent service features, units of reusable functionality that can be billed for. Application feature beans can be seen as equivalents to features at the service plane of the IN conceptual model (see Chapter 2). 3. Utility beans are auxiliary beans used for testing, monitoring, simulation, and management. The application beans at the top level are service-specific beans, the glue that binds together all feature beans and other beans into JAIN applications. There are no strict rules for the way in which beans at the different layers can be connected. An application bean can make use of application feature beans, but can also connect directly to application primitive beans, call control beans, or even protocol beans if needed. As we saw in Section 7.2.1, Java beans are graphical components that communicate via event channels. The use of Java beans in JAIN means that it is possible to use standard Java bean tools as part of the servicecreation environment.

Service creation

7.3.6

271

Specification, products, and conformance

The JAIN specification process is managed by Sun Microsystems as part of its Java developer-community process, the overall framework for the development of Java APIs. Participation in the definition of JAIN is free to anyone who enters the Java Community Process by signing the JSPA. JAIN is organized into two groups: 1. The protocol expert group is responsible for specifying and maintaining the individual protocol APIs at the lower end of the JAIN architecture. 2. The application expert group takes care of the JCC and JCAT interface specifications, as well as the SLEE and service-creation environment. According to the rules of the Java developer-community process, the specification of JAIN APIs takes the following path: ◗

Community review. The first review cycle is internal to members of the Java community process. The API may undergo modifications as a result of this review.

◗

Public review. Once an API has passed the community review, it is put up for public review on the Java community Web site. Anyone in the industry may comment on the API, and these comments may lead to new modifications.

◗

Proposed final draft. When the API has passed the public review it gets proposed final draft status. At this stage it must be complemented with a reference implementation plus a test suite to determine the conformance of implementations. The API can still be modified at this point, if experience with the reference implementation requires this.

◗

Final release. After the previous steps have been completed successfully, the API receives final release status. From this point on the API is maintained within the Java community process.

Based on its reference implementation JAIN defines a certification process to ensure that products are compatible. Certification is done on a per-API basis and is managed by private companies with whom Sun Microsystems has a special agreement.

272


JAIN defines three types of products, as follows: 1. Certified products are products that have successfully passed the certification process. 2. Preproducts are products that have not yet passed certification, or that are still under development. This includes product beta releases. 3. Early adoption products implement parts of the JAIN specification that are not yet released in final form by JAIN. 7.3.7

JAIN and Parlay

JAIN was created around the same time as Parlay, in the beginning of 1998, and they are often discussed together. There are so many similarities in JAIN and Parlay that the uninitiated sometimes have difficulty distinguishing between them. Both JAIN and Parlay are about providing APIs for network functionality, and about programming applications on these APIs. Both JAIN and Parlay are about integrated applications for multiple networks, including telephony, mobile, and Internet. There are, however, important differences between JAIN and Parlay. The most important difference lies in what they were intended for. The main objective of JAIN is to provide Java programmability for soft switches and service nodes. The main objective of Parlay is to allow third-party applications, external to the network, to control network resources. In JAIN, the applications run on soft switches inside the network and are managed by the service provider, while in Parlay they run on nodes outside the network and are managed by third parties. There are also several other distinctions, summarized in Table 7.2. As in Chapter 5, many of the points listed for Parlay also apply to OSA. Since JAIN comes from the Java community, it is completely centered on Java programming. JAIN specifies not only the Java APIs but the objects that implement these APIs, for example the JCC call-control objects described in Section 7.3.3. Parlay, on the other hand, is completely implementation independent. The Parlay interfaces are described in IDL, which is independent of any programming language. Parlay only specifies an interface; it does not specify how the objects behind the interface are implemented. JAIN was originally intended for the creation of applications that run within the operator domain. JAIN therefore does not have a security

Service creation

273

Table 7.2 Comparison Between JAIN and Parlay JAIN

Parlay

Specifications

Interfaces and components

Interfaces only

Secure access

No

Yes, via framework interface

Certification framework

Yes

No

Service logic

In operator domain

Operated by third parties

Implementation

Java beans

Any (usually CORBA)

Object communication

Event listeners

Callbacks

Standardization cycle

Per API element

Per version

Standardization group

Sun Microsystems Java community process

Parlay group (independent industry consortium)

framework like Parlay, since all applications are considered to be trusted. Inspired by the work in Parlay, the JAIN community soon realized that it would be useful to allow nontrusted third-party applications to also use the Java APIs. Rather than to develop its own security interface from scratch, JAIN adopted the Parlay interfaces to allow access from external applications. This interface is called JAIN service provider access (SPA); it is illustrated in Figure 7.13.

Third-party untrusted applications

Parlay API

Service-logic execution environment (SLEE) Trusted applications

Service provider access (SPA)

Java callcontrol (JCC)

TCAP

ISUP

MAP

Java coordination & transactions (JCAT)

INAP

Java soft switch Figure 7.13

JAIN service provider access.

OAM

MGCP

SIP

274


From the service provider’s point of view there are two ways of looking at the relationship between Parlay and JAIN. Seen from JAIN’s viewpoint, Parlay is a secure interface that allows external applications to use JAIN functionality. From Parlay’s viewpoint, JAIN is one of the possible implementations of the Parlay interfaces. The adoption of Parlay in the definition of JAIN SPA has brought Parlay and JAIN close together. Many companies that are in the Parlay group also participate in JAIN, and vice versa, and in the immediate future Parlay and JAIN are expected to synchronize their activities.

7.4

CPL

As we saw in Chapter 3, the Internet has its own concept of network intelligence. One of the key protocols for Internet telephony is SIP. According to the IETF definition of SIP, a SIP server can modify or redirect SIP requests, but the definition does not specify how the SIP server is programmed to do this. That is why the IP Telephony (IPTEL) working group of the IETF is working on a call processing language (CPL) that tells a SIP server what to do with a call. CPL is a very simple language that describes decision structures for routing calls. CPL does not allow loops and does not support user-defined variables. CPL is used to tell SIP servers such things as if the incoming call is from [email protected] and the time is between 6 P.M. and 8 A.M., then route the call to [email protected] unless it is a fax, then send it to [email protected]. CPL is described in XML, a metalanguage format for defining languages based on markup tags. XML-derived languages bear a strong resemblance to HTML, which belongs to the same family. A CPL script, therefore, has a very similar outlook to that of an HTML page description. 7.4.1

CPL structure

Each CPL script installed in a server has an owner, and is always associated with the address of this owner. A CPL script consists of top-level actions and subactions. There are two types of top-level actions: 1. Incoming describes what to do with calls whose destination address corresponds to the owner of the script.

Service creation

275

2. Outgoing describes what to do with calls whose origination address corresponds to the owner of the script. A subaction is any action that can be reused within other actions. A subaction can be compared to a procedure or subroutine in programming languages, except that CPL forbids subactions to be recursive. Top-level actions and subactions can contain the following elements: ◗

Switches, which compare an element of a SIP message against a set value and can make choices based on these comparisons. A switch is similar to a switch or case statement in programming languages, or can be seen as a nested if-then-else statement. A switch in CPL can make a choice on the basis of originating or destination address, time and date, priority, or even free-form text strings in the subject or body of the SIP message.

◗

Location modifiers change the location to which the call must be routed, as specified in the to: and via: lines in the SIP message, as we saw in Chapter 3. CPL allows location modifiers to specify an explicit new address, or it can order the new address to be looked up in an internal or external database.

◗

Signaling actions specify what to do next with the SIP message after possible modification. The options are to proxy the SIP message, to redirect it, or to reject it. Proxy means sending the message on to the destination or another SIP server and redirect means sending it back to the originator with a modified address.

◗

Nonsignaling actions are additional actions that are not related to the SIP message. There are two nonsignaling actions defined: sending an e-mail to a specified address, or writing information in a log file.

In a CPL script, all actions and subactions are delimited by markup tags of the form and , very much like in HTML. Tags can have attributes, for example as in , which is a tag with attribute url set to "SIP: [email protected]". Table 7.3 lists a few CPL elements as they appear in a CPL script. It is not our intention here to give a formal definition of CPL, only to convey a

276


Table 7.3 A Sample of the Main CPL Constructs CPL Element

CPL Example

Switch

..action to be taken when address matches.. ..default actions in case of no match..

Location modifier

Signaling action

<proxy timeout= time in seconds to wait for reply> ..actions to be taken on busy.. <noanswer> ..actions to be taken on no reply.. ..actions to be taken on failure condition.. (this is the short form for )

Subaction definition

<subaction id=”subaction name"> ..subaction definition..

Subaction reference

 (short form, as above)

feeling of what CPL looks like. CPL is quite simple; the complete CPL definition can be found in [2]. 7.4.2

Example CPL script

To see what a complete CPL script looks like, consider the example shown in Figure 7.14. This script instructs a SIP server to forward all incoming SIP calls from users at host tecsidel.es to be routed to SIP:[email protected] and all other calls to a voice mailbox, SIP:[email protected]. Moreover, if the forwarded calls are not answered or if the line is busy the SIP call must also be routed to the same voice mail.

Service creation

Address switch

field=“origin” subfield=“host” subdomain-of=“tecsidel.es”

<subactionid=“voicemail”>

otherwise

Location modifier

Proxy

<proxy timeout=“10”> <noanswer> 

timeout=“10”

No answer

Busy Failure



Location modifier

Redirect

Example of a CPL script.

277

Figure 7.14

278


Because CPL scripts are nonrecursive, they are easy to represent in graphical form as decision tree structures. Figure 7.14 shows the same script in graphical form on the right side, indicating which parts of the CPL text relate to which boxes. 7.4.3

Deploying CPL

So far we have seen what CPL is for and what it looks like, but that still leaves open a few key questions: How are CPL scripts created and by whom? How are they deployed, triggered, and executed on SIP servers? The IETF does not provide direct answers to these questions, because they are out of the scope of the definitions of SIP and CPL. The answers must come from the industry. Several manufacturers have already begun to come up with real solutions based on CPL and SIP. In this section we will take a look at the architecture proposed by the Alcatel Corporate Research Center [3]. The Alcatel approach makes extensive use of the existing Java servlet technology. A servlet is a small Java program that runs on a Web server and that is associated with an event on an HTML page. When the user clicks on a specific item on the page, an HTTP request is sent to the Web server, causing the servlet to be executed. Note that servlets are exactly the opposite of applets. Applets are downloaded from the Web server and are executed locally in the browser. Applets run on the client; servlets run on the server. Servlets typically do no real processing themselves, but activate other Java beans that form the application. This separation of presentation logic (servlets) and business logic (Java beans and EJBs) is of paramount importance in the J2EE framework. It ensures better modularity, reliability, and efficiency. In the Alcatel approach, the SIP server activates servlets as a result of incoming SIP requests. This is possible because SIP is based on HTTP. Servlets are designed for use with HTML pages, but can be applied to SIP without any effort because of the similarity between SIP and HTTP. To activate and run servlets, the SIP server must run a servlet engine, which can be seen as the equivalent of the Java virtual machine for servlets. Alcatel distinguishes three levels for the creation of CPL scripts: 1. Browser-based. End users can edit simple CPL scripts with a Macromedia Flash editor that runs in a standard Internet browser. The

Service creation

279

editor at this level is very user friendly but allows for the creation only of simple call-processing scripts. All the end user needs is a standard browser with Flash plug-in, as the CPL editor itself can be downloaded from the Web. When the user has completed a CPL script, it is sent to the SIP server where it is stored and executed. 2. Java-bean-based. Service providers can compose more complex scripts using Java beans. Alcatel has implemented a library of Java beans that correspond to CPL primitives. The service provider creates scripts by configuring and composing beans in a graphical environment. When a call arrives at the SIP server, a servlet is activated which in turn calls the Java bean script using the standard Java procedure. In this case the CPL script is encapsulated in Java beans. 3. Java-IDE-based. At the specialist level it is also possible to program custom call-processing code directly in Java, using Sun’s integrated development environment (IDE) for Java. As for Javabean-based creation of CPL scripts as described above, the resulting code is called from a SIP servlet. At this level the programmer has full control over call processing. It is still possible to use the library of CPL beans, but the programmer can add code that goes beyond the capacity of CPL. Figure 7.15 shows the three levels of the Alcatel CPL service-creation environment. The top part of Figure7.15 shows the three service-creation environments and the output they produce: the Flash editor produces CPL scripts, the bean editor produces Java bean scripts, and the Java IDE produces Java code. The execution environment contains two kinds of servlets: the CPL interpreter servlet, which interprets CPL scripts, and the SIP servlet, which starts Java bean applications. The thin arrows in Figure 7.15 show the dynamic behavior of this platform: when a SIP message arrives at the server, this starts one of the servlets. Figure 7.15 shows both scenarios: If the CPL interpreter servlet is started, it will interpret the CPL script that the user has previously downloaded from the Flash editor. If the SIP servlet is started, this servlet starts the Java bean script or Java program that corresponds to the address information in the message.

280


Flash editor

Java bean development

Java IDE

Java beans CPL

interpret script

start bean

CPL interpreter servlet

SIP servlet

SIP server

Java

Servlet engine start servlet

SIP message Figure 7.15

SIP protocol stack

start servlet

SIP message

Alcatel CPL service-creation and execution environment.

The Alcatel effort concentrated especially on browser-based CPL editing, since this allows end users to produce their own customized scripts for call processing. One of the strong points of SIP and CPL is their simplicity, making it possible even for end users to define their call treatment directly. 7.4.4

IN and CPL

At first sight, IN and SIP are worlds apart. IN offers a complete conceptual model that defines how services are created, deployed, triggered, executed, and managed. SIP on the other hand is only a protocol. The intelligence in IN is centralized; in SIP it can be distributed over any number of SIP servers between the origin and destination of the call. Yet there are striking resemblances between CPL scripts and IN service scripts. Both specify how to process incoming and outgoing calls. Both are decision tree structures without loops.

Service creation

281

CPL has less expressive power than IN SIBs. IN SIBs that forward or screen calls can be translated directly into CPL constructs, but there are no CPL counterparts for the more complex IN SIBs for charging, call queuing, user interaction, and service data management. Table 7.4 shows how some of the IN CS-1 SIBs can be translated to CPL. The difference in expressive power between CPL and IN can be explained from their backgrounds. The intention of IN SIBs is to give the service provider full control over call-processing features. CPL on the contrary is targeted more at the end user, and is based on the philosophy that the end user uploads his or her call-processing scripts on a SIP server. CPL therefore does not allow any actions that can be considered internal to the service provider, such as charging or modifying data in a subscriber database. CPL still offers a few important advantages that make it interesting for use in the IN environment. It is very simple and transparent, and has a well-defined syntax and semantics. But most importantly, CPL has the potential to provide a uniform call-processing language for SIP-based Internet telephony and IN.

Table 7.4 Mapping from IN CS-1 SIBs to CPL IN CS-1 SIB

CPL Equivalent

Algorithm

No direct equivalent: CPL is not a programming language

Authenticate

Address switch followed by reject

Charge

No direct equivalent

Compare

Switch

Distribution

Switch

Log call information

Nonsignaling action

Queue

No direct equivalent; could be implemented in CPL by proxying calls to a special queuing server

Screen

Switch

Service-data management Location modifier with lookup (CPL, however, does not allow to write in a database) Service filter

Switch followed by reject

Translate

Location modifier

User interaction

No direct equivalent; could be implemented in CPL by proxying calls to a special voice-response server

Verify

No direct equivalent

282


CPL can be used in IN as a high-level service-creation language with restricted expressive power that allows end users to define their callprocessing preferences. The idea of allowing end users to configure their call-processing profiles over the Internet was mentioned in Section 3.4. Some commercial IN products already allow such profile configuration based on proprietary interfaces. CPL now offers a standard mechanism. CPL tools such as Alcatel’s Flash editor (Figure 7.15) can be used to create call-processing scripts for both IN and SIP-based networks. The end user does not even have to be aware of whether the target network is a telephony network or the Internet.

7.5

Feature interactions

In this chapter we have seen several techniques for developing new services in the network. The ability to implement new services more easily and rapidly creates new business and competition, but also introduces a new problem. The more services operate in the network, the greater the chance that they will somehow interfere with each other. Consider the following simple example: Subscriber A uses the callscreening service to block all calls to subscriber B. Suppose that another subscriber, C, forwards all calls to subscriber B. If A calls C, then what will happen? There are two possibilities: 1. If the call-screening service is not aware of the forward, then the call will be completed to B. But this is in contradiction to A’s wish to block calls to B. 2. If the call screening is somehow aware that the call is routed to B, then it could decide to block the call. But this interferes with C’s intention to forward all incoming calls to B. Figure 7.16 illustrates the ambiguity of this situation. No matter how you look at this, the resulting behavior is likely to be unexpected to either of the parties A or C. What this example shows is that one service feature can interfere with other service features so as to result in unexpected or even undesirable behavior. This is called the feature-interaction problem.

Service creation

283

B Call screening Block all calls to B

C

Call forwarding Forward all calls to B

fo

rw ar ds

to

B

A calls C A Figure 7.16

7.5.1

C

Interaction between call screening and call forwarding.

Solving feature interactions

As it was rolling out IN in the early 1990s, Telcordia was the first company to recognize the feature-interaction problem. It was the first to propose a classification of feature-interaction types that might occur in telecommunications networks [4]. Since then, feature interactions have been intensively studied in the industry and in academia. There are three fronts on which the featureinteraction problem can be attacked: 1. Avoidance. In some cases it is possible to design the service control model in such a way that certain interactions cannot occur. The single point of control rule in IN CS-1 (meaning that only one service logic program can control a call at any time) mentioned in Section 2.8.1 was defined to restrict certain feature interactions. 2. Detection. When developing a new service, it is advisable to check its interactions with other known services in the network. This is typically done at specification time, to reduce the probability of implementing interaction-prone features. 3. Resolution. When a conflict between features occurs in the network, it has to be resolved. Researchers quickly realized that feature interactions can never be completely avoided. No matter what restrictions you put on the service control model, there are always interactions that slip through the net. There is also a tradeoff between avoiding feature interactions and

284


providing a rich feature set: the more restrictions, the more limited the services you can create. For these reasons, relatively little research was put into avoidance. Significantly more research effort was put into feature-interaction detection and resolution, the subjects of the next sections. 7.5.2

Detection

Over the last 10 years, by far the most effort has gone into the detection of feature interactions during the specification of new services. Different research groups have come up with a wide array of proposed solutions to the problem. These solutions can be roughly classified into two groups: formal-model-based approaches and heuristic approaches. Formal-model-based solutions describe the service features in a mathematical model (e.g., finite state machines, temporal logic, process algebra, and Petri nets) and then apply formal reasoning to detect feature interactions. When using this approach it is necessary to specify both the expected behavior of the feature and its implementation in the network context. The approach hinges on how well you manage to express these things in the mathematical model. There are many formal approaches, but all eventually boil down to specifying the state space of the problem. Zave [5] provides a good discussion of the formal approach. One example of a formal approach is the use of logic. With logic2 the situation of Figure 7.16 can be specified as follows: ◗

Call screening: ¬ ring(B) (never allow B to ring);

◗

Call forwarding: dial(C) ⇒ ring(B) (if you dial C, B will ring);

◗

Normal call completion: ∀ ( x ≠ B,C ) : dial(x) ⇒ ring(x) (if you dial x, x will ring).

If we now postulate that dial(C) is true for A, this leads to the conclusion that ring(B) is true, but this is in contradiction to the condition ¬ ring(B) defined for call screening.

2. For the sake of simplicity, we use normal first-order predicate logic in this example. In reality, researchers have studied the use of temporal logics, which allow for reasoning about events in (relative) time.

Service creation

285

This example is of course so ridiculously simple that logic is not needed to find the interaction, but it shows that feature interactions can be represented by contradictions in systems of logic. Such contradictions can then be found automatically with tools, such as Prolog. The formal approach allows for complete analysis and will in theory find all interactions that are expressible within the model. The big drawback, however, is that the size of the models tends to grow exponentially with the size of the problems. Even modest combinations of features have been known to generate models of billions of states, all of which have to be explored. Due to their limited practicality, formal methods have mostly stayed in the realm of universities and research labs, and have not crossed over into industry. 7.5.3

Heuristic methods

Heuristic algorithms also start from a model of features and network, but then use domain knowledge and heuristic reasoning to reduce the state space to manageable size. These methods do not guarantee exhaustive model analysis and can leave certain feature interactions undetected. Nevertheless, some heuristic approaches have shown to be quite promising [6]. An example of a heuristic approach is the mechanism proposed by Kolberg and Magill [7]. They represent a feature by a triple of the form: <X,(Y,Z),(P,Q)>

where X,Y,Z,P,Q are call parties; X is the triggering party, (Y,Z) is the connection requested and (P,Q) is the connection actually set up. The call-forwarding service described above is for example specified by the formula

and the call-screening service by the formula

where treat denotes any special kind of treatment (in this case, blocking of the call). Kolberg and Magill propose six heuristic rules for finding feature interactions; they are shown in Table 7.5 (in this table, * denotes “any”).

286


This method finds feature interactions by pairwise matching on features, trying to find one of the patterns as shown in Table 7.5. Of course it is necessary to consider all permutations of parties in each feature, so unfortunately the matching process is not linear in the number of features or parties. The output of this algorithm consists of a list of feature combinations that are combination prone and that need further examination. The rule that a pair of features violates also gives some indication of the cause of the interaction and its possible resolution. There is, however, no guarantee that this approach will find all possible interactions. On the other hand, not all combinations marked as interaction prone will eventually result in real interactions. Although these heuristic methods are not perfect, they do provide a good compromise between automated detection and knowledge of the domain. In practice, much depends on how well one can represent domain knowledge in the algorithm, and on how well the approach can be turned against known interactions. 7.5.4

Resolution

Although as yet relatively less research has gone into resolution than detection, there is an obvious need to deal with feature interactions once they manifest themselves in the network. Resolution can be as simple as disabling one of the features in favor of another. This is what IN and CAMEL feature-interaction managers currently tend to do. The recent hype surrounding intelligent agents technology has led to a more sophisticated way of resolving feature interactions by negotiation [8]. An intelligent agent is a piece of software that represents a

Table 7.5 Heuristic Feature-Interaction Rules Rule Name

Interaction Pattern

Single user—dual control

<X,(Y,Z),(*,*)> and <X,(Y,Z),(*,*)>

Connection looping

and

Diversion and treatment

and

Reversing and treatment and Diversion and reversing

and

Reversing and diversion

and

Service creation

287

specific set of knowledge, is capable of some reasoning, and interacts with other agents. Depending on what flavor you want to give them, intelligent agents can be looked upon as smart objects or mini rule-based systems. Each subscriber is represented by an intelligent agent that knows about the subscribed features and services and their relative importance. When a feature interaction occurs, the agents will negotiate and try to settle for a solution that best fits all requirements and preserves the intended behavior of the services [9]. In the example of Figure 7.16, subscriber A might have an agent saying, “Do not complete calls to B under any circumstance.” C’s agent could say, “If possible, forward incoming calls to B.” If A calls C, then the two agents negotiate how to complete the call. In this case they might conclude that A’s requirement to block calls to B prevails over C’s wish to forward them, and the network might decide to block the call. 7.5.5

Complexity of the feature-interaction problem

The agent approach is extremely flexible, but all depends on how well each feature is represented. This is where all solutions to the featureinteraction problem appear to break down. The solutions that we have looked at in this section were proposed relatively early, and little progress was made over the last 10 years. This is not because the quality of the research has been substandard, but because the feature-interaction problem is far more complex than was initially thought. The feature-interaction problem is in many ways comparable to that of building an automatic translator for natural language. Whereas it may be relatively easy to describe features syntactically, it is extremely difficult to express the intention or meaning of a feature. The vast majority of feature interactions do not cause incorrect behavior in the network, but simply alter a feature’s behavior with respect to the behavior we expect of it. Coming back to the example of Figure 7.16, A might have decided to block calls to mobile subscriber B because he or she does not want to pay for the higher rate of calls to mobiles. If A calls C and C forwards to B, the common practice is that A pays for a call to C and C pays for the leg to B. In this case, the completion of the call to B might be completely acceptable to A, because A only pays for the call to C. But another scenario might be that B is a line featuring adult content, and A wants to prevent his or her kids from connecting to this line under any circumstance. In this case, if A calls C and C forwards to B without

288


prior warning, the resulting behavior is always undesirable from A’s viewpoint. In the first case, A invokes call screening for charging reasons. If the resulting interaction does not violate A’s intentions with respect to charging, then the behavior can be acceptable to A. In the second case, the motivation for invoking call screening is to prevent a connection to a certain type of content, and A will object to any interaction that establishes this connection against his or her will. These kinds of context-dependent expectations are extremely difficult to express in any model. It appears that heuristic and artificialintelligence-based techniques have more to offer than formal approaches; much research remains to be done.

References [1]

Sun Microsystems, Java Call Control (JCC) Application Programming Interface (API), Overview of the API, version 1.0, January 19, 2000.

[2]

Lennox, J., and H. Schulzrinne, CPL: A Language for User Control of Internet Telephony Services, Internet draft draft-ietf-iptel-cpl-04.txt, Internet Engineering Task Force, November 2000.

[3]

Westerhuis, F., “Service Provisioning for SIP,” Proc. IBC Intelligent Service Platforms, Vienna, Austria, March, 26–29, 2001.

[4]

Cameron, E., et al., “A Feature Interaction Benchmark for IN and Beyond.”In Feature Interactions in Telecommunications Systems, Amsterdam, Netherlands: IOS Press, 1994, pp. 1–23.

[5]

Zave, P., “Feature Interactions and Formal Specifications in Telecommunications,” IEEE Computer, Vol. 26, August 1993, pp. 20–30.

[6]

Kimbler, K., C. Capellmann, and H. Velthuijsen, “Comprehensive Approach to Service Interaction Handling,” Computer Networks, Vol. 30, No. 15, 1998, pp. 1363–1387.

[7]

Kolberg, M., and E. Magill, “A Pragmatic Approach to Service Interaction Filtering Between Call Control Services,” Computer Networks, Vol. 38, No. 5, April, 2002, pp. 591–602.

[8]

Velthuijsen H., “Distributed Artificial Intelligence for Runtime Feature Interaction Resolution,” IEEE Computer, Vol. 26, August 1993, pp. 48–55.

[9]

Griffeth, N., and H. Velthuijsen, “Reasoning About Goals to Solve Conflicts,” Proc. CoopIS (ICICIS), Rotterdam, Netherlands, May 12–14, 1993 pp. 197–204.

CHAPTER

8 Contents

Evolution scenarios

8.1 Next generation networks 8.2 Convergence or divergence? 8.3

IN evolution

8.4 If it ain’t broke, why fix it?

In this book we have considered the concept of network intelligence from many different angles. We have studied protocols, methods, and tools for providing services in telephony networks, mobile networks, and the Internet. Some are well-established standards; others are new industry proposals. The technologies presented in this book can be seen as pieces of a giant puzzle that is slowly taking shape over time. There are still some holes in the puzzle, while in other places the pieces appear to overlap. It would not be surprising if, after studying all the material in this book, the reader were left with more questions than answers. In this chapter we will try to get an idea of what the completed puzzle will look like, if in fact it is ever completed. Some of the key questions that remain are What shape will the network of the future have? Will the different network intelligence architectures eventually converge, and if so, toward what will they converge? The eventual destination is one thing; how we get there is quite another. Thus we will also consider the question of how IN 289

290


will evolve in the coming years. What steps are necessary in order to achieve true integration of the different technologies? Of course, there is no way to predict the future with certainty, but below we will try to sketch out the main lines of evolution.

8.1

Next generation networks

A few decades ago, the term telecommunications was synonymous with the term telephony. The telephone network still represents a crucial communications infrastructure, but it has also become a source of value-added services. Mobile telephony and the Internet are now well-established means of communication in many households. Today, telephony, the Internet, and cellular mobile networks continue to be different domains. As we have discussed here, each has its own protocols and services. Each requires its own license, and often, each is managed by different, competing operators. Of course, there are connections between the Internet and fixed and mobile networks. It is possible to make a phone call from a fixed to a mobile network, to surf the Web from a mobile terminal, or to connect to the Internet over a telephone. Still, interconnection between telephony, mobile networks, and the Internet is now mostly on a point-to-point basis. To connect to the Internet from the telephone, you need a modem. To call from a fixed phone to a mobile phone, you need to go through an interconnection exchange (GMSC). To surf the Web from a mobile terminal, you need to pass through modems (if it is a GSM network) or a gateway router (if it is a GPRS network). Figure 8.1 illustrates the current reality. It is difficult to predict what these networks will look like 10 or 15 years from now. The term next generation network is a buzzword used by many people in the telecommunications industry today. It seems to refer to whatever network may lie around the corner, but it has no solid definition. Yet there are a few general points that appear to be common in most people’s vision of what next generation networks are about. One is that IP will eventually become the one technology for transport of voice, data, and multimedia. IP networks are inexpensive and easy to interconnect and manage as compared with circuit-switched telephony or mobile networks.

Evolution scenarios

PSTN ISDN

GMSC

GSM

291

Modems

Modems

Internet

Figure 8.1

Telephony, the Internet, and mobile networks today.

IP also has certain problems. IP networks do not always scale easily and have difficulties in providing QoS and security. IPv6, the new version of IP, is expected to do away with most of these drawbacks. It is widely assumed in the industry that the next generation networks will have an IPv6 core transport network. The telephony, mobile, and data networks of today will not disappear in this setting, but will be seen more as access networks that plug into the IP core network. Of course, this requires some kind of adaptation device, call these gateways or interworking units. Figure 8.2 shows this highlevel vision of next generation networks. As the illustration shows, IP is likely to become an integrating technology on the network level. Many people mistakenly believe that this solves all problems we have encountered in this book. Just the opposite is true: Our problems have only just begun.

292


Access

networks

Core PSTN ISDN

Data network

Gateway

Gateway

IP Gateway

GSM GPRS

Figure 8.2

Gateway

UMTS

Next generation networks scenario.

As listed below, there are at least three key issues in the next generation networks scenario of Figure 8.2: 1. Providing end-to-end QoS. Ensuring QoS for communications between two subscribers in different access networks may require QoS negotiation between different network technologies, for example between a GPRS network, the IP core network, and a telephone network. 2. Federation between service providers. With deregulation and competition increasing, it is likely that communications will span more than one operator’s or service provider’s domain. Next generation networks must be capable of negotiating connections and services across provider domains. Roaming between mobile networks can be seen as a special case of federation. 3. Managing distributed intelligence. Next generation networks will have intelligence inside the network (as in IN) and outside the

Evolution scenarios

293

network (as with applications on PCs, SAT, and MExE). They will have to provide means to interface between the intelligence in different parts of the network. Figure 8.3 illustrates these three problems. All three points are relevant to intelligence in the network and put new requirements on the technologies we have seen in this book. The key problem in next generation networks is heterogeneity in transport and control technologies, and distribution of data and control logic. Managing distributed intelligence therefore appears to be at the root of the problem. In the next section we will explore how the industry is responding to the new challenges.

8.2

Convergence or divergence?

After studying all the standards, platforms, and protocols in this book, the question that still lingers is, Where is all this heading? Will there be one universal standard for network intelligence that incorporates all

Distributed intelligence

IT application

SCP PSTN

Data network

End-to-end QoS

ISDN

Federation

GSM GPRS

Figure 8.3 networks.

IP

MExE UMTS

Distributed intelligence, federation, and QoS in next generation

294


technologies from SIP to TINA? Or will the different standards and protocols only diverge further? Looking at the development of standards so far, two seemingly contradictory trends can be distinguished. On the one hand, there seems to be an ever growing fragmentation of new technologies such as OSA, JAIN, TINA, and SIP, each attracting its own circle of supporters. On the other hand, each of these new technologies claims to be about integrating telephony, mobile, and Internet. Are we witnessing convergence or divergence? 8.2.1

Changes in standardization

Apart from the evolution of technology itself, important changes have taken place in the standardization process. Before the opening of the telecommunication markets, national operators and their suppliers were driving development of new telecommunications technologies. Standardization cycles were slow but sure; important new communications technologies would eventually find their way into standards. Typical examples of standardization-era technologies are the OSI stack, SS7, and certainly IN. As the telecommunications markets opened, many of the national operators lost their privileged positions. Telecommunications standards bodies, mostly composed of national operators and their suppliers, have been losing authority ever since. Competitive operators and smaller manufacturers have been nibbling away at the standards by proposing their own de facto solutions and starting their own industry forums. Many manufacturers are now driven by visions of having their proprietary technology converted to ad hoc standards, drawing inspiration from the success of companies like Microsoft. An example of such a proprietary technology that made it as an ad hoc standard is WAP. In today’s highly competitive setting, even operators and service providers are reluctant to share information with others in standardization, thus hollowing out the standardization process further. Standardization bodies try to respond by shortening the standardization cycles, and by copying the agile working-group structures of the industry forums. A good example of this new approach to standardization is 3GPP, a group that makes great efforts to keep pace with industry forums. The fact that 3GPP heavily relied on Parlay in the definition of OSA (see Chapter 5) underscores this new trend in standardization. The result is the complex picture we see today, where standards and de facto solutions exist side by side. Many of the new technologies have

Evolution scenarios

295

important overlaps, as is the case for example with JAIN, Parlay, OSA, TINA, and OMG. There is no longer one single master technology for network intelligence. In the near future we must expect to live with this fragmentation of technologies. It is unlikely that standards bodies will regain their authority at short notice or indeed ever again. We could be witnessing a permanent change toward a totally free market of ideas, products, services, and technologies, a market in which patents are more important than standards. 8.2.2

A new role for standardization

In the new order of things there is little more for standardization bodies to do than to define umbrella technologies that embrace existing standards as well as industrial ad hoc solutions. An example of such a largescale umbrella standard is the ITU-T’s IMT 2000, which represents an entire family of 3G mobile network technologies. The most promising umbrella technology for network intelligence is OSA, explained in Chapter 5. OSA accepts existing technologies as service capabilities and builds on them to define features and services. The way OSA is defined, it can easily take onboard new technologies. OSA exemplifies a shift from protocol-oriented to architectureoriented standardization. OSA does not specify any protocol, but rather an extendible high-level API for the underlying network capabilities. This approach seems to have had success, and appears to be the way forward for standardization. Figure 8.4 shows how network intelligence standards have evolved since the creation of IN. After an initial explosion of new technologies, the trend now seems to be toward convergence, with OSA as a candidate umbrella technology for IN, CAMEL, Parlay, and even Internet protocols such as PINT and SPIRITS. OSA will not replace technologies such as MExE, SIM Toolkit, WAP, PINT, and SPIRITS, but only provide an integration framework for them. The individual technologies will continue in existence, and the industry will continue to add new technologies to the list. On the other hand, comprehensive standards such as IN and CAMEL are likely to merge eventually with OSA into an overall network intelligence standard. Standards and ad hoc solutions will evolve differently: Standards will probably converge, but industry ad hoc solutions will continue to diverge. The next section will investigate how IN implementations are evolving toward this vision of convergence and divergence.


Mob i netw le orks

296

CAMEL MExE

Telephony networks

SIM toolkit Parlay IN

OSA

JAIN SPIRITS

TINA-C CPL

PINT

rks two

H.323

e IP n

SIP

Figure 8.4

8.3

Network intelligence standards.

IN evolution

Although most people in the industry seem to share the vision of a converged standard for network intelligence, how to get there from today’s installed base is a completely different story. Telecommunications operators invest enormous amounts of money in their infrastructure, and will not change their systems overnight. The telecommunication industry tends to be conservative when it comes to new technologies. Network operators will not install any new technology that has not been proven to be telecoms grade. Even a popular technology such as SIP has a ways to go before it is considered a serious competitor to SS7. Most of the world’s operators now have some kind of IN infrastructure installed, be it a small service node or a full-blown IN. They are demanding evolutions of their installed platforms rather than completely new products. Many of the newer technologies that we have looked at in

Evolution scenarios

297

this book will therefore be introduced gradually as extensions to the existing IN platforms. It is possible to recognize a few general trends in the evolution of commercial IN platforms. Figure 8.5 extrapolates these trends to the future and gives a possible evolution scenario for IN. The evolution steps in Figure 8.5 can be described as follows: 1. Third-party hardware and standard operating system. Initial IN systems used mostly proprietary hardware, operating systems, and databases. Many platforms also used proprietary versions of the INAP protocols. The first major evolutionary step was when manufacturers started using off-the-shelf computing equipment, often with the Unix operating system. Many IN systems now also use third-party databases. Most IN systems on the market now support standard ETSI core INAP. 2. Object-oriented service logic. Although the ITU-T standard for IN uses SIBs and is still based on procedural programming, most manufacturers have reimplemented their IN systems with objects. IN platforms of the near future are likely to be based on objectoriented software, and may rely on object-oriented middleware for distributing objects.

Today

Tomorrow

Horizon

(4) Separation of access, service, and connection

CORBA (2)

Proprietary IN

Figure 8.5

JAIN Parlay

Object-oriented IN

UNIX IN

OSA TINA

Federation

(3) Multiple protocols Third-party software

Third-party hardware (1)

Evolution path for commercial IN platforms.

298


3. Programmability interfaces. Now that most IN platforms are objectbased, most manufacturers are considering the use of Java as a programming language. Many IN systems are likely to adopt the JAIN interfaces and libraries as they mature, or a similar objectoriented API for service creation. JAIN introduces the advantages of Java programming into IN and allows service logic to process calls in a multiple transport, multiple protocol environment. At this point, many platforms are also being equipped with external programmability interfaces such as OSA (or Parlay), enabling third-party applications to interwork with network intelligence. 4. Rich session models and federation. To deal with the delivery of services across different networks, future IN systems will need a much richer session model than the narrow BCSMs. Future IN systems will probably take onboard some of the session concepts of SIP and possibly TINA. The TINA session model is particularly powerful because it fully separates service access from service usage, and service control from connection control. At this stage, IN platforms may also implement the TINA federation mechanisms, allowing services to be delivered by cooperating IN systems in different service provider domains. Practically all manufacturers have realized step 1, and many have also passed step 2. Today many products are in the transition phase from step 2 to step 3. In the coming years, most products will also take onboard the advances described in step 3. At this point the first steps toward convergence to OSA will have been made. Full migration to OSA and TINA-like platforms will, however, not be complete until step 4, when generic session models are introduced and full separation of service access, usage, and connections are achieved. This step is still on the horizon, and we must probably wait a couple of years before it becomes a reality.

8.4

If it ain’t broke, why fix it?

The last section of this book is for the skeptics. In my career I have worked both for an incumbent operator and for a major manufacturer of telecommunications equipment and software. In both environments I

Evolution scenarios

299

have come across a great deal of skepticism with respect to the technologies discussed in this book. Why should we open our network is the question often asked by a network operator’s management. The question that bounces back when presenting technologies like JAIN and OSA to manufacturers is why should we open our products. Looking at it from the perspective of an established operator or manufacturer, it is indeed difficult to see what is in it for them. Network operators make billions of dollars out of plain fixed or mobile telephony. Manufacturers make billions out of telephone exchanges and IN. What do they gain from OSA, Parlay, JAIN, TINA, or SIP? This book is not about business models, but one thing is certain: Telecommunications business is in a phase of change. Let us look at a few facts. Spain’s Telefónica Móviles recently launched Movilforum, a forum for cooperation between its main suppliers, third-party software developers and systems integrators. Movilforum is open to third parties and stimulates them to develop new mobile applications and services. Telefónica Móviles provides the members of Movilforum with APIs to mobile network features such as SMS, SAT, MExE, and WAP, and goes as far as providing free equipment and training to facilitate the development of new services. Why does Telefónica Móviles do this? Its management has realized that until recently it left a whole business sector unused: enterprise applications. Rather than get involved in niche markets, Telefónica figured it would be much more convenient to let each enterprise integrate its own application. The last Movilforum exhibition featured demonstrations of applications ranging from providing on-line newspapers for PDAs and using SMS to query company databases, to remote monitoring of electrocardiograms using cellular phones. Movilforum is just an example of a broader trend in telecommunications. Most network operators are now undertaking similar initiatives. Movilforum

On the manufacturer side, things have been moving in a similar direction. Alcatel, Ericsson, Lucent, Nokia, and others now have third-party development programs. The form of these programs varies from one manufacturer to another. Lucent’s Full Circle, for example, is a large-scale program that includes partnership agreements, conferences, and training. On the other hand, Alcatel’s third-party

Third-party developer programs

300


development program appears to be managed more on a case-by-case basis. But the idea behind them is pretty much the same: to enable the development of new applications that might otherwise not have been thought about.

Network APIs are a reality. Object-oriented telecommunications software is in existence. IP is a given. Next generation network intelligence is underway. It is not a question of whether technology will change, but how it will come to be used.

Appendix A: Standards This appendix lists the most important standards used in this book. Please keep in mind that standards change constantly. Although every effort was made at the time of writing to ensure that the numbers and versions given here are correct and reflect the most recent documents, things may have changed since publication. The list is by no means exhaustive and represents only a selection of standards and reports that are most relevant to this book.

3GPP 3GPP is a cooperative project between international standardization bodies that specifies GSM, GPRS, UMTS, and OSA technologies, among others. This list includes all of the open service access (OSA) specifications, because of their importance in this book. As explained in Chapter 4 the versioning of 3GPP is rather complex because of the coexistence of various GSM and UMTS releases. Each specification typically exists in several different versions, each corresponding to a UMTS release. As releases tend to get updated several times a year, the reader is advised to check the 3GPP Web site for the latest versions. All 3GPP specifications listed here in order of their number are adopted as ETSI standards. To avoid repetition, they are merely summarized under the ETSI section.

301

302


◗

3GPP TS 22.121, Virtual Home Environment (VHE), versions 3.3.0 (release 99), 4.1.0 (release 4), 5.1.0 (release 5).

◗

3GPP TS 22.127, Universal Mobile Telecommunications System (UMTS) Stage 1 Service Requirements for the Open Service Access (OSA), versions 4.2.0 (release 4) and 5.0.0 (release 5).

◗

3GPP TS 23.171, Functional Stage 2 Description of Location Services in UMTS, version 3.1.0 (release 99), July 2000.

◗

3GPP TS 24.030, Location Services (LCS) Supplementary Service Operations Stage 3, version 3.1.0, June 2000.

◗

3GPP TS 25.305, Stage 2 Functional Specification of Location Services in UTRAN, version 3.2.0 (release 99), June 2000.

◗

3GPP TS 29.198-1, Open Service Access (OSA) Application Programming Interface (API) Part 1: Overview, version 4.3.0 (release 4) January 2002.

◗

3GPP TS 29.198-2, Open Service Access (OSA) Application Programming Interface (API) Part 2: Common Data, version 4.3.0 (release 4), January 2002.

◗

3GPP TS 29.198-3, Open Service Access (OSA) Application Programming Interface (API) Part 3: Framework, version 4.3.0 (release 4), January 2002.

◗

3GPP TS 29.198-4, Open Service Access (OSA) Application Programming Interface (API) Part 4: Call Control, version 4.3.0 (release 4), January 2002.

◗

3GPP TS 29.198-5, Open Service Access (OSA) Application Programming Interface (API) Part 5: Generic User Interaction, version 4.3.0 (release 4), January 2002.

◗

3GPP TS 29.198-6, Open Service Access (OSA) Application Programming Interface (API) Part 6: Mobility, version 4.3.0 (release 4), January 2002.

◗

3GPP TS 29.198-7, Open Service Access (OSA) Application Programming Interface (API) Part 7: Terminal Capabilities, version 4.3.0 (release 4), January 2002.

Appendix A

303

◗

3GPP TS 29.198-8, Open Service Access (OSA) Application Programming Interface (API) Part 8: Data Session Control, version 4.3.0 (release 4), January 2002.

◗

3GPP TS 29.198-11, Open Service Access (OSA) Application Programming Interface (API) Part 11: Account Management, version 4.3.0 (release 4), January 2002.

◗

3GPP TS 29.198-12, Open Service Access (OSA) Application Programming Interface (API) Part 12: Charging, version 4.3.0 (release 4), January 2002.

◗

3GPP TR 29.998-1, Open Service Access (OSA) Application Programming Interface Mapping for OSA Part 1: General Issues on API Mapping, version 4.0.0 (release 4) April 2001.

◗

3GPP TR 29.998-4, Open Service Access (OSA) Application Programming Interface Mapping for OSA Part 4: Call Control Service Mapping, version 4.2.0 (release 4) October 2001.

◗

3GPP TR 29.998-5, Open Service Access (OSA) Application Programming Interface Mapping for OSA Part 5: Generic User Interface Service Mapping, version 4.0.0 (release 4) April 2001.

◗

3GPP TR 29.998-6, Open Service Access (OSA) Application Programming Interface Mapping for OSA Part 6: Mobility Service Mapping, version 4.0.0 (release 4) April 2001.

◗

3GPP TR 29.998-8, Open Service Access (OSA) Application Programming Interface Mapping for OSA Part 8: Data Session Control Service Mapping, version 4.0.0 (release 4) April 2001.

3GPP2 The following is a list of the 3GPP2 specifications relevant to this book. Most 3GPP specifications also exist as standards published by one of its members (ARIB, CWTS, T1, TTA, or TTC). ◗

3GPP2 C.S0022, Location Services (Positioning Determination Service), December 1999.

◗

3GPP2 N.S0004, WIN Phase 2, April 2001.

304


◗

3GPP2 N.S0018, Prepaid Charging, December 1999.

◗

3GPP2 P.R0001, Wireless IP Architecture Based on IETF Protocols, August 2000.

◗

3GPP2 P.S0001, Wireless IP Network Standard, July 2001.

◗

3GPP2 S.R0004, 3GPP Service Implementation Guide, January 2000.

◗

3GPP2 S.R0018, Prepaid Charging, December 1999.

ANSI ◗

ANSI T1.667-1999, Intelligent Network, 1999.

ETSI There are many ETSI standards for intelligent networks (IN). Some are modifications or extensions of ITU standards while others are new, ETSIspecific standards. Although ETSI also refers to capability sets (CS-1, CS-2, and CS-3), they are not exactly identical to those of the ITU, neither in content nor in timing. Apart from IN standards, this list also mentions some of the OSA specifications that ETSI adopts from 3GPP. ◗

ETSI TR 101 665, IN Service Capability Modeling for CS-4, April 1999.

◗

ETSI TS 122 127, Universal Mobile Telecommunications System (UMTS) Stage 1 Service Requirements for the Open Service (OSA), version 4.1.0 (release 4), March 2001.

◗

ETSI TS 123 119, UMTS Gateway Location Register (GLR), version 3.0.0 (release 99), March 2000.

◗

ETSI TS 123 127, Virtual Home Environment (VHE) / Open Service Architecture (OSA), version 3.0.0 (release 99), March 2000.

◗

ETSI TS 129 198, Universal Mobile Telecommunications System (UMTS) Open Service Access (OSA) Application Programming Interface (API), version 4.0.0 (release 4), March 2001.

Appendix A

305

◗

ETSI TR 129 998, Universal Mobile Telecommunications System (UMTS) Open Service Access (OSA) Application Programming Interface (API) Mapping for OSA, version 4.0.0 (release 4), March 2001.

◗

ETSI EG 201 367, IN and Intelligence Support for Service Provider Number Portability, February 1999.

◗

ETSI ES 201 915, Open Service Access (OSA); Application Programming Interface (API) (12 parts), version 1.1.1 (final draft), December 2001.

◗

ETSI ETS 300 374-1, IN CS-1 Core INAP Protocol, Part 1: Protocol Specification, September 1994.

◗

ETSI ETS 300 374-2, IN CS-1 Core INAP Protocol, Part 2: Protocol Implementation Conformance Statement Proforma Specification for SSF,SRF and SCF, September 1994.

◗

ETSI ETS 300 374-3, IN CS-1 Core INAP Protocol, Part 3: Test Suite Structure and Test Purposes Specification for SSF and SRF, December 1997.

◗

ETSI ETS 300 374-4, IN CS-1 Core INAP Protocol, Part 4: Abstract Test Suite and Partial Protocol Implementation Extra Information for Testing Proforma Specification for SSF and SRF, December 1997.

◗

ETSI ETS 300 374-5, IN CS-1 Core INAP Protocol, Part 5: Protocol Specification for the SCF-SDF Interface, November 1996.

◗

ETSI ETS 300 374-6, IN CS-1 Core INAP Protocol, Part 6: Protocol Implementation Conformance Statement Proforma Specification for the SCF-SDF Interface, September 1998.

◗

ETSI ETS 300 374-9, IN CS-1 Core INAP Protocol, Part 9: Test Structure and Test Purposes Specification for the SCF-SSF and SCF-SRF Interfaces, February 1998.

◗

ETSI EN 301 140-1, INAP CS-2 Part 1: Protocol Specification, June 1996.

◗

ETSI EN 301 140-2, INAP CS-2 Part 2: Protocol Implementation Conformance Statement Proforma Specification, August 1998.

◗

ETSI EN 301 140-3, INAP CS-2 Part 3: Test Suite and Test Purposes Specification for SSF, May 2000.

306


◗

ETSI EN 301 140-4, INAP CS-2 Part 4: Abstract Test Suite Specification and Partial Protocol Implementation Extra Information for Testing Proforma Specification for SSF, May 2000.

◗

ETSI EN 301 140-5, INAP CS-2 Part 5: Distributed Functional Plane (ITU Recommendation Q.1224, modified), November 1999.

◗

ETSI EN 301 152, IN CS-1 Extension INAP Customized Applications for Mobile Network Enhanced Logic (CAMEL), September 1998.

◗

ETSI EN 301 668-1, IN CS-1 Extension INAP Part 1: Protocol Specification for CAMEL, July 2000.

◗

ETSI EN 301 668-2, IN CS-1 Extension INAP Part 2: Protocol Implementation Conformance Statement Proforma Specification, July 2000.

◗

ETSI EN 301 931, IN CS-3 Extension INAP Protocol Specification, September 2001.

Eurescom Eurescom is a research and development organization whose members are a group of eastern and western European network operators. Legally speaking it is a company, not a standardization body, but its links with standardization are close. Eurescom projects produce reports that specify the network operators’ requirements and feedback on standards. In some cases Eurescom also prototypes new technologies and standards. Some of these reports are public, but many are confidential. Since its creation in 1991 Eurescom has done many projects on IN, Internet, mobile, and next generation networks. Rather than attempting to give an exhaustive listing of the many available documents, the following is an overview of recent projects of relevance to this book. ◗

Eurescom P909 Enabling Technologies for IN Evolution and IN/ Internet Integration.

◗

Eurescom P910 Technology Assessment of Middleware in Telecommunications.

◗

Eurescom P920 UMTS Network Aspects.

Appendix A

307

◗

Eurescom P1109 Next Generation Networks: The Service Offering Scenario.

◗

Eurescom P1110 Open Service Access (OSA): Advantages and Opportunities in Service Provisioning in 3G Mobile Networks.

IETF The following is a list of the IETF requests for comments (RFCs) and Internet drafts used in this book. Please be aware that RFCs have a limited validity and tend to have a short life span. Some of the documents listed here may have been superseded by newer versions. Please consult the IETF Web site for the latest updates. ◗

Cuervo, F., et al., Megaco Protocol Version 1.0, IETF Network Working Group, RFC 3015, November 2000.

◗

Greene, N., M. Ramalho, and B. Rosen, Media Gateway Control Protocol Architecture and Requirements, IETF Network Group, RFC 2805, April 2000.

◗

Johnston, A., et al., SIP Telephony Call Flow Examples, IETF Network Working Group, Internet Draft, November 2000.

◗

Lennox, J., and H. Schulzrinne, Call Processing Language Framework and Requirements, IETF IPTel Working Group, RFC 2824, May 2000.

◗

Lennox, J., and H. Schulzrinne, CPL: A Language for User Control of Internet Telephony Services, IETF IPTel Working Group, Internet Draft, November 2000.

◗

Lu, H., et al., Toward the PSTN/Internet Inter-Networking- Pre-PINT Implementations, IETF Network Working Group, RFC 2458, November 1998.

◗

Lu, H., et al., Pre-SPIRITS Implementations of PSTN-initiated Services, IETF Network Working Group, RFC 2995, November 2000.

◗

Petrack, S., and L. Conroy, The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services, IETF Network Working Group, RFC 2848, June 2000.

308


◗

Slutsman, L., et al., The SPIRITS Architecture, IETF Network Working Group, RFC 3136, August 2001.

ITU-T The ITU-T Q.12xy series recommendations specify the IN conceptual model and capability sets. The following is a complete list of all IN recommendations of the ITU-T, listed in order of their number. ◗

ITU Q.1200, General Series IN recommendations Structure.

◗

ITU Q.1201, Principles of the IN Architecture.

◗

ITU Q.1202, IN Service Plane Architecture.

◗

ITU Q.1203, IN Global Functional Plane Architecture.

◗

ITU Q.1204, IN Distributed Functional Plane Architecture.

◗

ITU Q.1205, IN Physical Plane Architecture.

◗

ITU Q.1208, General Aspects of the IN Application Protocol.

◗

ITU Q.1290, Glossary of Terms Used in the Definition of IN.

◗

ITU Q.1210, ITU Q.1210 Series Structure.

◗

ITU Q.1211, Introduction to IN Capablity Set 1.

◗

ITU Q.1213, IN Global Functional Plane Architecture for Capability Set 1.

◗

ITU Q.1214, IN Distributed Functional Plane Architecture for Capability Set 1.

◗

ITU Q.1215, IN Physical Plane Architecture for Capability Set 1.

◗

ITU Q.1218, IN Interface recommendations for Capability Set 1.

◗

ITU Q.1219, IN User Guide for Capability Set 1.

◗

ITU Q.1220, ITU Q.1220 Series Structure.

◗

ITU Q.1221, Introduction to IN Capability Set 2.

◗

ITU Q.1223, IN Global Functional Plane Architecture for Capability Set 2.

Appendix A

309

◗

ITU Q.1224, IN Distributed Functional Plane Architecture for Capability Set 2.

◗

ITU Q.1225, IN Physical Plane Architecture for Capability Set 2.

◗

ITU Q.1228, IN Interface recommendations for Capability Set 2.

◗

ITU Q.IMP1228, Implementor’s Guide for ITU Q.1228.

◗

ITU Q.1229, IN User Guide for Capability Set 2.

◗


◗

ITU Q.1236, IN Capability Set 3 Management Information Model Requirements and Methodology.

◗

ITU Q.1237, Extensions to Capability Set 3 in Support of B-ISDN.

◗

ITU Q.1238.1, Common Aspects.

◗

ITU Q.1238.2, Interface recommendations for IN Capability Set 3: SCF-SSF Interface.

◗

ITU Q.1238.3, Interface recommendations for IN Capability Set 3: SCF-SRF Interface.

◗

ITU Q.1238.4, Interface recommendations for IN Capability Set 3: SCF-SDF Interface.

◗

ITU Q.1238.5, Interface recommendations for IN Capability Set 3: SDF-SDF Interface.

◗

ITU Q.1238.6, Interface recommendations for IN Capability Set 3: SCF-SCF Interface.

◗

ITU Q.1238.7, Interface recommendations for IN Capability Set 3: SCF-CUSP Interface.

◗


◗

ITU Q.1234, Distributed Functional Plane for Capability Set 4.

◗

ITU Q.1248.1, Common Aspects.

◗

ITU Q.1248.2, Interface recommendations for IN Capability Set 4: SCF-SSF Interface.

310


◗

ITU Q.1248.3, Interface recommendations for IN Capability Set 4: SCF-SRF Interface.

◗

ITU Q.1248.4, Interface recommendations for IN Capability Set 4: SCF-SDF Interface.

◗

ITU Q.1248.5, Interface recommendations for IN Capability Set 4: SDF-SDF Interface.

◗

ITU Q.1248.6, Interface recommendations for IN Capability Set 4: SCF-SCF Interface.

◗

ITU Q.1248.7, Interface recommendations for IN Capability Set 4: SCF-CUSF Interface.

OMG The OMG Telecommunication Domain Task Force publishes both specifications and white papers on the use of CORBA in telecommunications. White papers are listed in alphabetical order of their authors, whereas specifications do not have explicitly defined authors. ◗

OMG Telecommunication Domain Task Force, Wireless Access and Terminal Mobility, specification DTC/01-05-01, 2001.

◗

OMG Telecommunication Domain Task Force, Telecom Service Access and Subscription, specification DTC/00-10-03, 2000.

◗

OMG Telecommunication Domain Task Force, CORBA/TCAP Interworking, specification 98-10-10, 1998.

◗

OMG Telecommunication Domain Task Force, Control and Management of Audio/Video Streams, specification formal/00-01-03, 1998.

◗

Raatikainen, K., et al., Wireless CORBA, OMG Telecommunication Domain Task Force, white paper telecom/98/11/09, 1998.

◗

Schenk, M., et al., Open Service Market, OMG Telecommunication Domain Task Force, white paper telecom/00-06-05, 2000.

◗

Stringer, D., et al., Intelligent Networking with CORBA, OMG Telecommunication Domain Task Force, white paper telecom/96/12/03, 1996.

Appendix A

311

TINA-C TINA-C is, strictly speaking, not a standards organization but an industrial group. Specifications that are essential to the definition of TINA are called baseline documents. ◗

Chapman, M. (ed.), Overall Concepts and Principles of TINA, version 1.0, TINA baseline document, February 1995.

◗

Colban, E. (ed.), Information Modeling Concepts, version 2.0, TINA baseline document, April 1995.

◗

Farley, P., R. Minetti, and M. Mampaey (eds.), Retailer Reference Point, version 1.1, Approved, April 1999.

◗

Handegard, T. (ed.), Computational Modeling Concepts, version 3.2, TINA baseline document, May 1996.

◗

Hansen, P.F., and C. A. Liccardi (eds.), Service Component Specifications, Computational Model and Dynamics, version 1.0, TINA baseline document, January 1998.

◗

Kristiansen, L. (ed.), Service Architecture, version 5.0, TINA baseline document, June 1997.

◗

Mulder, H. (ed.), Business Model and Reference Points, version 4.0, TINA baseline document, May 1997.

◗

Nataranjan, N. (ed.), Network Resource Information Model, version 3.0, TINA-C baseline document, November 1997.

◗

Natarajan, N., and L. Demounem (eds.), Connectivity Service Reference Point, version 1.0, Approved, February 1997.

◗

Steegmans, F. (ed.), Network Resource Architecture, version 3.0, TINA baseline document, February 1997.

Other forums ◗

Location Interoperability Forum (LIF) TS101, Mobile Location Protocol, version 2.0.0, November 2001.

312


◗

Parlay Group, Parlay API Business Benefits, white paper, version 2.0, January 2000.

◗

Parlay Group, Parlay APIs, version 2.1, June 2000.

◗

Presence and Availability Management (PAM) Forum, PAM Specification Document, version 1.0, September 2001.

◗

Sun Microsystems, Java Call Control (JCC) Application Programming Interface (API), Overview of the API, Version 1.0, January 19, 2000.

◗

World Wide Web Consortium (W3C), SOAP version 1.2, 2001.

Appendix B: Web sites This appendix lists the Web sites of the most important standardization organizations and industry groups mentioned in this book. It is important to keep in mind that the addresses of Web sites may change over time. Although every effort has been made to make this list as up to date as possible, some sites may have become unavailable or their content may have changed. 3GPP

http://www.3gpp.org

3GPP2

http://www.3gpp2.org

ACTS projects (European

http://www.infowin.org

Commission) ANSI

http://www.ansi.org

ETSI

http://www.etsi.org

Eurescom

http://www.eurescom.de

IST projects (European Commission)

http://www.cordis.lu

GSM Association

http://www.gsmworld.com

IETF

http://www.ietf.org

IMode

http://www.nttdocomo.com

ITU

http://www.itu.int

J2EE

http://java.sun.com/j2ee

J2ME

http://java.sun.com/j2me

JAIN

http://java.sun.com/products/jain

313

314


LIF

http://www.locationforum.org

PAM Forum

http://www.pamforum.org

Parlay

http://www.parlay.org

OMG

http://www.omg.org

SMS Forum

http://www.smsforum.net

Softswitch Consortium

http://www.softswitch.org

T1

http://www.t1.org

TINA

http://www.tinac.com

VASA

http://www.vasaforum.org

WAP Forum

http://www.wapforum.org

UMTS Forum

http://www.umtsforum.org

W3C

http://www.w3c.org

Glossary data-enhanced second-generation cellular networks

2.5G 2G

second generation cellular networks

3G

third generation cellular networks Third Generation Partnership Project (ETSI)

3GPP

Third Generation Partnership Project 2 (parallel project)

3GPP2

adaptive differential pulse code modulation

ADPCM ADSL AIN AMPS ANSI API ARP

asymmetric digital subscriber line advanced intelligent network Advanced Mobile Phone System American National Standards Institute application programming interface Address Resolution Protocol

ARPANET ASN.1

Advanced Research Projects Agency Network

abstract syntax notation number 1

ASP

application service provider

ATI

anytime interrogation

ATM

asynchronous transfer mode

315

316


basic call process

BCP BCSM

basic call-state model

BCUP

basic call-unrelated process basic call-unrelated state model

BCUSM

back-end processor

BEP BG

border gateway broadband ISDN

B-ISDN BSC

base station controller

BSS

base station subsystem

BTS

base transceiver system German analog cellular telephony network

C-450

customized applications for mobile-network-enhanced

CAMEL

logic CAMEL Application Protocol

CAP CC

connection coordinator

CCF

connection control function Comité Consultatif International Télégraphique et Télé-

CCITT

phonique CORBA component model

CCM

code division multiple access

CDMA

CEPT European Conference of Postal and Telecommunications Administrations CHTML CID CLDC CoC COM

compact HTML

call instance data connected limited-device configuration connection control component object model

Glossary

317

connectivity service reference point

ConS CP

connection point common object request broker architecture

CORBA CPH

call-party handling

CPL

call-processing language call-related radio access control function

CRACF CS

capability set, or call segment (in call-party handling)

CS-1

capability set 1

CS-2

capability set 2

CS-3

capability set 3

CS-4

capability set 4

CS-ACELP

conjugate

structure—algebraic-code-excited

prediction call segment association

CSA

call-state control function

CSCF

circuit-switched data

CSD CSI

CAMEL subscription information client-server layer network reference point

CSLN

communication session manager

CSM

CURACF

call-unrelated service function

CUSF CVS

call-unrelated radio access control function

connection view state

D-AMPS D-CSI DAP DARPA

digital AMPS dialed services CSI

Directory Access Protocol Defense Advanced Research Projects Agency

linear

318


data

DAT

distributed COM

DCOM

digital-enhanced cordless telephony

DECT

distributed functional plane

DFP

digital home network

DHN

dynamic invocation interface

DII

domain name system

DNS

detection point

DP

distributed processing environment

DPE DQDB

distributed-queue dual bus

DTMF

dual-tone multifrequency

EDGE

enhanced data rate for GSM evolution event detection point

EDP EDP-N

event detection point (notification type)

EDP-R

event detection point (request type) Enterprise Java Beans

EJB

European Telecommunications Standardization Institute

ETSI

execution environment

ExE

frequency-division duplex

FDD

fiber distributed data interface

FDDI

frequency-division multiple access

FDMA FE

functional entity

FEP

front-end processor

FIM

feature interaction manager

FPLMTS FTP

future public land mobile telecommunications system

File Transfer Protocol

Glossary

319

G.711

PCM codec standard (ITU)

G.726

ADPCM codec standard (ITU)

G.728

LD-CELP codec standard (ITU)

G.729

CS-ACELP codec standard (ITU) geostationary Earth orbit

GEO

GSM-EDGE radio access network

GERAN GFP

global functional plane

GGSN

gateway GPRS support node

GMLC

gateway mobile location center

GMSC

gateway mobile switching center

GPRS

General Packet Radio System

GPRS-CSI GSM

GPRS CAMEL subscription information

Global System for Mobile Communications

H.225

RAS standard (ITU)

H.245

control signaling standard (ITU)

H.261

video codec standard (ITU)

H.263

video codec standard (ITU)

H.320

multimedia over ISDN standard (ITU)

H.321

multimedia over broadband networks standard (ITU)

H.322

multimedia over LANs with guaranteed QoS standard (ITU)

H.323

multimedia over packet networks standard (ITU)

H.324

multimedia over switched telephony networks standard

(ITU) HE HLR HLSIB

home environment home location register high-level SIB

320


HSCSD

high-speed circuit-switched data home subscriber server

HSS HTML

hypertext markup language

HTTP

HyperText Transport Protocol initial agent

IA IAB

Internet Architecture Board

IAF

intelligent access function

IANA

Internet Assigned Numbers Authority

ICMP

Internet Control Message Protocol Internet call waiting

ICW

Internet draft (IETF)

ID IDE

integrated development environment

IDL

interface definition language

IEEE

Institute of Electrical and Electronics Engineers

IESG

Internet Engineering Steering Group

IETF

Internet Engineering Task Force

IIOP

Internet Inter-ORB Protocol

iMode

Information Mode (DoCoMo service)

IMSI

international mobile subscriber identity

IMT

International Mobile Telecommunications intelligent network

IN

information networking architecture

INA INAP

IN Application Protocol

INCM

intelligent network conceptual model

IP IPSec

intelligent peripheral; Internet Protocol IP security

Glossary

321

IPTel

Internet telephony

ISDN

integrated services digital network

ISOC

Internet Society

ISP ISUP ITU

Internet service provider ISDN User Part International Telecommunication Union

ITU-T

ITU Telecommunication Standardization Sector

IVPN

international virtual private network

J2EE

Java 2, Enterprise Edition

J2ME

Java 2, Micro Edition

JAIN

Java Applications for Integrated Networks

JCAT

Java coordination and transactions

JCC

Java call control

JCP

Java call processing; Java community process

JSP

Java Server Pages

JSPA

Java specification participation agreement Java telephony API

JTAPI LAI LAN

location area identifier local area network

LD-CELP LEO LIF LMDS

low-delay code-excited linear prediction

low Earth orbit Location Interoperability Forum local multipoint distribution system

LMU

location measurement unit

LNC

layer network coordinator

LNFed

layer network federation reference point

322


MAP

mobile application part

MCU

multiconferencing unit

MEGACO

media gateway control

mobile execution environment

MExE

media gateway controller

MGC MGCP


MIPD

mobile information device profile man machine interface

MMI

MMUSIC

multiparty multimedia session control (IETF)

MOF

metaobject facility

MRF

multimedia resource function

MS

mobile station

MS-ISDN MSC

message sequence charts; mobile switching center mobile subscriber roaming number

MSRN MTP

mobile station ISDN number

message transfer part network-specific services CSI

N-CSI

Nordic Mobile Telecommunications system

NMT NSF

National Science Foundation

NSS

network switching subsystem

OA&M

operations, administration, and maintenance

OAMP

Operations, Administration, and Maintenance Part

O-BCSM O-CSI OCS Oftel

originating basic-call-state model originating call CSI

originating call screening Office of Telecommunications (United Kingdom)

Glossary

323

OMA

object management architecture

OMG

Object Management Group

ORB

object request broker

OSA

open service architecture; open service access

OSI

open systems interconnection

OSP

open service platform (Alcatel)

OTA

over-the-air programming

PA PAM

provider agent presence and availability management

PBX

private branch exchange

PCM

pulse code modulation

PCU

packet control unit

PDP

Packet Data Protocol

PeerA PIC PICS PIN

peer agent point in call protocol implementation conformance statement personal identification number

PINT

PSTN and Internet Interworking Working Group

POA

portable object adapter

POI

point of initiation

PoP

point of presence

POP3 POR PP PRG PSTN

Post Office Protocol version 3 point of return physical plane service logic program public switched telephone network

324


quality of service

QoS RACE

Research for Advanced Communications Europe

RARP

Reverse Address Resolution Protocol registration, admission, and status

RAS

retailer reference point

Ret RFC

request for comments (IETF)

RNC

radio network controller

RTCP

Real-Time Transport Control Protocol

RTMS

French analog cellular telephony network

RTP

Real-Time Transport Protocol

RtR

retailer-to-retailer reference point

SAT

SIM application toolkit Signaling Connection Control Part

SCCP SCE

service-creation environment

SCF

service control function; service capability feature

SCP

service control point

SCS

service capability server

SCUAF

service control user agent function

SDF

service data function

SDH

synchronous digital hierarchy

SDL

specification and description language

SDP

service data point; Session Description Protocol

SF SGSN

service factory serving GPRS support node

SIB

service-independent building block

SIG

special interest group

Glossary

325

subscriber identity module

SIM

Session Initiation Protocol

SIP SL

signaling link service-level agreement

SLA

service logic execution environment

SLEE

session manager

SM

service management access function

SMAF

service management function

SMF

serving mobile location center

SMLC

service management point

SMP

Short Message Peer-to-Peer Protocol

SMPP

short message service

SMS

short message service center

SMSC

SMS gateway MSC

SMS GMSC SMS IW-MSC

SMS interworking MSC

SMTP

Simple Mail Transfer Protocol

SNMP

Simple Network Management Protocol

SOAP

Simple Object Access Protocol

SP

signaling point; service plane service provider access

SPA SPAN-3

Services and Protocols for Advanced Networks Group 3

(ETSI) SPIRITS (IETF)

Services in the PSTN/IN Requesting Internet Services

SRF

specialized resource function

SS7

signaling system number 7

SSD

service support data

326


SSF

service switching function

SSL

secure socket layer service session manager

SSM

service switching point

SSP

service session user application part

ssUAP

signaling transfer point

STP

data conferencing standard (ITU)

T.120

Committee T1—Services, Architectures, and Signaling Subcommittee

T1S1

T-BCSM

terminating basic-call-state model

T-CSI

terminating call CSI

TCAP

Transaction Capability Application Part Transport Control Protocol

TCP

TCP over IP

TCP/IP TCS

terminating call screening terminal communication session manager

TCSM

time-division duplex

TDD

time-division multiple access

TDMA

trigger detection point

TDP TDP-N

trigger detection point (notification type)

TDP-R

trigger detection point (request type) Telecommunications Domain Task Force (OMG)

TDTF TIA

Telecommunications Industry Association

TIF

translation information flag

TINA TINA-C

telecommunications information networking architecture TINA Consortium

Glossary

327

terminal-layer adapter

TLA TMN

telecommunications management network

TMSI

temporal mobile subscriber identity

TSAS

telecommunications service access and subscription (OMG) The TINA trial

TTT UA

user agent

UAC

user agent client

UAS

user agent server

UDP

User Datagram Protocol

UM

unified messaging

UMC

unified messaging center

UML

unified modeling language Universal Mobile Telecommunications System

UMTS

uniform resource locator

URL

unstructured service support data

USSD UTRAN

UMTS terrestrial radio access network

VASA

Value-Added Services Alliance

VDSL

very-high-speed digital subscriber line

VHE

virtual home environment

VLR

visitor location register

VMR

voice message relay

VPN

virtual private network

VT-CSI

visited network terminating call CSI

W3C

World Wide Web Consortium

WAP

Wireless Application Protocol

WG

working group (IETF)

328


WIN

wireless intelligent network

WML

wireless markup language

WWW X.25 X.500

World Wide Web packet data networking standard (ITU) directory service standard (ITU)

XMI

XML metadata interchange

XML

extensible markup language

Bibliography Delgado, J., et al. (eds.), Telecommunications and IT Convergence: Towards Service Evolution, Lecture Notes in Computer Science 1774, Berlin: Springer-Verlag, 2000. Faynberg, I., et al., Converged Networks and Services, Chichester, UK: John Wiley & Sons, 2000. Gamma, E., et al., Design Patterns: Elements of Reusable Object-Oriented Software, Boston, MA: Addison Wesley, 1995. Glitho, R., and T. Magedanz (eds.), “Intelligence Networks in the New Millennium,” IEEE Communications Magazine, Vol. 38, No. 6, June 2000. Inoue, Y., M. Lapierre, and C. Mossotto, The TINA Book, Englewood Cliffs, NJ: Prentice-Hall, 1999. Kaaranen, H., et al., UMTS Networks, Chichester, UK: John Wiley & Sons, 2001. Karim, S., and P. Hovell, “Everything over IP: An Overview of the Strategic Change in Voice and Data Networks,” BT Technology Journal, Vol. 17, No. 2, April 1999, pp. 24–30. Lazar, A., “Programming Telecommunication Networks,” IEEE Network, September 1997, pp. 8–18.

329

330


Mowbray, T. J., and R. Zahavi, The Essential CORBA: Systems Integration Using Distributed Objects, Chichester, UK: John Wiley & Sons, 1995. Trigila, S., F. Lucidi, and K. Raatikainen, “A Service Architecture for Fixed and Mobile Convergence,” Computer Communications, Vol. 25, No. 2, February 2002, pp.133–148. Trigila, S., et al., (eds.), Intelligence in Services and Networks: Technology for Ubiquitous Telecom Services, Lecture Notes in Computer Science 1430, Berlin: Springer-Verlag, 1998. Vandermeulen, F., et al., “A Generic Architecture for Management and Control of End-to-End Quality of Service over Multiple Domains,” Computer Communications, Vol. 25, No. 2, February 2002, pp. 149–168. Yankee Group, “Next-Generation Cellular Data: Now for the Rollout,” Wireless/Mobile Communications Global Report, Vol. 3, No. 23, July 1999. Zave, P., and M. Jackson, “A Component-Based Approach to Telecommunication Software,” IEEE Software, Vol. 15, No. 5, September 1998, pp. 70–78. Zuidweg, J., et al. (eds.), Intelligence in Services and Networks: Paving the Way for an Open Service Market, Lecture Notes in Computer Science 1597, Berlin: Springer-Verlag, 1999.

About the author Johan Zuidweg, born in Gouda, the Netherlands, in 1963, obtained his M.S. and Ph.D. degrees in computer science from Leiden University in the Netherlands. He started his career at KPN Research in the Netherlands, where he worked on IN- and UMTS-related R&D projects between 1987 and 1994. In 1991 and 1992 he was a permanent member of the RACE 1043 UMTS Systems Group, a European R&D project that formed the basis of today’s UMTS standardization work. Mr. Zuidweg joined Alcatel in 1994 where he worked until 2000. At Alcatel in France and Belgium, he led various R&D projects in the area of IN, UMTS, and TINA. Among these, he led VITAL, an international R&D project that successfully built a complete TINA system in 1998. He now heads the Next Generation Networks Center at Tecsidel, a Spanish IT company specializing in telecommunications software. He is also an associate professor at the Universitat Pompeu Fabra in Barcelona, Spain. Mr. Zuidweg is a member of the IEEE Computer and Communications Societies and the author of numerous articles on the application of software engineering in telecommunications. He is a much sought-after speaker at conferences and seminars.

331

.

Index 3G mobile networks, 165–78 open access, 175–78 UMTS, 168–72 VHE, 172–75 See also Mobile networks 3GPP2, 167, 303–4 3GPP, 166–68, 301–3 defined, 166 OSA, 178 specifications, 166 structure, 167 UMTS specifications, 166–67

Abstract syntax notation 1 (ASN.1), 53 Access session, 217, 220–21 defined, 217 functions, 221 start procedure, 220–21 See also TINA Alcatel, 70–73 configurations, 72 CPL script creation, 278–79 CPL service-creation and execution environment, 280 Open Service Platform (OSP), 73, 115 products, 70 SCE, 72–73 SCP architecture, 71 ANSI, 304

Application-initiated call setup, 197–99 defined, 197 procedure illustration, 198 steps, 197–99 ARPANET, 7–8 Asymmetric digital subscriber line (ADSL), 83 Asynchronous transfer mode (ATM), 77 Authentication, 192, 193–95 procedure illustration, 194 procedure steps, 193–95

Back-end processors (BEPs), 70, 71 Basic call process (BCP), 36–39 defined, 36–37 point of return (POR), 37, 38 points of initiation (POIs), 37, 38 Basic-call state model originating (O-BCSM), 42, 43, 44 terminating (T-BCSM), 42, 43, 44 Bluetooth, 163 Bridges, 79–80

C++, 253 Callback interfaces, 188 Call control function (CCF), 40, 41 Call-control interfaces, 189–92 illustrated, 189 inheritance structure, 189

333

334

Call-control interfaces (continued) See also Open-service access (OSA) Call forwarding call screening interaction, 283 example (JAIN), 267–69 service, 45 Calling card service EJBs implementation, 257 object implementation, 251–53 Call-related radio access control function (CRACF), 58 Call-state control function (CSCF), 170 Call-unrelated radio access control function (CURACF), 58 Call-unrelated service function (CUSF), 58 CAMEL, 15–16, 135–47 application part (CAP), 137 architecture, 136–38 attach-detach state model, 143–44 basic call-state models, 138, 143 call-unrelated state model, 157 control scenarios, 136–37 defined, 135 detection points, 138 force behind, 140 mapping OSA to, 202–3 phases, 142 prepaid roaming with, 141 SCF in, 137 service example, 140–42 service execution, 136 standardization, 142–43 state model for PDP context setup, 144–45 triggers, 145 CAMEL phase 3, 143–47 defined, 142–43 enhancements, 145–46 extensions, 143 skeptics, 146–47 value-added services, 146 CAMEL subscription information (CSI), 138 contents, 139


types, 138–39 Capability sets (CSs), 30 CS-1, 53–54 CS-2, 53–65 CS-3, 64–67 CS-4, 67–69 Cellular networks, 10–12, 121–22 2G, 121 3G, 122 analog, 121 capacity, 10–11 concept illustration, 11 generations, 122 Internet connection, 84 power, 11 second generation (2G), 12 security, 11 See also Mobile networks Centralized OSA implementation, 201–2 Circuit-switched domain, 169, 170 Clients PINT, 104 SIP, 94–97 SPIRITS, 109, 110 user agent, 94 Common object request broker architecture. See CORBA Communication session manager (CSM), 224 Computer networks, 7 Connection coordinator (CC), 224 Connection view state (CVS) call segment (CS), 61 call segment association (CSA), 62 complexity, 64 connection point (CP), 61 defined, 61 graphical notation, 62 leg, 62 model, 61–62 CORBA, 17–18, 234–36 client-server architecture and, 236 concept illustration, 235 defined, 234 features, 234–35 interface, 236–38

Index

remote method invocations, 235 See also Telecommunications middleware CPL, 274–82 action elements, 275 advantages, 281 defined, 274 deploying, 278–80 example script, 276–77 IN and, 280–82 mapping from IN CS-1 SIBs to, 281 sample constructs, 276 script creation, 278–79 scripts, 275, 278 structure, 274–76 tools, 282 top-level actions, 274–75 CS-1, 53–54 BCP, 38 extensions, 54–55 FEs, 40–41 GFP SIBs, 35, 36 limitations, 54 PICs, 60 service plane features, 33 CS-2, 53–65 BCUSM, 59, 61 CUSF, 118 distributed functional plane, 58–64 ETSI improvements, 66–67 features, 54–55 global functional plane, 56–58 graphical notation, 62 high-level SIB concept, 57 implementing, 64–65 information flows, 58–59 new FEs, 58 new SIBs, 57 O-BCSM, 59 PICs, 59, 60 SCUAF, 118 service plane, 55 service process, 56 target, 54 T-BCSM, 59 CS-3, 64–67

335

defined, 65 ETSI improvements, 66–67 features, 65–66 multiple points of control, 66 new facilities, 66 Q.1236, 65 Q.1237, 65 redefinition of INAP, 65 CS-4, 67–69 beyond, 69–70 communications over the Internet support, 68 defined, 67 distributed functional plane, 68 IPs, 68–69 Q.1244, 67 Q.1248, 67 session manager (SM), 68 specification, 67

D-AMPS, 121 Data networks, interconnecting, 84 DCOM, 200 Denial-of-service attacks, 113 Detection points, 43–45 CAMEL, 138 O-BSCM and, 43–45 processing, 46 T-BSCM and, 43–45 types of, 45 Digital exchanges, 4–5 defined, 4–5 ISDN, 5 stored-program, 5 Distributed functional plane (DFP), 39–47 concept illustration, 41 CS-2, 58–64 CS-4, 68 defined, 40 detection points, 43–45 functional entities (FEs), 40–42 half call, 42–43 trigger processing, 45–47 See also IN conceptual model (INCM)

336

Distributed OSA implementation, 201 Distributed processing environment (DPE), 219 Distributing intelligence, 16–17, 179–208 Domain name system (DNS), 85 Dual-slot terminals, 163 Dynamic invocation interface (DII), 236

Electronic exchanges, 4 Enterprise Java beans (EJBs), 256–59 advantages, 258 business roles, 258–59 calling-card service implementation with, 257 containers, 259 defined, 256 entity beans, 256 in intelligent networks, 258 servers, 259 session beans, 256–57 tool environments, 258–59 types of, 256 See also Java; Java beans ETSI, 15, 304–6 Eurescom, 306–7 Event listener model, 263 Evolution scenarios, 18, 289–300 IN, 296–98 next generation networks, 290–93 standardization, 293–96 Extensible markup language (XML), 200

Feature interaction manager (FIM), 45, 46 Feature interactions, 282–88 avoidance, 283 call screening and call forwarding, 283 detection, 283, 284–85 heuristic methods, 285–86 logic and, 284 problem complexity, 287–88 resolution, 283, 286–87


solving, 283–84 Federation, 228–30, 298 horizontal, 228 illustrated, 230 vertical, 228 See also TINA resource management architecture Firewalls, 80, 85 Flow control, TCP, 79 Front-end processors (FEPs), 70, 71 Functional entities (FEs) call control function (CCF), 40, 41 call-related radio access control function (CRACF), 58 call-unrelated radio access control function (CURACF), 58 call-unrelated service function (CUSF), 58 defined, 40 information flows, 40, 58–59 intelligent access function (IAF), 58 radio control function (RCF), 58 service control function (SCF), 40, 49, 90 service control user agent function (SCUSF), 58 service data function (SDF), 40, 49 service management access function (SMAF), 58 service management function (SMF), 40 service switching function (SSF), 40, 41 special resource function (SRF), 41 See also Distributed functional plane (DFP)

Gatekeepers accounting and billing, 89 address translation, 89 admission control, 89 bandwidth and, 91 call authorization, 89 call management, 89 call-setup procedure, 88–89

Index

defined, 87 functions, 89, 90 IN service mode and, 89 intelligent functions, 91 interworking between IN SCF and, 90 See also H.323 Gateway GPRS support node (GGSN), 132 Gateways, 79–80 controllers, 101 H.323, 87 PINT, 104 SPIRITS, 108, 110 TCAP-CORBA, 240, 241 WAP, 148–49 General packet radio service. See GPRS Global functional plane (GFP), 33–39 basic call process, 36–39 calling-card services defined at, 38 in CS-1, 35, 36 defined, 33–34 service plane mapping to, 34 SIBs, 34–36 See also IN conceptual model (INCM) GPRS, 16, 129–34 architecture, 131–32 attach-detach state model, 143–44 change-of-position session, 143 channel usage, 130 coding schemes, 131 connection model, 133–34 connection states, 133 core network, 131–32 data rate, 131 defined, 129 deployment, 129 gateway support node (GGSN), 132 location services, 157–58 mobility management, 132–33 network illustration, 132 radio interface, 130–31 routing areas, 132–33

337

serving support node (SGSN), 131 state transitions, 134 terminals, 130–31 time slots, 130 traffic, 131 GPS-assisted positioning, 159 GSM, 122–29 architecture, 123–25 connection services, 128–29 data service, 128 defined, 121 deployment, 123 handover, 125–26 identifier use in, 128 IMSI, 127 location services, 157–58, 159–61 location updates, 133 mobility management, 125–26 network components, 124 networks, 123, 129 operators, 124 optimization, 128 radio interface definition, 123 security, 126–28 SIM, 127 standardization, 123 subscription, 127 time line, 168 TMSI, 127 voice codec, 129

H.323, 86–92 calls, 88 characteristics, 86–87 defined, 86 gatekeepers, 87, 88–91 gateways, 87 IN and, 89–92 multipoint control units (MCUs), 88 protocols used in, 88 SIP vs., 98–99 Half call, 42–43 Heuristic algorithms, 285–86 High-level SIBs (HLSIBs), 57, 58 Home-zone service, 160–61

338

Home-zone service (continued) call procedure, 161 concept illustration, 160 Hubs, 79–80 Hypertext Transfer Protocol (HTTP), 79 forms, 116 requests, 113

IDL, 236–38 compilers, 236 compiling, 238 defined, 236 specification, 236, 237 See also CORBA iMode, 149–50 defined, 149 WAP comparison, 149–50 IN application protocol (INAP), 28, 50–53 core, 74 defined, 50 dialogue, 51 messages, 50, 52, 53 procedure, 50–52 specifications, 52 syntax, 53, 73 IN conceptual model (INCM), 30–31, 246 definition of, 31 distributed functional plane, 39–47 global functional plane, 33–39 Internet and, 85 physical plane, 47–53 service plane, 31–33 service scripts, 246–48 views, 31 See also Intelligent networks (IN) Integrated digital services network (ISDN), 5, 83 Intelligence distributing, 16–17, 179–208 on the Internet, 84–102 Intelligent access function (IAF), 58 Intelligent networks (IN), 14, 23–74 Alcatel, 70–73


CPL and, 280–82 EJBs and, 258 evolution, 296–98 H.323 and, 89–92 implementing, 70–74 Internet and, 14–15, 75–118 Internet interoperation, 114 mobile payment with, 163 model limitations, 248–49 multivendor products, 73–74 service processing, 97 SS7 and, 24–28 standardization bodies, 29–30 standardization cycles, 30, 294 standards, 29–31, 301–12 UM implementation within, 118 Web, 110–13 See also IN conceptual model (INCM) Intelligent peripheral (IP), 48 International mobile subscriber identity (IMSI), 127 International Softswitch Consortium, 102 International virtual private network (IVPN), 59 Internet beginning of, 7–9 connecting to, 82–84 IN and, 14–15, 75–118 IN interoperation, 114 intelligence on, 84–102 IP, 76–79 managing services via, 113–18 in mobile environment, 147–54 multimedia over, 85–86 principles, 75 routers and gateways, 79–80 telephony, 86 video over, 85–86 voice over, 85–86 Internet Assigned Numbers Authority (IANA), 81 Internet call waiting (ICW), 107 Internet Engineering Task Force (IETF), 81 RFCs, 307–8

Index

SDP, 93 Internet service providers (ISPs), 82, 83 Internetworking, 7–9 ARPANET, 7–8 growth, 8 illustrated, 8 IP, 76–79 application layer, 79 defined, 76 packets, 76 protocol stack, 78 routing, 76–77 standards creation, 81–82 transport layer, 78 See also Internet IP Telephony (IPTEL), 274 IS-95, 121 ISUP API, 263–64 ITU-T, 29, 308–10 G.711, 86 G.729, 86 H.261, 86 H.263, 86 H.323, 86–92 IN recommendations, 308–10

339

structure illustration, 262 Java advantages, 253–54 controlled soft switch, 261 programming, 246 servlets, 278 in telecommunications, 253–59 Java beans, 254–56 advantages, 256 assembling JAIN applications from, 270 defined, 254 enterprise (EJBs), 256–59 event channels, 254 execution of, 254 JAIN libraries, 269–70 service-creation environment, 255 Java call control (JCC), 261, 264–67 call state model, 269 defined, 261 JCP and JTAPI relationship, 265 objects, 265–66 structure, 266 See also JAIN Java call processing (JCP), 264, 265, 266 Java telephone API (JTAPI), 259–60

J2EE, 256 JAIN, 69, 259–74 applications, 269–70 architecture, 260–62 call control, 261, 264–67 call forwarding example, 267–69 conformation, 271 defined, 260 event listener mechanism, 262–63 Java bean libraries, 269–70 layers, 261 Parlay and, 272–74 products, 272 protocol APIs, 261, 262 service logic execution environment (SLEE), 261 service-provider areas, 273–74 soft switch, 261 specification, 271

Layer network coordinator (LNC), 225 Local multipoint distribution system (LMDS), 84 Location Interoperation Forum (LIF), 162 Location services, 156–62 cell identifier, 158 concept illustration, 159 examples, 157 GPRS, 157–58 GPS-assisted positioning, 159 GSM, 157–58, 159–61 home-zone, 160–61 measurements on radio interface, 158–59 proprietary, 161–62 techniques, 158–59

340

Media Gateway Control (MECP), 99–100 commands, 99–100 connection model for, 100 defined, 99 specification, 99 use of, 100 MExE, 150–53 application implementation, 152 application scenarios, 153 classmarks, 151–52 defined, 151 security, 152 specification, 151 terminals, 152 MMUSIC group, 92 Mobile application part (MAP), 28 Mobile e-commerce, 165 Mobile execution environment. See MExE Mobile networks, 10–13 3G, 165–78 cellular, 10–12 identifiers, 12 in-call mobility, 12–13 issues, 12–13 mobile management, 12 security, 12 telephony/data integration, 13 Mobile payment services, 162–65 with IN, 163 problems, 165 procedure, 163–64 solutions, 163 Mobile-specific services, 154–65 location, 156–62 payment, 162–65 SMS, 154–56 Mobility service, 119, 120 terminal, 119, 120 user mobility, 119 Mobility management GPRS, 132–33 GSM, 125–26 Morse, Samuel, 1–2


Movilforum, 299 Multiplexing, 78 Multipoint control units (MCUs), 88 Multivendor IN products, 73–74

Network APIs, 300 Network intelligence, 6 Next generation networks, 290–93 issues, 292–93 scenario illustration, 292

Object Management Group (OMG), 17, 233–43, 310 CORBA, 234–38 defined, 233 objective, 233–34 standards development, 234 TDTF, 238–43 Object-oriented programming, 250–51 Object-oriented service logic, 251–53, 297 Open-service access (OSA), 185–208, 295 3GPP and, 178 application-initiated call setup, 197–99 applications, 205–8 architecture, 16, 69 authentication, 192, 193–95 callback interfaces, 188 call-control interfaces, 189–92 call types, 189–90 centralized implementation, 201–2 conference calls, 190 configurations, 200–202 content billing, 206 CORBA, 199 distributed implementation, 201 drivers, 205 example application, 207 full migration to, 298 general interface structure, 187–88 implementing, 199–205 IN architecture and, 177 interface parts, 186

Index

interfaces, 185–87 interface structure, 188 mapping, to CAMEL, 202–3 multimedia calls, 190 multiparty calls, 190 object classes, 187 Parlay to, 183–84 phases, 192 products, 203–5 programming interfaces, 184 protocol replacement, 206 roaming interface, 206 service selection, 192, 195–97 service use, 192 specifications, 199 in standardization role, 295 third-party service control, 206 understanding, 185 using, 192–99 vendors, 204–5 Open-Service Marketplace, 241 Open-systems interconnection (OSI) model, 26 Operation, administration, and management part (OAMP), 27 Organization, this book, 13–19 Originating BCSM (O-BCSM), 42, 43, 44 CS-2, 59 defined, 42 detection points and, 43–45 illustrated, 44 See also Terminating BCSM (T-BCSM) Over-the-air (OTA) programming, 153

Packet-switched domain, 169 Parlay, 69, 180–84 business model, 182–83 client application, 182 concept, 180–81 defined, 180 framework interfaces, 183 interfaces, 188

341

JAIN and, 272–74 opening interface concept, 181 to OSA, 183–84 PAM, 188 policy management, 188 programming interfaces, 184 security, 181 service interfaces, 183 service management, 181 PDC, 121 Physical plane (PP), 47–53 colocation of SCF and SDF at, 49 illustrated, 48 mappings, 47–48 See also IN conceptual model (INCM) PINT protocol, 68–69, 103–7 architecture, 105 basis, 104 click-to-dial, 104 click-to-fax, 104 click-to-fax-back, 104 clients, 104 defined, 103 gateway, 104 requests, 105 SIP extensions, 105 voice-access-to-content, 104 Plaintext, 200 Point of return (POR), 37, 38 Points of initiation (POIs), 37, 38 Process management, 56 Programmability interfaces, 298 Protocol implementation conformance statements (PICS), 67 Proxy servers, 95 Public Switched Telephony Network Internet Internetworking. See PINT protocol

Quality of service (QoS), 91 Radio control function (RCF), 58 Radio network controllers (RNC), 169 Reading tracks, this book, 19–21

342

Redirect server, 95 Research for Advanced Communications Europe (RACE), 165 Routers, 79–80 Routing, 114

Satellite networks, 84 Screen SIB, 35, 37 SDL, 67 Security cellular networks, 11 GSM, 126–28 MExE, 152 mobile networking, 12 Parlay, 181 Servers EJB, 259 home subscriber (HSS), 171 proxy, 95 redirect, 95 registrar, 95 SIP, 94–97 SPIRITS, 108, 109, 110 user agent, 94 Service control, 114 Service control function (SCF), 40, 49 CAMEL, 137 H.323 gatekeeper and, 90 SCF-SCF communication mechanism, 113 triggering, 90 Service control points (SCPs), 48 Alcatel configuration, 70 in SS7 networks, 28 Service control user agent function (SCUSF), 58 Service creation, 18–19, 245–88 defined, 245–46 feature interactions, 282–88 Service data function (SDF), 40, 49 Service data points (SDPs), 48 Service logic execution environment (SLEE), 261 Service management, 114 access from Internet, 116


configuration over Internet and, 115–17 Parlay, 181 Service management function (SMF), 40, 117 Service management points (SMPs), 48 Service mobility, 119, 120 Service plane (SP), 31–33 CS-1, 33 CS-2, 55 defined, 31–32 features as reusable units, 32 features defined in CS-1, 33 illustrated, 32 mapping to GFP, 34 See also IN conceptual model (INCM) Services call-forwarding, 45 calling-card, 251–53 CAMEL, 136 composed of features, 33 customization, 116 data structures, 249 home-zone, 160–61 location, 156–62 managing, via Internet, 113–18 mobile payment, 162–65 mobile-specific, 154–65 OSA cycle, 192 SIBs, 39 TINA, 213 value-added, 249 Service scripts, 246–48 defined, 246 illustrated, 247 steps, 248 Service selection, 192, 195–97 procedure illustration, 196 steps, 195–97 Service session, 216, 217, 221–23 defined, 216 features, 222 graph, 222 stream binding management, 223 See also TINA

Index

Service switching function (SSF), 40, 41 Service switching points (SSPs), 48 Serving GPRS support node (SGSN), 131 Servlets, 278 Session Description Protocol (SDP), 93 example session descriptions, 94 PINT extension, 104–5 session descriptions, 94 Session Initiation Protocol (SIP), 92–99 calls, 96 clients, 94–97 defined, 92 flexibility, 96 H.323 vs., 98–99 HTTP basis, 106 messages, 92 PINT extensions, 106–7 requests, 92, 93 responses, 93 SDP extension, 104–5 servers, 94–97 service processing, 97 Session models, 298 Short Message Peer-to-Peer Protocol (SMPP), 156 Short message service centers (SMSCs), 155 SIBs, 34–36 basic call process (BCP) and, 36–39 BCUP, 56 call-instance data (CID) and, 34 CPH, 56 CS-1, 35, 36 CS-2, 57 defined, 34 defined in CS-1 GFP, 36 high-level (HLSIBs), 57, 58 illustrated, 35 IN standard for, 35 process management, 56 real-life services, 39 screen, 35, 37

343

See also Global functional plane (GFP) Signaling system number 7 (SS7), 6, 24–28 defined, 24 design, 25 IN application part (INAP), 28 introduction of, 24 ISDN user part (ISUP), 27 message transfer part 1 (MTP1), 26 message transfer part 2 (MTP2), 26 message transfer part 3 (MTP3), 27 mobile application part (MAP), 28 network elements, 25 operation, administration, and management part (OAMP), 27 protocol stack, 26 service control points (SCPs), 28 signaling connection control part (SCCP), 27 signaling links (SLs), 25 signaling points (SPs), 25 signaling transfer points (STPs), 25 telephony user part (TUP), 27 transaction capabilities application part (TCAP), 27 SIM application toolkit (SAT), 153–54 availability, 154 control features, 154 defined, 153 SIP, 200 SMS, 154–56 defined, 154 network elements, 156 short message service centers (SMSCs), 155 success, 155 triggers, 156 Soft switching, 100–102 concept illustration, 102 forum, 102 JAIN, 261 Java-controlled, 261 popularity, 102 Special resource function (SRF), 41 SPIRITS protocol, 68–69, 107–10

344

SPIRITS protocol (continued) architecture, 108 client, 109, 110 defined, 107–8 gateway, 108, 110 ICW with, 109 server, 108, 109, 110 Standardization, 293–96 bodies, 29–30 changes in, 294–95 cycles, 30, 294 evolution, 293–96 new role for, 295–96 Stream data transfer, 78 Switching, 114

Taxi dispatcher example, 207–8 TCAP-CORBA gateway, 240, 241 TCP/IP defined, 79 function of, 85 TDTF, 238–43 areas, 239 control/management of Audio/video streams, 239–40 defined, 238–39 interfaces, 239 Open-Service Marketplace, 241 TCAP-CORBA gateway, 240, 241 Telecommunications Service Access and Subscription (TSAS), 240–41 UML for Telecommunications, 242–43 Wireless Access and Mobility, 241–42 Telecommunications, 290 information networking architecture. See TINA Java in, 253–59 UML for, 242–43 Telecommunications middleware, 17–18, 211–43 CORBA, 234–38 defined, 211 OMG and, 233–43


TDTF, 238–43 TINA, 212–33 Telecommunications Service Access and Subscription (TSAS), 240–41 Telegraph, 1–2 Telephone exchanges, 2–4 defined, 2–3 hierarchy of, 4 Telephone network, 2–6 central office, 3 electronic/digital exchanges, 4–5 intelligence in, 6 signaling, 5–6 telephone exchange, 2–4 Telephony, 290 Internet, 86 Internet vs., 9–10 interweaving of, 10 mobile, integrating, 13 QoS, 91 Temporary mobile station identifier (TMSI), 127 Terminal communication session manager (TCSM), 225 Terminal layer adapter (TLA), 225–26 Terminal mobility, 119, 120 Terminating BCSM (T-BCSM), 42, 43, 44 CS-2, 59 defined, 42 detection points and, 43–45 illustrated, 44 See also Originating BCSM (O-BCSM) Third Generation Partnership Program (3GPP), 30 Third-party developer programs, 299–300 TINA, 17–18, 69, 212–33 access session, 217, 220–21 architecture overview, 216 auxiliary projects, 231–32 business model, 213–15 business model illustration, 214 communication session, 217 connection setup, 226–28

Index

decline, 232–33 domains, 213–15 DPE, 219 future of, 230–33 negotiation phase, 226, 227 reservation phase, 226–28, 229 services, 213 service session, 216, 217, 221–23 session model, 216–18 session model illustration, 218 TINA-C, 212–13, 311 See also Telecommunications middleware TINA resource management architecture, 223–30 computational objects, 224–26 connection establishment, 226–28 connection setup, 223–24 defined, 215, 223 federation, 228–30 functions, 223 illustrated, 225 TINA service architecture, 218–23 computational objects, 219–20 defined, 215 illustrated, 219 Transmission Control Protocol (TCP), 78–79 flow control, 79 multiplexing, 78 reliable delivery, 79 stream data transfer, 78 See also TCP/IP Triggers CAMEL, 145 processing, 45–47 SMS, 156

UML for Telecommunications, 242–43 UMTS, 121, 168–72 3GPP specifications, 166–67 ambitions, 168 architecture, 170 capabilities, 176 circuit-switched domain, 169, 170

345

deployment, 171 future networks, 171 home subscriber server (HSS), 171 multimedia domain, 170 multimedia IP domain, 169 network domains, 169 open service access, 175–78 packet-switched domain, 169 terrestrial radio access network (UTRAN), 169 time line, 168 unification, 176 Unified messaging, 117–18 center (UMC), 117 defined, 117 implementation within IN, 118 solution concept, 118 translations, 117–18 User Datagram Protocol (UDP), 79 User mobility, 119

Value-added services, 249 Value-Added Services Alliance (VASA), 30 Vendors, OSA equipment, 204–5 Very-high-rate digital subscriber line (VDSL), 83–84 VHE, 172–75 concept, 173 concept illustration, 173 from corporate and private-user perspectives, 174 ETSI definition of, 172 features, 172 implementation reference, 174 Voice message relay (VMR), 117

WAP, 147–49 defined, 147 definitions, 147–48 forum, 147 gateways, 148–49 iMode comparison, 150 pages, 148 protocol optimization, 148 specifications, 149

346

Web-IN, 110–13 defined, 111 principle, 112 scenario, 112 Web sites, 313–14 WIN standards, 135 Wireless Access and Mobility, 241–42


Wireless Application Protocol. See WAP Wireless intelligent networks (WIN) standard, 15 Wireless markup language (WML), 148

Next Generation Intelligent Networks

Algorithms for Next Generation Networks

Algorithms for Next Generation Networks