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!
For a complete listing of the Artech House Telecommunications Library, turn to the back of this book.
00_fm_4557.qxd
10/19/05
12:46 PM
Page iii
Implementing Value-Added Telecom Services Johan Zuidweg
artechhouse.com
00_fm_4557.qxd
10/19/05
12:46 PM
Page iv
Library of Congress Cataloging-in-Publication Data A catalog record of this book is available from the U.S. Library of Congress.
British Library Cataloguing in Publication Data Zuidweg, Johan Implementing value-added telecom services. — (Artech House telecommunications library) 1. Telecommunication systems 2. Value added I. Title 621.3'82 ISBN-10: 1-58053-978-5 Cover design by Cameron Incorporated
Advances in Computing Technology Digitalization of Communications Internet Mobile Networks
3 3 5 6
1.2 1.2.1 1.2.2 1.2.3
Liberalization of Telecommunications Markets The United States The United Kingdom Europe and the Rest of the World
7 8 9 9
1.3 1.3.1 1.3.2
The Rebirth of an Industry The Dot-Com Crisis A Healthy Industry
9 10 11
1.4 1.4.1 1.4.2 1.4.3 1.4.4 1.4.5
Opportunities for Third Parties Prepaid Services Messaging Services Content Services Location-Based Services Electronic Commerce
12 12 13 14 14 15
1.5 1.5.1 1.5.2 1.5.3
Nontechnical Factors Business Plan Regulation and Legal Aspects Dimensioning
16 16 17 18
v
00_fm_4557.qxd
10/19/05
vi
12:46 PM
Page vi
Implementing Value-Added Telecom Services
1.6 1.6.1 1.6.2 1.6.3 1.6.4
How to Use This Book Service Orientation Enabling Technologies and Case Studies Standards and Web Links The Book’s Web Site References Selected Bibliography
19 19 20 20 20 21 21
2
Prepaid Services
23
2.1 2.1.1 2.1.2 2.1.3 2.1.4
Prepaid Fixed Telephony Basic Point of Presence Using Voice over IP Prepaid Telephony with Intelligent Networks Prepaid Telephony with OSA-Parlay
24 25 27 29 33
2.2 2.2.1 2.2.2 2.2.3
Prepaid Mobile Communications Prepaid Mobile with CAMEL Mobile Virtual Network Operators Prepaid Mobile with OSA-Parlay Reference Selected Bibliography
38 39 41 44 48 48
3
Messaging Services
49
3.1 3.1.1 3.1.2 3.1.3 3.1.4
Electronic Mail Mailbox Provisioning Newsletters and E-Mail Publicity E-Mail Notification Services E-Mail Viruses and Spam
49 50 52 55 56
3.2 3.2.1 3.2.2 3.2.3 3.2.4
Short Message Service (SMS) Sending and Receiving SMS from Applications Premium Rate SMS Alerting Services Cell Broadcast Service (CBS)
59 59 62 64 65
3.3 3.3.1 3.3.2
Multimedia Messaging Service The MMS Standard MMS Interfaces
Unified Messaging Setting Up a Unified-Message Service OSA-Parlay Generic Messaging Interface Selected Bibliography
73 74 76 79
4
Content Services
81
4.1
Pull and Push Content
82
4.2 4.2.1 4.2.2 4.2.3
World Wide Web Setting Up a Web Site Item- or Subscription-Based Charging Dialers
83 84 85 86
4.3 4.3.1 4.3.2 4.3.3 4.3.4
Wireless Application Protocol (WAP) WAP Gateways Charging for WAP Content Billing WAP Content Through the Operator Third-Party WAP Billing
90 90 92 93 95
4.4
I-Mode
96
4.5 4.5.1 4.5.2
Push Content Web Push WAP Push
98 99 100
4.6 4.6.1 4.6.2 4.6.3 4.6.4 4.6.5 4.6.6 4.6.7
Streaming Content Streaming over IP Media Coding and Decoding Streaming Servers Streaming for Mobile Devices Charging for Streaming Content Mediation OSA-Parlay Mediation Interface
103 104 105 106 106 108 109 111
72
00_fm_4557.qxd
10/19/05
viii
12:46 PM
Page viii
Implementing Value-Added Telecom Services
4.7 4.7.1 4.7.2 4.7.3 4.7.4
Content Protection Many Options Digital Rights Management DRM Standards DRM-Enabled Content Business Reference Selected Bibliography
113 114 114 116 118 119 119
5
Location-Based Services
121
5.1 5.1.1 5.1.2 5.1.3 5.1.4 5.1.5
Location Techniques Cell ID–Based Location Enhanced Observed Time Difference Uplink Time Difference of Arrival Global Positioning System Assisted GPS
122 123 124 126 126 127
5.2 5.2.1 5.2.2 5.2.3 5.2.4 5.2.5
Location Architecture and Interfaces Mobile Location Protocol (MLP) Secure User Plane Location Combining MLP and SUPL Roaming Location Protocol (RLP) OSA-Parlay
129 131 134 136 137 139
5.3 5.3.1 5.3.2 5.3.3
Adding Location Value Location-Based Applications and Content Location-Based Gaming The Gimkana Location-Based Game
Business-to-Consumer Transactions Merchant Account Credit-Card Payments Online Store
155 156 158 160
00_fm_4557.qxd
10/19/05
12:46 PM
Page ix
Contents
ix
6.2.4 6.2.5
Analyzing Site Visits Preventing Fraud
162 165
6.3 6.3.1 6.3.2 6.3.3 6.3.4
Business-to-Business Transactions EDI EDIFACT and EDIINT ebXML Rosettanet
166 167 170 171 174
6.4 6.4.1 6.4.2 6.4.3 6.4.4
Person-to-Person Transactions Online Auctions Person-to-Person Payment on the Internet Mobile Payment OSA-Parlay Charging Interface References Selected Bibliography
176 176 179 181 185 188 189
Key Technologies
191
A.1 A.1.1 A.1.2 A.1.3 A.1.4 A.1.5 A.1.6
Internet Internet Protocols World Wide Web Cookies Server Side Processing Web Services Voice over IP
191 191 193 194 195 197 199
A.2 A.2.1 A.2.2 A.2.3
Information Technologies Extensible Markup Language Public Key Infrastructure Secure Socket Layer (SSL)
Mobile Networks Global System for Mobile Telecommunications General Packet Radio System (GPRS)
209 210 210
Appendix A
00_fm_4557.qxd
10/19/05
12:46 PM
x
Page x
Implementing Value-Added Telecom Services
A.4.3 A.4.4
Universal Mobile Telecommunications System CAMEL
212 212
Standards
215
B.1
CAMEL
215
B.2
Digital Rights Management
215
B.3
E-Commerce
216
B.4
Intelligent Networks
216
B.5
Location-Based Services
216
B.6
Messaging
217
B.7
OSA-Parlay
218
B.8
Streaming Content
218
B.9
WAP Push
218
Appendix B
Acronyms
219
Bibliography
227
About the Author
229
Index
231
00_fm_4557.qxd
10/19/05
12:46 PM
Page xi
Preface At the height of the dot-com boom in 1999, I started writing a book with Artech House Publishers on the evolution of intelligent networks. Many European administrations had liberalized telecommunications just a year earlier, and new entrants were storming the market. Diversion and value-added services were the keywords, and intelligent networks were the talk of the town as the enabling technology. There were few books on intelligent networks, and even fewer on newly emerging standards such as Telecommunications Information Networking Architecture (TINA) and Open Service Access (OSA)-Parlay. The moment seemed right to write a book on these technologies. While I was in the midst of writing the book, the dot-com crisis hit. Service providers and operators froze their investments, and intelligent networks sales stopped dead in their tracks. I had the feeling that my book, Next Generation Intelligent Networks, had come only months too late. But the telecommunications industry crawled back on its feet and is now experiencing steady growth. Yet some things have changed since the boom of the late 1990s. Bankruptcies, mergers, and acquisitions left only a few large service providers competing for the lion’s share of the market. At the same time, liberalization of telecommunications consolidated and entrepreneurs began to learn to operate in what is a young, but healthy industry like any other. Technology may have lost its sex appeal to investors, but they now consider it for what it is worth: a means to an end, where the end is business. This viewpoint has made me reconsider my first book, which I wrote from the perspective of technological standards for the fixed or mobile operator. While these standards have not lost their relevance, current times require a book written from the perspective of services and that is targeted at any business, incumbent operator, service provider, or third party wishing to provide communications services. Thus I was motivated to write the current book. The book before you takes a broad, service-oriented view of the technologies available to existing and future service providers. While still technical in
xi
00_fm_4557.qxd
xii
10/19/05
12:46 PM
Page xii
Implementing Value-Added Telecom Services
scope, the book has a practical approach, illustrated by case studies from the real world. I will by no means claim that this is the definitive work on third-party service provisioning. If I tried, the book would probably have a thousand pages and still be incomplete. A subject like mobile virtual network operators (MVNOs), for example, could easily take up an entire book. The same goes for programming applications in mobile terminals, or e-commerce. Though nontechnical aspects are crucial for setting up business in telecommunications, I deliberately avoided most of them. Business plans, regulatory and legal aspects, negotiations, purchasing, and dimensioning represent entire disciplines that easily go beyond the reach of a single book. If there is any point I want to get across in this publication, it is that technology should not be the barrier to starting business in telecommunications. It is easy to be intimidated by the standards, protocols, forums, and acronyms, but I hope this book shows that behind them lies no more than common sense and hard work. With a bright idea and a sound business plan, technology will do the rest. I highly appreciate any comments that the reader might have for improving this book or helping other readers. Comments can be made through the book’s Web site, www.implementingVAS.com, where updates and additional information can also be found, or I can be reached directly at [email protected].
00_fm_4557.qxd
10/19/05
12:46 PM
Page xiii
Acknowledgments Writing a book appears to be a solitary activity, but in practice, of course, I relied on the help and support from many others. First, I would like to thank my employer Telefónica I+D, and specifically Isidoro Padilla (former CEO), Francisco Golderos (General Director), Pedro Lizcano (Director), Luis Ranchal (Director), Francisco Puche (Department Head), and Rafael San José (Divisional Head), for their confidence in me, and for providing me with a stimulating hitech professional environment that I consider the most prestigious in Spain. As a consultant it has been a privilege for me to work for Telefónica Móviles, the Spanish incumbent mobile operator that now ranks fourth worldwide in terms of revenues. At Telefónica Móviles, I’m indebted to Luis Jorge Romero (Director), Marcos Eguillor, Juan Cambeiro, and Fernando Soriano, who introduced me to standardization, and specifically the Open Mobile Alliance (OMA). I also want to express my gratitude to Ramon Recio (CEO), Jordi Galera (general director), José Pérez (telecoms area director), and Ramon Figueras (telecoms commercial director) of Tecsidel SA (Spain), for introducing me to the Spanish telecommunications environment, and teaching me how to survive as a moderately sized systems integrator in a murderously competitive market. Professor Jaime Delgado of the Universitat Pompeu Fabra in Barcelona, an expert on Moving Picture Expert Group (MPEG)-21, deserves special mention for supporting me at critical times. I admire his relentless (and successful) effort to maintain a world-class research team in a difficult environment. My warmest thanks go out to my colleagues Silvia Fernández, Bernardo Campillo, Enrique Izaguirre, Santiago Martínez, Alvaro Ramos, Jordi Garcia, Marc Plaganumà, Sonia Segura, and Jordi Rovira, all of whom helped me solve technical (and not-so-technical) problems daily. I owe my gratitude to many others whose names do not appear here. The two most important people in my life, Ana and Daniel, have made perhaps the greatest contribution of all: that of love and understanding. More
xiii
00_fm_4557.qxd
xiv
10/19/05
12:46 PM
Page xiv
Implementing Value-Added Telecom Services
than that, Ana is a mean analyst who, with her knowledge of economics and technology, her creativity, and her woman’s sixth sense, predicted some of today’s broadband applications eight years ago. She provided me with ideas throughout the writing of this book, and Daniel’s razor sharp observations taught me that we adults miss important details all the time.
01_4557.qxd
10/19/05
12:49 PM
Page 1
1 Introduction Only two decades ago, telecommunications still meant “telephone and telegraph.” Telephony started as a private enterprise in the early days, but by the beginning of the twentieth century public administration controlled long distance communications in the United States, United Kingdom, and Europe. Those of us born before the 1980s were raised with the concept of the telephone as a public utility like electricity, water, public roads, and postal service. In most countries a single-state-controlled post, telephone, and telegraph (PTT) company managed both the postal service and telephone company until well into the 1980s. These state monopolies treated telephony not as a business, but a public utility or even a privilege. Some countries had year-long waiting lists for new telephone subscriptions until well into the 1980s. Figure 1.1 shows the front cover of a children’s book from 1938, explaining the services of the Dutch PTT. In less than a generation, the communications landscape has changed completely. Most of us still have telephones, but different companies now compete to serve our calls. In addition, apart from telephony we now communicate by e-mail, browsing, downloading, short messaging, mobile telephony, voice over Internet, even videoconferencing. Telecommunications are no longer the exclusive domain of a few national PTTs, and have become a competitive market like any other. Companies that operate from their owner’s garage now compete with international giants. This book is about the technologies available to entrepreneurs, whether they be
1
01_4557.qxd
2
10/19/05
12:49 PM
Page 2
Implementing Value-Added Telecom Services
Figure 1.1 A 1938 book dedicated to the Dutch PTT [1]. (Courtesy of KPN Beeldbank.)
01_4557.qxd
10/19/05
12:49 PM
Page 3
Introduction
3
individuals or multinationals, to make their business in telecommunications without necessarily owning any network infrastructure. But this is not to say that third-party service providers will reduce operators to mere voice and data carriers, so-called bit pipes. The operator’s network infrastructure, subscriber base, and know-how gives it an advantageous position to provide innovative value-added services that take advantage of the Internet as well as the switched telephony or mobile network. This book is for operators as much as it is for third-party service providers. Two factors have contributed to the landslide in telecommunications: advances in computing technology and liberalization of telecommunications markets. Before considering the technology itself, let us first explore the context in this introduction.
1.1 Advances in Computing Technology No doubt the decisive influence on telecommunications has been the advance in computing and information technology (IT). Until the 1970s, computing was not a utility but a science. Only research institutions and large corporations could afford expensive computers, and interconnecting them required proprietary data networks. By the beginning of the 1970s, minicomputers like the Digital Equipment Corporation PDP8 had become small and inexpensive enough for wider scientific and administrative use. The Hewlett-Packard 9830, introduced in 1972, was the first desktop all-in-one computer with a BASIC interpreter built into read only memory (ROM). By 1975 IBM had produced the portable IBM 5100 with a larger screen. These machines were still too expensive and complicated for personal use, but they set the trend toward miniaturizing and personalizing the computer. In 1977 Apple was the first company to successfully mass produce a microcomputer for the general public, the Apple II. Many other manufacturers followed suit, including Texas Instruments, Atari, and Commodore, which built one of the most popular personal computers of all time, the Commodore 64. IBM, which entered the ring in 1981 with the 5150 PC (see Figure 1.2), would set the standard for generations of personal computers and in fact established the term PC. The availability of cheap computing equipment has profoundly changed our society. In the next sections we will see how computing has played a decisive role in the evolution of telecommunications 1.1.1 Digitalization of Communications In the first half of the twentieth century, telephony exchanges were electromechanical devices. They switched telephony voice circuits by electrical relays
01_4557.qxd
4
10/19/05
12:49 PM
Page 4
Implementing Value-Added Telecom Services
Figure 1.2 IBM 5150. (Courtesy of IBM Corporate Archives.)
that responded to electric pulses from the rotary dial on a telephone. As transistors and integrated circuits became more widely available, telephony switches evolved from electromechanical to digital devices. By the second half of the 1970s, switches had become completely digital, not only in control but also in treatment of voice signals and in the switching itself. Voice signals now convert into streams of digital numbers, which multiplex into high-speed bit streams to be sent over optical trunk lines between digital switches. Digital signals are much easier to manipulate than analogical voice circuits, and this provides opportunities for value-added treatment of communications. The digitalization of telephone switching equipment also had an impact on signaling, the messages that switches exchange to set up calls. To avoid setting up calls to busy, disconnected, or absent subscribers, AT&T invented a digital signaling system that uses a separate packet data network to do the call alerting and routing before actually setting up the connections. The common channel signaling system number 7 (SS7) is now a worldwide standard. Being able to negotiate the way a call is going to be set up before the resources are actually committed provides new call processing opportunities. SS7 makes it possible to refuse a call (caller ID), change the call destination (call
01_4557.qxd
10/19/05
12:49 PM
Page 5
Introduction
5
forwarding), or placing a call on hold (call-waiting) before actually setting up the voice circuits. This extra call treatment adds value to the basic communications service. The next logical step was deploying specific nodes in the SS7 network for additional call treatment. These service control points (SCPs) form the basis of the intelligent networks (IN) concept, by which stored programs (scripts) control the processing of calls. SCPs are part of the operator managed SS7 signaling network, and as such IN does not allow third parties to program value-added services (VAS). But the telecommunications liberalization wave of the 1990s soon created a need for an interface that would allow third parties to program VAS fixed and mobile telephony network. The Open Service Access (OSA)-Parlay standard, first specified in 1998 by the Parlay Group and Third Generation Partnership Project (3GPP), provides such an interface. Network operators now have the technology to let third-party service providers control prepaid communications, messaging, location, and many other services in their network within a tight security framework. 1.1.2 Internet The proliferation of inexpensive, small computing equipment in the 1980s and 1990s created a pressing need for data communications. This initially led to the development of many different data communications standards, each with its advantages and drawbacks, and each optimized for a specific type of applications and network configuration. Among the many well-known standards are Ethernet (IEEE 802.3), token bus (IEEE 802.4), token ring (IEEE 802.5), DQDB (IEEE 802.6), FDDI, X.25, and ATM. Unfortunately, the many data networking standards were incompatible. The Internet protocol (IP) already existed by that time in the research community, and in less than a decade it became the foundation for the worldwide decentralized, distributed network we call the Internet. The invention of the hypertext browser1 and the search engine2 around 1990 gave the definitive boost to the Internet, and created what is now the World Wide Web (WWW). 1. The hypertext concept was in fact invented independently from the Internet, but it was Mosaic that provided the first Internet browser in 1993. One year later, in 1994, Netscape launched a Web browser that set the standard for what is now the World Wide Web. Around 1998 it looked as if Microsoft Explorer had effectively beaten Netscape and any other significant competition, but lately the open-source community is hitting back successfully with browsers like Mozilla Firefox and Opera. 2. Archie (1990) and Gopher (1991) can be considered the first primitive search engines. Excite, Yahoo, WebCrawler, and Lycos launched successful search engines in 1993 and 1994, followed later by AltaVista in 1995, Inktomi in 1996, and Google in 1997.
01_4557.qxd
6
10/19/05
12:49 PM
Page 6
Implementing Value-Added Telecom Services
Although the IP suite was initially designed for data communications, it is theoretically possible to encode any kind of signal into data packets. If the encoding, transport, and decoding sequences are fast enough to keep up with the original signal, the Internet can be used for real-time communications. In 1996 the Israeli company Vocaltec commercialized a way of encoding the analog voice signal in IP packets, and sending them over the Internet. Many analysts thought in the late 1990s that voice over IP (VoIP) would supplant switched telephony in a matter of years. This did not happen for several reasons. For one thing early VoIP voice quality could not compete with switched telephony, because of the bandwidth and the unpredictable transport on the public Internet. More importantly, however, the world lacked the critical mass of people with personal computers and Internet connections of sufficient speed. After a difficult start, complicated further by the dot-com crisis, VoIP is now steadily maturing. Companies such as Skype have brought VoIP up to near carrier grade3 and made it feature-rich and very inexpensive, and the growing number of people with digital subscriber line (DSL) connections keeps increasing. Figure 1.3 shows the user interface of a commercially available softphone that handles both voice and video over IP, as well as instant messaging. VoIP, and indeed video and multimedia over IP, provide tremendous opportunities for third-party service providers. Not only is the infrastructure investment a fraction of that needed for circuit-switched telephony, the Internet also provides unique opportunities for combining IT applications with voice and video communications, thus creating new VAS. 1.1.3 Mobile Networks The evolution of computer chips, and their declining cost also boosted the deployment of digital cellular mobile networks such as the global system for mobile telecommunications (GSM) and IS-95. The technical specifications of these networks rely on fast and inexpensive processing, both in the network and in the terminal. While the European Telecommunications Standardization Institute (ETS)4 specified the first GSM standards between 1982 and 1990, critics said that they were too complex and would never work in practice. They argued that the pro-
3. Carrier-grade service is often informally defined as “five nines” (99,999%) uptime and telephony quality voice. 4. At the time the European telecommunications standardization body was called Conference of European Posts and Telegraphs (CEPT). In 1986 it changed its name to European Telecommunications Standardization Institute (ETSI).
01_4557.qxd
10/19/05
12:49 PM
Page 7
Introduction
7
Figure 1.3 Eye Beam video SIP softphone. (Courtesy of Xten Networks, Inc.)
cessing power needed would make the terminal too big, too expensive, and too power consuming. Such arguments were valid in 1986, but by 1992 chips had become small and inexpensive enough to roll out commercial GSM networks. We can now buy GSM phones for less than $100 that not only serve as phones, but also offer address book, agenda, short messaging, browsing, games, and a Moving Pictures Expert Group Audio Layer-3 (MP3) player. Figure 1.4 illustrates how GSM phones have evolved in just a few years. Cellular mobile networks probably represent the last stronghold of the incumbent operator, because of the tremendous infrastructure investments, and because the mobile operator has a tight lock on its subscribers through the subscriber identity module (SIM). Even so, mobile networks provide opportunities for third-party service providers. The mobile phone itself is a personal and programmable device, a perfect channel for delivering third-party applications. While these applications may require airtime from the operator, the third party service provider can provide the added value.
1.2 Liberalization of Telecommunications Markets Apart from technical advances, the liberalization of telecommunications markets worldwide in the 1990s has provided opportunities for new entrants. While this
01_4557.qxd
8
10/19/05
12:49 PM
Page 8
Implementing Value-Added Telecom Services
Figure 1.4 Ericsson GSM prototype (1986) with first commercial phone (1992) on top. (Courtesy of Ericsson.)
has not been without pain for incumbent operators and new entrants alike, state monopolies gave way to free-market enterprise in most of the world. 1.2.1 The United States The year 1984 was a decisive period for liberalization of telecommunications in the United States. State regulation forced AT&T to break up into a longdistance operator (AT&T Long Lines) and 23 Bell Operating Companies, which later regrouped to form 7: BellSouth, Nynex, Ameritech, Bell Atlantic, U.S. West, Pacific Telesis, and South Western Bell Telephone. The network and numbering plans were divided into 160 local access and transport areas (LATAs), with one local exchange carrier (LEC) per area and interexchange carriers (IXC) to interconnect the LATAs (first AT&T Long Lines, later also MCI and Sprint). Telecommunications in the United States remain regulated, but it is relatively straightforward to obtain a license to operate telecommunications services.
01_4557.qxd
10/19/05
12:49 PM
Page 9
Introduction
9
1.2.2 The United Kingdom The government of the United Kingdom split telecommunications from postal services in 1981, when it created British Telecom (BT). Shortly afterwards, in 1982, Mercury Communications Limited (MCL) obtained a license to compete with BT, and VAS provisioning was liberalized. The U.K. government effectively privatized BT in 1984 by selling 50.2% of its shares. At the end of the 1990s, the U.K. Office of Telecommunications (Oftel, now called Ofcom) decreed that BT would have to provide third-party serviceprovider access to its switches. BT responded by launching the Parlay Group with a team of vendors, with the objective of defining secure interfaces for thirdparty provisioning of VAS. ETSI and 3GPP embraced the Parlay specifications soon afterwards, merging them with the OSA standard for programming VAS in mobile networks. The Parlay Group has grown into an open international forum with more than 60 members, and OSA-Parlay has become a significant enabling technology for offering third-party VAS through public switched networks. 1.2.3 Europe and the Rest of the World The European Union (EU) started considering liberalizing telecommunications markets in the mid-1980s. It was not until 1998 that telecommunications markets were actually liberalized across Europe, but liberalization is now complete in most countries of the EU. Also in 1998, the World Trade Organization (WTO) reached an agreement by which 69 countries accounting for 90% of worldwide telecommunications revenue pledged to liberalize their telecommunications markets. Many countries have already done so, including Argentina, Australia, Brazil, Colombia, Côte d’Ivoire, Czech Republic, Guinea, Ecuador, Estonia, Hungary, India, Indonesia, Israel, Korea, Kuwait, Latvia, Lithuania, Madagascar, Malaysia, Mexico, Nigeria, Pakistan, Panama, Paraguay, Peru, Poland, Puerto Rico, Russia, Singapore, Taiwan, Thailand, Turkey, Ukraine, and Venezuela.
1.3 The Rebirth of an Industry In spite of the liberalization of telecommunications, building a mobile or fixed telephony network requires investments that are usually unaffordable for smaller enterprises. Incumbent operators may allow third parties to resell call minutes and airtime to the public and become virtual network operators (VNOs). The third-party enterprise adds its own value to the basic communications services, which can be nontechnical (branding or added customer care) or technical (VAS).
01_4557.qxd
10/19/05
12:49 PM
10
Page 10
Implementing Value-Added Telecom Services
The Internet, on the other hand, has been a true frontier for entrepreneurs with great ideas but little, or in some cases even no, capital. The Internet has no central control or maintenance, and the initial investment of an Internet-based business requires no more than a couple of servers. Immensely successful services like Google, eBay, Amazon, or PayPal started as student projects, hobbies, or small businesses. While it is difficult to compete with these giants on their own turf, the Internet still provides plenty of opportunities for creative entrepreneurs. 1.3.1 The Dot-Com Crisis The prospect of providing online services with minimal investment led to widespread euphoria in the late 1990s. Investors became interested, and capital began searching for bright ideas, rather than the other way around. As if it were to abjure years of risk aversion throughout the early 1990s, investors plunged headlong into risky ventures as stock prices soared. While the bliss lasted, nobody bothered to question the integrity of the booming companies too much. The house of cards collapsed in March 2000 when investors failed to see short-term results. In a matter of months, $3 trillion, 500 tech companies, and 500,000 tech jobs evaporated (see Figure 1.5).
5,000
4,000
3,000
2,000 3/2000
6/2000
9/2000
12/2000
Figure 1.5 Nasdaq composite index between March 2000 and March 2001.
3/2001
01_4557.qxd
10/19/05
12:49 PM
Page 11
Introduction
11
Not only did the Nasdaq crash further undermine the confidence of investors and general public alike, but so did revelations of questionable practices by companies such as Enron, Worldcom and Lernout & Hauspie. Euphoria gave way to fear and risk aversion as investors turned away from technology and back to more classic sectors like real estate, banking, and insurance. As if that were not enough, the catastrophic events of September 11, 2001, and its sequel dealt another blow to the few years of economic and political optimism. 1.3.2 A Healthy Industry Technology and telecommunications appear to have lost their attractiveness to the general public and have disappeared mostly from the front pages. Does this mean, however, that telecommunications offers no more margins for business? Where do we stand today? After the dark years between 2000 and 2002, telecommunications revenues are returning to the levels they were at before the dot-com boom and subsequent crisis. According to the Telecommunications Industry Association (TIA), telecommunications revenues worldwide grew 9.4% between 2003 and 2004. Analysts agree that telecommunications revenues will continue to grow during the first decade of the new millennium, and put worldwide growth figures at between 6% and 10% annually. They cite VoIP, wireless local area networks (WLAN), 2G and 3G cellular mobile networks, and streaming media as the motors for growth. Telecommunications is a healthy industry, and most of its growth will occur in services that can be offered by third parties. Mobile subscriber penetration in Europe currently exceeds 70%. The Gartner Group predicts that the world’s mobile subscriber base will double between 2005 and 2010. According to one CEO,5 mobile data will generate $200 billion in revenues by decade’s end, as much as 15% of total telecommunications revenues. This means that we have to regard the mobile phone as the universal channel for providing VAS to a mass market. Emerging markets also provide interesting opportunities, as they present the most spectacular growth figures. Baskerville predicts that Africa’s mobile market will grow fivefold to 150 million subscribers by 2010, and Visongain expects China to reach 580 million mobile subscribers in the same time frame. As rationalization, fusions, and globalization sweep through the telecommunications industry, as much as 80% of the market is now in the hands of a
5. Estimate made by Michael Pousti of SMS.ac during special Wireless Wonk Segment at CTIA Wireless in March 2005.
01_4557.qxd
12
10/19/05
12:49 PM
Page 12
Implementing Value-Added Telecom Services
few big companies. However, this does not mean that new entries cannot make money in telecommunications. Although double-digit growth will remain a mirage, there is plenty of opportunity for enterprises with bright ideas, well researched business plans, and that are willing to put in a lot of hard work.
1.4 Opportunities for Third Parties After a turbulent decade of liberalization, technological bliss, financial collapse, and rationalization, telecommunications are maturing as an industry that offers opportunities for incumbent operators and third-party service providers, big, and small business alike. While operators generally possess the infrastructure, capital, and technological know-how to create innovative services, the technology labyrinth tends to intimidate new entrants. This book aims to explain in plain language how key technologies enable new VAS in a market where the boundaries between Internet, telephony, and mobile have faded. This book provides a broad practical, service-oriented implementation guide. Even the reader with modest technical background will find sufficient technical detail to understand the technology behind successful value-added services. Chapters 2 through 6 of this book are organized according to five key service areas: prepaid services, messaging, content services, location-based services, and electronic commerce. 1.4.1 Prepaid Services Prepaid communications have been among the most successful services deployed since the liberalization of telecommunications, and they continue to represent a growth market. Many fixed telephony prepaid services are operated by thirdparty service providers. Some resell switched telephony connections, while others operate via VoIP. T&F Informa predicts Asia to be responsible for most of the growth in prepaid communications, reaching 784 million prepaid users in 2010, which will account for almost 75% of the total market. But in the United States and Europe, prepaid will also continue growing at annual rates of at least 5% in the same time frame. Third parties encounter higher barriers for providing prepaid services in mobile networks, because the mobile network operator legally owns the SIM. But many mobile network operators will let third parties act as mobile VNOs (MVNOs) and resell prepaid SIM cards without managing their own radio network.
01_4557.qxd
10/19/05
12:49 PM
Page 13
Introduction
13
Yankee Group expects the MVNO market will reach 29 million customers and $10.7 billion in service revenue by 2010. While the established large MVNOs will take 80% of this market, the remaining 20% will still provide opportunities for medium and smaller enterprises. Chapter 2 addresses questions such as: How can a third party offer prepaid telephony without owning network infrastructure? How can calls be routed inexpensively over the Internet? How does one become an MVNO? What are customized applications for mobile enhanced logic (CAMEL) and OSA-Parlay, and how do they help third parties provide prepaid services in fixed and mobile networks? 1.4.2 Messaging Services If there is one service that has turned telecommunications upside down, it is messaging. As an asynchronous form of communications, electronic messaging provides the perfect complement to telephony, which requires simultaneous availability of both call parties. Two forms of electronic messaging6 have had the greatest impact: e-mail in Internet and the short messaging service (SMS) in mobile networks. e-Mail was one of the first Internet applications embraced by a larger public, simply because it is fast, quite reliable, and free.7 Since mail clients became capable of handling any kind of data attachments in multipurpose Internet mail extensions (MIME) encoding, e-mail has become an indispensable tool for most of us. SMS in mobile networks became equally successful, even though mobile networks have a distinct business model from the Internet and charge short messages individually at a price per character that would be considered outrageous on the Internet. In this case, too, SMS provided precisely the asynchronous communications service needed to complement synchronous voice calls. In addition, premium rate SMSs have become widely deployed as a way of delivering and charging value-added content through the mobile subscription.
6. The reason facsimile (fax) is not mentioned here is that it uses switched telephony and as such is not really messaging in a technological sense. 7. It is a myth that the Internet is free. Internet service providers (ISPs), corporations, administrations, research institutes, and others spend large amounts of money maintaining the many subnetworks and backbones that make up the Internet. But what is certain is that the business model for the Internet is radically different from that of fixed or mobile telephony. A user is not confronted with the price of an individual e-mail, but pays for it indirectly through the ISP access fee.
01_4557.qxd
14
10/19/05
12:49 PM
Page 14
Implementing Value-Added Telecom Services
Forrester predicts that traffic from all mobile messaging types will almost double to 23 billion messages per month worldwide by 2010. Although SMS remains dominant, its limitations will create significant growth opportunities for multimedia messaging systems (MMS) in the coming years. MMS allows subscribers to send not only text, but also photos, graphics, audio, and video, much in the same way as e-mail attachments. According to Forrester, MMS revenues could reach over $5 billion in 2010, in Europe alone. Chapter 3 investigates how third-party service providers can use e-mail, SMS, MMS, instant messaging, unified messaging, and other messaging forms to create VAS. Questions addressed include: How to provide information and notification services via e-mail. How to build third-party mobile applications with SMS and MMS. How to make business with premium-rate SMS. What new possibilities does cell broadcast service (CBS) offer? How to build applications with instant messaging. 1.4.3 Content Services As the Internet expands in bandwidth and users, and as mobile data services grow mature, digital content is becoming one of the most promising new business areas. Ring tones, screensavers, and wallpaper accounted for almost 30% of the Asian youth market for mobile data, followed by games at 10% and video at 6%. According to some analysts, digital song download revenues in Europe could account for 40% of the total market for recorded music by 2009. T&F Informa predicts that in spite of piracy threats, Internet movie downloads could bring $976 million revenues worldwide in 2010, the United States accounting for half this figure. Screen Digest forecasts that the global market for downloaded games will be worth $6.4 billion by 2010. Digital content does not only generate revenues from increased traffic and from the content itself, it is creating an ecosystem of new business roles and relations. New business opportunities arise for content aggregators, digital rights issuers, online rights brokers and resellers, and even end users. Chapter 4 explores the technologies available for delivering, charging, and protecting digital content. Some of the questions this chapter addresses are: What kinds of content exist, and how are they charged? What is the difference between push, pull, streaming, and progressive download? How do asymmetric digital subscriber line (ADSL) dialers work, and how can they be used to charge for content on the Internet? How to adapt and deliver content to mobile subscribers. 1.4.4 Location-Based Services Location-based services have been around for some time, but have faced many technical and nontechnical hurdles. While there are many positioning technolo-
01_4557.qxd
10/19/05
12:49 PM
Page 15
Introduction
15
gies, none is perfect: cell ID is inaccurate, plain global positioning system (GPS) is slow, assisted GPS (AGPS) makes terminals more complex, and networkbased algorithms require costly infrastructure. Timing has also caused problems. Location-based services began maturing just as the dot-com crisis hit, which slowed their deployment by operators and their acceptance by the public. The initial drive for location-based services, in fact, came from public administration, to enable emergency services, rather than from the market. Yet location-based services are beginning to emerge as technologies mature and subscribers embrace the new services. It is a myth that only mobile network operators can offer location-based services because they happen to own network infrastructure. A wealth of opportunity lies in combining location information with third-party applications and content. Different analysts put the revenues from location-based services between $1 billion and $4 billion in 2010. They agree that corporate customers will initially generate most demand for tracking employees and assets, while the consumer market will take off more slowly with applications such as navigation, child and asset tracking, and location-based gaming. Gaming represents a particular application area for location based services that is opening to creative entrepreneurs. Analysts estimate that the total mobile gaming market will be worth between $6 billion and $11 billion by 2010. While most of these revenues come from downloads, online multiplayer traffic will eventually represent 20% the total figure. What percentage of these figures will be location-based games remains uncertain, but game designers consider location information a way of making games more interactive, more competitive, and more addictive. Chapter 5 studies the technologies available for providing location-based services, not only from the operator’s perspective, but especially from that of the third-party service provider. The questions addressed in this chapter include: What location techniques exist, and how can a third-party service provider use them? What are the advantages and disadvantages of the different location techniques? Can a third-party enterprise become a location service provider itself? How does one implement a location-based game? 1.4.5 Electronic Commerce The essence of any business is the money that flows through it. The telephone has always been an instrument in purchasing, negotiating, marketing, and sales, but the Internet is now providing businesses with a low-cost, frictionless platform for marketing and selling products worldwide. Like business itself, electronic commerce comes in many forms. The most visible part of e-commerce is perhaps the large number of big and small online
01_4557.qxd
16
10/19/05
12:49 PM
Page 16
Implementing Value-Added Telecom Services
shops that proliferate on the Internet. But apart from business-to-consumer (B2C) commerce, the Internet also provides a space for interpersonal trade, auctions, payment services, and business to business (B2B) commercial transactions. Unlike most of the technologies treated in this book, such as messaging, location services, and VoIP, which are highly standardized areas, electronic commerce suffers from technological and market fragmentation. This has been one of the reasons that electronic commerce has not taken off as analysts projected at the end of the 1990s. Other factors have been the dot-com crisis, and the fear that fraud inspires with merchants, financial institutions, and the general public. Nevertheless, electronic commerce grows steadily and analysts believe online sales will grow at 15% annually until reaching $300 billion in 2010. Chapter 6 studies the different aspects of electronic commerce, and addresses questions such as: What electronic commerce models exist? What is needed to set up an online store? What standards exist for B2B transactions? How do Internet payment providers work? How can service providers take advantage of mobile phones? What fraud risks exist, and how can they be limited?
1.5 Nontechnical Factors Starting business as a third-party value-added service has many more sides than only the technical. Given the multidimensional nature of telecommunications, one could argue that technology is only the easiest part! Nontechnical aspects such as business plans and agreements, regulatory and legal aspects, and dimensioning can easily justify entire publications on their own. Although this book covers only technology, let us take a brief look at the other dimensions one needs take into account. 1.5.1 Business Plan Probably the most important step in setting up a business is writing a business plan. A financial institution or investor will not lend any money to an entrepreneur unless that person can show a sound business plan. Writing a business plan means identifying customers and competitors, evaluating opportunities and risks, calculating the necessary investments, and the expected return on investments. A business plan is a double-edged sword. The more optimistic, and the better the numbers look, the greater the chances of receiving funds from the bank or investors. But it is also important to be realistic and sincere about customers, sales, competitors, margins, and revenues. The taste for inflating business plans, so common in the years just before the dot-com crisis, has left many technology companies in the graveyard.
01_4557.qxd
10/19/05
12:49 PM
Page 17
Introduction
17
A key factor to take into account is the agreements with other providers. Third-party VAS providers will almost certainly have to negotiate bandwidth, airtime, or services from other service providers. It is crucial to negotiate a contract that benefits all parties involved, and there must be enough margin left for the third-party VAS provider. In the volatile telecommunications sector, having a good exit strategy is particularly important. A new application can go stale very quickly, as new technologies appear in Internet time, and in today’s globalization age, a successful business will quickly attract the attention of large international competitors, who may try either to choke or acquire the start-up. It is better to be prepared for this. There exist many good books on business plan writing, such as [2–4], while [5] specifically deals with negotiating cooperation with network operators. 1.5.2 Regulation and Legal Aspects In spite of the liberalization wave, telecommunications remains a regulated business in most countries in the world. Liberalization does not mean free-for-all, only that monopoly has made way for competition. Although there is now competition in most telecommunications administrations, it is most often regulated. This is particularly true for voice communications, whether they be prepaid or postpaid. Even service providers that do not own their own network infrastructure, for example, MVNOs, still require a license to operate in most locations. Although it is not necessarily difficult or expensive to obtain these licenses, an enterprise with ambitions to enter telecommunications will almost certainly have to consult legislation before starting business. The U.S. federal government, for example, considers any company that provides telecommunications services to the general public for a profit a common carrier, subject to regulation. Common carriers must obtain Public Utilities Commission (PUC) certification and Federal Communications Commission (FCC) licensing. They must also pay federal and state telecommunications regulatory fees and assessments such as the Universal Service Fund (USF) assessment, which is about 8% of telecommunications revenues. Many telecommunications services in addition are subject to privacy laws and other legislation. In the United States, an operator must obtain explicit permission from a subscriber before providing any customer proprietary network information (CPNI) to others. CPNI is the information an operator collects about a subscriber’s communications. It includes call time, date, duration, destination number, the long distance network chosen, plus any other information that appears on the consumer’s telephone bill. In mobile networks, location
01_4557.qxd
10/19/05
12:49 PM
18
Page 18
Implementing Value-Added Telecom Services
information is also part of the CPNI. Again, it is wise for a third-party service provider to check what kind of legislation applies prior to operation. Each country has its own telecommunications regulations, and it is therefore difficult to give any general advice, other than to consult an attorney specialized in telecommunications regulation. References [6, 7] provide material for those interested to read up on recent regulation issues. 1.5.3 Dimensioning Creating a VAS and dimensioning it are two different issues. Deploying the right infrastructure is essential: underdimensioning can lead to congestion and service outage, while overdimensioning means excessive cost and less net revenue. Dimensioning a telephony network requires dividing the network up in traffic areas, and predicting the number of call attempts, the average holding time, and their variation over time. It also means deciding on an acceptable level of congestion and blocked calls, generally referred to as the grade of service (GoS). There is abundant theory on telephony dimensioning. Traffic intensity in telephone networks is measured as the product of the number of calls per unit of time and the mean holding time for the calls. This unit of traffic flow is named erlang, after the Danish mathematician Agner Krarup Erlang (1878–1929) who developed the first theory that mathematically relates traffic, need for equipment, and GoS. Figure 1.6 shows a blocking diagram according to Erlang’s first formula. Ports 10
2%
9 8
5% 10% 20%
7
50%
6
100% Blocking
5 4 3 2 1 0
0.5
1.0
1.5
2.0
2.5
Traffic (erlang) Figure 1.6 Blocking diagram according to first Erlang formula.
3.0
3.5
01_4557.qxd
10/19/05
12:49 PM
Page 19
Introduction
19
Dimensioning not only applies to telephony but to any service. Messaging, content, location, and e-commerce services all have to be dimensioned to weigh service demand against grade of service and infrastructure investment. Although dimensioning is far from trivial, ample theory and tools are available. The standard textbook [8] explains basic traffic theory, while [9] contains specific dimensioning examples for VoIP networks and [10] provides help in analyzing and optimizing Web traffic. New entrants that need to provide carrier-grade (see footnote 3) service and do not possess detailed knowledge on traffic engineering should consider consulting a dimensioning expert. When looking for vendors and products, a new entrant best chooses a platform that scales up from entry-level service to large volumes.
1.6 How to Use This Book The remainder of this book is organized in five independent chapters, each covering a specific type of VAS: prepaid communications, messaging, content, location-based services, and electronic commerce. The order of the chapters is such that the wider-purpose communications technologies (prepaid, messaging) precede the more specific technologies that depend on them (content, location, and e-commerce). Although sections occasionally refer to material in other chapters, each chapter is self-contained and can be read on its own without having read the preceding chapters first. 1.6.1 Service Orientation This book has been written from the perspective of services, rather than architectures. The book deliberately does not focus on any specific standard or technology. Many excellent books already treat IN, Internet, location services, CAMEL, OSA-Parlay in detail, and this book will not try to duplicate them. On the other hand, this book was meant to be accessible to any professional with only a modest knowledge of telecommunications and computer technology. To make this possible, the appendices at the end of this book provide brief reference descriptions of the architectures referenced in the text. They are only summaries, and there is no claim as to their completeness, but they allow the reader to look up essential architectural concepts. For additional information, the author’s previous book, Next Generation Intelligent Networks [11], serves as a companion guide, as it treats most of the architectures in detail.
01_4557.qxd
20
10/19/05
12:49 PM
Page 20
Implementing Value-Added Telecom Services
1.6.2 Enabling Technologies and Examples There are often many ways to implement a service. In particular, OSA-Parlay provides an object-oriented alternative to protocols for controlling prepaid calls, messaging, location information, and charging. Where alternatives exist, the book identifies different implementation scenarios. Although the book mentions commercial technology as well as open standards, it does not bias any particular vendor or product. Where it applies, the book identifies open-source software. Open-source solutions are beneficial both to entry-level businesses that may not have the budget to purchase expensive commercial solutions, as well as more technology savvy enterprises that wish to build their own platforms. Each chapter contains practical examples that illustrate existing products, services, and deployment examples with references to live Web sites. These may be stories of real service providers, products, or enabling open-source software that provide the reader with information on the technologies that are actually used in the real world. The examples merely serve to illustrate. The author chose them randomly and has no relationship with the vendors or service providers cited, nor does he recommend or judge their products or services.
1.6.3 Standards and Web Links Each chapter contains a list of Web links to the standards bodies, vendors, and service providers mentioned in the text and case studies. In addition, Appendix B provides a list of standards used in this book.The standards lists are not exhaustive, as there are too many specifications and they evolve so rapidly that any snapshot would be inaccurate within a few weeks. Instead, only a set of key specifications are listed for each technology. While all care has been taken to assure that the Web links were up to date by the time this book went to press, companies do disappear, change ownership, or modify their information on the Web. Some Web links may therefore have gone stale. The Web site for this book, http://www.implementingVAS.com, reports updates in the Web links where necessary.
1.6.4 The Book’s Web Site In today’s world of rapidly evolving technologies and markets, a book on its own gets quickly outdated no matter the efforts to include the latest information at the time it goes to press.
01_4557.qxd
10/19/05
12:49 PM
Page 21
Introduction
21
This book therefore has a dedicated Web site, http://www.implementingVAS.com, where the reader will find updates, errata, new references, new standards, news, links, and other related information. The Web also serves as a forum to discuss particular issues with other readers and to contact the author. The Web site does not form part of this book itself, but is merely a complementary service on behalf of the author, to keep the reader up to date. The author maintains the Web site independently of the publisher, Artech House Publishers.
References [1]
Zwart, P., Het boek van PTT, Den Haag, the Netherlands: Posterijen, Telegrafie en Telefonie (PTT), 1938.
[2]
Arkebauer, J. B., The McGraw-Hill Guide to Writing a High-Impact Business Plan: A Proven Blueprint for First-Time Entrepreneurs, New York: McGraw-Hill, 1994.
[3]
Eglash, J., How to Write A .com Business Plan: The Internet Entrepreneur’s Guide to Everything You Need to Know About Business Plans and Financing Options, New York: McGrawHill, 2000.
[4]
Siegel, E. S., B. R. Ford, and J. M. Bornstein, The Ernst & Young Business Plan Guide, New York: Wiley, 1993.
[5]
Jaokar, A., and T. Fish, Open Gardens: The Innovator’s Guide to the Mobile Data Industry, http://www.opengardens.net, 2005.
[6]
Buckley, J., Telecommunications Regulation, London: Institution of Electrical Engineers, 2003.
[7]
Walden, I., and J. Angel, Telecommunications Law And Regulation, Oxford, England: Oxford University Press, 2005.
[8]
Freeman, R. L., Telecommunication System Engineering, 3rd ed., New York: Wiley, 1996.
[9]
Collins, D., Carrier Grade Voice over IP, New York: McGraw-Hill, 2002.
[10]
Poon, A., et al., Practical Web Traffic Analysis: Standards, Privacy, Techniques, and Results, Birmingham, U.K.: Glasshaus, 2003.
Selected Bibliography http://www.forrester.com, Forrester, technology research firm http://www.gartner.com, Gartner Group, research and consulting firm
01_4557.qxd
22
10/19/05
12:49 PM
Page 22
Implementing Value-Added Telecom Services
http://www.pulver.com, Jeff Pulver’s VoIP portal http://www.screendigest.com, Screen Digest, business intelligence and analyst firm http://www.stuffsoftware.com, software for traffic analysis and dimensioning http://www.tfinforma.com, T&F Informa, specialist information provider http://www.visiongain.com, Visiongain, specialist information provider http://www.tiaonline.org, TIA home page http://www.yankeegroup.com, Yankee Group, technology analyst and consultancy firm
02_4557.qxd
10/19/05
12:55 PM
Page 23
2 Prepaid Services Ever since the telecommunications markets have opened up to competition worldwide and voice telephony has become a commodity, telecommunications operators and service providers have been looking for so-called killer applications. There is still much debate over whether killer applications really exist, but if they do, prepaid calling is certainly one of them. Prepaid communications move over $5 billion in the United States alone, and have opened new markets that were difficult to reach with classic telephone subscriptions, like college students and migrant workers. Some people argue that prepaid is not a VAS, but rather an alternative way of paying for basic services like voice telephony and Internet access. No matter how one looks at it, prepaid communications are business. Moreover being a provider of prepaid services does not require being a telecommunications operator or owning a network. In fact, prepaid provides lucrative opportunities for third parties. Up to this point we have talked about prepaid communications in general, but there is an important difference between prepaid fixed and prepaid mobile services, both in terms of technology and business. In fixed telephony, prepaid accounts are most often used to allow long-distance calling from any public or private telephone, and are not normally associated with a particular subscriber line.1 1. Operators that provide prepaid line subscriptions do exist, as well as operators that offer prepaid long-distance calling based on preselection. But the bulk of prepaid services are line subscription independent. 23
02_4557.qxd
24
10/19/05
12:55 PM
Page 24
Implementing Value-Added Telecom Services
On the contrary, prepaid mobile accounts are tied to a SIM card, and as such are directly associated with a number and a subscription. A mobile phone is a personal device, which means that the prepaid mobile account is generally used as if it were a subscription, except that payment is in advance. The prepaid mobile also allows for incoming calls to the mobile device. Fixed and mobile prepaid are compatible to a certain extent. A user can have a prepaid calling card for low rate long distance calls from fixed to fixed telephones, and at the same time maintain a mobile phone with a prepaid subscription, for direct accessibility. The business model for prepaid services is complex, but full of opportunities for operators and third-party service providers. In this chapter we consider the implementation of fixed and mobile prepaid services separately.
2.1 Prepaid Fixed Telephony The most common form of prepaid telephony is through the use of prepaid calling cards that can be used to place prepaid calls from any phone. The prepaidcard business has been growing explosively since the mid-1990s. Some prepaid cards are offered by long-distance operators themselves, but the vast majority is offered by third parties that buy minutes wholesale from long-distance operators, and resell them through prepaid cards. The business model for prepaid fixed telephony usually involves the following actors: • The long distance operator owns the network, physically completes calls, and sells blocks of minutes to resellers at wholesale prices. • The reseller issues the calling cards, provide the access numbers, maintains the account information, and provides customer service. • The distributers and retailers sell the cards to their customers. In addition to the long-distance operator who actually completes the calls, prepaid telephony represents a business opportunity for resellers and distributers. In this chapter we concentrate on the role of the reseller, who can be any entrepreneur wishing to create a business with prepaid cards. Figure 2.1 illustrates the relationship of the reseller with the other participants. The single lines represent the sales chain, while the double lines represent the call flow. Becoming a reseller of prepaid telephony requires certain investment: • Branding, manufacturing, and distributing the calling cards; • Setting up one or more points of access and an account management system;
02_4557.qxd
10/19/05
12:55 PM
Page 25
Prepaid Services
Sells card to
Distributor
25
User
Calls access point
Sells cards through
Reseller Requests call completion Sells minutes to
Long-distance operator Figure 2.1 The relationship of reseller with other actors in prepaid calling card business.
• Setting up an agreement with a long-distance operator for the purchase of blocks of call minutes. Before considering setting up shop, be aware that the provisioning of prepaid telephony is subject to regulation and licensing in most countries. This is also true when using IP networks (including the public Internet!) for voice transport. It is important to investigate local regulation before starting your business, as penalties for offenders can be steep. There are many ways of implementing prepaid telephony. The choice of implementation model will depend on the scale (thousands or millions of users?), the underlying operator infrastructure (How to connect to its network. Circuit switching or VoIP? How is the pricing structure for call minutes?), and the level of investment (Is deploying your own equipment economically viable?). In the following sections we investigate a couple of common scenarios. 2.1.1 Basic Point of Presence The simplest configuration for a reseller of prepaid telephony is shown in Figure 2.2. In this basic scenario, the reseller installs a point of presence, an interactive voice response (IVR) system, and a prepaid application that includes a database of prepaid accounts. The point of presence is no more than a switch that accepts incoming calls and connects them to outgoing calls. It is usually connected to the telephone
02_4557.qxd
26
10/19/05
12:55 PM
Page 26
Implementing Value-Added Telecom Services
Reseller domain
Prepaid database (3) (2)
IVR
Point of presence
(1)
(4)
PSTN Figure 2.2 Basic configuration for prepaid calling cards.
network through time-division multiplexing links (E1/T1), but nowadays DSL are also used. Referring to Figure 2.2, the call procedure is as follows: 1. The user dials the access number for the prepaid calling service, and the call is routed to the reseller’s point of presence. 2. The call is first connected to an IVR system that prompts the user for the calling-card account number and the destination number. 3. The calling-card application checks the account credit in the prepaid account database. 4. If there is sufficient credit, the call is completed to its destination. The prepaid account is updated in real time, and when the credit expires the call is released. The basic configuration does not require advanced signaling connections to the telephone network, as the point of presence simply places an outgoing call to the destination number and connects the incoming to the outgoing call. There are many vendors that offer turnkey prepaid solutions like the one just described. Commercial solutions range from the simple implementation
02_4557.qxd
10/19/05
12:55 PM
Page 27
Prepaid Services
27
just discussed, to more sophisticated implementations that can connect directly to the operator’s SS7 signaling network.
Example for Section 2.1.1 CTI Labs of Karlsruhe, Germany (http://www.ctilabs.de) provides a lightweight switch that includes a prepaid application. CIT Labs’ CoolSwitch telephony switch can connect up to 24 E1 connections (up to 192 E1 connections if several switches are combined in a 19-inch rack), supports a variety of SS7 dialects, and can handle routing tables of up to 20 operators. Coolswitch is Intel based and comes in several configurations: entry level (120–240 simultaneous calls), midsize (360 simultaneous calls), and carrier class (600–1200 simultaneous calls). Prepaid telephony is one of the standard applications offered with the CoolSwitch. The service provider can manage the switch and the prepaid application remotely over the Internet. CoolSwitch can also off-load calls to the Internet or a private IP network, which makes it interesting for service providers that want to use VoIP.
2.1.2 Using Voice over IP In order to reduce costs, many prepaid telephony providers now route calls through IP networks, rather than the long-distance telephone network. Using VoIP technology, the reseller routes the call through the Internet or a private managed IP network to a gateway close to the destination line. From there the call is completed through the telephone network to its destination, but this requires only a local rather than a long-distance call. Figure 2.3 illustrates how this works. The procedure is now the following: 1. The user dials the access code for the prepaid card, and the call is routed to the point of presence. 2. The prepaid application uses an IVR to prompt the user for the account number and destination number (not shown here for simplicity) and checks the credit of the prepaid account. 3. If there is sufficient credit, then the point of presence converts voice to an IP packet stream and routes this stream to a VoIP gateway close to the destination line. The point of presence must of course be capable of connecting a public switched telephony network (PSTN) call to a VoIP session.
02_4557.qxd
10/19/05
28
12:55 PM
Page 28
Implementing Value-Added Telecom Services
Reseller domain Prepaid database (2)
Point of presence
(3)
Private IP network or public Internet
Voice over IP gateway (4) (1)
PSTN
Figure 2.3 Prepaid telephony using VoIP.
4. A local call from the gateway to the destination number completes the call. The VoIP gateway at the receiving end converts the IP packet stream back to voice. If properly set up, then the public telephony network is bypassed entirely for long-distance connections. Only two local PSTN calls are required, while the long-distance leg is routed over IP. This can result in important savings, but there is one important catch: voice quality. The VoIP gateways used in this scenario must be able to transcode voice from the public telephony network to a packet stream that can be sent over the Internet. Although telephone networks use digital voice encoding on the trunk, the resulting bit stream is not optimal for transport over IP. The standard for voice telephony encoding is A-law and m-law pulse code modulation [International Telecommunication Union–Telecommunications (ITU-T) standard G.711], which requires a 64-Kbps bit stream and is optimized for a trunk that uses time-division multiplexing. By contrast, VoIP coders/decoders are designed for cutting up the bit stream into IP packets, and work with lower bitrates,
02_4557.qxd
10/19/05
12:55 PM
Page 29
Prepaid Services
29
higher delay, and increased jitter. There are several such coder/decoder standards available, each optimized for particular network characteristics, for example, ITU standards G.726 (32 Kbps), G.728 (16 Kbps), and G.729 (8 Kbps). The choice of codec is a trade-off between the required bandwidth and speech quality.2 The voice encoding/decoding used at the point of presence obviously must match the encoding/decoding at the receiving end of the call. If the public Internet is used, then the cost for long-distance communications is negligible. It is important to keep in mind, however, that it is impossible to guarantee quality of service (QoS) over the public Internet. Still, many providers do use the public Internet in order to reduce prices to the minimum and improve competitivity.
Example for Section 2.1.2 Quicknet Technologies Inc. (QTI) of San Francisco, California, (http://www. quicknet.net), provides a global VoIP network for resellers of prepaid telephony. The reseller only needs to install the MicroTelco gateway, a PC-based application that accepts up to 16 simultaneous calls and routes them over the Internet to the MicroTelco Regional Server, using H.323 for VoIP signaling with the G723.1 codec (16 Kbps). The Regional Server handles the prepaid account management and completes the call to its destination. Resellers can manage their accounts entirely over the Internet. Quicknet maintains agreements with PSTN carriers in various countries to complete calls to any telephone. The reseller can define its preferred operators, or choose the “least cost routing” options. The Quicknet solution is particularly interesting for smaller resellers of prepaid telephony that want to set up shop with minimal investment.
2.1.3 Prepaid Telephony with Intelligent Networks The IN standard provides a more scalable way of implementing prepaid telephony, but it also requires more investment than the basic configuration of Section 2.1.1. Intelligent networks are mostly used by long-distance operators, or by 2. In international standardization, speech quality is determined by the mean opinion score [(MOS), ITU-T Standard P.800] or perceptual speech-quality measurement [(PSQM), ITUT Standard P.861]. MOS uses human judgment to rate voice quality on a scale from 1 (bad) to 5 (excellent). PSQM uses algorithms that simulate human speech perception and produces a score that can also be converted to the MOS scale.
02_4557.qxd
10/19/05
30
12:55 PM
Page 30
Implementing Value-Added Telecom Services
larger resellers that have their own infrastructure for long-distance connectivity and VAS. The principle of providing prepaid calls with IN is not that different from the basic scenario in Figure 2.2, except that the point of presence is replaced by IN functions. Figure 2.4 shows the resulting configuration. Some knowledge of the intelligent networks architecture is helpful to understand the functions of the different functions [service switching function (SSF), service control function (SCF), and service data function (SDF)]. A brief explanation of intelligent networks can be found in Appendix A.3.2, while [1] treats intelligent networks in more detail. With IN, the steps for making a prepaid call are: 1. The prepaid user calls the access number for the prepaid service. 2. The SSF recognizes the access number, triggers the prepaid service in the SCF, and waits for instructions to complete the call.
SDF (3)
SCF (2) (4) (1)
SSF
Operator domain Figure 2.4 Prepaid telephony with IN.
PSTN
02_4557.qxd
10/19/05
12:55 PM
Page 31
Prepaid Services
31
3. The SCF retrieves the prepaid account number from the user (this is not shown in the figure for simplicity and is usually done through an interactive voice response system) and checks the account credit in the SDF. 4. If there is sufficient credit, the SCF instructs the SSF to complete the call to its destination, and bills the call to the prepaid account in real time. If during the call the prepaid account credit runs out, the SCF clears the call. This looks easy enough, but how does the SCF in fact bill the call to the prepaid account? And when the credit runs out, how does it terminate the call? To understand how this works, let us take a closer look at the interaction between the SSF and SCF. Figure 2.5 provides a simplified view of the IN Application Protocol (INAP) messages that are exchanged between the SSF and SCF. Zooming into the INAP message exchange, the procedure is as follows: 1. The user dials the access number for the prepaid calling service. 2. The SSF recognizes that this is a special number, for which the collected_information trigger has been set.
SSF
(1)
(2)
SDF
collected_information (3)
(4)
SCF
Dial access number
initialDP(serviceKey,..)
Get account number and destination address (5) (6)
applyCharging(time)
Check and reserve credit Credit reserved
continue()
(7)
applyChargingReport()
Update and reserve credit
(8) (9)
releaseCall()
Figure 2.5 IN procedure for prepaid telephony.
Not enough credit
02_4557.qxd
32
10/19/05
12:55 PM
Page 32
Implementing Value-Added Telecom Services
3. The SSF sends the initialDP message to the SCF. This message informs the SCF that special call processing is needed, and carries as argument the service key (prepaid) and other parameters, such as the calling-line identifier. 4. The SCF starts the prepaid calling application and prompts the user to enter the prepaid account number and destination address. The details of this interaction, which involves an interactive voice response system, are not shown for simplicity. 5. Once the user has entered the prepaid account number and the destination address, the SCF consults the prepaid-card database in the SDF to check if there is enough credit to complete the call. If there is sufficient credit, then the SCF will lock (reserve) a certain amount of credit in the database that corresponds to a determined number of call minutes to the destination. 6. The SCF asks the SSF to set a timer for the call, using the applyCharging message. This message takes as argument the number of seconds or ticks that the call is allowed to continue. The SCF then sends the continue message to the SSF, which tells the SSF to complete the call to its destination. 7. When the indicated time has elapsed, the SSF notifies the SCF with the applyChargingReport message. 8. The SCF now charges the credit that was previously reserved under point 5, and checks if there is enough credit left in the prepaid account to continue for another time slice. If there is enough credit, then this is reserved and steps 6 through 8 are repeated. 9. If there is not enough credit to continue, the SCF instructs the SSF to release the call with the releaseCall message. So in reality what happens is that the SCF allows the call to proceed during a small time slice every time, and updates the credit every time the time slice runs out. The service provider sets the tariffs and the duration of the time slice when the prepaid service is configured. The longer the time slice, the less processing is required, because there are fewer frequent messages between SSF and SCF, and less database access. The downside of long time slices is that there is also less direct control over credit. The IN infrastructure can host several VAS, and is not specific to prepaid or any other service in particular. Many operators have deployed IN, which means they can use the same infrastructure for several VAS. With intelligent networks in place, deploying prepaid telephony only requires programming the service in the SCF and SDF.
02_4557.qxd
10/19/05
12:55 PM
Page 33
Prepaid Services
33
Does it make sense for third-party resellers to implement prepaid telephony with IN? In principle, yes. Many vendors offer scalable IN products that start from service nodes (all IN functions in one server), to distributed systems with redundancy and load balancing. This allows entry-level service providers to start with a small system and scale up as traffic increases. IN applications (including prepaid) normally migrate from smaller to larger platforms without any modifications. Some operators allow resellers to configure and manage prepaid applications hosted on their IN platform. This option does not require any investment in equipment from the reseller, and is particularly interesting for start-ups. On the downside, this also leaves the reseller with less control over call routing, service control, and pricing.
Examples for Section 2.1.3 Virtually all vendors of IN equipment now offer prepaid telephony ready for deployment on their platform. Alcatel 8612 (http://www.alcatel.com), Siemens INXpress Prepaid (http://www.siemens.com), and Teligent PrePaid (http://www.teligent.se) are examples of such products. Teligent of Nynäshamn, Sweden (http://www.teligent.se) was one of the first companies to build IN systems in the early 1990s. Over the years their P90/E intelligent networks platform has evolved to an integrated architecture for mobile, fixed, and packet data applications that is fully scalable from entry level to carrier-class configurations. Swedish operator Optimal Telecom (http://www.optimal-tele.com) uses the PrePaid application on Telligent’s P90/E platform in combination with a residential router to provide low-cost telephony anywhere in Sweden. A user can plug the residential router into any phone line, and calls will be charged automatically to the prepaid account. Other VAS that go with the prepaid account, such as the voice mailbox, are automatically accessible wherever the router is plugged in.
2.1.4 Prepaid Telephony with OSA-Parlay The previous section demonstrated that IN provide a scalable platform for prepaid telephony that also can be used for providing other services. One of the disadvantages of IN is that it requires switching infrastructure.
02_4557.qxd
34
10/19/05
12:55 PM
Page 34
Implementing Value-Added Telecom Services
Intelligent networks were standardized in the early 1990s, when incumbent operators were monopolies in most countries and VoIP was confined to laboratories. The IN standards assume the control interface between the SSF and SCF to be within the domain of the same operator, and not open to third-party service providers. This means that IN is only viable for enterprises that can afford to deploy their own transport and switching infrastructure, which can run into millions of dollars. Would it not be nice for third-party resellers to plug their prepaid application into the SSF and let the operator do the switching? This is exactly the idea behind the OSA-Parlay interface specifications, which are explained in Appendix A.3.3. The OSA-Parlay interfaces needed for third-party-controlled prepaid telephony are: 1. Framework Interface: This interface controls third-party access to the OSA-Parlay interfaces and network functions. It takes care of authentication, security, and management functions. 2. Call Control: This interface allows third-party applications to receive notifications about call events, to create, release, and manipulate calls and connections. This is the main interface needed to implement prepaid telephony with OSA-Parlay. 3. User Interaction: Through this interface an application can play announcements to the user, and get information from the user, such as dialed digits. It is technically possible to implement a prepaid telephony application without this interface, but using it enables a richer and more user-friendly interface to the caller, and therefore will be used in practice. The implementation of the prepaid telephony with OSA-Parlay is similar in structure to the IN in Figure 2.5. When the user dials the access number for the prepaid service, the application provides time slices of connection until the credit runs out or the user hangs up. The main difference is that the application is now communicating with the network through the external OSA-Parlay interface and not through the SCF–SSF interface. Figure 2.6 shows the message interchange for prepaid telephony with OSA-Parlay. OSA-Parlay is object oriented, and the basic communication mechanism is by remote method invocation. The OSA-Parlay call control interface contains the following remote object interfaces: • IpCallControlManager is the interface on the network side that provides call management operations: requesting call notifications, creating calls, and so forth.
superviseCallRes(report, used Time) release(cause) Operator domain
(6)
(7) Update and reserve credit (8) Third-party domain
Figure 2.6 Prepaid telephony with Parlay.
• IpAppCallControlManager is the callback3 interface on the client side for receiving results from invocations on the IpCallControlManager interface. • IpCall is the control interface of a particular call object, which allows operations like call routing, call release, receiving dialed digits, and setting the charging plan. • IpAppCall is the callback interface on the client side for receiving results from invocations on the IpCall interface. Any invocations on this interface are immediately forwarded to the application behind it. Any use of OSA-Parlay by a third-party application is normally preceded by authentication and discovery procedures on the framework interface. These have been omitted from Figure 2.6 for simplicity, since they are not specific to 3. OSA-Parlay uses remote method invocations in an asynchronous way. The client that invokes a method does not wait for the server to return a synchronous result, but instead receives the result in the form of a callback, a method invocation in the reverse direction. By convention, requests from client to server are suffixed by “Req” and the callbacks from server to client are suffixed by “Res.” Note that a client must implement its callback interfaces: any invocations on these interfaces are immediately forwarded to the client application.
02_4557.qxd
36
10/19/05
12:55 PM
Page 36
Implementing Value-Added Telecom Services
the prepaid-call scenario. The procedure starts at the point where the third-party service provider has logged into the operator network and is connected to the OSA-Parlay interfaces. Although the names of the messages are different, the OSA-Parlay message exchange bears strong resemblance to the IN application protocol dialogue of Figure 2.5. The OSA-Parlay procedure for third-party applications controlled prepaid calling is the following: 1. The prepaid application requests that it be notified of any calls to the access number for prepaid service. This is done by invoking the enableCallNotification operation on the IpCallControlManager interface. This operation takes as the main argument eventCriteria, a data structure that specifies the access number that triggers the notification, and the kind of notification (incoming call event: suspend call and await treatment). This operation is called only once, and is the OSA-Parlay equivalent of setting a service trigger in intelligent networks, as explained in Section 2.1.3. 2. When a user calls the access number for prepaid, the OSA-Parlay server creates a call object on the network side. The new call object notifies the prepaid application of the call, as requested previously in point 1. This is done by invoking the callEventNotify operation on the IpAppCallControlManager callback interface at the client side. The eventInfo parameter of this operation specifies the call parameters, such as the originating line and the dialed number. 3. The prepaid application now retrieves the prepaid account number and the destination number from the user. In this simplified example, the application acquires the necessary digits from the user by invoking the getMoreDialledDigits operation on the IpCall interface. OSA-Parlay does not specify precisely how the network retrieves these digits and if any prerecorded message is played to the user. The implementation is up to the network operator. An alternative, more flexible way of getting additional information from the user is through the use of the OSA-Parlay User Interaction interface (not shown in this example). This interface allows for playing announcements, prompting for digits, and even voice recognition if the appropriate equipment is installed in the network. 4. When the application has received the prepaid account number and destination number, it checks the credit and reserves a time slice, just as in the IN scenario (Figure 2.5). 5. The application requests notification from the call object when the time slice expires. This is done by invoking the superviseCallReq
02_4557.qxd
10/19/05
12:55 PM
Page 37
Prepaid Services
37
operation on the IpCall object. This operation takes as arguments the time that the call is allowed to proceed, and the treatment when this time elapses, in this case “wait for further instructions.” 6. The prepaid application then gives the go-ahead for completing the call to its destination, by invoking the routeReq operation on the call object. This operation takes as arguments the destination address (targetAddress) for the call and an indication whether any kind of response is requested (responseRequested), for example, a notification of successful completion or rejection of the call. The call object notifies the application of successful or unsuccessful completion of the call, by invoking the routeRes operation on the IpAppCall callback interface. The eventReport argument of this operation carries information about the completion of the call. 7. The IpCall object notifies the prepaid application when the time slice elapses, by invoking the superviseCallRes operation on the IpAppCall interface. The usedTime argument confirms the time elapsed, and any additional information can be given in the report argument (for example, if the user has ended the call, the used time can be less than the allowed time slice). 8. The application updates the prepaid account credit. If there is enough credit left to continue, it reserves a new time slice and repeats steps 5 through 7. If not, then the application invokes the release operation on the IpCall interface, which will force call release. If necessary, the application can indicate any reason for the release (in this case, “not enough credit”) in the cause argument. The prepaid application uses the enableCallNotification operation in step 1 to tell the network to suspend any call processing that meets the criteria specified in the eventCriteria argument, and wait for instructions from the application. The eventCriteria data structure contains the following information: • Event type: Indicates whether the notification has to be generated for an originating or terminating call attempt, and the type of treatment required. In the case of prepaid calling, the event type will be P_ORIGINATING. • Event name: Identifies the point in the call where a notification is to be sent and call processing is to be suspended. OSA-Parlay uses the same points in the call as IN. In the case of prepaid calls, the event name will be P_EVENT_GCCS_ADDRESS_COLLECTED_EVENT. • Originating address: Identifies the originating address that triggers a notification.
02_4557.qxd
38
10/19/05
12:55 PM
Page 38
Implementing Value-Added Telecom Services
• Destination address: Identifies the destination address that triggers a notification. Practically all major vendors of telecommunications equipment offer OSAParlay servers, and there are a number of smaller companies specialized in OSAParlay products. Many network operators have done pilot projects with OSA-Parlay and some have actually deployed OSA-Parlay gateways for thirdparty applications. In most cases however, these products support only interfaces for nonmission-critical network functions like messaging and user location. So far network operators have been reluctant to allow third-party call control, and the author knows of no real life deployment of prepaid telephony with OSA-Parlay to date (if you do, then the author welcomes your comments on http://www.implementingVAS.com!).
Example for Section 2.1.4 Infitel of the Netherlands (http://www.infitel.com) offers a prepaid application for Parlay-OSA that runs on their virtual network server (VNS). The VNS can connect to Infinitel’s own SCF or any other vendor’s OSA-Parlay platform. The prepaid application allows the service provider or reseller to manage prepaid accounts over the Web. The reseller can configure all prepaid service parameters, such as the tariff plan, required minimum credit, call setup fee, duration and fee for first and subsequent time intervals, and noncharged intervals for special promotions. It is possible to customize the service further using Infinitel’s graphical scripting language.
2.2 Prepaid Mobile Communications Section 2.1 showed a number of ways that third parties can provide prepaid telephony. Can we apply the same solutions to mobile telephony? Yes and no. On the one hand, one could consider prepaid as just a way of paying for communications, independent of the kind of network it is applied to. But there are important differences between fixed and mobile networks that complicate this view. Prepaid cards for fixed telephony are usually independent from line subscriptions and can be used from any public or private telephone. In fact, these cards are often targeted at customers who, for whatever reason, do not have a telephone subscription.
02_4557.qxd
10/19/05
12:55 PM
Page 39
Prepaid Services
39
On the other hand, a mobile phone is a personal device. It is not usual practice to walk up to somebody in the street and ask: “Can I use your mobile for a minute to make a call with my prepaid card?” Using a mobile telephone for anything other than emergency calls requires a SIM card that contains a subscription with a personal number. In mobile networks, prepaid accounts are generally associated with SIM cards. The regulating body in most countries allows only licensed mobile operators to distribute SIM cards. This increases the difficulty for third parties that wish to provide prepaid services to mobile subscribers. Still, let us consider how prepaid telephony is implemented in mobile networks and explore where the opportunities for third parties lie. 2.2.1 Prepaid Mobile with CAMEL The most obvious way for a network operator to implement prepaid calls is with IN, following the scheme presented in Section 2.1.3. In mobile networks this is not as trivial as it looks, unfortunately. In the fixed-network scenario of Section 2.1.3, the user dials a special access number to make prepaid calls. The call to the access number triggers the prepaid service in the operator network. In a mobile network, however, the subscription on the SIM already defines the call as being prepaid, and there is no need to dial a special access number. If the subscriber is connected to its home network, the operator will automatically detect the call as prepaid. But what happens when the subscriber roams to another network? How does the visited network recognize the prepaid subscription, and start the prepaid service in the home network? In roaming situations the serving SSF is a mobile switching center (MSC) located in the visited network and the SCF is a function in the home network. This introduces several complications: How does the home network set trigger detection points in the visited network? How does the visited network trigger the prepaid service? How are INAP messages exchanged between home and visited network? The original IN standard was not designed for this scenario. These questions prompted ETSI and 3GPP to specify CAMEL, an adaptation of IN for mobile networks with roaming, as shown in Figure 2.7. In fact, the main driver for the specification of the CAMEL standard in 3GPP and ETSI was to implement prepaid mobile telephony. The prepaid telephony scenario with CAMEL is the same as shown for IN in Figure 2.5, except that the messages between the SSF and SCF are now between networks. This looks straightforward enough, but there is one vexing question: How does the MSC of the visited network know it has to trigger the prepaid service for this subscriber? It is clearly unacceptable to set triggers for this prepaid subscription in all the networks that this subscriber could potentially visit.
02_4557.qxd
10/19/05
40
12:55 PM
Page 40
Implementing Value-Added Telecom Services
Subscriber information VLR
HLR
Trigger SCF
MSC
SDF
Response Visited network
Home network
Subscriber Figure 2.7 CAMEL: intelligent networks for mobile networks with roaming.
CAMEL solves this problem by using the standard mobility management procedures to download the trigger information to the MSC that the subscriber is connecting to. When a subscriber powers up its mobile phone, the serving MSC informs the HLR of the subscriber’s current location, and in turn the home location register (HLR) sends this subscriber’s data4 to the serving visited location register (VLR). In this location update procedure, which is part of the Mobile Application Protocol (MAP), CAMEL sends service trigger information to the VLR. One could say that CAMEL piggybacks the service triggers on the MAP messages sent to the serving MSC/VLR. What form does the trigger information take that is sent from HLR to VLR? In fact it is no more than a small data structure called CAMEL subscription information (CSI), which contains the following fields: • Trigger detection point list: This field identifies the trigger detection point to be armed in the MSC. CAMEL trigger detection points are a subset of the IN detection points. In this case it will be collected information, the same trigger detection point as in the IN implementation of Section 2.1.3. • Service control function address: This field contains the network address (in the SS7 signaling network, that is) of the SCF that will process the service. In this case, it will be the SCF that contains the prepaid application in the subscriber’s home network. • Service key: Identifies the service to be started. In this case, “prepaid.” • Default call handling: Indicates how the call should proceed if for some reason the CAMEL service cannot be started (for example, because the SCF is unreachable or overloaded). In this case, “release call.” 4. In particular, information for authentication and encryption of the voice stream.
02_4557.qxd
10/19/05
12:55 PM
Page 41
Prepaid Services
41
Thus, CAMEL implements prepaid mobile telephony much in the same way as intelligent networks, except that the roaming situation demands a slightly different way of setting the service trigger in the mobile exchange. Like intelligent networks, the CAMEL standard was originally designed for network operators, not for third-party use. CAMEL requires direct interaction with the operator’s HLR and MSC, which requires a high trust level. CAMEL provisioning across network boundaries is therefore governed by roaming agreements between operators. Is there hope for entrant third-party providers of mobile prepaid telephony? Maybe there is, because a reseller does not necessarily have to deploy a complete mobile network in order to provide CAMEL services. By far the most expensive part of a cellular network to deploy and maintain is the radio network, consisting of base stations and radio network controllers. A third party can skip the deployment of a radio network by simply buying airtime from existing operators. What is left is just the deployment of the mobile subscription database (HLR) and the CAMEL infrastructure, a fraction of the cost of a full blown mobile network. The name for companies that resell mobile communications without owning a radio network is mobile virtual network operators (MVNOs). In the next chapter, we take a closer look at how MVNOs operate.
Example for Section 2.2.1 Trident Telecom of Hong Kong (http://www.tridenttelecom.com.hk) claims to be the first full MVNO in Asia with a license for providing both second generation cellular mobile network (2G) and third generation cellular mobile network (3G) services. Founded in 2000, Trident buys airtime from Hong Kong mobile operator Sunday (http://www.sunday.com), which offers GSM 1800 service and also has a 3G license. Trident Telecom maintains its own core network, which includes an HLR, MSC, CAMEL, SCF, and billing gateway. This core network required an investment of approximately $20 million. Among the services Trident Telecom offers to its subscribers are prepaid calling, forwarding to any international number, roaming bypass, and an advanced unified messaging system (integrated SMS, e-mail, and voice mail).
2.2.2 Mobile Virtual Network Operators The most usual way for third parties to offer prepaid mobile telephony, is by becoming an MVNO. An MVNO is a reseller of airtime and long-distance
02_4557.qxd
10/19/05
12:55 PM
42
Page 42
Implementing Value-Added Telecom Services
connections, much like resellers for the fixed telephony discussed in Section 2.1.1. The difference, however, is that an MVNO distributes its own SIM cards and has to manage its own number plan. This has both advantages and disadvantages. The disadvantage is that the MVNO will need a more complex operations support system (OSS) to manage the mobile subscriptions and SIM cards, while the advantage is that the SIM card can be used as a channel for delivering VAS. A SIM card is effectively a smart card with a small memory and processor capability, and can be used to store menus, advertisements, games, and most importantly, preselection of communications settings for the mobile phone. Many MVNOs do not own any network infrastructure, but just buy airtime and call minutes from cellular mobile operators and resell those through their own SIM card. Larger MVNOs, however, maintain their own MSC, and may even have their own intelligent networks or CAMEL functions, as shown in Figure 2.8. An MVNO that has its own core network infrastructure can resell airtime from different mobile operators and is better positioned to provide roaming services to its subscribers. Using call-reverse mechanisms, these MVNOs can bypass expensive roaming charges for traveling subscribers. In Figure 2.8, a direct call from network X to network Y may involve high interconnection charges. These depend on the agreement between operators X and Y, over which the MVNO has no control whatsoever. However, if the MVNO uses call reversing to route the call through its own network, it has full control over the interconnection and roaming charges. For the subscriber, the prepaid service of an MVNO is indistinguishable from that of any mobile network operator. The subscriber will have to procure a mobile phone and a SIM card, and top up the prepaid account with a certain
CAM
GMSC
ut
Mo
bil
Mobile operator X
EL
Ro
GMSC
ity
SCF
ing
ma
na
GMSC
ge
me
nt
HLR MVNO Figure 2.8 MVNO with its own core network infrastructure.
Mobile operator Y
02_4557.qxd
10/19/05
12:55 PM
Page 43
Prepaid Services
43
amount of money. There are no special access codes to call for the prepaid service, as used in Section 2.1.1 for fixed telephony. MVNOs have been proliferating since the late 1990s, and there are now many in Europe as well as in the United States, as Table 2.1 illustrates. Some analysts argue that the rise of the MVNOs has been the product of the favorable conditions for entrants that have been created by deregulation legislation, but they question the viability of MVNOs in the long run. The sceptics argue that mobile telephony has become too much of a commodity to allow for sufficient profit margins for so many players in the market. But others point out that MVNOs are more about branding and crossmarketing than about competing on price. For example, Virgin Mobile packages branded mobile subscriptions and MTV content in a single product that targets the youth segment with considerable success. The optimists believe that brand loyalty and cross-marketing will make the MVNO business sustainable, albeit primarily for those enterprises that have already established brands and services, like Virgin. This debate is very much alive today, with analysts arguing both in favor and against the MVNO business model. The CAMEL-based MVNO model described in this section still requires the service provider to have substantial infrastructure and extensive roaming Table 2.1 U.S. Mobile Virtual Network Operators (2004) MVNO
Underlying Operator
9278 Mobile
Sprint
Air Voice Wireless
Cingular (AT&T)
Boost Mobile
Nextel
Call Plus
Cingular (AT&T)
EZ Link Plus
Cingular (AT&T)
GSR Mobile
Sprint
JusTalk
Cingular (AT&T)
Liberty Wireless
Sprint
Locus Mobile
Cingular (AT&T)
Mobile PCS
Sprint
Omni Prepaid Cellular
Verizon
Page Plus
Verizon
STI Mobile
Sprint
TracFone
Verizon/Cingular (AT&T)
U Mobile
Sprint
Virgin MobileUSA
Sprint
02_4557.qxd
44
10/19/05
12:55 PM
Page 44
Implementing Value-Added Telecom Services
agreements with mobile operators. This makes becoming a prepaid MVNO less viable for smaller enterprises. Is it also possible to skip the CAMEL infrastructure, and be a provider of the prepaid application only? In the next section we investigate if OSA-Parlay also applies in the mobile scenario.
Example for Section 2.2.2 Transatel (http://www.transatel.com) of France, founded in 2000, is an MVNO with a presence in France, Belgium, and the Netherlands. Transatel buys airtime from mobile operators in several European countries, but manages its own core network infrastructure and its own OSS. This allows the company to bypass the roaming charges that make placing and receiving mobile calls abroad so expensive. Transatel subscriptions allow the customer to select countries in which they would like to call against local charges. The subscriber receives a local mobile telephone number for each of the countries subscribed, which means that they can avoid roaming charges for incoming calls. For outgoing international calls, Transatel uses a call-reverse mechanism that is preprogrammed in the SIM card menu for the convenience of the subscriber. Transatel also resells connectivity and services to other enterprises that wish to become MVNOs, a service they describe as MVNO Enabling (MVNE).
2.2.3 Prepaid Mobile with OSA-Parlay Section 2.1.4 explained how OSA-Parlay allows third applications to be plugged into the network, by offering external interfaces to features like call control, messaging, and location. At first sight, it looks as though the OSA-Parlay solution of Figure 2.6 can be applied to wireless networks as well. Indeed, the OSAParlay standard does not restrict the use of the call control interfaces to fixed networks. It is up to the network operator to implement the functionality behind the interfaces. If we are lucky enough to find a mobile network operator that offers OSAParlay call control, then it looks as though we are in business. But there are a couple of complications: 1. Prepaid calls in mobile networks are usually not started by dialing a special access number. This is because the SIM card already identifies the subscription as being prepaid. Simply powering up the mobile phone will identify it to the network as a prepaid subscription. This
02_4557.qxd
10/19/05
12:55 PM
Page 45
Prepaid Services
45
means that we cannot use the same event criteria as in Figure 2.7 to trigger the prepaid application. 2. OSA-Parlay only provides a call-control interface to the subscriber’s home network. So what happens if subscribers roam to other networks? Is it possible to control a call in the visited network through the home network’s OSA-Parlay interface? This is not trivial! The first problem can be overcome simply by changing the event criteria. Instead of triggering with the dialed number as the main criteria, the subscriber identity can now be applied directly as trigger, since it is directly associated with a prepaid account. The roaming problem is more serious, however. The only way to allow the home network to control calls in a visited network, is by using CAMEL. This means that the operator must have a CAMEL infrastructure behind its OSAParlay interface. But this introduces a new question: How should the operator map the OSA-Parlay call-control interfaces to CAMEL? The problem lies particularly in the enableCallNotification operation, which takes as argument a list of event criteria that will generate a notification from the network to the application. When using CAMEL as the implementation behind OSA-Parlay, the effect of this operation should be the creation of CSI, which will be sent from the home network to the visited network as the subscriber roams. But as explained in Section 2.2.1, the CSI must include a service key, an identification of the service to be started. When using an OSAParlay application, there is no predefined service key, because enableCallNotification is a generic notification request for any application or service. In view of the current agreements between mobile network operators, it is unlikely that an operator will allow another operator to set some kind of “generic” trigger in its network. It is even less likely that they will grant call control to another operator if they know that there is a third-party application behind it. So, here we have the essence of the problem: it is technically possible to map the OSA-Parlay interfaces on corresponding CAMEL operations, but the agreements between operators will not allow generic call control from home to visited network. Still, it is possible to implement prepaid mobile with OSA-Parlay if calls are always routed through the home network. This option is less transparent to the subscriber, because it requires contacting the home network before calling the final destination, but it has the advantage that the service is triggered and the call is controlled entirely from the home network. There are several ways in which a prepaid call can be requested in a roaming situation: • By dialing a special access number, as in Figure 2.6; • By sending a short message to the home network, indicating the destination number;
02_4557.qxd
46
10/19/05
12:55 PM
Page 46
Implementing Value-Added Telecom Services
• By using an unstructured supplementary services data5 (USSD) connection to the home network In all three cases, the home network will reverse the call and connect it to an outgoing call to the destination number. The advantage is that the home network fully controls the call and its charges. But the disadvantage is the “tromboning” effect: the call is always set up through the home network even though the caller and callee may be in the same visited network. This can make the call very expensive. The SIM menu can be used in all three cases to make the prepaid call more transparent to the user. The third-party service provider can simply put a menu item “prepaid roaming call” in the SIM menu. Selecting this menu item will send the necessary SMS or USSD data to the home network and automatically answer the reversed call from the home network. The OSA-Parlay interfaces needed for prepaid mobile calls depend on whether one uses a special access number, short messages, or USSD to initiate the service. Table 2.2 shows which interfaces are needed in each case. Assuming the use of USSD to initiate the service, Figure 2.9 illustrates how the OSA-Parlay message dialogue unfolds for prepaid calling: 1. The subscriber requests the prepaid call by sending the prepaid account number and destination number over a USSD connection to the HLR. This is typically done from the SIM menu. 2. The HLR passes the request on to the OSA-Parlay server, which generates a reportEventNotification to the prepaid application. The third-party application has previously requested such notifications through the createNotification operation (not shown in Figure 2.9). 3. The third-party prepaid application proceeds as in Figure 2.6: verify the account credit, reserve time slice, call the superviseCallReq operation to request notification after expiration of the time slice, and call the routeReq operation to complete the call. 4. As a result, the call is routed to its destination. 5. If the destination number answers, the application instructs the MSC to reverse the call to the originating subscriber in the visited network (this is done by a second routeReq operation that is not shown in the figure).
5. USSD sets up a low bandwidth data connection to the terminal for use by applications. The mobile operator controls this data connection, which flows through the HLR.
02_4557.qxd
10/19/05
12:55 PM
Page 47
Prepaid Services
47
Table 2.2 OSA-Parlay Interfaces for the Different Service Request Mechanisms Service Request
OSA-Parlay Interface
Used For
Access number
Call control
Notification of service request; call setup
User interaction
Prompt user for prepaid account and destination number
Short message
USSD
Call control
Call setup
Generic messaging
Notification of service request, including prepaid account and destination number
Call control
Call setup
User interaction
Notification of service request, including prepaid account and destination number
The procedure is very similar in the alternative cases, when a special access number or short messages are used to request the service. The OSA-Parlay interfaces that are required in each case are slightly different, however, as Table 2.2 shows. Although this section has considered the call-reverse option for use with OSA-Parlay, it is interesting to note that these mechanisms are also used by
Third party prepaid application (3) superviseCallReq routeReq
reportEventNotification
OSA-Parlay (2)
ec (1) USSD conn MSC Visited network
(5) Call reverse
tion
HLR MSC
Home network
(4) Call to destination Figure 2.9 Mobile prepaid with roaming with Parlay, using USSD and call reverse.
02_4557.qxd
48
10/19/05
12:55 PM
Page 48
Implementing Value-Added Telecom Services
many operators with CAMEL, as an alternative to the scenario of Figure 2.7, when it is not possible to directly control the visited network MSC from the home network.
Selected Bibliography http://www.ctilabs.de, CTI labs, provider of telephone switches and IN equipment http://www.infitel.com, Infitel, provider of IN and OSA-Parlay equipment and services http://www.optimal-tele.com, Optimal Telecom, Swedish VoIP service provider http://www.phoneplusmag.com, magazine for resellers and wholesalers of telecommunications services http://www.quicknet.net, Quicknet, provider of prepaid VoIP communications http://www.teligent.se, Teligent, provider of IN equipment and services http://www.transatel.com, Transatel, a European MVNO enabler http://www.tridenttelecom.com.hk, Trident Telecom, Hong Kong–based MVNO http://www.virginmobile.com, Virgin Mobile, one of the world’s largest MVNOs
03_4557.qxd
10/19/05
12:58 PM
Page 49
3 Messaging Services Messaging is the oldest form of telecommunication. People have communicated via written letters for centuries, and the telex has allowed people to exchange written messages at the speed of light since the mid-1800s. Telephony upstaged the telex for most of the twentieth century, but eventually the computer industry revived electronic messaging. Early messaging systems were often specific to a particular computer system, and the few standards like X.400 were complex because there was no universal transport network to build on. But the Internet has simplified messaging dramatically, and has turned into the universal telecommunications application it is today. Mobile networks have been another factor in the success of electronic messaging. The SMS in GSM networks has proved to be the ideal complement for voice communications, because of its asynchronous, store and forward nature. In spite of its limited message size, mobility and universal availability (roaming) have made SMS one of the most spectacularly successful services. The more sophisticated MMS now also promises to lift the technical limitations of short messaging. Messaging has become an absolutely essential tool for business. Not only has it become the electronic alternative for surface mail, fax, and document interchange, but it has also created new channels for reaching out to customers and providing new services. In this chapter we shall study how enterprises can use electronic messaging technologies for the benefit of their business.
3.1 Electronic Mail In the 1980s, a small community of computer users started using an IP application called electronic mail (e-mail). It uses a Simple Mail Transfer Protocol 49
03_4557.qxd
50
10/19/05
12:58 PM
Page 50
Implementing Value-Added Telecom Services
(SMTP) that allows plain text messages to be sent line by line from one machine to another. Since then, e-mail has added a new dimension to interperson communications. Billions of people today have access to e-mail at very little or no cost, and use it to communicate with people thousands of miles away. In less than a decade, e-mail has evolved from small text-only messages to carriers of multimedia content of several megabytes. Electronic mail transfer over the Internet is free for the end user, and access to an electronic mailbox costs little to nothing. Many providers even provide electronic mail accounts for free. This appears to imply that there is not a lot of money to be made in messaging. Yet there are many ways for businesses to use electronic mail to reach out to customers and provide new services to them. In this section we shall explore some of the relevant technologies.
3.1.1 Mailbox Provisioning Many companies that offer online services or maintain portals, also provide email boxes to their customers. The provisioning of e-mail boxes normally does not generate any business by itself, and in many cases will even cost the company money. But there are important secondary considerations for providing this service: • Create customer binding and fidelity. A customer that has an e-mail account on a certain Web site is likely to visit the site regularly. • Know more about customers. To set up an account, the customer will have to enter certain details that will provide information about them. Although this is more polemic, some e-mail providers like Google (Gmail) even scan e-mail headers and content to determine a user’s context of interest and provide matching product offers. • Create a communication channel to customers. A customer e-mail account provides a sure address to send them messages. • Create a channel for publicity. Many Webmail applications will show publicity around the e-mail text area. This creates a push channel for publicity, whether they are a provider’s own or a third party’s paid advertisements. To understand what is needed to provision mailboxes to customers, we shall first take a look at how electronic mail is sent and retrieved over the Internet. Figure 3.1 shows the main elements of the e-mail chain. The core component of the e-mail application is the SMTP server. SMTP is a Point-to-Point Application Protocol that runs over the Transport Control
03_4557.qxd
10/19/05
12:58 PM
Page 51
Messaging Services
51
POP3 server
POP
SMTP SMTP server
Transfer mail Internet
SMTP server
e-mail Mail directory
HTTP HTTP server
HTTP server
HTTP
Figure 3.1 Mechanisms for sending and receiving electronic mail.
Protocol over IP (TCP/IP). In the simplest scenario, the sending host transfers the e-mail directly to the receiving host. An e-mail application can send mail by submitting it directly to an SMTP server, but it is also possible to send mail through Webmail applications. The two options are shown on the left-hand side of Figure 3.1. Likewise, a mail client can retrieve mail from a mailbox through the Post Office Protocol (POP), but may also use a Webmail interface to browse the mail. These options are shown on the right-hand side of Figure 3.1. Figure 3.1 shows the simplest scenario, where e-mail is transferred directly from sender to receiver. In reality SMTP servers may forward mail to other SMTP servers before they reach their destination. Figure 3.1 also does not show how SMTP interacts with the domain name system (DNS) to locate the destination host, based on the mail address. So what does an enterprise need in order to offer Webmail accounts to its customers? The main components are: • An SMTP server capable of sending and receiving e-mail, and a message store; • A Hypertext Transfer Protocol (HTTP) server that will support dynamic Hypertext Markup Language (HTML) pages, and in particular the Webmail program selected in the previous bullet [which can be based on Common Gateway Interface (CGI), Hypertext Preprocessor (PHP), Active Server Page (ASP), or any other dynamic HTML technology]; • A Webmail application that will manage mailboxes and generate HTML pages dynamically to access them.
03_4557.qxd
52
10/19/05
12:58 PM
Page 52
Implementing Value-Added Telecom Services
As in the case of Web hosting, there are also many Internet providers that allow reselling of Webmail accounts for a small fee, which saves the effort of providing the servers yourself.
Examples for Section 3.1.1 Horde Internet Messaging Program (http://www.horde.org/imp) is an opensource Web client. It is based on PHP and can be integrated easily in dynamic portals and Web sites. Neomail (http://www.neomail.org) is another free Web-based e-mail client. Neomail can interact directly with mail spool directories and does not need a POP3 or Internet Message Access Protocol (IMAP) server to retrieve mail. SendMail (http://www.sendmail.org) is one of the best known open-source SMTP servers.
3.1.2 Newsletters and E-Mail Publicity One of the most common ways for businesses to reach out to customers is by providing (free) e-mail newsletters. There are several advantages to providing email newsletters: • Access to the customer: Although the trend today is to ask for less personal information so as to lower the barrier for subscribing to a newsletter, it does at least provide a valid e-mail address through which to reach a (potential) customer. • Publicity channel: Newsletters provide a way to inform customers of special offers, new products, and so forth. • Instantaneous delivery, low cost: E-mail newsletters do not require any printing or shipping, and are delivered almost instantaneously to their destination. • Personalization: Electronic newsletters can easily be personalized according to each customer’s preferences In its most basic form, an e-mail newsletter does not require more than the content itself and a mailing list to send it to. The mailing list normally consists of clients that have previously registered for the newsletter on the company’s Web site. The newsletter content is usually authored in plain text, HTML, Portable Document Format (PDF), or another standard format that can be read by most
03_4557.qxd
10/19/05
12:58 PM
Page 53
Messaging Services
53
e-mail clients and browsers. In general, the simpler formats (for example, plain text) are graphically less attractive, but can be read by more mail clients, even the oldest ones. Some businesses provide personalized newsletters. This requires a more elaborate database, which also records the interests and preferences of each customer, and a program that can build and send personalized newsletters for each database entry. There is a thin line between (subscribed) newsletters and e-mail marketing campaigns. Note that we explicitly exclude unsolicited mail (spam) here; we are only talking about targeted marketing messages to registered customers. Spam is a different matter that we will deal with in Section 3.1.4. What distinguishes e-mail marketing from simple newsletters is the need for tracking responses from customers. Newsletters usually do not generate responses, but in the case of publicity by e-mail, a company may be interested to know how many of its publicity messages are actually read, how many of them lead to visits to the company Web site, and how many lead to sales. There are several companies that offer complete solutions for personalizing and tracking e-mail campaigns. Figure 3.2 shows how e-mail tracking works in four steps: 1. The sender composes a message in HTML that contains a link to a 1-pixel graphics file on a HTTP server of the tracking service. If the
Log file (3) (4)
HTTP server
1-pixel graphics file (2)
e-mail MIME encoded HTML content
(1)
Internet Sender Figure 3.2 E-mail tracking.
Receiver
03_4557.qxd
54
10/19/05
12:58 PM
Page 54
Implementing Value-Added Telecom Services
original mail was made in HTTP, all that is needed is adding a simple line of the form . 2. When the receiver opens the mail, the mail client automatically interprets the HTML contents.1 This will result in a HTTP GET request to be sent for the dummy graphics file. The file contains only 1 pixel and is not visible to the receiver. 3. The HTTP server logs this HTTP GET event in the log file. The logfile entry includes the exact time of the request, but also the requesting machine’s identity and often additional information, such as operating system and browser. 4. The sender consults the information in the log file to find out when the mail was read, and from where. In many cases, the machine’s domain or IP address can pinpoint the geographical region or even the organization from where the request was made. Note that this technique will allow e-mails to be tracked even as they are forwarded, because steps 2 and 3 repeat every time another client opens and reads the mail. This can provide extremely interesting information about how a piece of mail propagates through the Internet. If instead of a direct reference to a 1-pixel graphics file, one uses PHP, CGI, Java Server Page (JSP), or ASP, it is even possible to send more information to the HTTP server, such as identification of the e-mail and its original destination. It is also possible to send a cookie with the 1-pixel graphics file, which allows for correlation with later clicks to the server. The addition of the invisible link to the 1-pixel graphics file is usually done automatically, either in the sending e-mail application, or by routing the email through a provider of tracking services, which will add this information to the mail. Note that the receiver of the e-mail may not be aware that the mail is being tracked. This raises certain privacy concerns, although in practice it is difficult to legally prevent this. From Figure 3.2, it is clear that it is relatively easy to protect oneself from e-mail tracking by switching off automatic HTML interpretation, or by disabling images in HTML.
1. Most mail clients automatically interpret HTML content, and the more modern ones in fact don’t even let the user turn off this feature. However, most mail clients let the user block remote images, i.e. images that originate from a different domain than the mail itself.
03_4557.qxd
10/19/05
12:58 PM
Page 55
Messaging Services
55
Example for Section 3.1.2 Inxmail Professional (http://www.inxmail.com) by Inxmail, Freiburg, Germany, is a program that allows sending personalized newsletters and e-mail publicity to large numbers of recipients, but also to manage responses, track mails, and build personalized follow-up mail sequences. Blinker (http://www.blinker.nl, Web site unfortunately only in Dutch) of Zoetermeer, the Netherlands, offers a program called MailPlus, which allows a company to build targeted e-mail marketing campaigns, analyze the responses, and follow up on them.
3.1.3 E-Mail Notification Services The use of e-mail is a powerful new channel for businesses to provide instant notifications to their customers. Whether they be new product offers, stock price notifications, reminders, news flashes, e-mail allows any notification to be sent almost instantaneously to any number of recipients. The difference between e-mail notification and newsletters is that notifications are generally individual and sent in response to a specific event, while newsletters and e-mail publicity are sent periodically and are usually targeted at a wider audience. E-mail notifications are usually generated by an application, rather than typed and sent individually by a person. The application that generates the email notifications must have access to an e-mail server through a set of application programming interfaces (APIs), as is illustrated in Figure 3.3.
Many commercial and freeware e-mail servers exist, and two open APIs are widely used today: 1. MAPI (messaging API; http://msdn.microsoft.com) was originally designed by Microsoft as a library of functions to access the Exchange mail server. MAPI consists of functions written in C, and is available as a dynamic link library (DLL). Some of the prominent MAPI functions are SendMail, ReadMail, DeleteMail, SaveMail, Logon, and Logoff. There are several third-party mail applications that also use MAPI. 2. JavaMail API (http://java.sun.com/products/javamail) is SUN’s e-mail API for Java. It defines classes for the mail session, the mail store, the mail folder, and the message, with their respective functions. The message class allows the construction of messages with MIME attachments. JavaMail is supported by a large number of third parties and opensource mail servers, among them the Java Apache Mail Enterprise Server (JAMES). There are also many proprietary mail APIs, which come with specific mail applications.
Examples for Section 3.1.3 Phonotics (http://www.phonotics.com) of Fort Lauderdale, Florida, provides the Alert Engine, a versatile program that can build and send e-mail alerts from a file, but also from information sources on the Web, such as news, stock exchange, antivirus, and many other types of sites. KVT Software (http://www.kvtsoftware.com) of Russia provides a shareware program NotificationMail that sends e-mails from a file. It is mostly intended for administrators that monitor servers or processes, but can be used to send any file based information.
3.1.4 E-Mail Viruses and Spam Until the late 1990s, netiquette (net etiquette) had prevented the self-regulating Internet users community from using e-mail for unsolicited publicity. In hindsight, it is surprising that e-mail lasted for so long without commercial pollution. But eventually, the number of e-mail users reached critical numbers and commercial interests simply outgrew nettiquete and good behavior. Unsolicited
03_4557.qxd
10/19/05
12:58 PM
Page 57
Messaging Services
57
e-mail publicity, or spam as it is commonly known, has grown to worldwide proportions and is now part of everyday reality. Spam goes by various more official names, the most commonly used are unsolicited bulk e-mail (UBE) and unsolicited commercial e-mail (UCE). Most Internet service providers prohibit sending both UBE and UCE in their terms of use, and they will close down offenders as soon as they are detected or denounced. But in practice spamming is difficult to avoid, since spammers use false identities, frequently change them, and use hit-and-run tactics. By the time an ISP closes down an offender, they have already gone. Some ISPs in dubious legislations even specialize in UBE and UCE. Spam relies on two basic conditions: 1. Near zero cost: Any simple desktop computer connected to the Internet can send thousands of messages to any destination in the world. Anybody with a (free) e-mail account can spam. And if the ISP does not allow bulk e-mail sending, then there are many dedicated service providers more than happy to do it at low cost. 2. Brute force: Many spam messages bounce, and those that reach their destination often get thrown away without being read. Even if only 0.01% of messages generate a sale, however, this is still good business, if the volume of sent messages runs in the hundreds of thousands or millions. The main requisite for effective spam is having a very large database of email addresses. There are several ways to obtain a list of hundreds of thousands of e-mail addresses: • Use bots and crawlers to scoop e-mail addresses from Web pages and mail servers on the Internet. These bots and crawlers work in much the same way that search engines gather information, except that they only look for e-mail addresses. Two of the main sources for e-mail addresses are Usenet newsgroups, and mailto: fields in Web pages. • Send to public mailing lists that are sure to reach thousands of users. In this case, the sender does not even have to manage the mailing list itself. Many organizations will try to stop spam to their mailing lists, but in practice this spam is difficult to block if the sender has concealed its identity and intentions well enough. • Generate e-mail addresses randomly and automatically. This will result in many invalid addresses, but if one generates literally millions, and uses some intelligence (common names, birth dates, and so forth), at least a certain percentage is likely to be valid.
03_4557.qxd
58
10/19/05
12:58 PM
Page 58
Implementing Value-Added Telecom Services
• Buy mailing lists from third parties. There are many companies that specialize in creating and maintaining e-mail lists, both for legitimate marketing purposes and for illegal spam. In general, the more targeted the list, the more expensive. Many of the companies that maintain mailing lists will also do the actual sending, all at a price, of course. To send publicity mail requires access to a high-speed mail server that can send thousands of mails per minute, and an ISP that allows bulk e-mailing. Software also exists that will automatically analyze responses and track the e-mail that has been sent out. Although viruses are out of the scope of this book, it is interesting to note that some viruses have been explicitly designed to forward spam. This is usually done by worms sent in the attachment of e-mails with cryptic titles like “Hi” or “Your document.” When the curious user opens the attachment, the worm executes, acquires addresses from the user’s address book, and installs a hidden SMTP server on the machine. The user’s machine is now converted into an e-mail relay that will multiply incoming spam and send it to the user’s contacts. The author of this book by no means advocates spam, and is probably just as annoyed by it as you are, but this does not mean we should treat it as taboo. Spam exists, and looking at it from a purely analytical point of view, it apparently pays off or it would just not exist. In this section we just considered some of the technological aspects of spam without trying to judge whether it is good or bad.
Examples for Section 3.1.4 Contentsmartz (http://www.contentsmartz.com) of New York provides a complete software suite for e-mail publicity. Their products include software for crawling and extracting e-mail addresses from Web sites, an e-mail list manager, and also high-speed e-mail servers with reporting capabilities. Victims of spam can visit http://spam.abuse.net or http://abuse.net, which are experimental sites for informing network administrators about spam and dealing with the problem. Note that they are not spam blocking services in themselves, but are mainly networks for keeping the Internet community alerted on spam and Net abuse. There are also commercial spam blocking and reporting services, like http://www.spamcop.com.
03_4557.qxd
10/19/05
12:58 PM
Page 59
Messaging Services
59
3.2 Short Message Service (SMS) The SMS is one of the most remarkably successful mobile services. The standardization of SMS in the late 1980s was not a case of serendipity, as is sometimes believed. The creators of the standard did envision it as a potentially interesting service for GSM users from the outset, they just did not think it would be as successful as it is today. SMS was originally specified as an add-on service for GSM, but clearly of less importance than the GSM fax and data services. Reality completely turned things upside down, and made SMS the most important nonvoice service for GSM. Short messages are routed in the fixed network as MAP signaling messages and delivered on signaling channels on the radio interface. The reason for choosing MAP for routing short messages, as opposed to a dedicated data network, is that some of the new mobile operators simply had no data network infrastructure at the time. This choice proved to be crucial for the success of SMS, as MAP guarantees complete SMS interoperability between all GSM operators. The Transactional Capabilities Application Part (TCAP)/MAP protocol, however, also imposed a maximum message length of 160 characters. The success of the SMS and its limited message size are two faces of the same coin. Another key to the success of SMS is its store-forward feature. You cannot set up a call to a disconnected mobile phone, but you can send a message to it. The message is stored until the mobile attaches to the network. This nonsynchronous communication proved to be a very valuable complement to the synchronous voice telephony service. The GSM network, however, did not foresee store-forward functionality, and so the notion of a short message service center (SMSC) had to be added in the standards. SMS is one of the very few telecommunications services that has not experienced a sharp decline in price. SMS is an expensive service if one considers the price per byte transported. Short messaging is widely used from mobile to mobile and for interperson communications, but it is also an extremely interesting enabler for third-party services. In this section we concentrate on the B2C aspect of SMS. 3.2.1 Sending and Receiving SMS from Applications Most B2C services require that an application has to either receive and process an incoming SMS from a user (for example, a vote), or send an SMS to a user (for example, an alert), or both (for example, a request for information). There are two ways that an application can send and receive short messages: over the air interface, or via the SMSC. These two alternatives are illustrated in Figures 3.4 and 3.5, respectively.
Application sends and receives SMS via the phone API or PC GSM card
Mobile network
Figure 3.4 Sending and receiving SMS via the air interface. Application sends and receives SMS via SMSC protocol
Internet
SMS is routed to/from destination
SMSC
Mobile network
SMSC stores/forwards Figure 3.5 Sending and receiving SMS via the SMSC.
When using the air interface to send and receive short messages, the application server must have a GSM card, or be connected to a mobile terminal with a valid subscription (SIM). The application uses the mobile phone’s or GSM card’s API to send and receive short messages. The air interface imposes a strict limit on the capacity to send and receive short messages, and the price paid for each message sent is set by the GSM subscription. This option is therefore not suitable for sending short messages in bulk. To send and receive messages through an SMSC requires an agreement with the mobile network operator. Several protocols are in use for connecting to an SMSC. They have similar functionality and most of them work over TCP/IP as well as X.25 and other data networks, but they are incompatible. ETSI recognizes four protocols that are used in the industry:
03_4557.qxd
10/19/05
12:58 PM
Page 61
Messaging Services
61
• Short Message Protocol (SMPP) was developed by Logica before its merger with CMG, and is still one of the most important de facto standards for interfacing with SMSCs. • Universal Computer Protocol/External Machine Interface (UCP/EMI) was supported by CMG equipment, and continues being used by LogicaCMG. • Computer Interface to Message Distribution (CIMD) is supported by Nokia short message gateways. • SMS-2000 was supported by SEMA SMSCs, but appears to be less in use since the acquisition of SEMA by ATOS Origin. Many SMSCs support multiple protocols, in some cases even all four, and sometimes they offer standard HTTP as an alternative protocol for sending and receiving messages. If connecting directly to a mobile operator’s SMSC is not an option, then there are also third-party companies that offer SMS gateways accessible through the Internet. These gateways allow SMS to be sent and received via email, HTTP GET requests, or Web forms. They make integration with applications much easier and eliminate the need for establishing an agreement or taking a subscription with a mobile network operator. Since these service providers often maintain agreements with multiple mobile network operators, they can offer competitive SMS rates to and from many networks, even internationally.
Examples for Section 3.2.1 The SMS Forum (http://smsforum.net/) provides resources for SMS application development. The site offers the latest version of SMPP for download, and provides links to open APIs for SMPP-based development. WinSMS (http://www.winsms.com) by GPA Technology is a Windowsbased application for sending and receiving SMS through a GSM card or mobile phone attached to a PC. The WinSMS SMS Gateway works with any GSM phone or card that conforms to the ETSI 07.05 and 03.40 standards. NowSMS (http://www.nowsms.com) by Now Wireless Limited of London, United Kingdom, is a truly universal SMS gateway that can send and receive short messages both through a GSM card or phone, and through an SMSC. It supports all standard protocols. Cygnet Internet Services of London, United Kingdom, is a service provider that offers the Kapow! (http://www.kapow.co.uk) SMS gateway. Kapow! allows sending and receiving SMS via HTTP, Web forms, and standard e-mail.
03_4557.qxd
10/19/05
62
12:58 PM
Page 62
Implementing Value-Added Telecom Services
3.2.2 Premium Rate SMS The previous section described how applications can send and receive short messages. There are infinitely many ways that businesses can use short messages to deliver VAS to their customers. But the bottom-line question is how to make money from short-message-based services. The most common way to charge the user for short messages is by premium rate SMS services. Mobile network operators associate premium-rate billing with special short phone numbers, called shortcodes. Each shortcode has a fixed premium-rate charge. A third-party service or content provider can rent an entire shortcode from the operator, but it is also possible to share shortcodes with others. In the case of a shared shortcode, a unique keyword distinguishes the messages for each customer. All that the mobile network operator does is forward the messages to the respective customer by e-mail, or by sending an HTTP GET or POST request to a customer-defined uniform resource locator (URL). The mobile network operator shares the premium rate SMS revenues with the third-party service provider. Premium rate SMS and shortcodes can be used in two different ways: 1. Mobile originated: The user that sends a short message to the shortcode pays for the communication. 2. Mobile terminated: The user that receives information by SMS from the shortcode pays for the communication. 4422 weather Subscriber sends SMS to shortcode
Mobile network
SMSC notifies third-party application by e-mail or HTTP
SMSC
Internet
Application sends back an SMS with the requested content and the receiving subscriber pays the premium-rate charge
Figure 3.6 Premium-rate reverse billing with shortcodes.
03_4557.qxd
10/19/05
12:58 PM
Page 63
Messaging Services
63
Figure 3.6 illustrates the second option, in which the operator reverse charges short messages sent from a shortcode to a customer. Many mobile network operators only support mobile-terminated premiumrate SMS, because mobile-originated premium-rate billing can be implemented indirectly by it. When implementing mobile-originated by mobile-terminated premium-rate SMS, the user does not pay a premium rate for the outgoing message, but for an acknowledgment message that comes back from the network. The acknowledgment message does not necessarily contain any significant content, other than saying “thank you for using this service,” or similar. Nevertheless, it is the reverse charge on the acknowledgment message that makes the user pay for the service. There are many applications for mobile-originated and mobile-terminated premium rate SMS. Table 3.1 shows just a tiny sample. Table 3.1 Mobile-Originated and Mobile-Terminated Premium-Rate SMS Examples Mobile Originated
Mobile Terminated
Voting for television or radio programs
Ring tones, logos, games, other push content
Sending song requests to radio stations
News and stock quotes
Contests and lotteries
Answers to general questions
Examples for Section 3.2.2 The 82ask (http://www.82ask.com) service by Re5ult (http://www.re5ult.com) of London, United Kingdom, will answer any question on any subject by SMS. Customers only have to type any question in an SMS to shortcode 82275 in the United Kingdom, and the return message with the answer is reverse billed to the customer. 82ask also lets its customers win credits by becoming question answering experts themselves. Simply typing “ring tones” in one of the search engines on the Internet will return a long list of providers that sell ring tones and other content via premiumrate SMS. Some examples are http://uk.yourmobile.com and http://www.getringtones.com.
03_4557.qxd
64
10/19/05
12:58 PM
Page 64
Implementing Value-Added Telecom Services
3.2.3 Alerting Services Apart from person-to-person messaging and content delivery, SMS is also used for automatic alerting services. Alerts are usually application-generated short textual messages that contain information that a subscriber has requested previously. Alerts can be periodical (for example, traffic warnings), or once-only (for example, notifying a subscriber of the automatic sale of an amount of stock against a certain price). Alerts can be free, but can also be reverse billed at a premium rate, as discussed in the previous section. There are several ways that users can subscribe to alerts: by sending an SMS to a shortcode, via a Web site on the Internet, by calling a voice response system or a call center. An application can send SMS alerts in any of the ways explained in Section 3.2.1, via the air interface, or by direct connection to an SMSC. Many SMS alert services are active today, some of them premium rate, others free. The most frequent uses of SMS alerts are for stock price alerts, news flashes of all kinds, and weather alerts, but there are also many other original applications: • Pharmaceutical companies inform their customers of the need to repeat vaccinations after they have had an initial one. • Schools use SMS to inform parents of the absence of their children in class. This allows parents to act immediately if their children skip class, and has proved to dramatically improve school attendance. • Many Web sites now allow visitors to receive SMS alerts when there is a significant change to the site, so they can revisit to check out the news. Unfortunately some companies use premium-rate SMS alerts to provide expensive nonsense services to unsuspecting users. The scam works like this: the bogus service provider offers some attractive content (a ring tone or a logo) that the users can request by sending an SMS to a shortcode. The service provider indeed sends the requested content, but the fine print says that by sending a mail to this shortcode, the user subscribes to periodic SMS alerts at an expensive premium rate. From then on the victim starts receiving daily, or even hourly, alerts that often contain information of little value or are just plain publicity, but that cost several dollars per message. The fine print also says how to unsubscribe from the bogus alert service, but this is carefully disguised and far from straightforward. When the subscriber eventually finds out what happened, and worked out how to unsubscribe, he or she may already have been billed tens of dollars. The vic-
03_4557.qxd
10/19/05
12:58 PM
Page 65
Messaging Services
65
tims are often children and elderly people, and this practice is difficult to curb legally, especially if the service providers are in dubious jurisdictions.
Examples for Section 3.2.3 Goldenbytes (http://www.goldenbytes.nl) of The Hague, the Netherlands, is the creator of several original SMS-based alerting services. Among these are the school attendance alerts and the citizen alert services, both deployed in The Netherlands. RAC of Western Australia (http://rac.com.au) provides premium-rate SMS alerts for the lowest petrol rates around Perth.
3.2.4 Cell Broadcast Service (CBS) CBS consists of sending a short text message to all mobile phones connected to a specific radio cell. The format of a cell broadcast message is similar to that of a short message, in that it is very short and in plain text, but the service is very different. Cell broadcast does not, like SMS, deliver messages to specific subscribers. It is something inbetween broadcasting and messaging. Although essentially a different service from SMS, the CBS is sometimes also called SMS cell broadcast (SMS-CB). To avoid confusion with SMS, which is really a different service, we shall avoid the SMS-CB acronym in this book. Cell broadcast also exists in 3G networks, where it goes by the name of service area broadcast (SAB). Basic CBS messages are plain text, like short messages, but their format is slightly different. A cell broadcast contains a maximum of 93 characters, and it is possible to concatenate up to 15 messages, called pages, to form a larger message. The latest 3GPP specifications now also allow sending audio and graphics (ring tones, wallpapers, logos, and so forth) in cell broadcast messages. Cell broadcast messages are not sent to a specific mobile, and are unconfirmed, which makes them suitable for anonymous information. The operator can associate a message class with each cell broadcast message, which allows subscribers to tune into the information they wish to receive and block unwanted publicity (spam). This is very similar to the channel concept for push content discussed in Section 4.5. CBS is mostly used for pushing location- or context-sensitive information to users. In the vicinity of a shopping mall, for example, it can be used to push
03_4557.qxd
66
10/19/05
12:58 PM
Page 66
Implementing Value-Added Telecom Services
advertisements or special offers to subscribers. Some municipalities also use it to warn subscribers in a specific area about emergencies. But it is also possible to send cell broadcast messages to a wider area of base stations, turning it into more of a medium for push content. Cell broadcast messages are submitted via a cell broadcast center (CBC), which forwards it to the specified base-station controllers. The base station broadcasts the messages on a special GSM channel and repeats them cyclically for a duration specified by the network operator. Most mobile phones currently on the market can receive cell broadcast messages, though older models may be able to display only one channel at the time, or not receive cell broadcasts at all. Nevertheless, at the time of writing this book, the potential of cell broadcast for generating added value does not yet seem to have caught on with mobile operators and the public. The governments of some countries, such as The Netherlands, claim a certain percentage of cell broadcast capacity to be available permanently for emergency alerts.
Example for Section 3.2.4 Celltick (http://www.celltick.com) of London, United Kingdom, uses cell broadcast to create an interactive broadcast medium for mobile operators. Their platform aggregates content, organizes it in channels, and sends it to a mobile operator’s subscribers through the CBC. Each message contains an embedded menu that allows the user to send back an SMS, MMS, or to open a wireless application protocol (WAP) page from a received cell broadcast message. The Celltick system generates revenue through these clickthroughs, which can be to premium-rate SMS shortcodes or WAP content. Several operators have deployed Celltick’s platform.
3.3 Multimedia Messaging Service As SMS became popular in the late 1990s, its limitations also became obvious. The maximum of 160 characters makes SMS suitable for exchanging short text messages and small binary files, but not for graphics, photos, video, and audio. This prompted the 3GPP to standardize a new, more general messaging service for mobile networks that can handle larger messages and more content formats. The first MMS standard was published at the beginning of 2000, and most mobile operators have now deployed this service.
03_4557.qxd
10/19/05
12:58 PM
Page 67
Messaging Services
67
3.3.1 The MMS Standard The MMS specifications are not part of the GSM standard like the SMS specifications are. They form a separate standard that is independent of the underlying mobile network. MMS can be used with GSM, General Packet Radio System (GPRS), code division multiple access (CDMA), and 3G networks alike. MMS is based on the store-forward principle, just like SMS, but the messages are more complex and can consist of several parts that are sent separately and reassembled in the receiving terminal. The MMS standard only prescribes how multimedia messages are assembled, stored, and forwarded, but not how they are transported over the mobile network. This means that there are several possible implementations of the MMS standard. Most networks use existing WAP protocols to transfer the multimedia messages, but it is equally possible to use plain TCP/IP if the underlying mobile network infrastructure supports it (for example, in i-mode or 3G networks). The MMS standard is quite open, as it does not strictly impose any media format or maximum message size. In practice, this gives operators many interoperability headaches, since not all mobile phones and networks support the same formats. 3GPP does recommend a series of media formats to be supported by MMS clients, as shown in Table 3.2. To cope with incompatible media, service providers use transcoders that translate between message formats. A transcoder can, for example, translate a bitmap (BMP) file to a JPEG file or resize a JPEG picture to fit the network’s maximum supported message size. Table 3.2 MMS Media Formats as Recommended by 3GPP Media Type
Recommended Formats
Text
Unicode Transformation Format 8-bit (UTF-8)
Graphics
Scalable Vector Graphics (SVG)
Images
Graphics Interchange Format (GIF), Joint Photography Expert Group (JPEG), Portable Network Graphics (PNG)
Audio
Advanced Audio Coding–Low Complexity (AAC-LC)
Synthetic audio
Scalable Polyphony Musical Instrument Digital Interface (SP-MIDI)
Voice
Adaptive Multirate (AMR)
Video
H.263, Moving Pictures Expert Group 4-bit (MPEG-4)
Multimedia synchronization
OMA SMIL, 3GPP SMIL
03_4557.qxd
68
10/19/05
12:58 PM
Page 68
Implementing Value-Added Telecom Services
Service providers and handset manufacturers also try to agree on maximum message sizes. The typically supported maximum is 100 kb, although this figure is being revised as handsets and networks with higher capacity become available. A 100-kb message will carry a video clip of approximately 30 seconds for a small screen. In spite of the interoperability problems that still exist, MMS is becoming quite popular, especially for pushing content (ring tones, graphics, music, video) to mobile subscribers. 3.3.2 MMS Interfaces The MMS architecture is relatively simple, and consists of two main elements: 1. The MMS user agent is the software in the mobile phone that takes care of creating, sending, receiving, and reassembling multimedia messages. It figures that an MMS client is a relatively complex piece of software that will only be available on the more sophisticated phones. 2. The MMS relay-server is the network element that stores and forwards multimedia messages in the network. Within the relay-server the standard distinguishes the functionality of the relay, which takes care of message routing, and the server, which takes care of message storage and processing. In practice, however, these two functions are almost always combined in one server. The MMS standard also defines the protocols between the different network elements, which are numbered MM1, MM2, and so on. These are all application-level protocols, in other words, the underlying transport protocols are transparent to MMS. Figure 3.7 provides a simplified view of the MMS network elements and the protocols between them, as defined by 3GPP. As the figure shows, the MMS protocols also allow the exchange of messages with external servers, such as e-mail, fax, and voice mail servers, through the MM3 protocol. Sending and receiving MMS from third-party applications goes pretty much along the same lines as for SMS, though the interfaces are, of course, different. An application can send MMS messages either through a mobile phone with a valid subscription, or by connecting to an MMS relay server.
Examples for Section 3.3.2 NowSMS (http://www.nowsms.com) by Now Wireless Limited of London, United Kingdom, already mentioned in Section 3.2.1, is also a complete MMS
03_4557.qxd
10/19/05
12:58 PM
Page 69
Messaging Services
69
MMS Server MM2
HLR MMS user agent
Other servers
MM5
MM3
MMS relay-server
Message store
MMS Relay
MM1
MM4 MMS relay-server
Figure 3.7 Multimedia messaging service interfaces.
platform. It can act both as an MMS relay-server and as an MMS user agent, and can connect to an operator’s MMS server via the MM1 or MM4 interface. Mozat of Singapore (http://www.mozat.com) provides M2U, a solution that consists of a GPRS modem plus software that allows two-way MMS and SMS communications from a Windows PC. It contains a user friendly application for assembling multimedia messages from graphics, audio, and video files on PC. The Anny Way MMS server of Materna, Dortmund, Germany (http:// www.annyway.de), allows companies to send and receive messages to and from any network in the world. Companies can send and receive multimedia messages through the server via standard e-mail, File Transfer Protocol (FTP), or Simple Object Access Protocol (SOAP), which allows for easy integration with backoffice applications. Anny Way supports high-speed bulk messaging and provides tracking and statistics for messages sent and received.
3.4 Instant Messaging Early computer systems allowed its users to send small text messages from one terminal to another, where it would simply pop up on the screen rather than land in a user’s mailbox. At the time, this was probably never thought of as anything more than a means of occasionally sending quick messages like “let’s go to
03_4557.qxd
70
10/19/05
12:58 PM
Page 70
Implementing Value-Added Telecom Services
lunch” between users on the time-sharing system. But the Internet added a global dimension to direct interpersonal messaging. In the beginning of the 1990s the Internet Engineering Task Force (IETF) specified a new way of group communications over the Internet, called Internet relay chat (IRC). This application is very different from e-mail in that it allows multiple users to exchange messages instantaneously as if they were in a conversation. IRC requires a server to run sessions that a user can connect to. The chat model has several inconveniences if used for direct communication between two people. Since chat is servercentric, it is the server and the session that are persistent, not the user name. Users simply come and go in a chat session, and may use different identities in different sessions. This makes it difficult to address an individual user not connected to a session. Moreover the intermediate server is obsolete in the case of two-person communication, since the two computers could simply exchange messages directly! This eventually prompted the definition of a new form of direct, online, interpersonal communications that we now know as instant messaging. Although the line between instant messaging and chat may appear blurry at first sight, there are some important differences: • Instant messaging users have unchanging identities, while chat users’ identities may only exist during participation in a single session. • Instant messages can be sent directly from peer to peer, and do not require an intermediate server like IRC. • Instant messaging applications usually also provide presence and availability information about users. Instant messaging is essentially different from e-mail, both technically and conceptually. E-mail is based on the store and forward principle. It is possible to send e-mail to off-line users; in this case, the mail is stored until the user comes online and retrieves it. Instant messaging resembles a real-time conversation, with messages going back and forth instantaneously. It is only possible to exchange instant messages with online users.
3.4.1 Instant Messaging Standards Different competitors have evolved instant messaging in different ways, leading to several incompatible instant-messaging applications. Some of the more famous instant-messaging programs are ICQ, MSN Messenger, Netscape Messenger, and Yahoo Messenger. Even a client that is compatible with multiple instant-messaging servers still needs to register on each one of them separately.
03_4557.qxd
10/19/05
12:58 PM
Page 71
Messaging Services
71
More seriously, setting up a conversation between users on different servers is complicated. At this point there are two IETF standards for instant messaging, the Extensible Message and Presence Protocol (XMPP) and Session Initiation Protocol (SIP) for instant messaging and presence leveraging extensions (SIMPLE). Although both use Extensible Markup Language (XML) and plain text, XMPP and SIMPLE are very different and incompatible protocols, both in design and in philosophy. It is difficult to say whether XMPP or SIMPLE is best. XMPP has been designed as an instant-messaging and chat protocol from the outset and has been stable for a longer period of time than SIMPLE. This makes it a versatile protocol that can handle anything from instant messaging to complex presence information, group chat, file transfer, and address book exchange. 3.4.2 XMPP The XMPP is a client server–based protocol that negotiates the opening of a stream of XML plain-text messages. XMPP messages are used for communicating presence information, person-to-person instant messaging, or personto-group chat. XMPP uses straightforward logical addressing of the type user@domain/resource, which makes it relatively insensitive to the underlying network’s addressing structure. XMPP also includes a server-to-server protocol that allows anybody to set up a server and register it with other XMPP servers. Figure 3.8 shows a sample of an XMPP instant message from one person to another. The attributes of the <message> tag identify the sender and destination of the message, and the message type and language. The part contains the textual message itself. The part allows the correlation of messages that belong to the same conversation; it is a unique identifier that does not have to be human-readable. XMPP transports instant messages of this kind within a message stream negotiated beforehand between the two users, and which can pass through several intermediate XMPP servers. The open-source instant-messaging project Jabber (http://www.jabber.org) uses XMPP. While Jabber client and server can be downloaded for free, there is also a commercial Jabber organization (http://www.jabber.com) that sells commercial, licensed enterprise solutions based on XMPP. 3.4.3 SIMPLE SIMPLE is an instant messaging protocol built on the existing SIP protocol. Like SIP, SIMPLE is essentially a peer-to-peer protocol, though it is possible route the SIMPLE messages through intermediate SIP proxies and redirect servers. SIMPLE
03_4557.qxd
72
10/19/05
12:58 PM
Page 72
Implementing Value-Added Telecom Services
<message to='[email protected]/pc' from='[email protected]/workstation' type='chat' xml:lang='en'> Do you like this chapter? e0ff43h543uti5fe45iW34jyeVGo45Ho4537
Figure 3.8 Sample XMPP message from person to person.
uses SIP-style addressing, which is usually straightforward, but can be complex in some cases. The strength of SIMPLE lies in its reuse of SIP, which is already accepted by many hosts on the Internet. SIP was not originally designed as an instantmessaging protocol, but as a simple signaling protocol to set up multimedia sessions. In consequence, SIMPLE is limited in functionality and perhaps less efficient than XMPP. Also, SIP proxies were not designed to be instantmessaging servers, and SIMPLE does not support the easy interconnection mechanisms that XMPP does. The OMA appears to be betting on SIMPLE for instant messaging in mobile phones, perhaps because SIP is one of the pillars of the 3G IP multimedia subsystem (IMS). Although XMPP and SIMPLE are incompatible, it is in fact possible to build gateways between the two systems. Nevertheless, the lack of a single, universally accepted standard has proved to be a major roadblock for instant messaging.
3.4.4 Instant Messaging for Business-to-Consumer Communications Instant messaging is essentially intended for interpersonal communications, but there is nothing that prevents it from being used as a communications channel from business to customers as well. Microsoft has bundled the MSN Messenger with the Windows operating system, and uses it as a channel for alerts of different kinds, ranging from software updates to system notifications. This makes the Messenger suitable as a push channel for publicity and content. Unfortunately, the MSN Messenger is also vulnerable to unsolicited commercial messages (spam). However, if used correctly, the messenger allows an enterprise to push information to its customers.
03_4557.qxd
10/19/05
12:58 PM
Page 73
Messaging Services
73
Some ways in which a company can use instant messaging are: • Presales or postsales information, allowing a customer to contact a salesperson or technical expert directly; • Direct technical support and ticketing; • As a tool for distance learning and alternative for teleconferencing; • As a push channel for product updates and special offers to registered customers; • As a platform for online games; the MSN Messenger provides specific features for this. The enterprise needs no special software, apart from an instant-messaging client and content for the customer.
Examples for Section 3.4.4 MSN Games (http://games.mess.be) is the initiative of a Belgian programmer, who has developed various online games using the MSN Messenger. This Web site is in no way related to MSN Messenger itself, or other Microsoft products, it only promotes gaming through the Messenger. The Direct PopUp Advertiser of Bulk Email Software Superstore (http://www.americaint.com) of Coral Springs, Florida, is probably the most notorious application that uses the Windows Messenger service to send advertisements to PC users. Note that this application does not use the MSN Instant Messenger, but the simpler Windows Messenger service for simple text messages directly to a PC via its IP address. The site http://www.stopmessengerspam.com demonstrates how to disable the MSN Messenger, to stop receiving unwanted advertisements.
3.5 Unified Messaging One of the most pressing problems in the area of messaging is the lack of integration. E-mail, SMS, MMS, instant messaging, fax, and voice mail each have their own devices, interfaces, protocols, message store, and billing model. Each technology comes with its mailbox and requires separate accounts and login procedures, which is increasingly frustrating for the average user.
03_4557.qxd
74
10/19/05
12:58 PM
Page 74
Implementing Value-Added Telecom Services
Would it not be nice if one could receive all types of messages in a single mailbox? Also, would it not be even nicer if one could read the contents of that mailbox anywhere, from any kind of device, whether it be a fixed phone, mobile phone, or PC? This is exactly the idea behind unified messaging. There is no official definition for unified messaging, nor is there a definitive standard for it. Unified messaging is a concept rather than a specific protocol or technology. Many companies offer unified-messaging solutions. Some of these are complete unified-messaging systems that can send, receive, and store any kind of messages. But many others are partial services, for example: • SMS-to-e-mail and e-mail-to-SMS gateways (for example, http://www. sms2email.com); • Voice-to-e-mail and e-mail-to-voice gateways (for example, http://www. email2phone.net); • Fax-to-e-mail and e-mail-to-fax gateways (for example, http://www. callwave.com). In the United States the term unified messaging often refers to toll-free number services that allow the customer to concentrate its voice and fax communications in one number. However, true unified messaging means sending and receiving any kind of message from one single mailbox, through any device, as Figure 3.9 illustrates. 3.5.1 Setting Up a Unified-Message Service Any third-party enterprise can become a unified messaging provider. In fact, this does not require a great investment. The elements most likely needed are: • A number of incoming phone lines, for example, a T1/E1 interface or a VoIP connection to a network operator. • An array of E.164 phone numbers to assign to customers for their incoming voice and fax communications. These can be free phone numbers, if customers pay for the incoming calls, or normal phone numbers if the caller pays, or both. • A domain name for customers’ e-mail and instant-messaging addresses. Customers can also use their own domain names. In this case, the service provider must at least offer DNS servers to have the custom domain names point to its SMTP, POP, and instant messaging servers. The service provider can also opt for registering domain names for its clients.
03_4557.qxd
10/19/05
12:58 PM
Page 75
Messaging Services
Internet
Message store
75
POP, HTTP, instant messaging
e-Mail Instant message Mobile network
PSTN
SMS, MMS, voice message
Voice message
Unifiedmessaging server
SMS, MMS, WAP, instant messaging, voice Voice
Figure 3.9 Unified messaging server.
• Access to an SMSC of a mobile operator or SMS service provider, through one of the interfaces discussed in Section 3.2.1 • A unified-messaging server, as shown in Figure 3.9. This server should be able to convert incoming voice messages to audio files (.wav or .mp3), convert incoming faxes to graphics files (.jpg or .pdf), and convert text to speech and speech to text. The server should support at least HTTP access (Webmail), and one or more of the usual instant-messaging protocols. The server may also offer POP, SMTP, and WAP access. • A large, secure, and failure-safe message store. This can be any wellprotected array of massive storage disks. Of course, the service provider will also need software to manage the customer accounts and to correctly bill customers for service use.
Examples for Section 3.5.1 Cycos AG of Alsdorf, Germany (http://www.cycos.com), offers a complete unified-messaging system called MRS that can handle voice mail, fax, e-mail, and SMS from a single mailbox.
03_4557.qxd
76
10/19/05
12:58 PM
Page 76
Implementing Value-Added Telecom Services
Office EDITION, one of the products in the Anny Way suite (http://www.annyway.de) by Materna of Germany, is a unified-messaging server that supports sending and receiving voice mail, fax, e-mail, and SMS from a single Web interface. The application can be integrated with Lotus Notes and Microsoft Exchange/Outlook servers and also lets the user generate and manage communication reports.
3.5.2 OSA-Parlay Generic Messaging Interface The OSA-Parlay specifications include an open interface for unified messaging. The OSA-Parlay standard calls this the generic messaging interface, and its definition is object oriented. This means that the application calls methods on remote objects in the interface. The OSA-Parlay generic message interface defines four classes of objects: 1. MessagingManager is the general service class that lets the application access mailboxes and activate message notifications. 2. Mailbox is the main entry point for message handling. The mailbox contains messages, organized in folders. 3. Mailbox folder is a directory structure for storing messages within a mailbox. A mailbox contains by default two folders, inbox and outbox. The client application can create and delete additional mailboxes as necessary. Mailboxes follow a directory structure, in which the name of a submailbox is concatenated to the parent mailbox name and separated by a /; for example, inbox/mybook/chapter3relatedmails. 4. Messages can have any kind of content, and have visible properties, such as sender, receiver, subject, date sent, date received, size, priority, format, and status. Table 3.3 lists the methods an application can call on each of the objects. Most of these functions are straightforward and self-explanatory. Figure 3.10 shows the normal procedure for an application to retrieve a message: 1. First, the application opens a mailbox by calling the openMailbox method on the MessagingManager object. The MessagingManager creates a mailbox object and sends back its reference to the application. 2. The application then opens the inbox folder in the mailbox, by calling the openFolder method on the Mailbox object.
03_4557.qxd
10/19/05
12:58 PM
Page 77
Messaging Services
77
Table 3.3 OSA-Parlay Generic Message Interface (Summary) Interface Class
Figure 3.10 Retrieving message content with OSA-Parlay.
03_4557.qxd
78
10/19/05
12:58 PM
Page 78
Implementing Value-Added Telecom Services
3. The application asks for properties of the messages in the mailbox by calling the getInfoProperties method on the Folder object. The Folder object responds with the requested information, for example, the subjects of the messages it contains. 4. The application selects a message by calling the getMessage method on the Folder object. The folder returns the reference to the selected message object. 5. The application can then retrieve the content of the message by calling the getContent method on the Message object. The OSA-Parlay specification recognizes several kinds of message format: text, binary, UUencoded (text-encoded binary), MIME (text-encoded multipart content), wave (audio), and au (audio). The generic nature of these formats in fact allows for the handling of any kind of message, whether it be voice (audio), fax (image), e-mail (text, UUencoded, MIME), SMS (text), or video (binary, UUencoded, or MIME encoded). The OSA-Parlay generic messaging interface is a true unified-messaging enabler, in that it allows for sending, receiving, storing, and manipulating any kind of message through a single object-oriented interface.
Examples for Section 3.5.2 Redknee of Mississauga, Ontario, Canada, (http://www.redknee.com), offers a whole range of OSA-Parlay-based network solutions, among which are their Enhanced Messaging Gateway and the Syntaxis iHub SMS and USSD gateway. The latter does not actually use the OSA-Parlay generic messaging interface, but the user interaction interfaces instead. Several network operators have deployed their systems. Kabira Technologies of San Rafael, California, (http://www.kabira.com), provides an extensive OSA-Parlay platform that includes a unified-messaging service. It can connect to virtually any SMSCs, multimedia messaging service centers (MMSCs), mail, and instant-message servers. Oksijen Teknoloji of Istanbul, Turkey, (http://www.oksijen.com), is another well-known provider of OSA-Parlay solutions that provides a whole series of messaging servers.
03_4557.qxd
10/19/05
12:58 PM
Page 79
Messaging Services
79
Selected Bibliography http://www.82ask.com, answers any question by premium-rate SMS http://www.americaint.com, software for pushing publicity through the Windows messenger http://www.annyway.de, Materna’s unified-messaging suite http://www.blinker.nl, software for managing e-mail campaigns http://www.cellbroadcastforum.org, promotes the cell broadcast service http://www.celltick.com, content delivery via cell broadcast service http://www.contentsmartz.com, software suite for bulk e-mail publicity http://www.cycos.com, unified-messaging system provider http://games.mess.be, promotes gaming through the MSN Messenger http://www.goldenbytes.nl, creator of SMS alerting services http://www.horde.org, open-source Webmail application http://www.inxmail.org, software for managing e-mail campaigns http://www.kabira.com, Parlay-OSA platform and application provider http://www.kapow.co.uk, Internet-based SMS gateway service http://www.kvtsoftware.com, software for sending e-mail alerts from file http://www.mozat.com, Windows-based application for sending and receiving MMS through a GPRS modem http://www.neomail.org, open-source Webmail application http://www.nowsms.com, universal SMS gateway http://www.oksijen.com, Parlay-OSA platform and application provider http://opensmpp.logica.com, open-source Java library for SMPP and SMSC simulator http://www.phonotics.com, software for generating e-mail alerts from Internet sources http://rac.com.au, premium-rate alerts of the lowest-priced gasoline around the city of Perth, Australia http://www.re5ult.com, SMS-based information services http://www.redknee.com, Parlay-OSA platform and application provider http://www.sendmail.org, open source SMTP server http://smsforum.net, resources for SMS application development, using the SMPP protocol http://www.spam.abuse.net, experimental site to inform network administrators about spam
03_4557.qxd
80
10/19/05
12:58 PM
Page 80
Implementing Value-Added Telecom Services
http://www.spamcop.com, commercial spam blocking and reporting service http://www.stopmessengerspam.com, demonstrates how to disable the Messenger in Windows systems http://www.winsms.com, Windows-based application for sending and receiving SMS through a GSM phone
04_4557.qxd
10/19/05
1:04 PM
Page 81
4 Content Services The content business is complex. Although companies like Disney, Time Warner, and Virgin have built empires on content, it is not an easy business. The value of content is difficult to assess. Television and early Web content used to be free, which has given many people the perception that content should not be paid for. Piracy has also put a serious dent in the content business, at least if one believes the complaints from its victims, the content providers. Yet there is a lot of content out there that people are willing to pay for. Some examples are: • • • •
This is just a tiny sample, and there are doubtless many other types of content that people will pay for. Content is a healthy business for those who find their place in the market. It is not within the scope of this book to identify what is value-added content, but we do explore the technologies used to bring content to the consumer and charge for it. In the next section we first introduce the types of content delivery. Then, in Sections 4.2 through 4.7 we consider some content delivery technologies in detail. 81
04_4557.qxd
10/19/05
1:04 PM
82
Page 82
Implementing Value-Added Telecom Services
4.1 Pull and Push Content Content delivery involves three agents: the client, the server, and the network. The client is the hardware and software that receives the content, as well as by rendering it. The server is the hardware and software that retrieves and delivers the content in whatever form to the client. The network transports requests for content from client to server, and transports the content itself from server to client. There are many ways to bring content to the consumer, but they are usually broken down in two categories (see Figure 4.1): 1. Pull: The client makes a request for content to the server and the server responds with the requested content. Navigation on the WWW is a typical example of pull content. 2. Push: The server spontaneously sends content to the client without a previous request being made. Radio and television broadcasts are typical examples of push content. Some instances of push content (for example, newsletters or pay television) require the client to subscribe previously, but the content itself is sent without explicit requests. In this chapter we investigate both models of content delivery over networks, with special focus on two questions: What technology is required to deliver content? How can one charge the consumer for it?
Push
Pull
Server
Server
Reply Request Content
Client
Figure 4.1 Pull and push model for content delivery.
Content
Client
04_4557.qxd
10/19/05
1:04 PM
Page 83
Content Services
83
4.2 World Wide Web Radio, television, and newspapers were common channels of content distribution for the decades preceding the early 1990s when the first Web browsers appeared. The Internet had already existed for some time, but was mostly used by the research community, universities, and big corporations. HTTP revolutionarized the way the Internet was used, and made it accessible and appealing to the general public. HTTP browsers turned it into a completely new channel for content distribution, with a degree of interactivity that radio and television broadcasts were unable to provide. The WWW uses a pull model for content distribution, and “browsing” became the paradigm for pulling content from the millions of Web servers on the Internet. Today when thinking of browsing, what first comes to mind is the WWW. There are also other browsing services, however, such as Videotex, WAP, and iMode. This chapter concentrates on the WWW and its mobile counterparts, WAP and iMode. The strength these technologies is their accessibility to both clients and servers alike. Anybody can set up a Web site in half an hour, and completely for free. This makes the Web, WAP, and i-mode very interesting for third-party content delivery. The vast majority of Web sites contains free information, but there are also many sites that require payment. And they are not all adult sites, as Table 4.1 shows. In this section we take a brief look at the technologies needed to set up a premium content site. It is not the intention of this book to explain in detail how IP, HTTP, cookies, applets, PHP, CGI, and other Web technologies work. Appendix A.1.4 provides a brief overview, and there are many good books on the subject. Here we take a practical approach and see what is needed to get into the online content business. Table 4.1 A Few Examples of Premium Content Site URL
Premium Content Offered
http://www.apple.com/itunes/store
Online music store
http://www.bluemountain.com
Electronic postcards for all occasions
http://www.clipart.com
Clip art graphics, photos, animations
http://www.consumerreports.org
Tests and comparisons of all sorts of products
http://www.ft.com
News and articles
http://www.pcquote.com/products
Stock quotes and stock market tips
http://www.usnews.com
School rankings and selection information
04_4557.qxd
84
10/19/05
1:04 PM
Page 84
Implementing Value-Added Telecom Services
4.2.1 Setting Up a Web Site Setting up a Web site involves the following components (Appendix A.1 explains Internet technology in more detail): • An Internet connection: A 56-Kbps dial-up connection to the Internet is not likely to be sufficient for providing content. The least access needed would be a DSL, cable, or E1/T1 connection that offers 1 Mbps or higher speeds. The required bandwidth depends on the kind of content offered, and the number of visits expected. • A domain name: Few people can remember a Web site by its IP address, so it is convenient to register a domain name. A domain name provides a mnemonic name for a Web site, and is automatically translated to the server’s IP address by the global DNS. A well-chosen domain name can have great commercial value, and it is not surprising therefore that there is a lucrative trade in domain names. • A Web server: Although it is not technologically difficult to install an HTTP server, many people opt for hosting or housing their content with an ISP. Hosting means placing content on one of the ISP’s Web servers. It has the advantage that the user has to worry only about the content itself, and not about maintaining and protecting the server. Housing means installing a company’s own Web server at the premises of the ISP, that will take care of its management. This is generally more expensive than hosting, because the server is fully dedicated to the company. • The content: In essence, Web site content can be a simple collection of linked HTML (marked-up plain text) files and pictures. But many sites today offer dynamic content and employ back-office applications to generate it. Today there is a wide range of technologies and tools for the creation and management of static or dynamic content on the Web. This book does not go too deeply into creating the content itself. There are many excellent books on this, and today many content management tools exist for the creation of Web content with little or no programming. Instead, we focus on another important question: how to charge for Web content. When browsing the Web, one really finds two types of paid content: 1. Browsable content, for example, online news articles; 2. Downloadable content, for example, e-books and music. From a technical point of view, there is not a great deal of difference between browsing and downloading. A browser in effect downloads the pages you
04_4557.qxd
10/19/05
1:04 PM
Page 85
Content Services
85
see, including graphics and small applications (applets). But there can be a difference in the way this content is billed. Downloaded content is often billed per item, while browsing content is usually billed per subscription, or time frame. In the following subsections we consider the most common mechanisms for charging for Web content. 4.2.2 Item- or Subscription-Based Charging If a site offers downloadable content, like MP3 music files, then the most usual way to charge is by item. The usual way to allow for several files to be paid for and downloaded is by shopping-cart systems. There are several open-source solutions for online shops that can be downloaded for free. Chapter 6, which is on e-commerce, explains online payments and shopping carts in detail. An alternative to billing per item is to bill for subscriptions. This is the usual way of charging for dynamic content like news and stock market information. Subscription-based charging can be seen as a special case of the per-item payment just discussed. Rather than providing the customer with the downloadable content, the content provider issues a user name and password that will give site access for a certain period of time. Beware that in order to receive credit-card payments, a content provider needs what is called a merchant account, which is more fully explained in Chapter 6. Due to the high fraud rates, banks can ask for a deposit of thousands of dollars to open a merchant account for electronic commerce. Also beware that the content provider bears the risk of bad credit and charge-backs in case of online credit-card transactions that do not involve a physical signature. If a merchant does not want to establish a merchant account with a creditcard company, then an alternative is to seek payment through online payment services. There are certain disadvantages to this, the most important being that these services often require customers to have an account with them as well. This tends to raise the threshold for many potential clients who might wish to use a site. Most of the payment services on the Internet support both charging per item and per subscription.
Examples for Section 4.2.2 Firstgate AG (http://firstgate.com) of Germany provides a billing service for online content that also supports subscription. Customers can pay by credit card, but also by direct-debit against their bank account. Risk Center (http://www.riskcenter.com) of New York is a Web-based information source for risk specialists in the financial, operational, and energy
04_4557.qxd
10/19/05
86
1:04 PM
Page 86
Implementing Value-Added Telecom Services
industries. Customers can pay for premium articles on a per-item basis, but can also subscribe to discount plans.
4.2.3 Dialers Although credit cards are often used for online payments, they are not always the optimal way of billing for content. Apart from the charge-back and fraud risk involved, credit cards lock out a certain group of potential clients who either are not eligible for this type of payment or are reluctant to use it online. One alternative way of charging for the Web without requiring direct payment is by charging through a premium-rate phone line. This method of payment is less sensitive to fraud and has the added advantage of providing a certain level of anonymity for the customer, as there is no need to ask for any personal or credit-card information. There are several ways to use premium-rate lines. The simplest is to install a Point-to-Point Protocol (PPP) server behind the premium-rate number that is connected to the Web server that contains the premium-rate number. To access premium content, the user must disconnect from his or her ISP and reconnect to the premium-rate number, which from then on serves as a Web server. In this way, the user pays indirectly for the content by paying for a premium-rate phone connection. The content provider settles off-line with the owner of the premium-rate number (usually the operator), who usually charges a commission. It is not necessary that the user makes the reconnection to the premiumrate number manually. Java applets exist that can do the dialing automatically. Unfortunately, some Web sites use Java dialers to lure unsuspecting people to expensive premium-rate numbers, a practice that is popularly called Internet dumping, but when properly used, dialers can be a legitimate and convenient way to charge for content without involving direct payment. Obviously, the dialer solution works only when the customer uses dial-up Internet access. But it is still possible to use a variant of dial-up premium content when the customer connects to the Internet via LAN or DSL, provided he or she also has access to a phone line. Figure 4.2 illustrates this situation. When trying to access the premium content, the Web site will prompt the user to dial a premium-rate number. To correlate the call with the client, the Web site may display a number that the user has to enter when connected to the premium-rate number. Alternatively, the user can be prompted to enter his or her telephone number, so that the incoming call can be identified at the server side (provided the operator supports calling-line identification, and the customer has not blocked this).
04_4557.qxd
10/19/05
1:04 PM
Page 87
Content Services
Dial premium number
PSTN Client
87
Premium number termination Forward
Browse premium content
Content server
Internet Serve premium content while phone connection is open Figure 4.2 Charging for Internet content through premium-rate phone numbers.
The site will need cookies to identify the client browser, or will alternatively have to use PHP, CGI, or JSP to do so. The user will have access to premium-rate content for as long as the call to the premium-rate number is kept open. Figure 4.3 shows in detail how a DSL dialer solution works. The steps shown in Figure 4.3 for charging Web content to a premiumrate phone number are the following: 1. The user makes a request to browse payable content. The user’s browser sends an HTTP GET message to the server requesting the corresponding HTML file. In this example, we assume the file is called premiumcontent.htm. 2. The server generates a unique personal identification number (PIN) code for this session and sends back a dynamically created HTML page that prompts the user to dial a premium-rate telephone number, and enter the personal identification number (PIN) code (let us assume 1234). The HTTP response carries a cookie with the same PIN code, which is stored on the client computer. (Note that the PIN code can be any sequence of letters or digits, as long as it is unique and difficult to guess or to obtain by brute-force trying.) 3. Following the instructions on the Web page, the user dials the premium-rate number. The call is forwarded to the content provider, who prompts the user for the PIN code and associates this code with the call. We do not go into detail about how the PIN code is obtained
04_4557.qxd
10/19/05
88
1:04 PM
Page 88
Implementing Value-Added Telecom Services
from the user. One solution is for the content provider to install software that can interpret dual-tone multifrequency (DTMF) tones. 4. The user now clicks on a link in the page (downloaded in step 2) to proceed to the payable content. The HTTP GET request carries the cookie with the PIN code that was earlier stored on the client computer. 5. The server compares the PIN code received with PIN codes associated with currently open premium-rate calls. If there is an open telephone call associated with this PIN, the server sends back the payable content. 6. While the telephone connection remains open, the user has access to payable content pages. Every time the user requests a page, steps 4 and 5 are repeated. When the user terminates the telephone connection, the server registers that there is no longer an open telephone connection for PIN 1234. Any further requests for payable content that carry a cookie with PIN 1234 will be denied. The example of Figure 4.3 deliberately uses static HTML content to show that the DSL dialing solution does not necessarily need sophisticated solutions
Premium number termination
Content server
GET / premiumcontent.htm
(1)
Create page and cookie with unique pin 1234 (2)
200 OK dial-and-enter-pin-1234 (3)
(4)
Set-cookie: 1234
Dial, enter pin 1234
Forward
GET / premiumcontent1.htm
Cookie: 1234
Check PIN received in cookie against PIN received in call (5)
(6)
200 OK premiumcontent1.htm
GET /premiumcontentN.htm 200 OK premiumcontentN.htm
Figure 4.3 Dialogue for the DSL dialer solution.
Cookie: 1234
04_4557.qxd
10/19/05
1:04 PM
Page 89
Content Services
89
such as PHP, CGI, or Java. Still, the server must have some processing capacity to generate and verify PIN codes. It is, in fact, possible to implement a solution without PIN codes, if the operator supports calling-line identification (CLI). Instead of sending a PIN code in step 2, the server sends a simple HTML form asking the user to enter his or her phone number. When the user has filled out and submitted the form, the server responds with a “thank you” page that carries a cookie with the phone number entered by the user. When the user then makes the call to the premium-rate number as in step 3, the operator reveals the calling-line number to the server. The server can check this against the numbers received in cookies that come with subsequent GET requests. Note that the CLI approach is more sensitive to security problems. People who frequently call in expose themselves to hackers that can piggyback on their sessions. All a hacker needs to do is fake a cookie with a telephone number that is frequently used to pay for content. If the client computer is connected to the telephone line, then this procedure can also be automated using Java applets, just as in the case for dial-up access.
Examples for Section 4.2.3 Coulomb Internet Payment Systems (http://www.coulomb.co.uk) of London, United Kingdom, provides an Internet dialer that can be integrated into HTML pages, which allows premium content to be offered through premium-rate dialup Internet access. They also have a complete dialer solution for DSL connections, which requires the customer to dial a premium-rate number and enter a PIN code. Magenta Systems (http://www.magsys.co.uk) of Croydon, United Kingdom, offers an Internet dialer that can auto-dial from the browser, called the Dial Up Networking Manager (DUN Manager). Beware that many governments are now taking action against Internet dumping, the term used for autodialing premium-rate phone numbers from a browser without a user’s explicit consent. Some operators, like BT in the United Kingdom, have started blocking premium-rate numbers associated with Internet dumping (and is donating its share of the revenue from such numbers to charity!). Providing premium-rate dial-up access to content is now subject to prior approval in the United Kingdom and other countries.
04_4557.qxd
90
10/19/05
1:04 PM
Page 90
Implementing Value-Added Telecom Services
4.3 Wireless Application Protocol (WAP) The previous section showed that anybody can build a Web site for delivering content to Internet users. There are many ways to charge for content, and there are many companies that will handle the payment transactions for the content provider. The most difficult aspect is really to find the content that has added value for the customers, so that they will pay for it. Up until now we have tacitly assumed that the customer uses a PC to access the Internet and to access the content. However, what about users on the road that only have a mobile phone or personal digital assistant (PDA)? Is it possible to deliver browsable or downloadable content to these users as well? It is perfectly possible to deliver Internet content to mobile devices, but there are two important constraints. First, mobile devices have reduced input and output capabilities, typically a small screen and a reduced keyboard. And second, 2G and 2.5G bearers put severe limits on data rates, which are typically between 10 Kbps and 50 Kbps.1 WAP was designed in the late 1990s to bring hypertext content to mobile devices. The first generation of WAP V1.x specifications cannot really be called mobile Internet, since it does not necessarily use the IP. Moreover the name wireless application protocol wrongly suggests that it is a single protocol, while it is in fact a whole series of standards for transporting hypertext content over mobile networks and delivering it on mobile devices. In the following sections we consider what the necessary components are to provide WAP content. 4.3.1 WAP Gateways It is easier to provide WAP content than is often believed. Most mobile operators have a WAP gateway that provides access to any WAP content on the public Internet. To become a WAP content provider, it is sufficient to put Wireless Markup Language (WML) content on a standard HTTP server anywhere on the Internet. Figure 4.4 illustrates how the WAP gateway mediates
1. In mobile networks there tends to be a significant difference between the theoretical maximum data speed, and the speed that is available in practice. 2.5G systems like GPRS may offer theoretical speeds of 170 Kbps, yet real speeds will typically be in the range of 50 Kbps or less. This has to do with technological constraints (terminal multislot class, error correction, redundancy, and also signal-propagation conditions) as well as with operator imposed limitations so as not to exceed network capacity. 3G networks do offer significantly better data speeds in excess of 100 Kbps.
04_4557.qxd
10/19/05
1:04 PM
Page 91
Content Services
Encoded request
WAP gateway
Mobile network
WSP
Encoded reply
WTLS
User agent (microbrowser)
WTP
WDP
HTTP TCP
91
HTTP request
HTTP server
Internet HTTP reply
IP
WML content
Figure 4.4 WAP gateway allows access to WML anywhere on the Internet.
between encoded Wireless Data Protocol (WDP) requests and standard HTTP requests. When the user requests WAP content from his or her mobile device, the microbrowser sends this request to the WAP gateway in binary encoded format in order to save radio resources. The WAP gateway translates its request to a standard HTTP request and forwards it to the HTTP server where the content resides. The HTTP reply is converted by the gateway into a binary encoded response and sent back to the mobile device. Of course, the HTTP server must contain WML documents rather than HTML documents. Some WAP gateways are capable of translating standard HTML pages to WML, but it is not easy to preserve the page layout or even the content itself in the translation process. For this reason, serious WAP content providers tend to design their content specifically for mobile devices and avoid using standard HTML pages. Although it is a different language, WML is not any more difficult to use than HTML. It is a text-based mark-up language that supports hyperlinks, forms, and embedded graphics just like HTML. WML uses a deck of cards metaphor rather than a page concept, to suggest the reduced size of its content. Due to the limitations of mobile devices, creating WML content can be a bit tricky, but it is not any more complex than creating Web pages. There are many tools and emulators available for designers of WML content, and just as on the Web, some Internet service providers now offer Web-based tools for creating and managing WML sites without programming. The next version of WAP (V2.0 and beyond) uses extensible HTML (XHTML), a generalization of standard HTML, which makes it even easier to create WAP content. WAP 2.0 also supports standard TCP/IP and HTTP protocols.
04_4557.qxd
92
10/19/05
1:04 PM
Page 92
Implementing Value-Added Telecom Services
Examples for Section 4.3.1 Apart from Ericsson, Materna, Nokia, Openwave, and other well-known players in the mobile networks market, there are also many smaller companies that sell WAP gateways, browsers, and services. Here are a few examples. Kannel (http://www.kannel.org/) provides an open-source WAP gateway that can be downloaded free. WAP Tunnel (http://www.waptunnel.com) provides a free public WAP gateway that can be used for designing and testing sites. Inetis (http://www.inetis.com) provides a user-friendly Web-based interface for building WAP content without editing WML, and offers free WAP hosting. The Dutch site Msitebuilder (http://www.msitebuilder.com) is another online what-you-see-is-what-you-get (WYSIWYG) service for building and hosting WAP content. GoLive, the Web design tool of Adobe Systems (http://www.adobe.com) is one of the professional packages on the market for creating Web and WAP content.
4.3.2 Charging for WAP Content The previous section has demonstrated that it is not any more difficult to create WAP content than it is to create Web content. Now for a crucial question: How does one charge for WAP content? In essence WAP content is hypertext, which means the charging mechanisms in Section 4.2 can also be applied in this case. Just like Web content, WAP items and subscriptions can be billed via credit-card transactions or by using one of the many online payment services. It is also possible to provide dial-up access to content using premium-rate numbers, but this requires the content provider to install its own WAP server. Technically speaking, a WAP server is no more than a WAP gateway and an HTTP server collapsed into one server, as illustrated in Figure 4.5 (compare this with Figure 4.4). But deploying a WAP server is more complex than hosting WML content on an HTTP server, for several reasons: 1. The server must have a mobile network address, for example, a mobile station integrated services digital network (MS-ISDN) number in GSM networks. This network must have enabled premium-rate billing, which requires an agreement with the operator. 2. The server must support the complete WAP protocol stack, including the WDP, Wireless Transport Protocol (WTP), Wireless Session Protocol
04_4557.qxd
10/19/05
1:04 PM
Page 93
Content Services
Premium-rate connection
Mobile network
93
WAPserver WSP WTP
WML content
WTLS User agent (microbrowser)
WDP Premium-rate access
Figure 4.5 WAP server.
(WSP), and optional wireless transaction layer security (WTLS) protocols. 3. The server must be protected against hackers and fraud, which will involve the installation of a firewall. On the other hand, the great advantage is that the content provider has complete control over the access to its content and can bill for the content by charging premium rate access to the server. WAP servers come in many sorts and sizes, but are generally expensive. Of course, the bold can opt for implementing a server themselves, but bear in mind that this is significantly more complex than implementing an HTTP server. There is some open-source software available that can aid the implementation of a WAP server or WAP gateway. 4.3.3 Billing WAP Content Through the Operator So far we have not mentioned one of the unique features that set mobile networks apart from the Internet: the mobile subscription. As already observed in Chapter 3, when talking about prepaid services, a mobile device is a personal device that contains a SIM card. The SIM card directly associates the microbrowser on a mobile device with a mobile subscription; a crucial difference from PCbased browsers that can be used from any anonymous Internet café. This means that we can use the mobile subscription to bill for content. There are two common scenarios for charging WAP content provisioning to a mobile subscription: 1. The content provider has a direct billing agreement with the mobile operator. 2. The content provider uses a third-party payment service billing for WAP content.
04_4557.qxd
10/19/05
1:04 PM
94
Page 94
Implementing Value-Added Telecom Services
(5) (4)
Bill
Billing system
Bill subscriber
100
Share revenue with content provider
(3) create CDR
(1) WAP request
WAP Mobile network gateway
Client
100
WAP reply
HTTP request
Internet
HTTP server
HTTP reply (2)
Mobile operator
Content provider
Figure 4.6 WAP content billing through gateway.
Let us consider these two alternatives in turn. Figure 4.6 shows the first case, in which the content provider has a direct agreement with the mobile operator. The procedure in this case is the following: 1. The subscriber requests pay content. The request goes through the WAP gateway, which converts it to a standard HTTP request. 2. The HTTP server sends the requested WML content back to the gateway, which converts it into encoded format for the radio interface. 3. Upon successful transfer of the content to the client, the WAP gateway sends a call data record (CDR, i.e., billing information in standard format) to the billing system. 4. Off-line, the operator bills the subscriber. For simplicity, this example assumes that billing is postpaid, so that no previous credit checks or reservations are necessary. 5. Also off-line, the mobile operator settles with the content provider and shares the revenue for the transaction. The operator will normally charge a commission. The disadvantage of this scenario is that the content provider binds itself to a specific operator. This can restrict the group of potential customers, and can mean that the content may not be available to roaming users, if they use another WAP gateway than the home network’s. In the worst case, the content provider will have to establish agreements with several operators.
04_4557.qxd
10/19/05
1:04 PM
Page 95
Content Services
95
4.3.4 Third-Party WAP Billing An alternative is provided by companies that mediate between the content provider and the mobile network operator. In this case, the content is still charged against the mobile subscription, but the third-party payment provider takes care of charging and settlement with the mobile operator. This scenario is explained in Figure 4.7. Now the procedure is slightly different from that explained in the previous section: 1. The client makes a WML request to the content server. For simplicity, the WAP gateway has been omitted, because it does not play a crucial role in this scenario. 2. The content provider forwards a notification of the request to the payment server. 3. The payment server asks for confirmation from the subscriber. This can be done by sending of a simple WML form, and is done for nonrepudiation purposes. 4. The payment server generates the billing information and sends it to the mobile operator’s billing system. The payment server also reports back to the content server that the transaction has been confirmed (not shown in Figure 4.7).
Payment service (4) Generate CDR
Billing system
Payment server (2)
(3) Confirm
Forward request
Internet WML request (1)
Client
HTTP server
WML reply (5)
Mobile operator Figure 4.7 Third-party WAP billing service.
Content provider
04_4557.qxd
10/19/05
96
1:04 PM
Page 96
Implementing Value-Added Telecom Services
5. The content provider sends the requested content to the client. Later, the operator will settle with the payment service off-line, and the payment service will share revenues according to the agreement with the content provider. The advantage of this scenario is that the content provider has to liaise with only one party, the payment server, which in turn can have agreements with many operators. This means that the content provider has to connect to only one interface, and does not have to worry about roaming and settlement. The disadvantage is that both the operator and the payment service will take their commission, which leaves less revenue for the content provider. There are several variations of this scenario, and there are several companies offering this type of service.
Examples for Section 4.3.4 Telcopay (http://www.telcopay.com) of Zürich, Switzerland, offers a payment solution for mobile content that follows the scheme of Figure 4.7. NetCom of Oslo, Norway (http://netcom.no/partnere/contentprovider.html), offers a similar service though its own WAP gateway. European and U.S. operators have not been overly enthusiastic about providing revenue-sharing programs for WAP content. Although they are not publicized too widely, KPN, TeliaSonera, T-Mobile, and some other operators do offer revenue-sharing programs.
4.4 I-Mode I-mode stands for information mode, and is the mobile web technology launched by Japan’s incumbent mobile operator Nippon Telephone and Telegraph (NTT) DoCoMo in 1999. The intention behind i-mode is not that different from WAP: bringing Web content and applications to mobile devices. In terms of technology and business, however, there are significant differences. While WAP has been struggling for survival, i-mode has been hugely successful in Japan since its creation. Apart from the cultural differences that exist between Japanese subscribers and subscribers in the rest of the world, there are two factors that can explain the success of i-mode: 1. I-mode comes technologically closer to what could be called mobile Internet than WAP. It relies on standard TCP/IP, HTTP, and a reduced
04_4557.qxd
10/19/05
1:04 PM
Page 97
Content Services
97
version of standard HTML. This makes it much easier to port Web content and Internet applications to i-mode. 2. As soon as it launched i-mode, NTT DoCoMo created a revenuesharing program that made it interesting for third parties to provide premium-rate content through i-mode. This generated a critical mass of content providers and content consumers in a short time. Technologically, i-mode comes closer than WAP to what could be called mobile Internet, for two reasons: 1. I-mode uses standard HTTP and SMTP, and uses TCP/IP for packet transport, except on the air link. I-mode also supports standard mail protocols SMTP and POP. WAP uses its own protocol stack WSP/WTP/WDP. 2. I-mode uses Compact HTML (cHTML) as the hypertext mark-up language, a reduced version of standard HTML. WAP uses its own language WML, which is different from HTML. In Japan, DoCoMo provides an i-mode gateway, the Gateway Service Representative Internet Market Mobile Access Exchange (GRIMM), that works pretty much like a WAP gateway in that it relays HTTP requests from the mobile device to the content provider. The gateway also handles SMTP and POP, and can temporally store e-mail that has not been retrieved by the mobile device. The procedures for providing i-mode content are essentially the same as the ones presented in Section 4.3.2 for WAP. All a content provider needs to become an i-mode content provider, is cHMTL content and an HTTP server to host it on. A content provider can request to be included in the i-mode menu free of charge, but DoCoMo does reserve the right to review the content for its appropriateness for i-mode users. I-mode pay content is always billed on a monthly subscription basis, and is bound to a maximum subscription fee. DoCoMo bills the subscriber on a monthly basis, takes a percentage2 of the subscription revenue, and pays the rest to the third-party content provider. To become a provider of pay content, a content provider must previously have been approved for inclusion in the i-menu, and must provide a certain level of customer support for the site.
2. At the time of this writing, the maximum subscription fee was 300 yen, and DoCoMo charged 9% commission for monthly subscriptions.
04_4557.qxd
98
10/19/05
1:04 PM
Page 98
Implementing Value-Added Telecom Services
The i-mode revenue-sharing program is as simple as it is powerful. I-mode has an impressive subscriber base in Japan, which makes it very interesting for content providers to use this channel. Although i-mode does not appear to have reached critical mass in Europe, it is certainly worth considering for content providers as an alternative to WAP. The OMA has been making efforts since 2002 to merge WAP and i-mode. This means that standards for mobile device–optimized hypertext content are set to converge from the mid-2000s onwards.3 3G technology will eliminate the need for specific mobile packet transport protocols and will improve data rates, so that the IP protocol stack will become the standard for fixed and mobile networks alike.
Example for Section 4.4 The primary source of information about i-mode is, of course, NTT DoCoMo. On their site http://www.i-mode.com, DoCoMo explains the technology and business aspects of i-mode. Here one can also find the latest information on worldwide partners and deployment figures. A stepwise explanation on how to become a third-party i-mode content provider can be found on DoCoMo’s page, http://www.nttdocomo.co.jp/english/p_s/i/tag/newip.html. (Note that most of the tools mentioned in Section 4.3 also support the creation and hosting of imode pages.) BASE (Belgium), Bouygues Telecom (France), COSMOTE (Greece), EPlus (Germany), Far EasTone Telecommunications (Taiwan), KPN Mobile (The Netherlands), Telefónica Móviles España (Spain), Telstra (Australia), and WIND Telecomunicazioni (Italy) have licensed i-mode and are providing it outside Japan. Mitsubishi, NEC, Sagem, Samsung, Siemens, Toshiba, and Vitelcom offer i-mode-compatible mobile devices.
4.5 Push Content As explained in the introduction of this chapter, “push” content is sent from server to client spontaneously, without an explicit request. There are many types of push content. Radio and television broadcast, e-mail alerts, newsletters, SMS
3. Whether operators and manufacturers will actually adopt this standard remains an open question, of course.
04_4557.qxd
10/19/05
1:04 PM
Page 99
Content Services
99
welcome messages, spam mail, and pop-up advertisements in Web browsers are all examples of push content. In fact, it is not entirely correct to define push content as “content delivered without explicit request.” Many benign forms of push content are provided after a user subscribes to it. It is more accurate to say that push content does not involve a strict request–reply dialogue between client and server. Payable push content is normally subject to prior subscription, for the simple reason that the content provider needs to establish a billing relationship with the subscriber. By analogy to radio and television broadcast, push content on the Internet is often organized in channels. The push client software tunes into these channels by subscribing to the corresponding server for particular information. The difference with radio and television is, of course, that a push client can receive information from as many channels at the time as the user wants. 4.5.1 Web Push Internet push content survived a short hype at the end of the 1990s, with companies like Microsoft, PointCast, and Marimba proposing new ways of sending content from servers to clients on the Internet. Many Web-based push technologies, like Microsoft’s Active Channel technology, were in fact not strictly push but really intelligent and automated pull technologies. Using structures like the channel description format (CDF), the browser is instructed to crawl the Web for particular content and pull the relevant content from it. The World Wide Web Consortium (W3C) worked on push technology for a while, but it never caught on, and many of these companies disappeared. Web push is now mostly used in proprietary (and expensive) corporate applications, to make enterprise back-office applications and data available to employees on the road. Many news-oriented sites today use an XML-based metadata format called RSS to create and distribute news feeds. The acronym RSS seems to have several meanings, including real simple syndication, rich site summary, or RDF site summary, but they all refer to the same technology. In essence RSS is no more than a very simple language for summarizing Web site content or news feeds. RSS is used by news reader applications that fetch the feeds from their respective source URLs, agregate the content from several sources, and present it in the form of channels to the client. Most open-source content management systems include modules for RSS content aggregation. There are several versions of RSS in existence, created by different organizations, the most important of which are the RSS-DEV Working Group and Userland Software. Although very similar, the specifications from these two organizations are incompatible. Still, RSS appears to be the open standard for
04_4557.qxd
10/19/05
1:04 PM
100
Page 100
Implementing Value-Added Telecom Services
push content agregation that is more or less widely used today, albeit mostly for news feeds. The most common way of pushing content over the Internet today is by using standard e-mail. Most mail clients can now handle HTML-formatted e-mail with MIME attachments, and are perfectly integrated with Web browser software. Today’s mail clients and servers do not frown on handling e-mail messages of several megabytes, which means that it is possible to send virtually any content by e-mail today.
Examples for Section 4.5.1 PointCast, founded in 1992, was one of the first companies to develop Web push technology. The company was hot news in the mid-1990s, but while the Web continued to grow explosively, push technology never took off and PointCast ended up with serious financial problems. EntryPoint acquired PointCast in 1999, and in late 2000 EntryPoint merged with Internet Financial Network Inc. to form InfoGate, a provider of IP television, video, and games on demand technology. Marimba Inc. (http://www.marimba.com), of Mountain View, California, now part of the BMC Software group, offers push technology for remote administration and management of corporate networks. Applications include content distribution for corporate intranets and extranets and remote operating system provisioning and maintenance. Userland (http://www.userland.com) of Danville, California, is the source of the RSS 2.0 specification, which is now released through Harvard under a Creative Commons license. Organizations like the New York Times, Washington Post, and Yahoo! use RSS to provide news feeds to their customers. Bloglines (http://www.bloglines.com) is a Web portal that allows its users to agregate and share RSS feeds. Sharpreader (http://www.sharpreader.net) is a Windows-based client application that fetches and aggregates RSS feeds on PCs.
4.5.2 WAP Push Maybe Web push never caught on, but things are quite different in the mobile arena. Although WAP in general suffered many setbacks, WAP push has been quite successful because 2G networks do not really offer the equivalent of e-mail with attachments. WAP push technology is widely used in various applications:
04_4557.qxd
10/19/05
1:04 PM
Page 101
Content Services
101
• Sending ring tones, logos, games and other content to mobile devices. This is one of the most lucrative mobile applications apart from voice and short messaging. • Over the air (OTA) configuration of handsets, which is sometimes referred to as device management (DM). • Implementing MMS. There is more about this in Section 3.3. Just like plain WAP, the WAP push service involves a gateway that mediates between content providers on the Internet and devices connected to mobile devices. Such a gateway is called a push proxy. WAP push uses two protocols: 1. Push access protocol (PAP) is used by the push initiator (the content provider) to submit push content to the push proxy. This protocol usually runs over plain HTTP. It consists of a MIME encapsulated XML format for specifying the content itself, which may be multipart, and the delivery conditions, sent with a HTTP POST message to the proxy. 2. Push over the air protocol (OTA) is used by the push proxy to send the content to the mobile device. This protocol can run over WSP (the WAP session protocol), or standard HTTP, if the mobile network is GPRS or 3G and supports standard TPC/IP. The push proxy gateway not only mediates between PAP and OTA, but can also cache push content until it is delivered to the mobile device. The proxy may also authenticate the push initiator before accepting its push request. Figure 4.8 shows a confirmed WAP push transaction: 1. The push initiator initiates the push transaction by sending an HTTP POST message to the push proxy, which contains the content encoded in a MIME multipart body. PAP-specific parameters are specified in XML and embedded in this MIME body as well. The push initiator can be any HTTP client capable of sending a POST request. The push proxy immediately sends back a 202 accept message if the HTTP message was correctly received, regardless of errors that may have occurred in PAP or OTA delivery. This is because the 202 accept message refers only to the HTTP dialogue. 2. Before forwarding the push content to its destination, the push proxy may store it for a specified time (for example, if the push initiator has indicated delivery at some future time, or for as long as the destination device is disconnected), and may adapt the content to the destination device.
04_4557.qxd
10/19/05
1:04 PM
102
Page 102
Implementing Value-Added Telecom Services
(2) (3) OTA Po-ConfirmedPush.req
Mobile network OTA Po-ConfirmedPush.cnf Client (4)
WAP Push Proxy
MIME multipart
(1) HTTP POST
Internet HTTP POST (5)
Push Initiator (HTTP client)
Result notification
Figure 4.8 WAP push.
3. The push proxy delivers the push content to its destination. In this example we assume that delivery is over WSP, and requires confirmation. It is also possible to send unconfirmed push content. 4. Upon successful delivery, the target device sends back a confirmation message to the push proxy. 5. The push proxy sends back the result notification to the push initiator in the form of an HTTP POST message. This information is encoded as XML in the multipart MIME body of the HTTP message. Note that the push initiator acts both as HTTP client (in step 1) and HTTP server (in this step). Although the example of Figure 4.8 assumes WSP is the carrier for the OTA protocol, WSP can be implemented over different bearers. This leaves us with the question: How is push content actually sent to mobile devices? A common way of delivering WAP push content to mobile devices is by sending a specially formatted SMS, containing a URL that points to the content on a server. Instead of showing the message to the subscriber, the mobile device interprets it, and goes to the specified URL to retrieve the content. This means that step 3 in Figure 4.8 is actually implemented by a push message (SMS) followed by a pull transaction (retrieving the content from a standard WAP server). This implementation need not affect the content provider, however, as he or she interacts with the push proxy through PAP and does not need to worry about delivery to the destination device. WAP push can be billed per item or per subscription. A common way of billing for WAP push is to let the subscriber order the content first by sending a premium-rate SMS,4 or by calling a premium-rate telephone number. This is how many download sites for ring tones and logos operate. 4. More about premium-rate short messaging can be found in Chapter 3.
04_4557.qxd
10/19/05
1:04 PM
Page 103
Content Services
103
I-mode also allows content to be pushed to subscribers using standard e-mail. The procedure is similar to the one discussed in this section for WAP: A content provider submits content to the i-mode gateway, which pushes it to the mobile device. In the case of i-mode, however, the protocols are standard e-mail (POP and SMTP) and HTTP.
Examples for Section 4.5.2 NowSMS (http://www.nowsms.com) of London, United Kingdom, provides a push proxy gateway and client software that allows for easy submission of push content to the gateway. SMS2Email (http://www.sms2email.com) of Leeds, United Kingdom, also offers WAP push with SMS alerting. They will let the customer try it out for free, without registering. Mediaplazza (http://us.mediaplazza.com) of France is one of the largest providers of mobile phone content, including ring tones, logos, and games. Mediaplazza supports several means of content billing, but the most common way is by letting the subscriber send a premium-rate SMS, or call a premium-rate number, to order the content by its catalogue code. The content is then pushed to the subscriber’s mobile device. Mediaplazza offers an affiliation program that allows third parties to sell their content for commission. An example affiliate content site is http://www.hit-logo-ringtone.com.
4.6 Streaming Content Up to this point we have tacitly assumed that content comes in discrete form: a book, a file, a ring tone, a logo. But there is also content consumed in a more continuous way. For example, most of us prefer watching a football game in real time rather than downloading it as a video file after the match is over. This type of content, which is consumed directly as it is transferred, is called streaming content. There are several characteristics that set streaming content aside from downloaded or browsable content: 1. There must be a continuous flow of information from server to client. Streaming content does not tolerate intermittent connectivity, and requires a minimum bandwidth to be constantly available. 2. Streaming content is less sensitive to errors and may have value even if not delivered completely. By contrast, downloaded content that is corrupted or incomplete usually does not render, and has no value
04_4557.qxd
104
10/19/05
1:04 PM
Page 104
Implementing Value-Added Telecom Services
whatsoever. Watching only part of a concert can be considered to have certain value, even if it is not the same as seeing the whole concert. 3. In some cases, the added value of streaming content is in the event’s timeliness, rather than the quality of sound or image (e.g., sports matches). This means that streaming content has different requirements, both in terms of technology and charging. 4.6.1 Streaming over IP Less than a decade ago, streaming was almost synonymous with radio or television. Neither dial-up Internet nor mobile networks offered sufficient data rates to deliver music or video of any quality. But ADSL, cable, IEEE (Institute of Electrical and Electronics Engineers) 802.11b standard for wireless LAN (WIFI), and 2.5G/3G networks have changed this. Streaming content over IP is now a reality both for fixed and mobile subscribers. There are several types of streaming content and several ways to get it from the server to one or more clients. The main categories of streaming content are audio, video, and Web cast (typically slide presentations with text or audio). Streaming over IP is normally done with the Real-Time Streaming Protocol (RTSP). A streaming content provider will need to install a RTSP server that is dimensioned to handle as many concurrent streams as needed. There are four ways to route streaming media through an IP network: 1. Unicast: The server sends a separate packet stream to each client. This is the usual communications model for TCP/IP. The advantages are that the server can deliver individual information to each client, and that all routers on the Internet support unicast. The disadvantage is that the streaming packets are duplicated for each client, resulting in high bandwidth demand. 2. Broadcast: The server sends a packet stream to all clients within a certain IP address range. For obvious reasons, most IP routers will refuse broadcast traffic, or limit broadcasting to subnets only. Version 6 of the Internet Protocol (IPv6) does not support broadcast anymore. 3. Multicast: The server sends a single packet stream to all clients in a previously defined multicast group. This type of communications requires the assignment of special IP addresses reserved for multicast communications and management of multicast groups through a special Internet Group Management Protocol (IGMP). 4. Anycast: The server sends a single packet stream to any one client of a multicast group. This transmission mode is supported only by version
04_4557.qxd
10/19/05
1:04 PM
Page 105
Content Services
105
6 of the Internet Protocol (IPv6), and is mostly intended for supporting application failover. Of these four options, unicast is still used in most cases to stream content from clients to servers, even though it is less bandwidth efficient than multicast. Multicast is a bandwidth-saving alternative if several clients are to receive the same content simultaneously. Broadcast and anycast are virtually unused at present. An alternative way to broadcast IP packets is by sending them over broadcast channels like terrestrial digital television (DVB-T) or digital radio. This technique, called IP datacast (IPDC), is essentially different from IP broadcast or multicast in that it does not really involve IP routing. 4.6.2 Media Coding and Decoding When streaming audio or video over IP, the server must encode the audio or video signal into a packet stream that matches the characteristics of the connection, and the client must decode it at the other end. Choosing the right audio or video codec (coder–decoder) is a hard trade-off between bandwidth and quality. There are many standard and proprietary codecs available for audio and video today. Common standards that originated in the MPEG are:5 • MPEG-2 (and MPEG-1, which is a subset of the former) are standards for video coding and decoding, used among others in video CD and digital television. • H.264 is a video codec standard from the ITU-T and ISO that allows high-quality video at relatively low bit rates. H.263 is an alternative video codec used mostly for videoconferencing. • MPEG-4 is an elaborate standard for multimedia coding that supports interactivity, synthetic content, and digital rights management. It actually includes several codecs and media formats. • MPEG audio layer 3 (MP3) uses perceptual coding to compress CDquality audio into a 112–128-Kbps bit stream, corresponding to a compression rate of up to 1 through 12. Stronger MP3 compression rates of up to 1:24 still give radio-quality audio. In addition 3GPP has specified codecs and a file format called 3GP for mobile video and multimedia streaming.
5. Strictly speaking, these are not standards in themselves, but specifications that have been adopted as standards by official standardization bodies like ISO.
04_4557.qxd
106
10/19/05
1:04 PM
Page 106
Implementing Value-Added Telecom Services
4.6.3 Streaming Servers It is perfectly possible to implement a streaming server with standard codecs and open-source platforms. There are also providers of complete streaming solutions, which may be proprietary or standards based. The most commonly used streaming servers on the Internet today are: • Microsoft Windows Media (http://www.microsoft.com/windowsmedia) supports several codecs, which include Microsoft’s own Windows Media 9 series, as well as the MP3 and MPEG-4 standards. Windows media uses the proprietary Advanced Systems Format (ASF) for storing synchronized multimedia content. This format also supports digital rights management. As can be expected, Microsoft offers extensive server software for Windows Media streaming. • Real Networks (http://www.realnetworks.com) uses its RealAudio 10 and RealAudio 10 codecs, but can also handle MP3, MPEG-4, 3GP, and a host of other industry standard codecs. Its Helix product line of streaming servers ranges from step-in servers that can handle 25 streams at a time, to large distributed server systems that can handle thousands. • QuickTime (http://www.apple.com/quicktime) is Apple’s media streaming technology, though Quicktime also runs under Microsoft Windows. The Darwin streaming server is an unsupported open-source version of Apple’s commercial QuickTime Streaming Server (QTSS), especially intended to enable portability to other platforms. QuickTime can handle MPEG-4, MP3, 3GP, and other standard formats. It is impossible to recommend any of these as the best. The choice really depends on the type of connection, the type of content, the client platforms it is delivered to, and on personal preferences. In most cases, the client software (the media player) is distributed for free, so as to ensure a maximum customer base. 4.6.4 Streaming for Mobile Devices When talking about bringing content to mobile devices in Section 4.3, one of the main concerns was the limited bandwidth and device capabilities. The same restrictions also affect streaming content for mobiles. This has direct consequences for the technology used: • The codecs must deliver the best possible audio or video quality at relatively low bandwidths. • The server must be able to adapt the media stream to varying transmission speeds and conditions.
04_4557.qxd
10/19/05
1:04 PM
Page 107
Content Services
107
• The client software must run in a restricted execution environment (little memory and processing power, reduced operating system, limited input/output (I/O) facilities). All the streaming solutions mentioned in Section 4.6.3 can also be applied to mobile networks, with adapted codecs and client software. There are also companies, such as Packet Video, that specialize in streaming for mobile devices. Pure streaming can be difficult in situations in which the quality of the air link fluctuates. In this case, it can be advantageous to use a combination of streaming and download, called progressive download. In essence, this is plain download, except that the client software will start rendering the content before the complete file has been downloaded. Rendering and downloading then proceed in parallel. Progressive download combines the advantages of near real-time content delivery with constant quality, even at variable data rates, because the content is effectively buffered before rendering. It also allows the downloaded content to be stored on the client device for future use. Progressive download uses standard HTTP or FTP as download protocols, which means that it does not require special server software, and is relatively insensitive to firewall protection at the client side. There are also disadvantages, however, the most important being that progressive download is not suitable for real streaming content, like real-time events (sports matches, webcams). Also, progressive download requires the content to be stored on the mobile device, which makes it less appropriate for long movies or audio files, which take up a lot of storage space. Table 4.2 compares some of the characteristics of streaming and progressive download.
Table 4.2 Streaming Versus Progressive Download Property
Streaming
Progressive Download
Real-time content
Yes
No
Broadcast and multicast
Yes
No
Long movies or concerts
Yes
No
Protocol
RTSP
HTTP, FTP
Constant quality a varying data speed
No
Yes
Firewall sensitive
Yes
No
Retransmission of lost packets
No
Yes
04_4557.qxd
108
10/19/05
1:04 PM
Page 108
Implementing Value-Added Telecom Services
Examples for Section 4.6.4 Packet Video (http://www.packetvideo.com) of San Diego, California, is one of the major vendors of streaming solutions for mobile devices. Their client and server software will run on almost any available operating system. The 3GPP compliant AAC Audio codec optimizes audio compression for mobile networks. Packet Video’s FrameTrack technology ensures that the video stream is adapted to the varying bandwidth conditions. Packet Video also offers progressive download, a mixture of download and streaming. Scandinavian operator TeliaSonera (http://www.teliasonera.com) offers streaming video services to 3G terminals, using the 3GPP media format and the RealNetworks platform. A pilot for mobile TV using IPDC has been available since October 2004, with CNN being one of the live channels that can be accessed via mobile phones.
4.6.5 Charging for Streaming Content In the introduction of this section, we have observed that streaming content differs from downloaded content, not only in technology but also in terms of value and charging. This raises the question: How and what does one charge for streaming content? In fact there is not one unique way of billing for streaming content, and many of the mechanisms for browsing content (Section 4.1) are also valid for streaming: • Per subscription: The user pays for access to a category of streaming content for the duration of the subscription; • Per item: The user pays for one particular item of streaming content; • Per duration: The user purchases the right to watch streaming content for a certain duration. The dialer-based approach of Section 4.2.4 can be used to bill content streaming against a subscriber account. Streaming content may not be essentially different from downloaded content in terms of coding and file format, but its perception of value by the user can be very different. Downloaded content, such as audio or video, usually only has discrete value, that is, it only has value if it has been downloaded completely and uncorrupted. Streaming content by contrast can have partial value. For example, if a user sees part of a sports match, one can argue it is still fair he or she pays for the part watched, even if it is not the complete match. Duration-based charging therefore makes more sense with streaming than with downloaded content, since you pay for what you have seen up to a given point in time.
04_4557.qxd
10/19/05
1:04 PM
Page 109
Content Services
109
A similar argument goes for progressive download, which is a mixture of download and streaming. If a client interrupts a progressive download, then the downloaded file is not complete, but the user may still have watched or listened to the part that was downloaded progressively. One can argue that it is fair to charge the user for at least the part downloaded. Charging for streaming or (progressively) downloaded content can be particularly complicated in mobile networks, as shown in the next section.
Example for Section 4.6.5 MotoGP.com (http://motogp.tiscali.com) by Dorna Sports S.L. of Madrid, Spain, is a portal for motorcycle racing content that offers high-quality pay-perstream video.
4.6.6 Mediation Most mobile network operators charge for communications either by volume (per kilobyte or megabyte), or by airtime (per second), or a combination of the two. This charging principle, which is still a legacy from the telephony era, is proving inadequate for content download and streaming. The problem is that the user’s perception of the value of communication is elastic, and varies with the content accessed, while charging per megabyte or per second is rigid. Let us consider an example. A subscriber may be perfectly willing to pay 10 cents for sending a short message (SMS) of 160 bytes, but is much less likely to pay $1,966 for downloading a 3-Mb audio file, even if the cost per byte is the same (0.0625 cents)! In other words, the price that a user is willing to pay per transferred byte depends completely on the service or content. Things get even more complex if the content provider is a third party, and also wishes to charge for the content itself. In the worst case, the user may end up with several charges for a single content download: one for the airtime used, another for the byte volume, and yet another for the content itself. This may seem exaggerated, but cases like these do exist and are creating unnecessary barriers for the content business. This is why some operators now use mediation devices to create a single bill from several charging components. Mediation also allows the supplier to adapt the price of the communication to the content purchased. The principle of mediation is shown in Figure 4.9.
04_4557.qxd
10/19/05
110
1:04 PM
Page 110
Implementing Value-Added Telecom Services
HTTP server
Mobile network BSC
SGSN
GGSN
Internet
BTS WAP gateway R
CDR
CD
IP
DR
Mediation
IPDR
Bill
Figure 4.9 The principle of mediation.
As an example consider the download of a document on an HTTP server through a WAP gateway using GPRS. As Figure 4.9 illustrates, the equipment across the communications chain generates different charging records, which are collected and correlated by the mediator to create a single bill for this event. Network equipment typically generate CDRs, but in the case of Internet equipment they can also generate IP data records (IPDRs) or even proprietary event records. Although the principle of mediation is easy to grasp, its implementation is not trivial. Mediation often relies on the correlation of very different data elements. For example, the access to URL http://www.myserver.com/song.mp3 recorded by an HTTP server and the transmission of 3,250,585 bytes of data recorded by a gateway GPRS support node (GGSN) could be part of the same download transaction. The mediator typically uses packet labeling, time stamps, session identifiers, or a combination of these to correlate the different chargeable events. Mobile network operators tend to apply mediation only in a walled-garden setting, where all equipment is within their management domain. This is because correlating data with events recorded outside their domain is simply too difficult. Most mediation solutions are proprietary, but OSA-Parlay provides an open interface for third-party charging. In the next section we take a closer look at this interface.
04_4557.qxd
10/19/05
1:04 PM
Page 111
Content Services
111
Examples for Section 4.6.6 Comptel (http://www.comptel.com) of Helsinki, Finland, provides mediation solutions for off-line and online billing. Hewlett-Packard of Palo Alto, California, (http://www.openview.hp.com/products/iumgprsm) also provides mediation as part of its Openview product suite. Highdeal (http://www.highdeal.com) of Caen, France, offers a rating engine that can calculate prices, commissions, and royalties dynamically.
4.6.7 OSA-Parlay Mediation Interface The OSA-Parlay charging interface allows third parties to report charging events to the network operator. It can be seen as an external mediation interface, which makes it very interesting for third-party content providers. Instead of providing CDRs and IPDRs to the operator for off-line mediation, the OSA-Parlay charging interface lets a third-party content provider make charges directly to mobile subscription accounts. This means that the operator can confirm the charges immediately, and can correlate them in real time with other network events like streaming sessions or file downloads. The OSA Parlay charging interface offers two distinct charging models: 1. Direct charge: Without prior reservation, the charge is made directly to a subscriber’s account. The server may reject the charge, for example, in case of bad credit, so this charging mode is mostly used for micropayments. 2. Reservation and payment in parts: The client can reserve amounts in the subscriber account and charge them later. This is mostly used for streaming and point-to-point communications, similar to the way shown in Figures 2.5 and 2.7. Moreover, the interfaces offer a number of options for charging. Here are two of them: 1. Split charging: Charges can be split among more than one user, for example, in the case of multiparty games. The OSA-Parlay interface allows the identification of more than one charged party for a charging session, but does not support dynamic definition of how the charges are divided between them.
04_4557.qxd
10/19/05
112
1:04 PM
Page 112
Implementing Value-Added Telecom Services
2. Currency or volume-based charging: The charging interfaces allow for charging amounts of money, or charging units of volume to a subscriber account. The OSA-Parlay charging interfaces are built on the concept of a charging session. In technical terms, a charging session is an object that is created for the duration of a chargeable transaction (for example, access to a WAP or Web site), and to which the third party can report its charging events. Figure 4.10 illustrates how OSA-Parlay interfaces can be used to charge for streaming content, using reservation-based charging. The steps are the following: 1. The third-party content server receives a request for streaming content from a client. 2. The third-party requests the creation of a new charging session by invoking the createChargingSession method on the operator’s IpChargingManager interface. In this method of invocation the third-party identifies both its own merchant identifier and the subscriber for which the session is created. This results in the creation of a new IpChargingSession object at the operator side.
(1) Content request
Third-party streaming server (2) (3)
Stream content
IPApp Charging Session
IP Charging Manager
IP Charging Create Session reserveAmountReq(app, parameters, preferred, minimum)
Third-party domain Figure 4.10 Streaming content charging with OSA-Parlay.
Operator domain
04_4557.qxd
10/19/05
1:04 PM
Page 113
Content Services
113
3. Before starting the streaming of content to the user, the third-party server first reserves an amount of credit in the user’s account. This is done by invoking the reserveAmountReq method on the IpChargingSession object created in the previous step. The thirdparty indicates the preferred amount it wishes to reserve, and can also indicate a minimum reservation it is willing to accept, in case the reservation cannot be granted completely. The third-party can also indicate the application for which the reservation is made (e.g., streaming content), and can set a number of additional charging parameters. The IpChargingSession will respond with the reserveAmountRes method, which indicates the amount reserved. The third-party server will now start streaming content to the client. 4. After a certain time has passed or volume has been sent, the third party will request payment of the reserved amount (or part thereof), by invoking the debitAmountReq method on the IpChargingSession object. The charging session will respond by calling back the debitAmounRes method, indicating the amount debited and the amount reserved left (if any). 5. The third party will repeat steps 3 and 4 for as long as there is content to stream to the client. 6. When the streaming has terminated and there are no more events to charge, the third party can request the release of the charging session, which will result in the deletion of the IpChargingSession object. OSA-Parlay does not specify exactly how the operator processes the events reported to this object in steps 2 through 5. Typically, an operator will store them in a charging database for later processing and settlement. Section 6.4.4 revisits the OSA-Parlay charging interface in more detail, in the context of e-commerce.
4.7 Content Protection Companies whose business is content generally want to protect it against piracy and abuse. Piracy is not a new problem. It has been around for as long as there have been printed books, radio, and tape recorders. Piracy is a complex phenomenon, as it seems to harm and nourish the content industry at the same time. The video recorder, and all the piracy that came with it, has not killed the movie business. Quite the contrary, it created a new market that is now bigger than that of movie theaters. A well-known software company is known to live by the philosophy that “If you are going to pirate any software, make sure it is ours.”
04_4557.qxd
114
10/19/05
1:04 PM
Page 114
Implementing Value-Added Telecom Services
But the Internet has lifted piracy to an unprecedented global scale, and has made illegal content sharing almost frictionless. The content industry is trying to answer with digital rights management (DRM) technology. 4.7.1 Many Options There are many ways to protect content and manage digital rights, depending on the type of content, the level of protection it requires, and the way it is delivered. Some of the methods used are: • Watermarking: This technique consists of adding some invisible information to the content that allows it to be recognized and tracked. The watermark is transparent to the rendering software, but can be detected with special tracking tools. Watermarking can be quite complex, as the watermark must be protected against manipulation.6 • Copy protection: Techniques to protect software to be copied have been around for as long as there are electronic media like floppy disks and CD-ROMs. There are different patented approaches to this. • Forward lock: A special case of copy protection is forward locking, which is mostly used with short messaging or multimedia messaging in mobile networks and devices. Forward lock puts a restriction on the number of times that content can be forwarded from one device to another. • Access control: This technique controls the use of digital content according to rights expressed in a rights expression language (REL). Different patented solutions exist, but they are almost all based on encryption techniques. In the following section we take a closer look at the last category of digital rights management solutions, which use rights expression languages to control access to encrypted content. 4.7.2 Digital Rights Management Although there are many DRM standards, they usually draw on the principles of cryptography. A content issuer provides encrypted content, which a user can freely download and store. To render the content, however, the DRM agent on
6. Of course, watermarking should be resistent to malicious manipulation, that is, attempts to remove the watermark, but it must also be resistent to nonmalicious manipulation, such as resizing or rotating a picture, which can inadvertedly remove or alter the watermark. Watermarking therefore often involves segmenting the content and adding a good deal of redundancy.
04_4557.qxd
10/19/05
1:04 PM
Page 115
Content Services
115
Encrypted content Content issuer Rendered content
DRM agent User
Rights issuer Rights object Figure 4.11 OMA digital rights management principle.
the client’s machine must obtain a rights object from a rights issuer. Figure 4.11 illustrates this scheme. The rights object contains the decryption key for the content, plus a document in the REL specifying under what conditions the DRM agent may render the content. The DRM agent that interprets the rights object and applies it to the content must be a trusted device. A DRM agent in OMA has a certified identity, and must register with a rights issuer with its digital certificate before it will be able to receive rights objects. Alternative DRM standards differ in the REL they use and the protocols to distribute the rights object. The open digital rights language (ODRL), for example, recognizes permissions (for example, read, write, execute), constraints (number of plays, validity time), and users (permitting only specific authenticated users to render the content). Figure 4.12 shows a sample of another REL, Extensible Rights Markup Language (XrML). The root XrML element is the license, which defines the rights of one or more users on one or more digital resources. The license contains two parts, the list of grants and the issuer. Each grant identifies a particular user and a digital resource, and specifies what rights the user has over the resource and under what conditions. There can be more than one grant in a license. The issuer part verifies the issuer of the license, and provides any additional details. The most common way for an issuer to authenticate itself is by digital signature.
04_4557.qxd
116
10/19/05
1:04 PM
Page 116
Implementing Value-Added Telecom Services
..... ..... ..... ..... <details> .....
The grant defines the rights that each party has over the digital resource(s): Information about the rights holder(s)
Description of the digital resource(s), for example, a URL License conditions, for example, the interval of validity This part describes the license issuer: Authentification of the issuer, typically by digital signature Details about the license issue, for example, date and time
Figure 4.12 Simple license example in XrML.
4.7.3 DRM Standards Among the most important digital rights management standards today are MPEG-21 and OMA DRM. Both have their own rights expression language: MPEG-21 uses the XrML and OMA uses an extension of the ODRL from W3C.7 XrML is widely used in MPEG-compatible systems, has been adopted by the Open eBook (OeB) Consortium, and is also used by Contentguard, one of the principal providers of proprietary DRM solutions. ODRL is more popular in the Web services and W3C community, and has also been used as the basis for the DRM standards of OMA. XrML and ODRL are incompatible, though recently researchers have created an ODRL profile for XrML, allowing ODRL rights expressions to be converted to XrML [1]. Apart from MPEG-21 and OMA DRM, there are many other DRM standards and proprietary solutions, as Table 4.3 shows (in alphabetical order). 7. Although XrML and ODRL are standards, their origins are proprietary. XrML comes from Contentguard (with participation from Microsoft Corporation) and ODRL comes from IPR Systems (an Australian company).
04_4557.qxd
10/19/05
1:04 PM
Page 117
Content Services
117
Digital rights management is a relatively new technology. Today’s technologies are still maturing, and there is still a great deal of divergence in technology and standards. DRM technologies are strongly patented, which makes most DRM applications subject to licensing. Table 4.3 A Sample of Digital Rights Management Standards Forum
Standard
Description
CRF
Contract Expression Language (CEL)
Contract expression language of the Content Reference Forum (CRF), mostly intended for consumer-to-consumer marketing, P2P file exchange, and content referral. http://www.crforum.org
ISMA
ISMA1.0.1
Internet Streaming Media Alliance (ISMA) standards suite includes digital rights management standards for streaming media. http://www.isma.tv
MPEG-21
XrML
Extensible rights markup language, one of the most prominent digital rights expression languages, based on XML. http://www.mpeg-21.org
OASIS
XACML
Extensible access control markup language (XACML), a language for defining access rights to digital resources, part of the Organization of the Advancement of Structured Information Standards (OASIS) suite of languages and protocols for electronic commerce. http://www.oasis-open.org
OMA
REL, ROAP
The Open Mobile Alliance’s (OMA) rights expression language is an extension of ODRL, and the rights object acquisition protocol (ROAP) is a protocol for acquiring rights for digital resources. The OMA DRM standards are mostly intended for use in mobile networks and devices. http://www.openmobilealliance.org
SDMI
PDS
The Secure Digital Music Initiative (SDMI) Portable Device Specification (PDS) is an open standard for watermarking and copy protecting digital music (including CD and MP3).
W3C
ODRL
Open digital rights language, W3C’s widely used rights expression language for digital resources, based on XML. http://www.w3.org
04_4557.qxd
118
10/19/05
1:04 PM
Page 118
Implementing Value-Added Telecom Services
MPEG-21 and OMA DRM are public standards, but that does not mean their application is license free, as private companies have patented the general principles behind them. The industry currently debates the implications of this seemingly contradictory situation, and the dangers it may hold for the content industry. 4.7.4 DRM-Enabled Content Business DRM opens doors to new business roles and business models. Perhaps the most promising new business scheme is superdistribution, whereby users can copy, exchange, and store encrypted content, but must obtain rights objects to render it. Superdistribution could become a legal and secure way of file sharing, which has become popular on the Internet. Picking the right digital rights management solution for a particular business is not a simple task. Sometimes the simplest solution is the best, and there are even situations in which it makes sense not to protect the content altogether. Some considerations to take into account when looking for the right technology are: 1. What kind of content are you selling? Some solutions may work better for certain types of content. For example, watermarking may work fine for images, but may not be as appropriate for streaming. 2. What is the value of the content you are selling? Does it weigh against the cost of the content protection software? 3. How complex are the rights you want to define? Do you want to define just one class of users, or are you considering more complex licensing structures? 4. What life cycle does your content have? Can it be stored? Copied? Forwarded? Does it loose value over time? 5. Do you need special client software on the playback device? In general, the more transparent the content protection solution is to standard playback software, the more likely it is to be accepted by your customers. 6. How much trust do you have in your customers? Is your content hacker sensitive?
Examples for Section 4.7.4 Contentguard (http://www.contentguard.com) of Bethesda, Maryland, a joint venture of Microsoft and Time Warner, in which Xerox Corporation also has a
04_4557.qxd
10/19/05
1:04 PM
Page 119
Content Services
119
small stake, is one of the most important providers of digital rights management technology. Contentguard’s patented technologies are compatible with the MPEG-21 XrML standard. Digimarc (http://www.digimarc.com) of Beaverton, Oregon, provides watermarking solutions for digital content. Their technology not only lets one watermark the content and notify the user of the copyright, but also allows the content to be tracked as it is distributed to authorized and nonauthorized sites. Zapper Software (http://www.zappersoftware.com) of British Columbia, Canada, provides free software for MP3 music protection. The MP3Guard software encrypts the MP3 files, which can only be played if one has the decryption key and the MP3Guard client software (player).
Reference [1]
Delgado, J., J. Prados, and E. Rodríguez, Profiles for Interoperability between MPEG-21 EL and OMA DRM, 2005 IEEE Congress on Evolutionary Computation, Edinburgh, U.K., September 2005.
Selected Bibliography http://hoohoo.ncsa.uiuc.edu/cgi, CGI developers resources http://java.sun.com/products/jsp, JSP developers resources http://motogp.tiscali.com/, payable streaming content site http://msdn.microsoft.com/asp.net, ASP developers resources http://web.resource.org/rss/1.0/, real simple syndication (RSS) resource page http://www.apple.com/quicktime, QuickTime home http://www.comptel.com, provider of mediation solutions http://www.contentguard.com, provider of digital rights management solutions http://www.coulomb.co.uk, provider of dialer solutions http://www.crforum.org, Content Reference Forum http://www.digimarc.com, provider of watermarking solutions http://www.firstgate.com, billing service for online content http://www.highdeal.com, provider of real-time rating engines http://www.i-mode.com, NTT DoCoMo’s i-mode site http://www.inetis.com, Web-based WML content management
04_4557.qxd
120
10/19/05
1:04 PM
Page 120
Implementing Value-Added Telecom Services
http://www.ipdc-forum.org, IP Datacast Forum http://www.ipdr.org, IPDR Consortium http://www.isma.tv, Internet Streaming Media Alliance http://www.kannel.org, open-source WAP gateway http://www.magsys.co.uk, provider of dialer solutions http://www.mediaplazza.com, provider of mobile-oriented content (ring tones, logos, games) http://www.microsoft.com/windowsmedia, Windows Media home http://www.mpeg-21.org, MPEG-21 home http://www.msitebuilder.com, Web-based WML content management http://www.nowsms.com, provider of WAP push proxy gateway http://www.oasis-open.org, OASIS portal http://www.openmobilealliance.org, Open Mobile Alliance http://www.openwap.org, portal for open WAP software http://www.packetvideo.com, provider of streaming solutions for mobile http://www.php.net, PHP developers resources http://www.realnetworks.com, Real Media home http://www.riskcenter.com, premium content for the risk business http://www.sms2email.com, provider of WAP push with SMS alerting http://www.telcopay.com, payment service for third-party WAP content http://www.w3.org, World Wide Web Consortium http://www.zappersoftware.com, provider of freeware MP3 protection
05_4557.qxd
10/19/05
1:07 PM
Page 121
5 Location-Based Services The previous chapters have treated prepaid communications, messaging, and content, all services that represent added value in themselves. Some of these services can take on an additional value dimension if the location of a user were to be taken into account to provide a more personalized, context-sensitive experience. Location-sensitive services are only meaningful in networks where users are mobile, and their location can be tracked. Cellular mobile networks are especially suitable for providing location-based services because of their widespread deployment. Mobile phones have become feature-rich, personal devices that support a broad range of communication services and can even run local applications. However, it is also possible to provide location-based services for wireless local or metropolitan area networks (WLANs or WMANs). The idea of enriching applications and content with location information is easy enough to grasp, but how difficult is it to determine the location of a user? This question is not so easily answered, as there are both technical and legal aspects to take into account:
121
05_4557.qxd
122
10/19/05
1:07 PM
Page 122
Implementing Value-Added Telecom Services
• What exactly does the location or position of a user mean?1 Is it a set of precise geographical coordinates, a street address, a company or domain name, or some other indication of context? • What resolution is needed for services to be meaningful? Do you need location information down to thousands, hundreds, tens, or individual meters? • What technology is available to locate a user? Does the technology selected require additional hardware or software in the network, or in the terminal, or both? Is the location information controlled by the mobile network operator, or can it be provided by a third party? • What does it cost to locate a user, both in terms of equipment and traffic? And what is the user’s perceived value of a location? • Does the country’s or region’s legal context allow for users to be located? How is the user asked for permission to be located? How is the user’s privacy protected? This chapter answers some of these questions by examining the technology available today for providing location-based services. In it we also analyze some location-based applications, their implementations, and some privacy questions.
5.1 Location Techniques There are many ways to locate a terminal in a mobile network. Each location technique has its own complexity, its resolution, cost, time, advantages, and drawbacks. It is possible to combine several location techniques to obtain higher resolution, faster response, or both. The mandate for wireless emergency calls has been one of the main drivers for deploying location services in mobile networks worldwide. The relatively high resolution required by this mandate has prompted network operators to deploy better location techniques, which are now also becoming available for commercial applications. Different types of location-based services require different resolutions, as Table 5.1 illustrates (adapted from 3GPP Specification 23.271).
1. The technical literature employs both the words location and positioning, and there appears to be some ambiguity as to what they mean. The word positioning usually refers to the algorithms used in determining the exact geographical positioning of a terminal, while location is also used in the broader sense of location management in 2G and 3G networks. This broader meaning of location includes the interaction between HLR (or HSS in 3G networks) and VLR to determine where a subscriber is roaming.
05_4557.qxd
10/19/05
1:07 PM
Page 123
Location-Based Services
123
Table 5.1 Resolution for Location-Based Services Resolution
Types of Service
> 1 km
Local news, weather, and traffic reports
500m to 1 km
Location-based information services, route planning, fleet management, local traffic information
75m to 125m
Local advertising, home zone services, location-based information services, tracking of vehicles and assets
10m to 50m
Navigation, tracking of persons and assets
100m (67%) to 300m (95%)
U.S. FCC Mandate 99-245 for wireless emergency calls using network-based positioning methods
50m (67%) to 150m (95%)
U.S. FCC Mandate 99-245 for wireless emergency calls using terminal-based positioning methods
The most frequently used location techniques are cell ID–based location, GPS and assisted GPS, and triangulation techniques. The following sections consider the characteristics of each of these techniques. 5.1.1 Cell ID–Based Location In GSM networks a terminal is always connected to a specific base station during conversation. The radio network knows what base station a terminal is connected to, which gives a certain indication of the location of a terminal. The margin of error of this method of location is the area covered by a base station, in other words, the radius of the radio cell. A radio cell can vary in size between 100m in densely populated areas and tens of kilometers in the country. What determines the cell size is the population and traffic in a certain area. The more capacity required, the more base stations per square kilometer are needed, and therefore the smaller the cell size. Cell-based location is therefore more accurate in metropolitan areas than in rural settings. To illustrate the unpredictable resolution of cell ID–based location, consider the following example. Have you ever experienced looking for a gasoline station in your vicinity, and found that the address provided was at the other end of town? This can be due to the use of umbrella cells in high-density areas, which can seriously complicate location procedures. An umbrella cell consists of a high power base station with a high antenna serving a wide area, to pick up any overflow traffic that cannot be handled by the smaller cells, and to facilitate smoother handovers. If a terminal connects to an umbrella cell, then the resolution of its location drops dramatically.
05_4557.qxd
124
10/19/05
1:07 PM
Page 124
Implementing Value-Added Telecom Services
Cell ID-based location techniques can be enhanced by measuring the strength of the radio signal received. This gives some indication of how far the mobile is from the base station itself, though it is very sensitive to error due to obstacles and multipath propagation. Another way to improve cell-based location is by using the timing advance (TA). The coordinates of base transceiver stations are usually not disclosed to the public by the mobile network operator. If the mobile network locates a mobile user via cell ID, it does not reveal the cell ID outside the network, but maps it onto a geographic service area. In 3G networks things are slightly more complicated, for two reasons. First, the base station identifiers are meaningless, because of the strict separation between the radio network and the core network. 3G base station identifiers are only used inside the radio network and are not even known in the core network. Second, terminals can be connected to more than one base station at the time in CDMA networks. This, combined with soft handovers, makes the relationship between terminals and base stations much more ambiguous in CDMA. For this reason, CDMA networks tend to use triangulation techniques to locate terminals. In spite of the problems mentioned and the relative inaccuracy, cell ID is probably the most commonly used location technique in cellular networks today. The enormous advantage of this location technique is that it does not require any additional hardware or software, either in the network or in the terminal, which makes it immediately available for all subscribers at low cost.
Example for Section 5.1.1 MobileLocate of Guildford (http://www.mobilelocate.co.uk) is a third-party U.K. provider of location services, which obtains cell ID–based location information from any of the United Kingdom’s mobile networks. Note that the subscribers of the terminals to be located must give explicit consent each time they are located.
5.1.2 Enhanced Observed Time Difference Enhanced Observed Time Difference (E-OTD) is one of the most common terminal-based location techniques. It works like this: Terminals in the network record each time they receive a synchronized signal from the surrounding base stations and send a periodic report of this back to the network. From the reports received from the different terminals and the known location of its base stations, the network calculates the unique position of each terminal. Figure 5.1 illustrates the principle of E-OTD.
05_4557.qxd
10/19/05
1:07 PM
Page 125
Location-Based Services
125
Reports
t 13
m3
Re
po
t 11, t 21, t 31 t 12, t 22, t 32 t 13, t 23, t 33
r t(t 1 3, t 2 3, t3 t 33 3)
t 23
bs1
t 11
bs3
t 31 t 21
Re
m1
por
t 22 Rep
Positionbs1 Positionbs2 Positionbs3
Position mobiles
t 12
3 2 t 2) 1 , t 2, t or t( 2
t(t 1 1 , t 2, 1 t3 1)
t 32
Known positions
m2
bs2 Figure 5.1 Principle of E-OTD positioning.
The main drawback of E-OTD is that it requires additional hardware, both in the terminal and in the base stations. On the other hand, its advantages are the rapid response time (2 seconds to locate a mobile), the high success rate (99% both indoor and outdoor), and the relatively good resolution of 100m. Basic E-OTD only works if there are sufficient terminals that support it in the network. If this is not the case, it is still possible to generate network timing information from only one or a few mobiles, if the reporting history is long enough. This provides a less accurate location, but does not require many EOTD enabled mobiles in the network.
Examples for Section 5.1.2 Cambridge Positioning System (CPS) of Cambridge, United Kingdom, (http:// www.cursor-system.com/), is the creator of Matrix, a popular E-OTD positioning system. Although Matrix relies on multiple terminal reports, CPS now also offers Matrix Solo, which works even if there is only one terminal in the network with this software. The U.S. mobile operators AWS, Cingular, and Voicestream use E-OTD in their GSM/time division multiple access (TDMA) networks.
05_4557.qxd
126
10/19/05
1:07 PM
Page 126
Implementing Value-Added Telecom Services
5.1.3 Uplink Time Difference of Arrival One of the most popular techniques that do not require special software in the terminal is Uplink Time Difference of Arrival (U-TDOA). In essence it does not differ much from E-OTD, except that it works the other way around: the network measures the signal from the terminal. One of the main drivers for U-TDOA has been the U.S. FCC mandate for wireless 911 emergency calls, which requires better resolution than cell ID, yet has to work with any terminal without any special software. U-TDOA can use from three to many base stations to locate a terminal. In general, the more base stations that receive a terminal’s signal, the better the triangulation result, and the better the resolution of the location. This means that U-TDOA usually performs better in high-density areas where there are many base stations around. U-TDOA has a very high success rate (99%), and also works indoors. It can achieve very good resolution of up to 50m in urban areas. However, one of its drawbacks is the latency of up to 10 seconds for a triangulation. This is because the network cannot rely on timing reports, as E-OTD can, and must do the triangulation separately for each specific mobile. Another drawback of U-TDOA is that the terminal must be communicating for it to be located. This means that in the case of a location request for a terminal that is not in active conversation, the network must page the terminal in order to force a communication.
Example for Section 5.1.3 TruePosition of Berwyn, Pennsylvania, (http://www.trueposition.com/), is a provider of the complete Managed Location System (MLS), which includes all network elements and software for location services. MLS supports several location methods, including the U-TDOA positioning system.
5.1.4 Global Positioning System GPS is a well-known satellite-based positioning system that is available anywhere on the Earth. GPS is independent of any telecommunications network, and requires special terminals (hardware and software) to perform positioning. Its resolution is very high, in the range of ten meters or less.
05_4557.qxd
10/19/05
1:07 PM
Page 127
Location-Based Services
127
GPS functions similarly to E-OTD in that it measures the observed time difference of signals arriving from different reference stations. There are two differences, however: 1. The reference stations are satellites orbiting at about 20,000 km above the Earth and making two complete revolutions per day (approximately one revolution per 12 hours). The satellite orbits are configured in such a way that there are always between 4 and 12 above the horizon at any time, at any position on the Earth. 2. The signal from the satellite contains the position of the satellite itself, which allows for the GPS terminal to compute its position. This is opposed to E-OTD, where the terminals simply send timing reports to the network, and the network computes their position. The key advantages of GPS are its general availability, its independence of any telecommunications network, and its high resolution. But there are also a few downsides to GPS that the next few paragraphs discuss. One of the problems with this technology is its poor performance indoors. In order for GPS to function, the terminal must receive signals from at least four satellites. This can be quite a challenge indoors, since the high frequency and weak satellite signals have problems penetrating walls and obstacles. Another important drawback of GPS is its acquisition delay. In order for a terminal to calculate its location, it must first find at least four satellites, receive their synchronized timing and positioning information, and then triangulate the position. Since the data transmission from the satellites is very slow, the complete acquisition procedure can take tens of seconds if the GPS receiver starts cold without being connected to any satellites previously. This latency can be unacceptable for certain applications. Finally, GPS is a completely different system from GSM or CDMA. To use GPS in a terminal means collocating all the electronics necessary for GPS reception and calculations. This means that GPS-enabled terminals are both more expensive and consume more battery power. While GPS is a U.S. system, the European community has plans to deploy a similar satellite-based positioning system called GALILEO. GALILEO is set to be operational in 2008, and is compatible in technology with GPS. This means that the same terminals will be able to use both GPS and GALILEO. 5.1.5 Assisted GPS The costliest part of GPS positioning is determining which satellites are currently above the horizon. If the terminal had previous knowledge of this, then it
05_4557.qxd
10/19/05
128
1:07 PM
Page 128
Implementing Value-Added Telecom Services
could tune into the right satellites directly, grab their timing signals, and compute its position within a matter of seconds. The principle of assisted GPS is to provide terminals with prior information about the satellites to be used in a particular area. Mobile networks can use the base stations to send such GPS satellite information over the signaling channel. This is called assisted GPS (AGPS) and can considerably improve the performance of GPS-based location. Figure 5.2 illustrates how AGPS works: the base stations maintain constant track of the visible satellite configuration, and send this information to terminals over the signaling channel. The terminal directly tunes into the timing signals of the most appropriate satellites and computes its position more rapidly. The only drawback of AGPS is that it requires information from the mobile network, which makes AGPS less independent than plain GPS. There are several ways to make plain GPS and AGPS work indoors. One possibility is to use a gyrocompass that takes over when the GPS signal falls below the threshold. However, a gyrocompass has the drawbacks of losing accuracy over time and of introducing extra hardware in the terminal. Another way is to use a technique called massively parallel correlation to obtain as many samples as possible of the available satellite signals in parallel, thus improving the performance indoors with weaker signals. Massively parallel correlation requires dedicated chips, and of course still requires at least some signal to be available indoors.
Timing signal Satellite information
Terminal Figure 5.2 Assisted GPS in mobile networks.
GPS receiver Base station
05_4557.qxd
10/19/05
1:07 PM
Page 129
Location-Based Services
129
Examples for Section 5.1.5 Globallocate of San José, California, (http://www.globallocate.com), provides chips for assisted GPS and holds a patent for indoor GPS based on massive parallel correlation. Nextel, Spring, and Verizon use AGPS in their CDMA networks, in combination with a triangulation technique for CDMA networks called advanced forward link trilateration (AFTL).
5.2 Location Architecture and Interfaces As the previous sections demonstrated, several different methods exist for positioning a terminal. Considering all the possible mobile networks (GSM, GPRS, CDMA, Universal Mobile Telecommunications System (UMTS) among others) these methods can be applied to, the result is a complex set of combinations. The standards community has tried to design a general location architecture that is compatible with all mobile networks and positioning methods. A widely accepted standard architecture for location services is that of the 3GPP (specifications TS 23.171 and TS 23.271). The 3GPP standard describes functions rather than equipment for location services. These functions can be allocated to any existing and new network elements, thus ensuring flexibility in implementation. Yet most implementations of location services introduce three specific network elements: 1. Gateway Mobile Location Center (GMLC): A server that bridges between the mobile network and external clients of location services. It authenticates the client, contacts the HLR for the status of the mobile to be located, and checks location permissions in the HLR subscriber profile, looks up which MSC is currently serving the mobile and sends the actual location request to that MSC. When the result comes back, the GMLC replies to the client in the requested format. 2. Serving Mobile Location Center (SMLC): This is the network element connected to the serving MSC that determines the available positioning method most appropriate to fulfill a location request. It executes the request by initiating the positioning procedures, and calculates the location from the results obtained. Note that the SMLC can combine different positioning techniques, if this best serves the request.
05_4557.qxd
130
10/19/05
1:07 PM
Page 130
Implementing Value-Added Telecom Services
3. Location Measurement Unit (LMU): This is the specific hardware and software needed to carry out a specific positioning technique, for example U-TDOA. It is normally collocated in the base transceiver station. Figure 5.3 illustrates the deployment of these network elements in a 2G network. In a 3G network the use of these elements is essentially the same, though the radio network elements and the positioning procedures are different. 3GPP uses MAP to carry the location requests and results in the network. The advantage is that 2G and 3G networks already use MAP, which is part of the SS7 signaling protocol stack. MAP is an extensible protocol, and all that is needed is a couple of new messages to support location services. Figure 5.3 shows that the GMLC is the only network element communicating with external clients of location services. This is to avoid clients connecting directly to mobile network elements, which would be unacceptable to most mobile network operators for security and privacy reasons. 3GPP specifies in detail the interfaces between the GMLC and other network elements: • Le to external clients: This is the interface that external clients use to make location requests, and to receive results back. • Lh to HLR: The gateway MSC (GMSC) uses this interface to query the HLR about the subscriber to be located and permissions to perform the location. It also queries the HLR for the MSC that is currently serving the mobile to be located, The GMLC needs this information to route the location request to the right MSC. • Lg to MSC or Serving GPRS Support Node (SGSN): This is the interface that the GMLC uses to send the location request to the serving MSC that will execute the location procedure. • Lc to SCF: This interface allows the CAMEL service control function to make location requests, for VASs that need location information. • Lr to another GMLC: This interface is for roaming, and allows a GMLC to revert a location request to the GMLC of the visited network. All the interfaces mentioned in the preceding points are based on MAP, with one exception: the external interface Le. This interface uses the Mobile Location Protocol (MLP) defined by another organization, OMA.2 MLP is the pro-
2. It was actually the Location Interoperability Forum (LIF) that started work on the MLP in 1999. The OMA adopted LIF in 2003, along with a host of other microfora for mobile applications, and now maintains the MLP.
05_4557.qxd
10/19/05
1:07 PM
Page 131
Location-Based Services
131
SCF
GMLC Lc
Lg
Lr
BSC LMU
SMLC
SGSN
Le
Lg
GMLC Lh
External client
MSC
HLR Radio network
Core network
Figure 5.3 Location architecture for 2G networks.
tocol available to external clients to request location services. The next section explains MLP in more detail. 5.2.1 Mobile Location Protocol (MLP) MLP is a simple protocol based on plain-text XML. OMA has defined its messages in the form of XML document-type definitions (DTDs). A DTD allows a well-formed XML document to be validated against a defined syntax.3 MLP specifies only a message format, and can function with any application layer protocol that supports request–reply-type dialogue and plain-text payload. One of the most common carriers for MLP is HTTP, the universally available plain-text request–reply protocol. MLP defines different types of location service, depending on whether the location request is initiated by a client application, by a subscriber, or by an emergency service. The standard service for a request from an external client application, leading to an immediate reply is called the standard location immediate
3. There are two ways to define XML (sub)syntaxes: DTDs and XML schema. DTDs are a special non-XML format for describing a syntax. XML schema are more recent, and use XML itself to describe an XML syntax. Though XML schema seem to become more popular, there are still organizations and standards that use DTDs instead. More on XML and DTDs can be found in Appendix A2.1.
05_4557.qxd
132
10/19/05
1:07 PM
Page 132
Implementing Value-Added Telecom Services
service (SLIR), but it is also possible to request that location services be triggered by events or time intervals. MLP messages consist of a header and a body. The header identifies the client and the originator of the location request. The client is the machine or software that made the request, while the originator is the requesting organization or subscriber. The MLP body can specify the following information: • The terminal to be located can be identified by an International Mobile Subscriber Identity (IMSI), an MS-ISDN, an IP address, or a host of other types of identities. It is possible to request the location of several terminals in one request, either by listing them one by one, or by specifying a range (for example, numbers 34676482460–34676482469). • The quality of positioning (QoP) can be specified in terms of the required horizontal and vertical resolution, the response time, and the actuality of the location information. • The coordinate reference system in which the location result is to be expressed is specified by citing the geographic authority, the code of the reference system, and a version number. • The type of location requested can be current location or last known location • The priority of the location, specified as normal or high. Figure 5.4 illustrates that an MLP message is easy to read, once you know how they are structured. This particular example is of a direct request from an external client (SLIR) to locate the terminal with MS-ISDN 34676482469 in the Worldwide Geodetic System 1984 (WGS84) coordinate system with a horizontal resolution of 1,000m and a low delay. The client will accept either the current or the last known position of the mobile. An MLP reply comes in the form of a location result or a location error. An error occurs when the mobile cannot be located for whatever reason, when the requested location service is not available, or when the quality of positioning requirements cannot be met. A successful location result is given in the form of a geometrical shape that depends on the location method and coordinate system used. This can be a point with an uncertainty circle or ellipse, a polygon, string of lines, or another shape. Figure 5.5 shows that MLP replies are equally easy to read. This location result corresponds to the request in Figure 5.4, and specifies the location of terminal 34676482469 on April 7, 2005, 17h33 +0200 universal time coordinated (UTC), in terms of a ellipsoid point in reference system WGS84, with an uncertainty circle with a radius of 750m.
5.2.2 Secure User Plane Location As noted in the beginning of this section, mobile networks use an extension of MAP to support location services. MAP is part of the Number 7 (SS7) signaling system, which is administered by the mobile operator, and not accessible from outside the network. The network operator must update network elements like the base transceiver station (BTS), BSC, and MSC to support the MAP extension for location services. Third-party location service providers depend on the network operator for providing location services. Some positioning procedures, like cell ID and U-TDOA rely specifically on information controlled by the mobile network operator. But those procedures that do not rely on network-specific calculations, for example, E-OTD and AGPS, could be provided by third parties without relying on the operator. The use of MAP in the 3GPP architecture for location services, however, implies the involvement of the network operator in all location services. To relax the dependency on the mobile network operator, OMA has been working on a protocol that transports location information over plain IP connections rather than over the SS7 network. The resulting protocol, called secure user plane location (SUPL) can be used to bypass the use of MAP for location procedures. This has advantages both for the network operator and for thirdparty service providers. For operators, SUPL provides the advantage of not requiring modifications to the existing SS7 and MAP protocols in the network. For third parties, SUPL creates the possibility of being able to provide location-based services without relying on the operator for positioning the mobile. SUPL uses point-to-point TCP/IP communication between the location service provider and the terminal to be located, and requires three network elements: 1. SUPL enabled terminal (SET) is any GSM, IS-95, UMTS, or CDMA terminal that supports SUPL. 2. SUPL location center (SLC) manages SUPL sessions on the service provider side. It sets up the SUPL procedures, negotiates QoP, and selects the SPC that will do the actual positioning. 3. SUPL positioning center (SPC) manages the specific location procedures on the service provider side. As just observed, SUPL does not require the location service provider to be the network operator. Any third-party service provider can deploy an SLC and SPC, and simply use mobile TCP/IP data connections to run SUPL over. SUPL can work in proxy mode or nonproxy mode. In proxy mode, the terminal exchanges messages only with the SLC. Any message exchange between
05_4557.qxd
10/19/05
1:07 PM
Page 135
Location-Based Services
135
the SET and SPC is indirect, and flows through the SLC. In nonproxy mode, the SET can exchange messages directly with the SPC. The proxy mode exists to allow the SLC to act as a kind of policy server, and to protect the SPC from direct access if a service provider does not wish this. Unlike MLP, SUPL is defined in abstract syntax by means of Abstract Syntax Notation One (ASN.1) and is not based on XML. The SUPL protocol is rather simple and has six main message types, as shown in Table 5.2. SUPL can carry specific positioning protocol messages as part of the SUPL POS INIT SET, or SUPL POS messages. The SUPL standard currently supports GPS (assisted and autonomous), enhanced Cell ID, E-OTD, and AFLT, and can transport messages of standard location protocols TIA-801, Radio Resource Location Services Protocol (RRLP), and Radio Resource Control (RRC). SUPL uses plain TCP/IP connections for all messages between terminal and network, with one exception: the SUPL INIT message. If the network initiates the SUPL session, then the SUPL INIT message is sent to the terminal either by SMS or by WAP push. The reason for this is that the network cannot assume the terminal to be ready to receive TCP/IP data. A dual-mode GSM/
Table 5.2 SUPL Message Types Message Type
Description
SUPL INIT
Network-initiated SUPL session. In this message the network notifies the terminal of the positioning methods it supports, and the IP address of the SLC (or SPC in nonproxy mode). It may also specify the desired QoP.
SUPL START SET
Terminal-initiated SUPL session. In this message the terminal notifies the network of the positioning capabilities it supports, and the identity of the cell it is currently connected to. It may also specify the desired QoP.
SUPL RESPONSE
Response to START message from SLC to SET, in which the network may specify the positioning method to be used, and/or the IP address of the SLC or SPC.
SUPL POS INIT SET
Terminal-initiated positioning protocol session, in which the terminal provides its positioning capabilities and current cell information to the network. It may also contain a specific position, a request for GPS assistance, or a location protocol– specific payload.
SUPL POS
Carries a specific position protocol payload from SET to SPC (or SLC in proxy mode), or vice versa.
SUPL END
Ends SUPL session (by SET or SLC).
05_4557.qxd
136
10/19/05
1:07 PM
Page 136
Implementing Value-Added Telecom Services
GPRS terminal, for example, may be busy if the user is engaged in a voice call, and some terminals may not have TCP/IP capabilities at all. In roaming situations, SUPL relies on the Roaming Location Protocol (RLP) for communication between the requesting network SLC and serving network SLC. 5.2.3 Combining MLP and SUPL SUPL by no means replaces MLP and can even be used in combination with it. Very often, the GMLC and SLP are collocated in the same node. MLP is used to talk between this node and an external client, while SUPL is used between this node and the terminal to be located. To see how SUPL and MLP complement each other, consider the example in Figure 5.6. In this example, an immediate location request4 from an external client application leads to a SUPL location procedure being initiated from the network. The steps are as follows: 1. An external client makes an immediate location request (SLIR) to the GMLC, which is collocated with the SLP. 2. The SLP initiates the location procedure by sending a SUPL INIT message to the terminal. Remember that this first message is sent by SMS or WAP push, and that it contains the positioning method(s) to be used and the IP address of the SPC that will do the positioning on the network side. Let us assume that the positioning method to be used is AGPS. 3. The terminal sets up a TCP/IP connection to the SPC identified by the SUPL INIT message. 4. Then the terminal initiates the positioning procedure by sending a SUPL POS INIT message to the SPC. In this example, we assume that the terminal acknowledges it with a can do AGPS and makes a request for GPS assistance data (the satellite data to be used for positioning in this particular cell). It also provides its current cell identification. 5. The SPC and terminal now exchange SUPL POS messages to execute the AGPS positioning. In the simple case, these are just two messages: one from the network to the terminal with the GPS assistance data, and one back from the terminal to the network with the terminal’s geographic position, as determined by GPS in the terminal.
4. Such an immediate location request corresponds to the snippet of MLP text shown in Figure 5.4.
05_4557.qxd
10/19/05
1:07 PM
Page 137
Location-Based Services
GMLC SLP
Client
(1)
137
SET
SPC
MLP <slir> SUPL INIT Set up TCP/IP connection SUPL POS INIT SET
Exchange SUPL POS messages
SUPL END Result (7)
(2) (3)
(4)
(5)
(6)
MLP <slia>
Figure 5.6 SUPL example: direct location in nonproxy mode.
6. Once the SPC has acquired the position of the terminal, it closes the SUPL session by sending a SUPL END message to the terminal, and passes the location result to the SLP. 7. The GMLC then sends the MLP location answer [standard location immediate answer (SLIA)] back to the requesting client application. The interesting thing in this scenario is that the GMLC, SLC, and even SPC do not necessarily have to belong to the mobile network operator, as long as the SPC can provide the relevant GPS assistance data for the geographical area that the target terminal is moving in. For this reason, and because SUPL uses plain TCP/IP and does not require changes to the control plane, it is likely to become the standard in the near future for AGPS location services. 5.2.4 Roaming Location Protocol (RLP) So far we have seen how an external client can request the location of a terminal in a single network, and how the location can be executed either over the network control plane by using MAP or over the user plane by using SUPL. Now
05_4557.qxd
10/19/05
1:07 PM
138
Page 138
Implementing Value-Added Telecom Services
the question is, What happens if the terminal in question happens to be roaming in another network? This is not really a problem if the home GMLC can somehow delegate the location request to the visiting network. The first things the GMLC does when it receives a location request is to interrogate the HLR [or Home Subscriber System (HSS) in 3G systems] to determine which MSC the target terminal is connected to, and to check location permissions. If the HLR tells the GMLC that the target terminal has roamed to another network, then the GMLC only has to relay the location request to the GMLC of the visiting network. The RLP is used for this delegation procedure between GMLCs. Figure 5.7 illustrates how it is used. The location procedure in a roaming situation is the following: 1. A client makes a location request to the GMLC in the home network of a subscriber. 2. The GMLC interrogates the HLR to find to which MSC to relay the location request. The HLR responds that the subscriber is currently roaming in another network. 3. The GMLC then forwards the location request to the GMLC of the visited network, using RLP. 4. The GMLC in the visited network uses any of the available technologies to locate the target terminal. 5. The GMLC in the visited network sends the location result back to the requesting GMLC. 6. The original GMLC sends the location result back to the client.
Client (1)
(6)
GMLC
(3)
(4)
GMLC (5)
(2)
Home network HLR Figure 5.7 Typical use of the roaming location protocol.
Visited network
05_4557.qxd
10/19/05
1:07 PM
Page 139
Location-Based Services
139
Taking a closer look at the situation, we see that the requesting GMLC in fact only has to act as a client application to the serving GMLC. Why could we not then use standard MLP for this? Indeed, RLP is very similar to MLP, differing only in the header part. The actual location request is the same in the MLP and RLP body. The difference in RLP and MLP headers is that the RLP header contains additional information about the requesting GMLC and about the roaming information obtained from the HLR in the home network. This includes the MSC that the GMLC in the visited network must contact. The visited network GMLC cannot obtain this information from its own HLR, since the latter does not hold records for visiting subscribers! RLP also differs from MLP in that it can relay embedded SUPL messages. This allows the RLP to be used also as a delegation protocol between SLCs in roaming situations. 5.2.5 OSA-Parlay The OSA-Parlay specifications contain an interface that is very similar to MLP. The OSA-Parlay mobility interfaces allow an external client to make location requests compatible with those that can be made with MLP. The choice between MLP or OSA-Parlay is therefore more a question of network context and implementation preferences than of location features. The most notable differences between MLP and OSA-Parlay are: • MLP is a stand-alone protocol while the OSA-Parlay mobility interface is part of a broader set of interfaces. This means that it can be convenient for a client application to use OSA-Parlay mobility interface if it needs uniform access to several network features. • MLP is the protocol for the Le interface of the GMLC, whereas OSAParlay is an independent set of object interfaces. OSA-Parlay goes to great lengths to explain that their interfaces do not imply any underlying network infrastructure. The OSA-Parlay mobility interfaces can be connected to a GMLC directly, or via a gateway that translates the OSAParlay calls to MLP. However, the OSA-Parlay specifications themselves do not imply any specific location architecture, so in theory it is possible to have a completely different or proprietary location infrastructure behind the OSA-Parlay mobility interface. • MLP is a plain-text message protocol, whereas OSA-Parlay describes remote object classes and interfaces in Interface Definition Language (IDL). OSA-Parlay is specifically suitable for use in distributed object-oriented processing environments, since it strictly adheres to object-oriented
05_4557.qxd
140
10/19/05
1:07 PM
Page 140
Implementing Value-Added Telecom Services
principles, such as synchronous method calls,5 callbacks,6 factories,7 inheritance. MLP does not have an underlying computing model. • OSA-Parlay specifications separate authentication and security from the mobility interface. In OSA-Parlay, access and security are dealt with by a specific set of framework interfaces that are independent of the particular service interfaces. MLP, on the other hand, includes client authentication information in the message headers. In MLP, therefore, access and security is embedded in the location protocol itself. • OSA-Parlay only allows geographic positions to be expressed in the Worldwide Geodetic System 1984 reference system, while MLP allows other geodetic systems to be used as well. This is not an essential restriction, however, since it is always possible to convert the coordinates in one system to another. Figure 5.8 compares how a direct location request is made in MLP and in OSA-Parlay. The MLP request and response are plain-text XML messages of the format illustrated in Figures 5.4 and 5.5. In OSA-Parlay, the request takes the form of a method invocation on a remote object of the class IpUserLocation, and the response is a callback method on the client object of the class IpAppUserLocation. Despite the difference in protocols, the request and response parameters are very similar in MLP and OSA-Parlay. In both cases, the request carries the list of mobiles to be located (the <msids> tag in MLP equals the users parameter in OSA-Parlay), and also may carry the quality of positioning in terms of resolution, response time, and priority (the <eqop>, , and <prio> tags in MLP equal the request parameter in OSA-Parlay). One cannot say that either of MLP or OSA-Parlay is better than the other. Based on the observations made earlier, the choice between MLP or OSA-Parlay depends on the location topology (Is the service provider using a GMLC?) and computing environment (Does the network service provider offer other OSAParlay interfaces? Is it relying on distributed object-oriented computing?).
5. All Parlay-OSA operations are synchronous: a client that calls a method on a remote object waits for the response to return before continuing computation. To avoid clients being blocked indefinitely, however, most OSA-Parlay operations return a void (empty) result. Instead, the result is sent back in the form of callbacks. 6. A callback is an operation that the server calls on the client to submit the result of an earlier request. Callbacks are used to support asynchronous communications in synchronous environments, by allowing the server to call back with its results. The downside of using callbacks, is that the client must also implement remote interfaces. This often makes the distributed system much more complex. 7. A factory is a remote object that creates a remote object on behalf of the client on the server side.
extendedLocationReportRes(locations) Figure 5.8 Direct location request in MLP and OSA-Parlay.
A third-party location-based service provider is usually dependent on the location interface that the network operator offers. This may be MLP or OSAParlay, depending on the operator and its network. In either case, the location requests that can be made are the same.
5.3 Adding Location Value While emergency services have been a driver for the deployment of location technologies in mobile networks, location information is being used increasingly in other services and applications. Location information enables new services and can add a new value dimension to existing ones. The standardizations community recognizes four categories of locationbased services: 1. Internal location services are used by the network itself to optimize resources and provide quality of service. The location information generated for this purpose is not available to subscribers or third parties outside the network, and therefore cannot be used for VAS. 2. Emergency location services are used by the authorities to provide emergency assistance.
05_4557.qxd
10/19/05
1:07 PM
142
Page 142
Implementing Value-Added Telecom Services
3. Lawful interception location services are used by the authorities in case of lawful interception. 4. Commercial location services: This type of location information is available to the network operator, third-party service provider, and subscriber for providing location-based VAS or content. The next section concentrates on the last category, since this is the only type of location information available to third parties for providing VAS. Table 5.3 gives an idea of the types of commercial services that are possible with location information. The list of services in this table, which is based on the 3GPP categorization of location-based services, is by no means exhaustive. One of the established location-based services in mobile networks is homezone charging. Mobile operators use home-zone charging to compete with wireline operators, by applying special communication rates when a mobile sub-
Table 5.3 Location-Based Service Categories and Services Service Categories
Location-Based Services
Charging
Home-zone charging
Tracking
Person tracking Fleet management Asset management
Intelligent call routing
Roadside assistance Routing to nearest office
Information
Local traffic information Public transport information Sightseeing and tourist information Location-based advertising Location-based yellow pages Local weather Location-based service search
Entertainment and community
Location-based gaming Find a friend Location-based dating Location-based chat Route planning Where am I?
05_4557.qxd
10/19/05
1:07 PM
Page 143
Location-Based Services
143
scriber is in his or her home zone, which is usually the mobile network cell that covers the subscriber’s home. This means that the subscriber can use the terminal at home to call against fixed network rates. Other well-established location-based services are location-based service search (find nearest . . .) and tracking services, especially fleet management. At the same time, new location-based services are now on the rise, especially in the content and entertainment area. The next sections briefly explore these new areas. 5.3.1 Location-Based Applications and Content Mobile devices are becoming increasingly used to browse and download content while the subscriber is on the move. The personal and mobile aspect makes these devices especially suitable for delivering personalized and location-sensitive content. Among the most common location-based content services already deployed in some countries are location-sensitive maps (Where am I now? Where is the nearest . . . ?), location-sensitive transport information (How do I get by bus from here to . . . ?), and location-sensitive tourist information (What am I looking at?). It does not make sense trying to enumerate all possible types of location-based content. Any third-party enterprise can deliver location-based content, as long as it can locate a user using any of the technologies described in this chapter. The possibilities for providing innovative content based on location information are only limited by the imagination. The most critical factor in launching a new location-based service, or creating location-based content, is the business model. Especially in the United States and Europe it still appears to be difficult to cash in on the added value provided by location information, for several reasons: 1. Legislation: Virtually all countries require explicit consent from a user to allow him or her to be located. Under some laws, acquiring this consent can be quite difficult, since the request has to be documented and be very explicit. This discourages many potential users and service providers. 2. Cost: Most mobile network operators still charge relatively high rates for locating a mobile. In most U.S. and European networks, a single location attempt typically costs roughly the same as a short message (SMS), even if it fails. This makes location-based services and content expensive to provide. In particular, those services that require constant tracking or repeated location quickly become prohibitively expensive.
05_4557.qxd
144
10/19/05
1:07 PM
Page 144
Implementing Value-Added Telecom Services
3. Culture: In a world where much of the content on the World Wide Web is absolutely free, it is difficult to convince users that they have to pay for content they access through their mobile phone. Until the present, users failed to appreciate the added value in location-sensitive information. In spite of these barriers, location-based content is a growth industry. Japan currently appears to be ahead of the United States, Europe, and the rest of the World. This is partly because mobile devices are already being used extensively to access content (the success of i-mode), partly because of the dense population of the country (which creates a critical mass for content services and keeps infrastructure costs low), and partly because Japanese legislation for location-based services has been well-defined since the end of the 1990s. Section 5.4 studies legislation in more detail.
Examples for Section 5.3.1 Alcatel (http://www.alcatel.com) and Oberthur Card Systems (http://www. oberthurcs.com) of France are the creators of a terminal-based application for tracking children on their way to and from school. The Guardian Angel application lets a parent set the itinerary for the child by simply walking with the child’s mobile and defining checkpoints on the way with one click of a button. A server on the network side registers the positions of these checkpoints and the time elapsed between them. When the child walks to school, the server keeps track of the position of the mobile and checks it against the set itinerary. When the child deviates from the defined track, or when the system observes an unusual delay, it sends an SMS warning to the parents. The Guardian Angel application is an example of a new class of mobile applications that are made possible by using location information. Earthcomber of Chicago, Illinois, (http://www.earthcomber.com), provides what they call a virtual treasure map for Palm users. Users can download the software for free, while businesses pay a fee to get their services listed. The user can indicate the type of services they are interested in: museums, restaurants, shops, and so forth. Earthcomber constantly maintains a map of the user’s vicinity and the services of his or her interest. Strictly speaking, Earthcomber is terminal based and does not rely on mobile network connectivity. Yet it is a good example of how third parties can provide location-sensitive content. Moreover, the business model is interesting: the service is free for the end user, while the advertisers pay.
05_4557.qxd
10/19/05
1:07 PM
Page 145
Location-Based Services
145
5.3.2 Location-Based Gaming A specific type of location-based application that is gaining ground is locationbased games. Portable game consoles have been the standard for many years, and represent a steady market. Until recently, these consoles were unconnected, stand-alone devices. But now that mobile phones have become a commodity even among children and teenagers, manufacturers have begun designing devices that combine gaming and communications facilities. This creates new opportunities for networked games on mobile devices. Networked games have already proved themselves on the established game consoles, which are now routinely equipped with Internet connections to allow interactive multiplayer gaming. But mobile gaming devices also add the possibility of involving the geographic position of the player in the game. This leads to a whole new range of highly interactive, even physically challenging games, since the user’s real position and movements are now part of the game. One of the oldest location-based games is geocaching (http://www. geocaching.com), where participants have to search for physical treasures or caches using GPS receivers and following more or less enigmatic clues. Geocaching cleverly combines Internet and GPS technology with outdoor experience in a simple, yet highly attractive activity. Basic geocaching relies only on GPS, not on cellular communications, but games are currently becoming more sophisticated and are also using the networking features that mobile phones provide. Most of today’s location-based games superimpose a virtual map onto the real geography of a city or area. The virtual map can show the positions of other players, virtual objects, treasures, and fantasy buildings. Figure 5.9 illustrates how games can use a virtual map overlay on real geography. Starting from the virtual-map concept, many types of game are possible. Here is a sample of the types of game in existence: • Item collection: Players have to pick up virtual objects by moving to specific geographic locations. Many games also let the players swap or trade objects for points. • Virtual shoot-outs: Players have to engage in virtual combat with other players by moving into a specific geographic range of each other. Note that for privacy, games usually do not allow players to know each other’s real identity, and tend to avoid physical contact. • Puzzles: Players have to solve enigmas or answer questions related to specific geographic locations. An example is historic games, in which the virtual map shows a historical view of the city and the players enact historic figures.
• Vintage games: These are human versions of classic games like Pac-Man. Players enact the games’ characters and chase each other physically through a geographic area. Many variations on these schemes exist, and there are also games that combine one or more of them. Many games include instant messaging or chat to communicate with other players, and some even make use of the phone’s camera. The variety of location-based games has steadily grown over the last couple of years, and games are becoming increasingly creative and sophisticated. Yet no location-based game has succeeded in becoming so addictive that it has turned into a real moneymaker. Some games, like Mogi in Japan (see the Examples below), are beginning to build a steady following. Whether location-based gaming catches on in the United States, Europe, and the rest of the world remains to be seen. Considering the success of the game console among children and teenagers (and more than one adult), location-based gaming certainly has a promising future.
Examples for Section 5.3.2 Gizmondo of Farnborough, United Kingdom, (http://www.gizmondo.com), produces a mobile gaming device with GPRS and GPS for networked and location-based gaming. It also includes a camera, an MP3 audio player, MPEG-4
05_4557.qxd
10/19/05
1:07 PM
Page 147
Location-Based Services
147
video player, and SMS functionality. One of its distinctive features is that it lets parents locate and track their children through the built-in GPS and GPRS interfaces. Mogi (http://www.mogimogi.com) is doubtlessly one of the most famous location-based games in Japan. The game overlays a map with virtual treasures and objects onto Tokyo’s geography. Participants are to gather as many points as possible by searching for objects and trading them with other users. A participant can pick up an object by moving within 400 meters of it. Mogi is charged through a monthly fee, plus communication charges (by data packet volume). Gunslinger (http://guns.mikoishi.com/gunsSingTel/gametour.html) is a less pacific multiplayer, location-based game offered by Singtel in Singapore. Participants have to engage in location-based missions and battle with networked opponents. The interesting feature of this game is that although you have to engage your opponent geographically, you do not actually get to know who he or she is. The game strictly protects the user’s privacy. Gunslinger mainly relies on SMS communication, and the game is mainly charged by the message.
5.3.3 The Gimkana Location-Based Game Let us put ourselves in the shoes of a third-party enterprise wanting to provide a location-based game. How to implement it? This section considers the implementation steps for a sample location-based game, called Gimkana (which means puzzle tour in Spanish). The game has simple rules: participants have to make a tour through a city, visit predefined landmarks, and accomplish a small mission at each of them. The challenge at each landmark can consist of answering a simple question, solving a puzzle, or even making a picture on the spot and uploading it. The game begins at a set time and the player (or group) that completes the tour first and has accomplished all missions satisfactorily wins. There are many ways to implement the Gimkana game, but we cannot enumerate all of them. Instead we consider a simple implementation scenario, requiring almost no infrastructure, apart from the game server, on behalf of the game provider. The ingredients for the simple implementation of the Gimkana game are no more than: • Access to a location server (GMLC) of a network operator or third-party location provider (for example, the one mentioned in the Example for Section 5.1.1); • Access to an SMS server with premium-rate SMS facilities (see Chapter 3);
05_4557.qxd
10/19/05
1:07 PM
148
Page 148
Implementing Value-Added Telecom Services
• A Web application to let the puzzle tour organizers define their landmarks, challenges, start date and time, participants, and so forth. The game starts by registering the terminals of the participants and sending them off to the first landmark of the puzzle tour. In most countries it will be necessary to obtain prior permission from the players to locate them during the game. All this can be done via a simple SMS dialogue. Once the participants have registered, the game application asks the GMLC to provide triggered location reports with set intervals of 15 minutes.8 Supposing the GMLC works with MLP, the request could look something like this (the difference from the earlier sample request in Figure 5.4 has been highlighted in boldface): <msids>
The list of participant terminals to be tracked goes here; see Figure 5.4 00001500 <start_time utc_off="+0200">20050426100000 <stop_time utc_off="+0200"> 20050426130000 <eqop>
The required quality of positioning goes here; see Figure 5.4 <eqop>
The geographic reference system to be used goes here; see Figure 5.4 <prio type="LOW"/>
8. It would actually have been more efficient and less costly to let the GMLC provide a triggered location report each time a participant entered the geographic area close to a landmark. The current version of MLP does not support this feature, but it is planned for later releases as an option. The MLP tag used for this will be <ms_action>.
05_4557.qxd
10/19/05
1:07 PM
Page 149
Location-Based Services
149
In this MLP request, the tag specifies the requested location interval in a ddhhmmss format, where dd are days, hh hours, mm minutes, and ss seconds. The <start_time> and <stop_time> tags specify when the periodic location has to start and stop, respectively. Note also that an MLPtriggered location request body starts with the tag . Figure 5.10 shows what happens as the game unfolds: 1. The GMLC sends a periodic location report for all players to the game application server. 2. The game application server checks which players have reached the vicinity of their next landmark. 3. If a player has come within reach of his or her landmark, the game server sends an SMS with a challenge, which may also include a clue for the next landmark to look for.
4. The user sends back the reply to the challenge by SMS. The game server evaluates the answer and updates the score of this player in the database. The game provider will typically use an SMS shortcode to communicate with the players and can charge for the game by applying a premium rate for the SMS messages. Chapter 3 extensively discusses the use of premium-rate shortcodes. They are attractive because they allow participation on an ad hoc basis without subscriptions or alternative payments. Of course, there are many other, more sophisticated ways to implement this game and make it more attractive to the players. However, the point behind this section is that a third-party service provider can quite easily implement a location-based game without an elaborate infrastructure, by simply using the location and messaging services provided by the operator or third-party service providers.
5.4 Regulatory Issues Many countries now require mobile networks to support location technologies with a minimum resolution for emergency services. This has obliged many network operators to deploy one or more of the location technologies discussed in this chapter. The use of location information for commercial purposes, however, is often bound to strict regulations. Although legislation varies from country to country, most administrations consider location information to be privacy sensitive and require explicit consent from the user before he or she can be located. U.S. federal law [1] considers location information to be CPNI, which also covers the destination, time, and duration of calls. Until recently, U.S. Federal law did not specify very clearly whether CPNI is subject to opt-in (meaning that a user must give explicit consent to use the data) or opt-out (meaning that the data can be used unless a user expressly forbids it) type of consent. Network operators, however, adhere to a code of practice whereby the user is explicitly asked for prior consent (opt-in) before allowing him or her to be located. In the United Kingdom, all location services are subject to the Data Protection Act [2], which also requires explicit prior consent on behalf of the user. In the request for consent, the service provider must inform the user of: • The operator or service provider who is tracking the location of their mobile, and for which purpose the location information is used; • What location information will be provided to any third parties, how this data will be processed and for how long it will be stored.
05_4557.qxd
10/19/05
1:07 PM
Page 151
Location-Based Services
151
In the case of company phones, the owning company is under the obligation to notify its employees when their mobile phones are being located, and to explain how the location data is used. The Directive on Privacy and Electronic Communications [3] formulated by the European Union in 2002 also requires service providers to ask for prior consent before a user can be located. According to the EU directive, the user must be well informed when asked for his or her consent. What exactly wellinformed consent means is left up to the EU member states to define, but in many cases it comes down to similar information, as mentioned earlier: Who is locating the mobile? For what purpose? Are third parties involved? How to withdraw consent, and so forth. In addition, the user must have the possibility of withdrawing his or her consent at any time, and free of charge. Most E.U. countries have now implemented the directive.
Example for Section 5.4 The IETF has a working group on geographic privacy called GEOPRIV (http://www.ietf.org/html.charters/geopriv-charter.html). This group has produced a proposal for XML-based document format for expressing geographic privacy profiles, and defines an API for requesting location information in such a way that privacy is respected. One of the ideas of GEOPRIV is that the user can set the resolution of the location information to be revealed for his or her terminal. For example, a user can request that the service provider only reveal the city in which he or she is currently located, but not the exact geographic location. See also [4] for more information.
References [1]
United States Code, Title 47, Chapter 5, Subchapter II, Part I, paragraph 222, Privacy of Customer Information, release 2003.
[2]
Elizabeth II, Data Protection Act 1998, Chapter 29, United Kingdom, 1998.
[3]
European Parliament and Council, Directive on Privacy and Electronic Communication, Directive 2002/58/EC, 2002.
[4]
Ackermann, L., J. Kempf, and T. Miki, Wireless Location Privacy: Law and Policy in the U.S., E.U. and Japan, Internet Society (ISOC) Member Briefing #15, 2003.
05_4557.qxd
152
10/19/05
1:07 PM
Page 152
Implementing Value-Added Telecom Services
Selected Bibliography http://www.alcatel.com, telecommunications equipment vendor and creator of the Guardian Angel location-based tracking service http://www.alohamobile.net/tech.html, WiFi-based location-based services http://www.cursor-system.com, CPS, provider of E-OTD location technology http://www.earthcomber.com, location-based service directory for Palm users http://www.gizmondo.com, mobile game console that includes GPRS and GPS http://www.globallocate.com, provider-assisted GPS and indoor GPS technology http://guns.mikoishi.com/gunsSingTel/gametour.html, Gunslinger, location-based game for Singtel users in Singapore http://www.ietf.org/html.charters/geopriv-charter.html, IETF GEOPRIV working group on geographic privacy http://www.in-duce.net/archives/locationbased_mobile_phone_games.php, extensive list of locationbased games http://www.mobilelocate.co.uk, U.K.-based provider of location services http://www.mogimogi.com, famous location-based game, set in Tokyo http://www.oberthurcs.com, Oberthur, manufacturer of card-based systems http://www.trueposition.com, TruePosition, provider of U-TDOA location technology (among others)
06_4557.qxd
10/19/05
1:12 PM
Page 153
6 Electronic Commerce People have used different forms of currency for thousands of years. Until only a couple of decades ago, commerce meant buying or selling goods directly with cash. In fact, paper money and cheques have only been in use since the second half of the nineteenth century. The invention of the credit card in the 1950s marked a turning point.1 Credit cards became an immediate success and removed the barriers for global commerce, but also quickly revealed their sensitivity to fraud and bad credit. The growth of the World Wide Web has been another landmark in the evolution of commerce. Within the span of no more than a decade since 1994, the World Wide Web grew from an experiment into a global information network that reaches from the heart of Manhattan to Kathmandu. Any business now has frictionless access to hundreds of millions of customers worldwide, at near zero cost. Mobile networks have added a new dimension to the equation. Because of their high penetration, personal nature, and universal coverage, mobile phones have all the potential to replace the purse, the credit card, and the personal cheque. Why carry around all these objects if they can be combined in one personal device? There is also a price to pay. Business transactions in the old days were physical meetings between buyer and seller, and the transaction would leave the seller 1. Diner’s Club introduced the first credit card in 1950, followed by American Express and Bank America (now known as VISA) in 1958. Credit cards were initially targeted at traveling businesspeople, but immediately caught on with the broader public in the United States. It was not until the 1980s, however, that credit cards became widespread in Europe and the rest of the world.
153
06_4557.qxd
154
10/19/05
1:12 PM
Page 154
Implementing Value-Added Telecom Services
with cash in hand. Today, all a seller may know about a buyer is an IP address and a credit-card number. This opens the door for wide-scale hacking, fraud, and identity theft. Electronic commerce is a complex space with technological, legal, and commercial dimensions. While the legal and commercial aspects are at least as important, this chapter only studies the technological side of e-commerce.
6.1 E-Commerce Models For many people, the term electronic commerce (e-commerce) has an almost magical ring to it. The combination of the two words electronic and commerce, both laden with notions of importance and power, tends to inspire respect. For many, e-commerce seems like a black art that requires specialist knowledge and that generates wealth for those who are part of the secret. Indeed, commerce has become more complex in the electronics age. Today a transaction between buyer and seller can involve several intermediaries who check their identities and credit, manage their accounts, transfer the money, and provide them with credit if necessary. For a fee, of course. Still, let us not forget that e-commerce is no more than a name for doing old business with new means. The only thing that’s new in e-commerce is the e, not the commerce. Before delving into the tools in more detail in this chapter, let us mark the territory first. It is generally understood that e-commerce somehow involves the Internet. Or in the case of mobile e-commerce (m-commerce), it can also involve mobile network services such as short messaging (SMS), USSD, or WAP. But there are many ways of doing business over the Internet, or with mobile phones. The first distinction to make is between selling and marketing. Many Internet sites market products or services, but do not actually sell them online. They refer the customer to an off-line procedure for ordering, delivery, and payment. Whereas Internet marketing deserves a book of its own, this chapter concentrates on technologies for electronic business transactions, in other words, buying, selling, and paying online. The usual way to categorize e-commerce technologies is by identifying who sells, who buys, and who pays. The industry recognizes three common ecommerce patterns [1]: 1. Business-to-consumer (B2C) transactions: These are between business and individuals. These usually involve online shops with products for a large consumer base, and they are normally subject to commercial legislation and taxes (VAT, for example).
06_4557.qxd
10/19/05
1:12 PM
Page 155
Electronic Commerce
155
2. Person-to-person (P2P) transactions: These are more incidental in nature and do not necessarily involve a product list or professional trading. 3. Business-to-business (B2B) transactions: These are between enterprises and usually involve smaller communities of businesses with industryspecific requirements. Transactions can be more complex and typically involve larger amounts of money than B2C or P2P transactions. Because of the different characteristics, these transactions have different requirements in terms of technology and trust model. In this section, we investigate the technologies used in each of these e-commerce scenarios.
6.2 Business-to-Consumer Transactions The usual B2C model for e-commerce involves three actors: 1. The customer is the party that wishes to acquire services or goods, and is willing to pay for them. 2. The merchant is the party that offers services or goods, receives payment for them, and delivers them to the customer. 3. The payment service provider is the party that facilitates payment. Its services may include authenticating customer and merchant, checking customer credit, transferring funds from customer to merchant, and confirming payment to customer and merchant. Figure 6.1 shows how these roles interact. The payment service provider may or may not actually hold funds for the customer or merchant, and may or may not assume risk of fraud and bad credit. In many cases, the payment service provider acts only as intermediary between merchant and bank for online payments, and does not offer standard banking services itself. For that, the payment service provider relies on a financial service provider (typically a bank) for settlement, as illustrated in Figure 6.1 by the dotted lines. Note that different standardization forums use different terminology. The OMA, for example, refers to the payment service provider and financial service provider as the issuer and acquirer, respectively. But in spite of the differences in terminology, the underlying models are very similar. Figure 6.1 shows that the payment service provider plays a central role in online B2C transactions. Both the merchant and the customer must have a relationship of trust with the payment service provider. In the next sections, we explore this relationship further.
06_4557.qxd
10/19/05
1:12 PM
156
Page 156
Implementing Value-Added Telecom Services
Delivery
Customer
Payment
Settlement
Merchant
Payment Payment service provider
Settlement
Financial service provider Figure 6.1 Basic e-commerce model.
6.2.1 Merchant Account A prerequisite for accepting payments, whether online or off-line, is to have a merchant account. A merchant account is a bank account established by a business with the purpose of receiving payments from customers. Banks apply different conditions for merchant accounts than for personal accounts, because they consider merchant accounts to have a greater risk of fraud and bad credit. Opening a merchant account generally requires abundant documentation and credentials, and maintaining a merchant account has a higher cost than maintaining a personal account. In spite of the fierce competition between financial service providers, different banks offer wildly different prices and conditions for their merchant accounts. Most banks charge at the least the following fees for a merchant account: • Monthly charge, sometimes called a statement fee: this is simply a monthly charge for maintaining a merchant account, similar to a subscription fee. • Monthly minimum: Many financial service providers require a minimum sales volume, to ensure that your account actually generates transactions.
06_4557.qxd
10/19/05
1:12 PM
Page 157
Electronic Commerce
157
• Discount rate: This is the commission that the financial service provider charges for each transaction, as a percentage of the transaction amount. This fee is typically between 2% and 4%. • Transaction fee: Most financial service providers also incur a small fixed charge per transaction. While these are the usual minimum charges for a merchant account, some financial service providers impose additional fees, such as a setup fee (a one-time charge when the account is set up), a gateway fee (a euphemism for another one-time setup fee), a termination fee (a penalty when the merchant terminates the account before a certain date), a chargeback2 fee (a penalty for a valid chargeback, or in some cases, even for invalid chargeback attempts). There is a lot of small print and it is advisable to shop around and compare before settling for a specific merchant account. But what really raises the threshold for opening a merchant account is that most banks require the account to be secured by a deposit.3 Such a deposit can be fixed, or a percentage of projected sales, sometimes as high as 10%. There are, however, alternatives for merchants that wish to do e-commerce without opening their own merchant accounts: third-party merchants and alternative Internet payment service providers. Third-party merchants let others use their merchant account for a fee. They will effectively play the merchant role for others and sell other merchants’ products through their online business. Their conditions are simpler than those offered directly by payment service providers or financial service providers. Third-party merchants usually do not ask for deposits or monthly minimums, but they do charge higher commissions and transaction fees. The commission rate for third-party merchants is usually over 5% of the transaction amount. Third-party merchants can be good for entry-level merchants who cannot afford the deposit and charges associated with a merchant account, or whose sales levels do not make a merchant account viable. Another way around the merchant account is to use the services of alternativepayment service providers. These payment service providers are not banks and merely process payments by credit card, personal cheque, or by direct debit. They allow the merchant to withdraw funds to an existing bank account. 2. A chargeback occurs when a customer denies a credit card payment. This is explained in more detail in Section 6.2.2. 3. From the financial service provider’s point of view, the deposit is quite understandable. Criminals often open a merchant account and then set up a fake e-commerce site to make fake purchases with stolen credit cards. When the legitimate cardholders discover the fraud and start making chargebacks, usually one to several months later, the criminals have already disappeared with the money.
06_4557.qxd
158
10/19/05
1:12 PM
Page 158
Implementing Value-Added Telecom Services
Payment service providers have their own particular way of securing payments and combating fraud, usually by creating a community of registered users. Payments are password protected and associated with a registered user, which reduces the risk of fraud and chargebacks. The downside is that the customer experience is more cumbersome, since customers must register for the use of the payment service.
Examples for Section 6.2.1 2CheckOut (2CO) of Columbus, Ohio, (http://www.2checkout.com), is one of the mayor third-party merchants online. They act as an intermediary merchant for both physical and digital products. Another third-party merchant, more specialized in software and digital goods, is Kagi of Berkeley, California (http://www.kagi.com). Nochex of Leeds, United Kingdom (https://www.nochex.com), is an Internet payment service provider that allows merchants to accept credit-card payments without owning a merchant account. Nochex guarantees credit-card payments, so there is no chargeback risk for the merchant. To increase trust, they allow customers to provide feedback on registered merchants and users.
6.2.2 Credit-Card Payments An overwhelming number of online payments are made with credit cards. Credit cards offer the advantage of universal acceptance, ease of use, and reduced risk for customer and merchant. But credit-card processing has become increasingly complex, as a result of online use and rising fraud levels. There are two types of credit-card transaction: card present and card not present payments. Card-present payments require the customer’s physical signature, and are guaranteed by the credit-card company if the merchant has verified the signature and additional identification, such as the card holders’ photo printed on the card. Card-present transactions usually involve swiping the card through a reader, which validates the card data instantly. Card-not-present payments, on the other hand, only require the card number and expiration date. Since they cannot be verified by signature, photo ID, or swiping the card through a reader, card-not-present payments are more prone to fraud than card-present payments. If the owner of the card denies a transaction, the credit-card company undoes the payment and investigates the transaction by
06_4557.qxd
10/19/05
1:12 PM
Page 159
Electronic Commerce
159
searching for evidence in the form of a receipt, order form, e-mail, or even taped telephone sales. If a card-not-present transaction was indeed fraudulent, then the merchant will not receive payment. This procedure is known as chargeback. Chargebacks are a nuisance for merchants. Merchants bear the risk when they deliver a product, but do not receive payment due to a chargeback. But even when the merchant has no material loss, chargebacks generate useless transactions, unproductive Web site traffic, administrative overhead, and sometimes even processing fees on behalf of the financial service provider. E-commerce sites can usually accept only card-not-present payments, which makes online merchants vulnerable to fraud and chargebacks. If a card is not present in a transaction, a merchant can apply various levels of card verification, as shown in Table 6.1. As a general rule, the more secure the verification, the more costly the transaction both in terms of processing time and fees. Table 6.1 Credit-Card Verification Procedures Method
Description
Luhn10
Simple checksum verification of the credit-card number. This method only verifies that the number is a valid credit-card number, not whether it actually corresponds to an active credit card.
On-line check
Connect online to financial service provider or clearing house to check whether the card number is not blacklisted and corresponds to an active credit card with sufficient credit. Financial service providers charge for this service.
AVS
Address verification system (AVS) matches the address associated with the credit card with the shipping address. Clearing houses and financial service providers provide on-line AVS checking for fees.
CVV
Card verification value* (CVV) is a three- or four-digit verification number printed on the back of the credit card, which is created from the credit-card number, expiration date, a three-digit service code, and an encryption key. The CVV is not part of the credit-card number itself, and is not embossed on the front of the card, so as to ensure that the person who makes the payment actually has the card in hand. Clearing houses and financial service providers provide on-line CVV checking for a fee.
password
Most credit-card companies now have additional verification methods, such as Verified by VISA, which uses a password to confirm credit-card transactions. Password verification of credit-card transactions is also subject to fees.
*Also called CID, CVV2, or CVC2 by some credit-card companies.
06_4557.qxd
160
10/19/05
1:12 PM
Page 160
Implementing Value-Added Telecom Services
In transactions that involve high volumes of small payments, the merchant may only check whether the card number is valid. This is done by using a wellknown Luhn10 checksum algorithm, which is very simple: taking a credit-card number and starting from the right, every second digit of the credit-card number is multiplied by 2. Of the resulting numbers, the digits are taken separately and added up, together with the digits of the credit-card number that were not multiplied. The resulting number must end in 0 for the card to be valid. For example, considering number 4486530053307543, take every second number starting from the right: 4486530053307543 and multiply each by two, which gives 2 × 4 = 8, 2 × 8 = 16, 2 × 5 = 10, 2 × 0 = 0, 2 × 5 = 10, 2 × 3 = 6, 2 × 7 = 14, 2 × 4 = 8. Then add up the digits of the results: 8 + 1 + 6 + 1 + 0 + 0 + 1 + 0 + 6 + 1 + 4 + 8 = 36, and further add the digits that were not multiplied: 4 + 6 + 3 + 0 + 3 + 0 + 5 + 3 = 24. The total is 36 + 24 = 60, which ends in 0, so the number is valid.4 This low verification level is particularly sensitive to fraud, but the merchant may choose to accept it in return for very fast local transaction processing without any verification costs. Today, practically all online merchants use online credit checks, AVV, CVV, or a combination of these.
6.2.3 Online Store Now that we know how to receive payments over the Internet, the next subject is how to set up an online business. Setting up an online shop is easiest when using the services of a third-party merchant, because they actually manage the Web store and the entire order and payment process. All that is required in this case is to set up an account and enter the products in their store. If the merchant chooses to build its own online store, there are several ways to do this, depending on the nature and size of the business and the expected sales volume. Online stores have gone through three generations of increasing complexity and feature richness: 1. Direct payment links: The simplest online shop consists of a simple product listing on one or more HTML pages. For each product, a simple link or button takes the customer to the order and payment procedure, which can be no more than a Web form for entering shipment and credit-card information, or a link to a payment service provider. The merchant can implement this simple Web store in plain HTML without dynamic processing.
4. Disclaimer: this number is merely an example and does not correspond to a valid credit card!
06_4557.qxd
10/19/05
1:12 PM
Page 161
Electronic Commerce
161
2. Shopping carts: If customers generally purchase several items in one session, it is convenient for the merchant to use a virtual shopping-cart system. A virtual shopping cart allows a customer to browse the product catalogue, accumulate several purchases, and pay for them in a single transaction, usually referred to as check-out. Shopping carts need some dynamic processing, because a plain HTTP server is stateless and cannot remember the item selection history of a user. 3. Dynamic storefront systems: Businesses that sell larger amounts of products (for example, Amazon), or that have a dynamic product base, or that sell services by reservation (for example, airlines), use dynamic storefronts with search facilities and back-office applications. Dynamic storefronts are essentially content management systems that use dynamic scripting (CGI, PHP, ASP, JSP, or similar) and a database [mySQL (Structured Query Language) or similar] to maintain the product catalogue, process orders, follow up sales leads, analyze sales statistics, and so on. Figure 6.2 illustrates this. To accept online payments, the merchant will need an account with a payment service provider. As explained in the introduction to this section, this can be the merchant’s bank or an Internet payment service provider. If a merchant chooses to process orders and payments by itself, it will need to support secure Internet communications. The standard way of providing secure communications over the Internet is by secure socket layer (SSL). SSL lets the client authenticate the server and exchange encrypted data. The principle of SSL and digital certificates is briefly explained in Appendices A2.2 and A2.3.
Storefront system Dynamic HTML processing HTTP HTTPS
HTTP server
Database
Payment gateway
Products Customers Orders Payments
Customers
Payment service provider Figure 6.2 Dynamic storefront system.
06_4557.qxd
162
10/19/05
1:12 PM
Page 162
Implementing Value-Added Telecom Services
SSL requires the server to have a digital certificate, a digitally signed file containing the server’s public key. Certificates issued by a registered certification authority can cost between $500 and $1,500, depending on the level of encryption they provide. Older certificates may have 40-bit public keys, while the most secure ones can contain keys of up to 128 or 256 bits, which are virtually impossible to crack even with a large computer. Certificates are only valid for a limited period, and have to be renewed after that. The relatively high cost of SSL technology makes it sometimes unattractive for smaller businesses to process their own secure transactions. In this case, a payment service provider or third-party merchant can provide a solution, since they will process the secure transactions instead. Many payment service providers now offer free code that can be incorporated into a Web site to refer customers to their payment services, where the payment is processed over SSL connections.
Examples for Section 6.2.3 OsCommerce (http://www.oscommerce.org), founded by Harald Ponce de Leon (Germany) in 2000, is one of the best-rated open-source storefront solutions. It supports the whole sales cycle and offers product catalogue, order, payment, customer information, shipping, administration, and tax management. OsCommerce connects to a multitude of payment provider gateways, including PayPal, 2CheckOut, AuthorizeNet, and PSiGate. ZenCart (http://www.zencart.org) by Ian C. Wilson (England) et al. is a slightly simpler, but popular open-source storefront system centered around its catalogue and shopping cart functions. The system is based on PHP and can work with various databases. It connects to over 50 payment systems worldwide. There are also scores of proprietary commercial storefront solutions, such as ShopFactory (http://www.shopfactory.com), EasyShopMaker (http://www. easyshopmaker.com), and Advancenet (http://www.advanceware.net). These storefronts offer different services at different prices, sometimes including payment processing, shop template design, and search engine submissions.
6.2.4 Analyzing Site Visits Just like a real shop, an online shop has to attract buyers and provide an efficient and pleasant shopping experience. The way that information is structured can have a direct impact on the visits that turn into sales. Creating the optimal online shop is not straightforward, and Web sites
06_4557.qxd
10/19/05
1:12 PM
Page 163
Electronic Commerce
163
typically go through several revisions before hitting the structure that generates most sales. The most successful online businesses constantly analyze their Web traffic to see how the site performs, where it fails, and how they can turn more visits into sales. While Web site design is not in the scope of this book, here we investigate a bit deeper how to analyze a Web site’s visits. A standard HTTP server writes the details of each HTTP request and response into a flat text file called the log file. For each individual HTTP request, the log file records the IP address of the client, date, time, HTTP request type and version, the status of the response, and the volume of the file sent back by the server. A typical entry in a log file looks something like this: 207.94.105.77--[27/Jun/2004:12:09:53-010]"GET/logo.gif HTTP/1.1" 200 4528
meaning that client 207.94.105.77 requested file logo.gif on 27th June 2004 at 12:09 –1 hour UTC. The server responded positively (200 OK), with a 4528 byte file. Most HTTP servers generate extended log entries that also record the browser and operating system of the client, the time needed for the server to process the request, cookies sent with the request, and the referrer (the hyperlink from where the request originated). Although log files provide a rudimentary tool for analyzing Web traffic, they have several important drawbacks. Log files record every individual HTTP request in plain-text format, which means they can become very large indeed. Moreover, loading a page with images often requires several HTTP requests, and analysis tools will have to correlate the different requests belonging to the same page download. Plain HTTP servers are stateless and serve HTTP requests from different clients simply in the order in which they arrive. Tracking the request history of a particular client is complicated by the fact that the log file will show its requests interlaced with unrelated requests from other clients. The use of proxy servers between the client and the HTTP server can seriously complicate log file analysis. If the proxy (for example, of an ISP) serves a large user community, this results in millions of requests with the same client address—that of the proxy. These log-file entries are practically useless, since they tell nothing about the original client. If the proxy caches Web pages, then the situation is even worse, because some client requests will not even reach the server; instead, the proxy responds to them from the cache. From the preceding discussion, it is clear that log-file analysis requires significant computing resources, while it yields results of only limited significance. Still, log-file analysis may answer some basic questions about site visits, as Table 6.2 shows.
06_4557.qxd
164
10/19/05
1:12 PM
Page 164
Implementing Value-Added Telecom Services
Table 6.2 Easy and Difficult Questions to Answer with Log-File Analysis Easy Questions to Answer with Log Files
Difficult Questions to Answer with Log Files
• How many visits does the site receive per hour, day, week, month?
• Who is the user behind IP address 207.94.105.77?
• Are there peaks and valleys in site visits?
• How many times does a user revisit our Web site? (A user may have different IP addresses at each visit because of dynamic IP assignment by the ISP)
• Which pages are most visited, and which are rarely or never visited? • How many times is a certain file downloaded? • Where do visits come from? (IP addresses can reveal nationality, but also companies or ISPs; the referrer can provide additional clues) • What search engine keywords do clients use to reach the site? (HTTP requests can include cookies or query strings)
• Why do users leave our Web site? • Where do they go when they leave? • What does a user look for when he or she visits our Web site? • What makes a user buy products?
Web sites with dynamic HTML processing offer more prospects of meaningful Web site usage statistics. There are several ways that a dynamic Web server can identify clients and track visits: 1. Cookies are small text files that a Web server can place on the client machine to maintain state information. When a Web server puts a cookie on a client machine, then the client will send it back to the server with each subsequent HTTP request. This allows the server to identify and correlate client requests. 2. URL query strings: Dynamic servers can accept variables in HTTP requests, in the form of query strings. Query strings are of the form ?variable=value and are appended to the URL of the HTTP request, as in http://www.myshop.com/checkout.html?cart= 73h887he3. 3. Server side scripting: Dynamic scripting techniques such as CGI, PHP, ASP, and JSP provide full control over the session state. The scripts themselves can directly register data that go beyond standard logfile content, for example, the username and password of a registered site user.
06_4557.qxd
10/19/05
1:12 PM
Page 165
Electronic Commerce
165
Most online merchants now use online storefront systems and shopping carts, which means they also have rich information available about clients and sales. Successful online businesses use this information to constantly monitor site usage and optimize their site’s structure and content. Some general characteristics of successful online stores are: • A simple product catalogue with an efficient and accurate search facility. • Minimal click distances to finding a product and closing the sale. Some analysts say that every click in excess of two reduces the percentage of successful sales. • A personalized browsing experience that takes into account a customer’s details and preferences. Some Web sites use recommendation engines to suggest products to visitors. There are also caveats. For example, providing free stuff may increase site traffic, but does not necessarily increase sales. Registering users does not necessarily translate into sales leads. Also, cross-selling may actually alienate customers. Of course, there is much more to tuning a Web store than simply generating statistics about visits. The real challenge lies in interpreting the information, and using it to improve the site. It is outside the scope of this book to go deeper into Internet marketing, as there are excellent publications on this subject [2]. 6.2.5 Preventing Fraud A merchant that engages in e-commerce, or indeed any type of commerce, exposes itself to fraud. Although financial institutions rarely release any figures about exact fraud percentages, merchants have to embrace the risks and deal with them. However, many myths surround the risks of e-commerce, and a few simple measures go a long way toward preventing fraud. Although people commonly regard Internet technology with little trust, hacking and technology flaws only account for a minor percentage of fraud cases. Part of fraud has its roots in the credit-card payment system, regardless of whether it is used online or off-line. But the weakest link in the chain by any account is the human factor. The most common problem with credit cards is that it is easy to generate valid card numbers using the Luhn10 algorithm explained in Section 6.2.2. Criminals create long lists of random credit-card numbers, and then test them with programs that make massive automatic purchase attempts at online stores. Such programs are called card testers, and are easy to find in the hacker community. Once a card tester program hits a credit-card number that makes a successful purchase online, it gradually steps up the transaction value to drain the
06_4557.qxd
166
10/19/05
1:12 PM
Page 166
Implementing Value-Added Telecom Services
card until it reaches the credit limit. Surprisingly, criminals also obtain valid credit-card numbers by buying them directly from unscrupulous businesses, such as adult content sites or even shady financial service providers. Professional criminal organizations will usually try to buy large quantities of low-value articles that are easy to sell, like watches, lighters, medicines, CDs, and DVDs. Alternatively, they set up a fake online store, and cash in on the stolen credit cards by buying nonexisting products from their own “business.” Knowing this, a merchant can take a few basic precautions against creditcard fraud: 1. Watching for signs of fraudulent card use and card testing, such as repeated small purchases from the same client with different card numbers, or repeated purchases of increasing magnitude with the same card, or orders that involve high volumes of low-priced products that are easy to sell. 2. Using Turing numbers to thwart automatic card testing programs. A Turing number is a randomly generated number, displayed in graphical format that is easy to read by humans, but difficult to process by card tester programs. 3. Having a single failure response for refused transactions makes a site virtually useless for card testers. The less information given when a card is refused, the less helpful a site will be to criminals who generate fake transactions to find out if a credit card is valid. 4. Maintaining a blacklist of known defrauders and of fraudulent orders, and always reporting fraud (attempts) to financial institutions and authorities. The more proactive a business is in tracking fraudulent users, the less likely they are to return. None of these measures can completely eliminate the fraud risk, but in practice a combination of these, together with the credit-card verification services mentioned in Section 6.2.2, can effectively discourage most common fraud.
6.3 Business-to-Business Transactions Every enterprise has its own way of ordering, invoicing, shipping, accounting, and managing stock. There are almost as many business processes as there are businesses. In big companies, one department sometimes cannot even read or process the data generated by another, because they use incompatible administrative software. Exchanging business documents between companies is even more troublesome, especially if they are located in different countries.
06_4557.qxd
10/19/05
1:12 PM
Page 167
Electronic Commerce
167
As early as the 1970s, when only big corporations had data communications and the Internet was still experimental, the industry had already started recognizing the need for standardizing the exchange of business information between computers. The first standards for electronic document interchange (EDI) date back to the late 1970s. The evolution of the Internet has boosted electronic business dramatically in the last decade. Up to the first half of the 1990s, only larger companies had the resources for data communications and EDI. Today, businesses of any size have access to the Internet and can run e-commerce software on inexpensive computers. More recent B2B standards envisage a global electronic marketplace where businesses of any type and size negotiate, buy, and sell any type of product over the Internet. These standards are based on XML and Web services technology, which are easy to implement even with open-source tools. In this section we take a brief look at some of the most popular electronic business standards. 6.3.1 EDI The idea behind EDI is to settle on a common machine-readable format for common business documents, such as orders, invoices, and shipment forms. But electronic business standards today also extend into specifying business transaction patterns, business registries, and sector specific dictionaries. The oldest standard for EDI is X.12, standardized by the American National Standards Institute (ANSI) in 1979. For almost two decades, X.12 ruled as the EDI standard, until new XML-based technologies started appearing at the end of the 1990s. X.12 specifies a machine-readable format for common business transactions, and calls these transaction sets. Examples of transaction sets are order, invoice, and shipment notice. Each transaction set has a unique three-digit code, for example, 850 for purchase order and 810 for invoice. X.12 structures transaction sets in three parts: header, detail, and summary. Each part is made up of segments, which in turn contain data elements. Examples of segments are CUR for currency, TAX for tax reference, LIN for item identification, and N1 for name and address. All transaction sets begin with the special header segment ST and end with a special trailer segment SE. Segments contain related data elements in a fixed sequence. Data elements have a variable length, and are separated by a special delimiter character not used in the data itself. Each data element consists of a qualifier and a typed value, which can be numeric, decimal, string, date, time, binary, a special code, or a composite structure. Data elements can be mandatory or optional.
06_4557.qxd
10/19/05
1:12 PM
168
Page 168
Implementing Value-Added Telecom Services
An example X.12 segment takes this form: G61*CA*MR. J. ZUIDWEG*TE*935545262
where G61 is the segment identifier indicating contact details, CA is the qualifier of the first data element contact address with value MR. J. ZUIDWEG, TE is the qualifier of the second data element telephone with value 935545262, * is the separator symbol, and is the segment terminator. The terminator symbol may be a nonprintable character, for example, a carriage return. The X.12 standard allows several transaction sets to be grouped in one interchange envelope, so that they can be sent in a batch in a single communication. Interchange envelopes join related transaction sets in functional groups. This results in a nested envelope structure, as Figure 6.3 illustrates. X.12 describes a large variety of transaction sets, segments, and data elements for many industry sectors. Figure 6.4 shows what a typical X.12 interchange for a straightforward order could look like: 1. Company 1 sends a purchase order transaction set to business 2. Business 2 unparses and validates the order.
ISA ...
Interchange envelope
GS ...
Functional group
ST ... CUR ...
Transaction set Segments
TAX ... SE ... ST ... SE ... GE ... GS ... GE ... IEA ... Figure 6.3 X.12 interchange format.
856 Shipment notice 856 Invoice (4) Figure 6.4 Example X.12 EDI interchange.
2. Business 2 sends back an interchange envelope with two transaction sets: a functional acknowledgment that it received and unparsed the purchase order successfully, and another, more specific acknowledgment that it can actually fulfill the order. 3. Business 1 acknowledges that it has received Business 2’s previous acknowledgments. 4. Business 2 sends an interchange envelope with two transaction sets: the shipment notice and the invoice for this order. The X.12 standard includes a complete dictionary for transaction sets, segment identifiers, and data elements. It also allows industry sectors to add their own extensions and codes. This makes X.12 slightly less interoperable than if it were a rigid standard, but as long as the industry-specific dictionaries are well known, this actually adds flexibility.
06_4557.qxd
10/19/05
170
1:12 PM
Page 170
Implementing Value-Added Telecom Services
6.3.2 EDIFACT and EDIINT A decade after the X.12 standard, the United Nations Electronic Data Interchange for Administration, Commerce and Transport (UN/EDIFACT) specified a global framework for the electronics business, similar to X.12, but with a number of additions. They first published the standard as ISO 9735 in 1988, and updated it in 1990. EDIFACT specifies messages for 10 different application fields: trade, transport, customs, finance, construction, statistics, insurance, tourism, health care, and social administration. EDIFACT also includes a directory and an extensive dictionary of codes. X.12 and EDIFACT are similar, but not compatible. X.12 tends to be used more in the United States, while UN/EDIFACT is more popular in Europe and Asia. As always, when an Internet-based application becomes popular, IETF gets involved. This also happened in e-business. ANSI and UN/EDIFACT created their EDI standards before most companies had access to the Internet. In the early days, corporations sent X.12 and UN/EDIFACT messages over direct dial-up connections (using slow 9,600-baud modems) and dedicated data networks (like X.25). In 1996, the IETF created the Electronic Data Interchange-Internet Integration (EDIINT) Working Group to investigate how to securely send standard EDI documents with existing Internet protocols and document formats. The IETF did not aim to define a new protocol suite, but produced three applicability statements (AS) that explain how to use existing Internet technology. Table 6.3 describes the three EDIINT applicability statements. Although X.12 and EDIFACT use straightforward, plain-text message formats, commercial EDI software is often very expensive. This is because EDI is still seen by the industry as a technology for large enterprises that deploy comprehensive back-office applications and can afford the price tag. The XML com-
Table 6.3 EDIINT Applicability Statements AS
Description
Security
AS1
Secure EDI transactions with MIME and SMTP (e-mail)
Message digital signature; message encryption
AS2
Secure EDI transactions in real time, with MIME and HTTP
Message digital signature; message; session encryption
AS3
Secure EDI transactions with FTP
Message digital signature; message; session encryption
06_4557.qxd
10/19/05
1:12 PM
Page 171
Electronic Commerce
171
munity targets a wider user community, and tries to lower the threshold for electronic business. Yet, even though X.12 and EDIFACT now face tough competition from more recent XML-based EDI, they are still used today.
Example for Section 6.3.2 The Drummond Group Inc. (DGI) of Fort Worth, Texas, tests e-business products for standards conformance and interoperability. They specialize in AS2 testing, but also test ebXML products. Being an independent company that does not build any e-commerce products itself, DGI assists the Uniform Code Council (UCC) with its e-business certification program. Details can be found on http://www.ebusinessready.org. Rik Drummond, the CEO of DGI, is also the founder and chair of the EDIINT Working Group of the IETF.
6.3.3 ebXML EDI standards such as X.12 and EDIFACT have their roots in the 1980s, when few companies had access to data communications. Since then, the world has changed in many respects. The cost of data processing has fallen. Even the smallest businesses can now afford computers powerful enough to run administration and communications software. High-speed Internet access has become a commodity, and Internet standards are truly universal. Businesses and individuals all over the world now communicate with a small set of standard protocols: SMTP for e-mail, HTTP for browsing, FTP for file transfer, and SOAP for remote procedure calls. W3C’s XML has become the standard for structured plain-text communications. Web services [SOAP, WSDL, and Universal Description, Discovery and Integration (UDDI)] are becoming the standard means of machine to machine communications over the Internet. These developments prompted UN/EDIFACT and OASIS to define a new EDI standard in 2001, one that is more adapted to the new environment. The resulting ebXML standard has the same objective as the older EDI standards, in that it seeks to provide a universal format for electronic business transactions, but it offers a couple of new features: 1. ebXML uses XML as text format, making extensibility an intrinsic feature of ebXML. It allows organizations to use existing tools for creating, parsing, validating, and interpreting XML messages. ebXML tags are also more easily readable by humans than the EDI codes of the 1980s.
06_4557.qxd
172
10/19/05
1:12 PM
Page 172
Implementing Value-Added Telecom Services
2. ebXML incorporates standards for a machine-accessible registry that allow clients to search for providers, products, and services. Businesses do not have to have advance knowledge of each other’s business processes and message formats, since this information can be downloaded from the registry. 3. ebXML allows businesses to specify complex work flows and transaction structures that go beyond the order–shipment–invoice–payment sequence. In particular, ebXML allows businesses to negotiate terms and sign a transaction agreement electronically before actually executing the business transactions. The ebXML electronic business model has four phases,5 which Figure 6.5 illustrates: 1. Implementation: The first step for a business is to analyze its business model and describe it in a machine-readable format called the collaborative protocol profile (CPP). The business also describes its technical communication requirements (accepted protocols, message formats, etc.) in the CPP and uploads it to an ebXML registry so that other businesses can discover it. 2. Discovery: A business that looks for a trading partner searches an ebXML business registry for enterprises that fulfill its needs. Apart from CPPs, the registry may contain additional human-readable documentation about a business, to facilitate navigation and search. When a business finds a potential trading partner, it downloads the company’s CPP from the registry. 3. Negotiation: The two trading partners interpret each other’s CPPs, and settle on a common business model and communication parameters acceptable to both. They describe their agreement in the form of a machine readable collaboration protocol agreement (CPA), which can be seen as an intersection of the two CPPs. A CPA may actually serve as a business contract and can be digitally signed. 4. Transaction: Once the two trading partners have established a CPA, they can start doing electronic business. Business transactions consist of a well-defined exchange of messages that contain information packages, as defined by the CPA.
5. The ebXML standard in fact talks of three phases, since it combines discovery and negotiation in one.
06_4557.qxd
10/19/05
1:12 PM
Page 173
Electronic Commerce
ebXML registry
2. Discovery
173
1. Implementation
CPP
CPP
CPA 3. Negotiation
Business 1 4. Transaction
Package
Business 2
Figure 6.5 ebXML usage phases.
Although this may not look overly complicated, the business models, CPPs, and CPAs can get complex. ebXML relies on the UN/EDIFACT modeling methodology (UMM) to model business processes and functional service requirements, in the form of an elaborate ebXML metamodel. Following this metamodel, enterprises can define their ebXML business models in Unified Modeling Language (UML) and refine them down to a point where they are translated to XML for inclusion in CPPs and CPAs. CPPs are typically long documents that can contain 1,000 lines or more of XML. Figure 6.6 shows a small excerpt of a CPP, stating that an enterprise can accept transaction messages via SMTP to the address ebxml@mybusiness. com. This particular excerpt is part of the company’s functional service requirements, and not the business model description. ebXML uses MIME to encode messages, and can run over any kind of protocol that will accept MIME as a payload. Although ebXML can be used over simple e-mail or HTTP, the ebXML standard also provides its own secure messaging protocol. Business modeling according to the UMM requires expert knowledge and skill. On the other hand, the majority of business transactions are standard, and business partners can often choose their CPP and CPA from a set of predefined templates. A business can fully or partially automate the discovery, negotiation, and transaction phases, but in practice they often require some degree of human intervention.
Examples for Section 6.3.3 The ebXML Web site (http://www.ebxml.org) provides many resources for ebXML users, including the ebML specifications themselves, and examples of CPP and CPA documents. http://www.ebxml.org/tools lists some available tools for ebXML, including registries, and message handlers. Major business integration software, including Oracle 9i, BEA WebLogic, Iona Orbix, and Fujitsu Interstage, can now interact with ebXML registries and process ebXML messages. The Open ebXML project (http://www.openebxml. soundforge.net) provides open source ebXML tools, though they appear to be mostly in prototyping stage. The Yellow Dragon Software Corporation of Vancouver, Canada, (http://ebxml.pwgsc.gc.ca) provides a live ebXML registry.
6.3.4 RosettaNet Around the same time that UN/EDIFACT and OASIS were creating ebXML, the UCC produced a similar, but different standard for electronic business based on XML called RosettaNet. Although the ebXML and RosettaNet concepts and structure are similar, they are incompatible and have different backgrounds. Simplistically put, UCC created RosettaNet from a practical point of view, while ebXML pretends to be more comprehensive and academic in its modeling of business processes. RosettaNet places more emphasis on the direct negotiation and transactions between trading partners, and does not have an extensive registry service like ebXML does. One could consider RosettaNet as a kind of compromise between X.12 and ebXML. RosettaNet built its e-business standards around four key concepts:
06_4557.qxd
10/19/05
1:12 PM
Page 175
Electronic Commerce
175
1. Partner interface processes (PIP) are templates for business processes. PIPs are grouped in seven clusters of related business processes, such as product information, order management, and inventory management. Each PIP contains a DTD describing the format of the XML messages that make up the business process in question. The role of PIPs in RosettaNet is similar to that of CPPs in ebXML and transaction sets in X.12. 2. RosettaNet implementation framework (RNIF) describes the messaging and protocol conventions used for communication between trading partners. RosettaNet messages are encoded in MIME format, but have a different structure than ebXML messages. The RNIF also describes how to use certificates, digital signatures, and encryption to implement secure transactions. 3. RosettaNet business dictionary (RNBD) provides a common vocabulary for business processes, so as to minimize ambiguity and confusion about the meaning of certain terms and procedures. 4. RosettaNet technical dictionary (RNTD) provides common descriptions of products and their properties, and assigns codes to them. Each industry sector can have its specific technical dictionary. The technical directories are available in a number of formats including XML. Table 6.4 contains an example of an entry in a RosettaNet technical directory. While many differences remain between ebXML and RosettaNet, they are now converging on the messaging protocols and formats. It is also possible, at least theoretically, to model RosettaNet PIPs in ebXML CPPs. The EDI community still vigorously discusses the question of whether ebXML and RosettaNet will eventually replace X.12 and EDIFACT. While Table 6.4 Sample RosettaNet Technical Dictionary Entry Code
XJA305
Major revision
4
Date defined
2000-06-16
Date revision
2001-07-11
Preferred name
EARPHONES–MICROPHONES
Short definition
A combination of telephone earphone, telephone transmitter, and possibly other components in a form convenient for holding simultaneously to ear and mouth.
Industry domain
EC
Property definitions
RNS204, RNS-XJA001, RNS-XJA305
06_4557.qxd
176
10/19/05
1:12 PM
Page 176
Implementing Value-Added Telecom Services
XML is generally accepted as the preferred format for plain-text message interchange, some point out that the relative simplicity of X.12, its proved maturity, and widespread deployment still give it a competitive edge over ebXML. Many of the larger business software suites now support both RosettaNet and ebXML, and often X.12 and UN/EDIFACT as well. At a price, of course.
Examples for Section 6.3.4 The Web site of RosettaNet, where one can find all relevant specifications, is http://www.rosettanet.org. It also offers a registry of electronic businesses. Global Exchange Services (GXS) of Gaithersburg, Maryland, (http://www. gxs.com), provides a service called the trading grid, a worldwide platform for electronic business. GXS supports multiple e-business standards, including RosettaNet, X.12, and UN/EDIFACT.
6.4 Person-to-Person Transactions Traditionally, people made payments to other individuals in cash, by personal check, or bank transfer. This works fine on a local scale, when the parties can trade in person, or when there exists some level of trust between them, or when they at least live in the same jurisdiction, so that there is some chance of settling disputes legally. But on the Internet, individuals now have the means to trade with others they have never seen, who might live tens of thousands of miles away. The Internet created the need for new global-scale forms of payment that provide a compromise between universal acceptability, on the one hand, and fraud resistance, on the other. The credit-card provides such a solution, but not all people have credit cards. And more importantly, accepting credit-card payments requires a merchant account at a cost that may be simply too high for doing only occasional transactions. For this reason, online enterprises have sought intermediate solutions for electronic P2P payments. In this section, we take a look at some of these new payment technologies. 6.4.1 Online Auctions Having a Web site product catalogue and storefront may be inconvenient for individuals who trade only occasionally on the Internet, and who do not offer products publicly. So how do individuals connect to each other for trading on
06_4557.qxd
10/19/05
1:12 PM
Page 177
Electronic Commerce
177
the Internet, without having to set up their own e-commerce solutions? The answer has come from online auctions. Over the last decade, Internet auctions have became immensely popular as P2P trading platforms. They provide several functions in one: 1. A catalog of items offered and sought by users. The advantage of online auction systems is that they can provide search facilities and an online entry of items for sale. 2. A system that executes auctions in a standard way, keeping track of bids, and closes the sale at a set time. Auctions can last anywhere from minutes to days. The shorter the auction, the more real time the bidding experience. 3. A system to increase trust with its users. This may be direct arbitration, in the case of disputes, or a peer-to-peer evaluation system that allows users to evaluate their trading partner after the transaction has been closed. There are literally hundreds of online auctions on the Internet that differ in many ways. Some online auctions serve particular communities, for example, collectors of specific items, while others are more general trading platforms. Some are pure auctions, while others combine auctioning with online stores for B2C sales. Some auction platforms provide payment services, others do not. Some auctions are pure P2P transaction platforms that only support bidding, while users take care of their own shipping and payment. In other cases, the auction provider manages parts of the cataloging, storage, auctioning, shipping, and payment process. Although most online auction providers use standard bidding, there are, in fact, many types of auction. Table 6.5 lists the most common ones. Many platforms allow users to bid by proxy. This means they do not have to make their bids manually each time the maximum bid raises, because the system will automatically bid for them. All a user has to do is specify the maximum price he or she is willing to pay. Given the fierce competition, there may not be much profit left in starting another general-purpose online auction system. Yet there are still business opportunities in providing online auctions for specific communities, or in providing alternative auctioning systems. The advantage of targeting specific communities, for example, of collectors, is that they tend to have higher trust levels. The smaller the community, the more likely the members are likely to know each other. The more specific the items, the more difficult it will be for imposters to steal them and sell them outside the community. The author knows of a community of rare coin collectors
06_4557.qxd
10/19/05
1:12 PM
178
Page 178
Implementing Value-Added Telecom Services
Table 6.5 Auction Types Auction Type
Description
Standard (English)
Users make increasing bids. When the auction time expires, the highest bid wins.
Sealed bid
Users deliver their sealed bids in a single round, and do not get to see the bids made by others.
Vickrey
These are sealed-bid auctions where the highest bidder gets the item at the price offered by the second highest bid. This ensures that bidders do not worry about what others bid, and offer the price they think the item is actually worth.
Dutch
Auctions for selling several identical items at a time. The bidder must specify not only a price, but also the amount of items he or she wishes to buy. The price multiplied by the amount determines the bid value. A single Dutch auction may have several winners.
Decreasing price
The seller calls out a high initial price, and lowers it stepwise until one of the bidders accepts and wins the auction.
Reserve price
The seller specifies a minimum price, and reserves the right not to sell the item if the highest bid is below the minimum.
Instant buy
The seller specifies a maximum price at which a bidder can shortcut the auction and purchase the item immediately.
Reverse
Auctions in which the lowest bid wins. These auctions are used in situations where a buyer selects a supplier offering the best price.
in Spain that uses mostly bank transfers for payment and ships coins to each other before actually receiving payment!
Examples for Section 6.4.1 If you believed eBay was the only online auction, think again. Yahoo! Auctions (auctions.yahoo.com), QXL (http://www.qxl.com), E-Way (http://www.ewaey. com), eBid (http://www.ebid.co.uk), Proxibid (http://www.proxibid.com), Bidvision (http://www.bidvision.com) all provide online auction systems. The site http://www.bidz.com supports auctions of very short duration (3 minutes), which give a strong real-time experience.
06_4557.qxd
10/19/05
1:12 PM
Page 179
Electronic Commerce
179
An example of a more specific auction is http://www.teletrade.com for coin collectors. The site http://www.seizedelectronics.com offers the possibility of participating in state auctions of seized electronics equipment from bankruptcies, among other seizures. Commercial auctioning platforms can cost anything between a few hundred and a few thousand dollars. XCAuction of Bristol, Pennsylvania, (http:// www.xcauction.com), is one of the providers of a licensed online auctioning system. Everysoft (http://www.everysoft.com) provides a free auction platform called EveryAuction. It requires CGI and the Practical Extraction and Report Language (PERL) to run. Strictly speaking, it is not open source, since it is actually under copyright, but the makers distribute it for free.
6.4.2 Person-to-Person Payment on the Internet Now that the Internet and mobile phones have become part of everyday life, they are also becoming alternative payment channels for individuals. There are several advantages to using Internet payment providers for individual payments: 1. Individuals can receive credit-card payments without an expensive merchant account. 2. Unlike personal checks, online payments are guaranteed. Unlike bank transfers, online payments are instantaneous. The risk of fraud and chargeback is lower than with direct credit-card payments. 3. Customers can buy items online without submitting any credit-card details to the seller. Instead, they register the credit-card details only to the trusted payment provider, and then make all subsequent payments through this provider. Most Internet payment providers allow individuals to make payments simply by sending an e-mail to their recipient, while providing multiple settlement options, by credit card, personal check, or bank transfer. They will usually hold funds for a user until he or she spends it online or withdraws it to a normal bank account. Internet payment service providers combat fraud by registering their users. Most payment services have several trust levels: the longer the history of good payment behavior, the more privileges a user gains. Some Internet payment providers also offer escrow services, which makes payment conditional to successful delivery and acceptance. Escrow services hold
06_4557.qxd
10/19/05
180
1:12 PM
Page 180
Implementing Value-Added Telecom Services
payment from the buyer in a special escrow account until the seller has shipped the items and the seller has acknowledged receipt. The purpose of an escrow service is to reduce the chances of fraud, especially in the case of transactions involving big-ticket merchandise, such as electronics, collectibles, or jewelry. An escrow service relies on a reliable delivery service that allows for tracking deliveries. Figure 6.7 shows the principle of escrow service, and how it interacts with the delivery service. Some alternative payment providers work with an independent virtual currency. This ensures that they do not need to manage any real currency, which has financial, logistic, fiscal, and legal advantages. The downside, however, is that buying or selling virtual currency is not straightforward. Virtual currency payment providers will try to keep the payment circuit as closed as possible and minimize liquidizing their accounts. To guarantee the value of the virtual currency, it must be anchored in some physical entity. This can be precious metal, diamonds, or even barrels of crude oil. Virtual currency–based payment providers may reside in offshore jurisdictions, so as to make their services more attractive to users who are subject to property taxes in their country of residence.
Seller
Escrow service
Delivery service
Buyer
Buyer and seller agree on a sale Buyer deposits payment Escrow holds payment Escrow notifies seller Seller ships item Shipment tracking ID Shipment tracking ID
Escrow pays seller Figure 6.7 Escrow service for on-line transactions.
Buyer accepts
06_4557.qxd
10/19/05
1:12 PM
Page 181
Electronic Commerce
181
Examples for Section 6.4.2 PayPal of San José, California, (http://www.paypal.com), is one of the most widely used Internet payment services. It features a simple Web interface for setting up accounts, sending, and receiving payments. PayPal verifies its new users by making a small initial payment with their credit-card upon registration. While this makes the initial user experience somewhat cumbersome, it helps in combating fraud. Being part of the eBay group, PayPal is well integrated with eBay auctions. There are many other payment providers on the Internet, such as FastPay by Natwest Bank (http://www.fastpay.com) and MoneyBookers (http://www .moneybookers.com). While their basic payment service is similar, they offer different conditions and added features. PPPay Ltd. of the United Kingdom (http://www.pppay.com) offers online payment and escrow services. They can track delivery by the Royal Mail, City-Link, UPS, and Parcelair. E-gold of Delaware (http://www.e-gold.com) is an alternative payment provider that aims to minimize the effect of fluctuating currencies by using a virtual worldwide Internet currency tied directly to the gold price. E-gold expresses value in precious metal weight, and does not hold any real currency. The company also offers accounts in the e-silver, e-palladium, and e-platinum virtual currencies, though these are less popular.
6.4.3 Mobile Payment While online shopping and payments are becoming increasingly popular, they still require a computer with an Internet connection, which not all people have. Moreover, it is difficult to make online payments while on the away from home or the office, and specifically while shopping. In these situations, the mobile phone may provide a solution. Mobile phones have become truly universal in a span of no more than a decade. Today, more people have mobile phones than personal computers. This, and its personal nature, give the mobile phone the potential of becoming a universal payment device. Table 6.6 lists some of the advantages of mobile phones as means of payment, as well as also some of its drawbacks. Although the advantages are significant, the disadvantages appear to have outweighed them until now. Analysts now agree, however, that this is likely to change in the next five years, as the industry standardizes more efficient and secure mobile payment solutions. There are different ways to use the mobile phone as a payment device. If the terminal and user subscription support packet data, then the mobile phone
06_4557.qxd
10/19/05
182
1:12 PM
Page 182
Implementing Value-Added Telecom Services
Table 6.6 Advantages and Disadvantages of the Mobile Phone as Payment Device Advantages
Disadvantages
• Personal device, always with the user
• Many different models and capabilities
• High penetration and acceptance
• Expensive communications
• Multiple interfaces (voice, text, browsing)
• Theft prone
• Processing capability and memory • High security level (SIM, encryption)
acts as a browsing client like any other, and all the standard Internet e-commerce techniques of Sections 6.2 and 6.4.1 and 6.4.2 apply. Even if the user has no access to mobile packet data connections, it is still possible to offer Internet-based payment services through WAP. In this case, the payment provider must provide its interfaces in the WAP Markup Language (WML). In practice this means simplifying and reducing page size, limiting graphics, and trimming user interaction (forms and dialogues). If the terminal has neither mobile Internet nor WAP, then the payment service provider can still use mobile specific communication channels: • Voice: The user connects to a voice response system and confirms payment by voice or by DTMF tones. • Short messaging (SMS): The user makes payments by sending an SMS. Note that this is not the same as paying through an SMS shortcode, as explained in Section 3.2.2. In the case of shortcodes, it is the message itself being charged at a fixed price. Here, the message carries information for the payment provider to complete a payment of any amount. • Unstructured supplementary service data (USSD): The service provider can set up the phone so that it sets up an USSD connection from the menu. USSD connections are low bandwidth data connections for exchanging application-specific data between network and terminal. A payment provider cannot use USSD without support from the operator, since USSD connections flow through the HLR. There are many ways to create payment systems with SMS or voice, and Figure 6.8 shows a practical example. In this example, the sender of the payment must have previously registered his or her credit-card data with the payment provider.
06_4557.qxd
10/19/05
1:12 PM
Page 183
Electronic Commerce
676482469
Financial service provider Payment service provider
(1)
183
696089758
cc
“pay 10 696089758 1234” Authorize amount SMS
(2) Acknowledge authorization “you have received payment of 10 euro from 676482469” (3)
SMS “accept 6789” SMS Charge amount
(4)
Acknowledge charge
“payment successful” SMS
(5)
“payment successful” SMS
Figure 6.8 An example of mobile payments with SMS.
If we imagine that the subscriber with number 676482469 wants to pay 10 euros to subscriber with number 696089758, the steps are the following: 1. The sender sends a short message to the payment service provider, indicating the amount (10), the destination (696089758), and a PIN6 (1234). The payment service provider may have an SMS shortcode to receive payment orders. 2. The payment service provider looks up the sender’s credit-card information from the customer profile and contacts the credit-card company to authorize the payment. The credit-card company notifies the payment service provider if the authorization succeeds. 3. The payment service provider sends an SMS to the receiver, to notify him or her of the payment. The receiver must confirm for the payment to be executed. 6. Sending the PIN in a short message may not be the safest way, especially if the phone stores the sent message. There are other ways of authenticating the payment with some additional dialogue. For example, the payment provider could send a short message to the sender, asking for three random positions in a six-digit or longer PIN.
06_4557.qxd
184
10/19/05
1:12 PM
Page 184
Implementing Value-Added Telecom Services
4. The payment service provider charges the credit card of the sender for the amount authorized in point 2. The financial service provider notifies the payment service provider of successful payment. 5. The payment service provider notifies both sender and receiver of the successful transaction. Most providers of mobile payment services use the concept of the virtual wallet or stored-value account (SVA), which works more or less like a prepay system. A user must maintain sufficient credit in the account in order to make payments, and can replenish the account via credit card, bank transfer, or check. If the payment service provider in the example of Figure 6.8 used a SVA rather than a direct credit-card payment, then the payment procedure would consist only of steps 1, 3, and 5. Some mobile network operators themselves act as payment provider, by allowing users to charge payments to their mobile subscription accounts. Operators have important advantages over third parties: they own a large base of registered customers and already have a billing relationship with them. SIM authentication is efficient and secure, and does not require the customer to memorize yet another username and password. Operators tend to be more enthusiastic about payment services for postpaid than for prepaid providers. This is not because prepaid accounts are less reliable (in fact, they are more reliable than postpaid accounts, because of the absence of bad credit risk), but because it becomes difficult for a mobile operator to predict which part of the credit will be spent on communications and which part they will have to pass on to third parties. Although mobile e-commerce has enormous business potential, it suffered serious setbacks in the early 2000s, as neither mobile network subscribers nor businesses embraced the technology. At this moment the market is fragmented, and several industry forums are trying to establish standards for mobile ecommerce: • Mobile Payment Forum (http://www.mobilepaymentforum.org) is mostly a business-oriented group that promotes existing e-commerce practices and standards. • Mobey Forum (http://www.mobeyforum.org) has specified requirements and a high-level architecture for mobile payments that takes into account a broad range of scenarios and technologies. • Mobile Electronic Transactions (MeT; http//www.mobiletransaction.org) has specified a specific way of making mobile payments using WAP connections.
06_4557.qxd
10/19/05
1:12 PM
Page 185
Electronic Commerce
185
• Open Mobile Alliance (OMA, http://www.openmobilealliance.org) plans to provide specifications for mobile e-commerce enabling technologies, but is likely to reuse existing specifications from other forums wherever possible. • Simpay (http://www.simpay.com) consists of a group of operators that share the ambition to promote a single interoperable mobile ecommerce solution for micropayments. Fortunately there are signs that these forums are converging, and are coming to the conclusion that it is better to cooperate than to compete.
Examples for Section 6.4.3 Txtorder of Bristol, United Kingdom, (http://www.txtorder.com), provides a system for selling products via SMS. The merchant gives a specific code to each of its products, and a customer buys by sending the code plus a unique signature to the Txtorder server. Txtorder charges the purchases to a credit card previously registered by the user. Swiftpass of Bristol, United Kingdom, (http://www.swiftpass.com), has created a system that processes payments and sends machine-readable tickets to mobile phones by SMS or MMS. This system is convenient specifically for theater and transport tickets, and vouchers. Telefónica’s Mobipay (http://www.mobipay.com) uses USSD connections to make mobile payments. They support both B2C and P2P payments, and provide connections to vending machines.
6.4.4 OSA-Parlay Charging Interface Although OSA-Parlay is not strictly speaking an e-commerce technology, it includes an interface for charging subscribers of telecommunications networks. This is particularly interesting for billing third party VAS to mobile or fixednetwork subscriber accounts. The Parlay group matched the OSA-Parlay charging interfaces with common prepaid and postpaid charging procedures, in particular the CAMEL charging mechanisms for roaming users with prepaid subscriptions. The OSA-Parlay interfaces are object-oriented, and describe remote objects with their methods, parameters, and value types. In order for a third-party application to charge a subscriber, it must start a charging session. In technical
terms, this means creating a charging session object that will manipulate the subscriber account. Within the charging session, the application can make two kinds of charges: direct (one-step) charges, or reservation-based (two-step) charges. Table 6.7 summarizes the OSA-Parlay charging operations. Reservation-based charging is mostly used with prepaid accounts. The application first reserves an amount to make sure that there is enough credit in the account, and then confirms the charge. Chapter 2 explains in detail how this works in CAMEL for providing prepaid communications. Direct charging is more often used in micropayments, where the service provider can afford a percentage of payments to fail. The OSA-Parlay interfaces in fact allow the service provider to specify both a preferred and a minimum accepted charge, so that a direct charge may still succeed partially if the account does not have sufficient credit. OSA-Parlay allows charging in currency, or in units of data volume. The latter charging method allows charges to be relative to the data volume transported. This is interesting specifically for charging content download or streaming, and even allows the network operator to adjust the price of the data transport to the application. Table 6.7 shows that each debit operation (whether direct or reservationbased) has its matching credit operation. The credit operations provide a means to undo debit operations, in case part of the transaction fails. But it also allows service providers to implement more complex application charging schemes that may include giving bonuses and loyalty incentives, or even transferring funds from one subscriber to another. Figure 6.9 shows how this can be done.
Figure 6.9 Person-to-person payment with OSA-Parlay.
Figure 6.9 depicts the use of OSA-Parlay to make a person-to-person payment from subscriber one to subscriber 2. The steps are the following: 1. The client application (which can be third-party operated) asks the charging manager interface to open a charging session for subscriber 1 and subscriber 2. 2. In the charging session for subscriber 1, the client application creates a reservation for the amount to be transferred to subscriber 2. In addition to the preferred amount, the client application can indicate a minimum amount to be reserved if there is not enough credit left to reserve the preferred amount. Charging session 1 responds with a confirmation, indicating the amount reserved and the amount left in the account after reservation. 3. The client application also creates a reservation in the charging session for subscriber 2, to receive the funds. The initial value of this reservation is 0, so no money is blocked initially in this account. Nevertheless, the application creates this reservation so that it may roll back the transaction if any of the next operations fail.
06_4557.qxd
188
10/19/05
1:12 PM
Page 188
Implementing Value-Added Telecom Services
4. The client application credits the amount to be transferred to the reservation in session 2, but leaves the reservation open so that this operation can be undone if another part of the transaction fails. If this succeeds, session 2 responds with an acknowledgment. 5. The client application now debits the amount to be transferred from the reservation in session 1. Again the client application may specify a preferred and minimum amount, but by setting them equal, it ensures that the session will charge the exact amount. The charging session responds with an acknowledgment, indicating the amount charged and the amount left in the reservation, which should be 0 if the operation succeeded. 6. The client application now closes charging sessions 1 and 2. This will close the reservations and free their blocked funds automatically. Although this may look like a complicated way of doing things, the two reservations ensure that the transaction can be rolled back if any of the operations fail. In particular, if the debitAmountRes operation in step 5 fails, then the client application can undo the creditAmountRes operation of step 4 by executing a debitAmountRes operation for the same amount on the reservation in session 2. Since the reservation blocks the funds for the client application, any other application cannot have consumed them. Apart from the charging operations shown in Table 6.7, an application can ask about the credit of the subscriber account (in currency or data volume units), set, and query the length of reservations. The OSA-Parlay charging interface is now also available in simplified form as a Web service, as part of the Parlay X Web services specifications created in collaboration with Paycircle (http://www.paycircle.org). The author is currently unaware of any live deployment of the OSA-Parlay charging interfaces, available to third-party application developers. In spite of OSA-Parlay’s elaborate security framework, fixed and mobile networks still appear to be reluctant to give third parties access to their subscriber accounts.
References [1]
PayCircle, PayCircle User Scenarios, white paper, http://www.paycircle.org, 2002.
[2]
Zoellick, B., Web Engagement—Connecting to Customers in e-Business, Reading, MA: Addison-Wesley, 2000.
06_4557.qxd
10/19/05
1:12 PM
Page 189
Electronic Commerce
Selected Bibliography http://www.2checkout.com, third-party merchant http://www.advanceware.net, Internet storefront software http://www.bidvision.com, Internet auctions http://www.bidz.com, Internet auctions http://www.easyshopmaker.com, Internet storefront software http://www.ebay.com, Internet auctions http://www.ebusinessready.org, AS2 interoperability testing http://www.ebxml.org, ebXML resources http://ebxml.pwgsc.gc.ca, Yellow Dragon ebXML registry http://www.e-gold.com, Internet payment provider with virtual currency http://www.everysoft.com, Internet auction software http://www.ewaey.com, Internet auctions http://www.fastpay.com, Internet payment provider http://www.gxs.org, B2B e-business solution provider http://www.mobeyforum.org, Mobey Forum http://www.mobilepaymentforum.org, Mobile Payment Forum http://www.mobiletransaction.org, Mobile Electronic Transactions Forum http://www.moneybookers.com, Internet payment provider http://www.nochex.com, Internet payment provider http://www.openebxml.soundforge.net, ebXML open-source tools http://www.openmobilealliance.org, Open Mobile Alliance http://www.oscommerce.org, open-source storefront software http://www.paycircle.org, Paycircle forum http://www.paypal.com, Internet payment provider http://www.pppay.com, Internet payment provider with escrow service http://www.proxibid.com, Internet auctions http://www.rosettanet.org, RosettaNet EDI home page http://www.propay.com, Internet payment provider http://www.seizedelectronics.com, Internet auctions of seized electronics
189
06_4557.qxd
190
10/19/05
1:12 PM
Page 190
Implementing Value-Added Telecom Services
http://www.shopfactory.com, Internet storefront software http://www.swiftpass, SMS-based electronic ticketing http://www.teletrade.com, Internet auctions http://www.txtorder.com, SMS-based e-commerce provider http://www.unece.org/trade/untdid/welcome.html, UN/EDIFACT home page http://www.x12.org, X.12 electronic document interchange (EDI) standard http://www.xcauction.com, Internet auction software http://www.zencart.org, open-source shopping-cart software
07_appendix_4557.qxd
10/19/05
1:16 PM
Page 191
Appendix A Key Technologies This appendix briefly reviews some key technologies referred to in this book, including Internet, XML, PKI, IN, OSA-Parlay, mobile networks, and CAMEL. It only serves as a quick reference; for a more comprehensive treatment of these technologies, please refer to the author’s companion book, Next Generation Intelligent Networks (Artech House, 2002).
A.1 Internet The Internet is best characterized as the worldwide interconnection of data networks, using the IP. The IP sends data in the form of discrete packets or datagrams, as they are sometimes called in IP terminology. IP packets consist of two parts: a header that contains information about the origin and destination of the packet, and the content of the packet to be filled by the application. Packets are sent from origin to destination by routers, much as letters are sent through the mail. 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 may be the next router on the path to the destination. A.1.1 Internet Protocols Apart from IP there are many other protocols that make the Internet work. The IETF structures these protocols in four layers, as shown in Figure A.1: 191
07_appendix_4557.qxd
192
10/19/05
1:16 PM
Page 192
Implementing Value-Added Telecom Services
Transport
TCP
Figure A.1 Internet protocols.
Others
...
UDP
...
FDDI
ATM
Ethernet
Token ring
IP
Internetwork
Network interface
FTP
HTTP
Applications
SMTP
1. The network interface layer represents the underlying physical network. This can be any kind of network as long as is it can transport data from one point to another, for example, ethernet, token ring, X.25, or multiprotocol label switching (MPLS). 2. The internetwork layer contains the IP for routing packet data through the interconnected networks of the underlying layer. This layer also contains the necessary protocols to manage IP, such as Internet Control Message Protocol (ICMP), Address Resolution Protocol (ARP), and Reverse Address Resolution Protocol (RARP). 3. The transport layer allows applications to exchange data over the Internet. The two main protocols in this layer are TCP and User Datagram Protocol (UDP). TCP provides a reliable connection for sending a continuous stream of bytes from application to application. TCP uses port numbers to distinguish packets coming from different applications, controls the data flow between sender and receiver, and ensures reliable delivery by retransmitting lost packets. UDP is similar, except that it does not retransmit lost packets and does not guarantee delivery.
07_appendix_4557.qxd
10/19/05
1:16 PM
Page 193
Key Technologies
193
4. The applications layer contains all the protocols that are specific to applications communicating over IP, such as e-mail (SMTP, POP3), file transfer (FTP), browsing (HTTP), remote invocation (SOAP) and many, many more. One of the application-layer protocols that has had the most impact on the development of the Internet is the Hypertext Transfer Protocol (HTTP), one of the cornerstones of the WWW. A.1.2 World Wide Web In essence, the WWW relies on two standards: HTTP and HTML. HTTP is a simple request–reply protocol. The client requests a page by sending a GET message to the server, indicating the file to be transferred. The server responds by sending back the requested file or files, with a status code (normally 200 OK when the request has been processed correctly). HTML is a simple language to format hypertext pages. HTML documents describe how the browser should treat the text, and how text is linked to other objects. When a user clicks on text that contains a hyperlink, the browser sends a HTTP GET command to the server specified in the link. When it receives the requested file, it interprets the HTML commands and automatically retrieves all the page components, such as graphics files, to render the page correctly. The Internet protocol uses 32-bit addresses (most commonly represented as four decimal numbers separated by dots, such as “10.95.112.257”), but most Web sites are known through a mnemonic name such as implementingVAS.com. The DNS, a standardized Internet application, maps mnemonic names to IP addresses. The best way to see DNS is as a distributed directory service. The DNS is a hierarchical system. Below the root server there are nine toplevel domain servers (TLDs): .com, .org, .net, .biz, .info, .edu, and 244 countrycode domain servers: .au, .es, .us, .uk, and so on, and each of these in turn points to millions of lower-level domain name servers that reside in companies, ISPs, and the like. The Internet Corporation for Assigned Names and Numbers (ICANN) administers the DNS, but delegates the registration of new names to commercial registrars such as AOL, Deutsche Telekom, Tucows, and Wild West Domains. Registrars can in turn use commercial resellers to sell domain names. Top-level domains are deregulated, and over the years a lucrative trade has emerged in much wanted names. Country-code domains fall under each country’s legislation, which varies significantly from administration to administration. Recently, however, some countries have started to deregulate their country-code domains as well.
07_appendix_4557.qxd
10/19/05
194
1:16 PM
Page 194
Implementing Value-Added Telecom Services
A.1.3 Cookies One of the most important limitations of HTTP is that it is stateless. An HTTP server simply serves HTTP requests in the order in which they arrive and sends back the requested information without keeping track of the dialogue with a specific client. To remember the dialogue state of a client, HTTP servers can use cookies. Cookies are small text files (maximum 3 kb, but usually much smaller) that a Web server sends with an HTTP response. The information fields in a cookie include the sending server’s domain and directory path, an expiration date, and a free text field that can contain any server-specific information. Table A.1 describes the cookie fields. When a browser receives an HTTP response with an attached cookie, it saves the cookie on the client’s disk and sends it back to the server with each subsequent HTTP request. This allows the server to identify and correlate client requests. Figure A.2 illustrates the use of cookies in a HTTP message sequence. In Figure A.2, the client requests a page named file.html. The HTTP server sends back the requested page, which contains links to various images, and attaches a cookie. When the client receives the reply, it saves the cookie and interprets the HTML file. Next, it has to request the image files that make up the
Table A.1 Cookie Fields Field
Explanation
Example
domain
The server domain that sends the cookie. The client machine will only save the cookie if this field corresponds to the server domain that sent the cookie. Every time the browser makes a request to this domain, the cookie is sent along with it. The domain requires at least two dots.
.mydomain.com
path
The path within the domain. Cookies will only be sent with a request to the exact path specified.
/shop
security
Normally not used.
FALSE
expires
Expiry date in milliseconds from January 1, 1970. If left blank, the cookie will expire when the browser is terminated.
2082787017
name
Any plain-text name.
user-type
value
Any plain-text string. The total length of the cookie, including the other fields, cannot exceed 4 kB.
registered
07_appendix_4557.qxd
10/19/05
1:16 PM
Page 195
Key Technologies
195
HTTP client (browser)
HTTP server (web server) GET /file.html
200 OK Store cookie Interpret page
200 OK
file.html
SET COOKIE
GET /image1.gif
imageN.jpg
Create cookie Retrieve page
Cookie Process cookie Retrieve file
image1.gif
GET /imageN.jpg
200 OK
Cookie
Cookie Process cookie Retrieve file
Render page Figure A.2 HTTP dialogue with cookies.
page. With each request for an image file, it sends the cookie back to the HTTP server, which can process the cookie to keep exact track of this client’s dialogue. Clients only send cookies to the server that originated them. This ensures that no third party can get a hold of the cookies on a client machine, and learn, for example, what items a user bought online. Still, Internet marketing firms have worked out tricks to exploit cookies for upselling and cross-selling. In the example of Figure A.2, all the images are located on the same server as the original HTML file. But a HTML page may also include links to pictures located at other servers. Such an external server can put its own cookies on the client’s machine, and if used cleverly, can get interesting information about the sites a client visited. A.1.4 Server Side Processing Many Web sites act as front ends to back-office applications that manage dynamic information, such as airline ticket reservations, online shops, currency conversion,
07_appendix_4557.qxd
196
10/19/05
1:16 PM
Page 196
Implementing Value-Added Telecom Services
and stock quotes. These applications demand that the HTTP server be able to execute programs, or consult databases, and create responses dynamically. Although HTML represents static content, nothing prevents an application from creating HTML pages on the fly and passing them to the HTTP server just in time to return them to the client. This is the principle of server-side processing. Different programmer communities have come up with different approaches to generating dynamic HTML content. Table A.2 shows four of the most popular technologies, with a reference to their support sites. Figure A.3 shows how server side processing works in the case of PHP, where the scripts are embedded in the page itself. When the user clicks on a link in the browser, the client requests the corresponding PHP page from the server. It can pass parameters as query strings of the form ?variable=value in this request. When the HTTP server receives the request, it interprets the scripts on the page with the parameters provided by the client. The scripts may involve queries to a database, for example with SQL. It inserts the result of each script into the page and sends back the dynamically generated result to the client. Needless to say that PHP requires an extension to HTML, to allow for embedded scripts.
Table A.2 Technologies for Dynamic HTML Content Generation Technology
Open source protocol for launching Perl scripts from a Web server. CGI is one of the older technologies for dynamic HTML content, and is generally used in UNIX environments.
PHP (Hypertext Preprocessor), www.php.net
Open-source scripting language for dynamically generated HTML pages, where the scripts are embedded in the page itself. Generally used in combination with Apache Web servers and MySQL database, also open source.
JSP (Java Server Page), java.sun.com/products/jsp
Calls Java programs from HTML pages. Combined with Java 2 Enterprise Edition (J2EE), this program allows for integration of complex enterprise back-office applications.
ASP (Active Server Page), msdn.microsoft.com/asp.net
Similar in approach to CGI and JSP, but for Microsoft systems.
07_appendix_4557.qxd
10/19/05
1:16 PM
Page 197
Key Technologies
197
Client Browser
GET file.php?var=value
SQL
Result
HTTP
Database
HTML pages Server
Figure A.3 Server-side processing with PHP.
A.1.5 Web Services The original purpose of the WWW was to provides access to human-readable text and graphics with hyperlinks. But there is no reason why programmers cannot use the Internet for communications between applications. Computer programmers have used remote procedure calls (RPC) and remote method invocations (RMI) for some time to build distributed applications, but plain RPC and RMI require that the client knows the server’s address, as well as which functions it exports. Web services combine the idea of RPC/RMI with that of the loosely linked information on the WWW. Web services allow clients to search for an available service on the Internet and connect to it, even if it has no previous knowledge of the remote service interface. To achieve this, Web services rely on three standards: 1. Simple object access protocol (SOAP) describes a remote procedure call as an XML document that can be sent in the payload of an HTTP request/reply sequence.
07_appendix_4557.qxd
10/19/05
198
1:16 PM
Page 198
Implementing Value-Added Telecom Services
2. Web Services Description Language (WSDL) describes the interface of a remote service, so that a client knows what to invoke and how to invoke it. 3. Universal Description, Discovery, and Integration (UDDI) registry allows a server to publish and a client to search Web services interfaces in the WSDL format. As the name suggests, SOAP has a simple XML structure that can be read even by humans. SOAP requests travel from client to server in the payload of an HTTP message. Using HTTP as a transport protocol has the enormous advantage that almost any computer on the Internet supports it, and most firewalls let HTTP traffic through, if anything at all. WSDL documents contain XML schema that define how to structure the SOAP messages to the service in question. XML and XML schema are further explained in Appendix A.2. Figure A.4 shows the typical usage scenario for Web services: 1. Publication: A server publishes its Web service on the UDDI register, in the form of a WSDL document. 2. Discovery: A client that wishes to use the service searches the UDDI register and downloads the WSDL file of the service. 3. Invocation: Once the client possesses the WSDL file, it has the necessary XML schema to formulate a correct SOAP request to the server. The schema also tells the client how to parse the response that comes back from the server.
UDDI WSDL
Discovery
WSDL
Client Client application
Figure A.4 Web services concept.
Register
Invocation
Publication
Server Web service
SOAP
07_appendix_4557.qxd
10/19/05
1:16 PM
Page 199
Key Technologies
199
A.1.6 Voice over IP The Internet was born as a network of data networks. Although IP protocols were not designed with telephony in mind, there is no fundamental reason why voice or video signals cannot be coded into IP packet streams. This is exactly what voice and video codecs do. There are many kinds of voice codecs, each with its own quality of voice, bandwidth, required processing power, and delay. Today’s codecs can convert voice signals into bit streams of 6 Kbps, which is such a narrow bandwidth that the Internet can easily carry it. Telephony over the Internet requires not only coding voice into data packet streams, but also a signaling protocol to set up calls between origin and destination. The two most widely used standards for voice and multimedia over IP signaling are H.323 and SIP. The H.323 standard of the ITU-T is not really a protocol, but a group of specifications that include codecs, control signaling, registration, admission, and conferencing control. SIP is an application-layer Internet protocol specified by the IETF, and based for a large part on HTTP. As in HTTP, its messages are plain text, 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. In principle, two hosts (computers) on the Internet can negotiate a voice call directly between them, as long as they know each other’s address. They exchange the necessary SIP or H.323 messages to acknowledge their availability (SIP calls this inviting), settle on a codec and port to connect to, and start the codecs. Very often, however, both the signaling path and the voice (or media) stream pass through intermediate nodes. Signaling messages can flow through SIP proxies or H.323 gatekeepers, which authorize, screen, redirect, queue, or otherwise treat the signaling messages. Clients can direct their voice or media streams to media gateways, which can do anything from translating between codecs to multipoint conference bridging, providing automatic voice response, and bridging to the public switched telephony network. A media gateway is usually controlled by a media gateway controller, which must support signaling to negotiate the connections with its clients. The standard protocol for controlling a media gateway is Media Gateway Control Protocol (MGCP) or MEGACO. The combination of media gateway and media gateway controller does much the same as a telephony switch: treating voice streams in response to signaling. For this reason, and because it treats packet streams rather than voice circuits, the media gateway and its controller together are called a soft switch, as illustrated in Figure A.5.
07_appendix_4557.qxd
10/19/05
200
1:16 PM
Page 200
Implementing Value-Added Telecom Services
SIP, H.323, SS7 Media gateway controller
Media gateway
Terminations
Terminations
MGCP
Figure A.5 Soft switch.
A.2 Information Technologies Many of the standards in this appendix rely on information technologies for information exchange and security. The following sections briefly explain two key technologies, Extensible Markup Language (XML) and public key infrastructure (PKI). A.2.1 Extensible Markup Language Computers that exchange textual data have to structure it in some way to ensure that the sender and receiver understand each other. For example, if a library sends book information to another library, it is convenient to structure the text in such a way that the receiver understands what line contains the author, title, and so on. This can be achieved by marking up the text with tags that identify each data item. The XML serves this purpose, and is the most widely used markup language for machine-to-machine communications. XML uses simple tags of the form , which marks the beginning of a data element, and , which marks its end. The XML syntax has only a few basic rules, for example, a document must start with an XML declaration () and must have a root element; each
07_appendix_4557.qxd
10/19/05
1:16 PM
Page 201
Key Technologies
201
element opened must be closed; tags must be properly nested (e.g., … is correct, but … is not); tags may contain quoted attributes (e.g., ); XML is case sensitive; and white space is reserved. This is almost all there is to plain XML. In many applications, it is convenient to impose an additional syntax on XML documents, for example, “the element contains a sequence of , , , and elements.” Two important metaformats exist for defining additional XML syntax: DTD and XML schema. An XML document that also conforms to a particular DTD or XML schema is called valid with respect to that DTD or schema. DTD use a format different from XML, while XML schema themselves are expressed in XML. Comparing them very superficially, XML schema allow for stronger data typing and better semantic description, while DTDs are simpler and more compact. Yet both XML schema and DTDs have their proponents, and both are used today. A.2.2 Public Key Infrastructure Public key infrastructure (PKI) refers to asymmetric encryption technologies that allow one key to be public, while the other is secret. PKI is used for encryption, authentication, and message verification. There are several public key technologies, the most widely known being RSA. RSA stands for Rivest, Shamir, Adleman, the names of the three scientists who invented and patented the technology, and commercialized it through a company with the same name (http://www.rsasecurity.com). The idea behind RSA is that it is mathematically possible to derive three numbers, e, d, and n from two very large prime numbers, so that: encryptedtext = (originaltext e) mod n originaltext = (encryptedtext d ) mod n and moreover, it is very difficult to derive e from d and vice versa, even if one knows n. This allows the pair (e,n) to be used as a public encryption key and the pair (d,n) as a secret decryption key. However, used in reverse it can also be used to authenticate a sender, since a message encrypted with a secret encryption key can only be decrypted with the matching public decryption key. Figure A.6 illustrates how PKI can be used for encryption and digital signing. The top part of the figure shows how the sender encrypts a message with the receiver’s public key. Although the encryption key is public, only the receiver that has the matching secret key can decrypt the message.
07_appendix_4557.qxd
1:16 PM
Page 202
Implementing Value-Added Telecom Services
Encrypted message
Encrypt Public key
Message
Decrypt
Message
Nonsecure network
Secret key
Signed message
Verify
Message
Message
Sign
202
10/19/05
Figure A.6 PKI for encryption (top half) and digital signing (bottom half).
The bottom part of Figure A.6 shows how a sender signs a message with its secret key. If a receiver can decrypt the message with the matching public key, then only the holder of the secret key could have sent this message. This allows the receiver to verify that the message indeed came from its claimed origin, not from an impostor. Digital certificates combine the principles of encryption and digital signing. A digital certificate is a digitally signed document containing the holder’s name, a serial number, an expiration date, and the holder’s public key, used for encrypting messages from client to server. The certificate’s digital signature comes from a known and trusted certificate-issuing authority, so that a recipient can verify that the certificate is real. ITU standard X.509 fixes a format for certificates, so that standard registries can store and manage them. A.2.3 Secure Socket Layer (SSL) The standard technology for secure communications between a client and a server on the Internet is SSL. SSL provides two types of security: 1. Authentication: SSL allows the client to authenticate the server, so it knows it is actually communicating with the server it is supposed to, and not with an impostor. SSL guarantees the server identity by means of digital certificate.
07_appendix_4557.qxd
10/19/05
1:16 PM
Page 203
Key Technologies
203
2. Encryption: SSL encrypts the IP packets exchanged by client and server so they cannot be eavesdropped. Since the server and client do not necessarily know each other, they will have to exchange authentication and encryption keys before they can start communicating. SSL uses PKI, and particularly digital certificates, for this. Figure A.7 explains how SSL works. When a URL starts with https:// the client (browser) knows it has to start an SSL session. Figure A.7 shows the sequence of steps to set this secure communication up: 1. The client opens a TCP/IP connection at TCP port 443, which is the port reserved for SSL. 2. The client and server send handshake messages to confirm their readiness. 3. The server sends its certificate to the client. The certificate contains the server’s public encryption key. 4. The client verifies the certificate. The certificate may come directly from a trusted certification authority, in which case the verification is
Client Symmetric
Secret Server Certificate (1)
Open TCP port 443
(2)
SSL handshake
Public
Certificate Public
(3)
(4) Symmetric (5)
(6)
Exchange encrypted information (7) Figure A.7 Secure socket layer.
07_appendix_4557.qxd
10/19/05
204
1:16 PM
Page 204
Implementing Value-Added Telecom Services
straightforward. It may also involve a certification chain (i.e., a certification authority, certified by another certification authority, etc.) leading up to a trusted root. Even if the client is unable to verify the certificate, it may still ask the user to accept the certificate at known risk. 5. The client encrypts its symmetric encryption key using the sender’s public key, and sends this to the server. Note that PKI guarantees that only the server can decrypt this information, as it is the only party holding the matching secret key. 6. The sender decrypts the client’s symmetric key with its secret key. 7. Sender and receiver can now exchange information in both directions, using the client’s symmetric key for encryption and decryption. While the client and server use PKI for initial certification and key exchange, the subsequent information flow is encrypted by secret keys for several reasons: • PKI is computationally heavy. While symmetric encryption algorithms have the large drawback that their keys must be kept secret, they are computationally much less complex and use smaller encryption keys, thus allowing for more efficient encryption than the asymmetric RSA algorithm. • A single symmetric key allows two-way encryption of information between client and server. The sender’s asymmetric key pair only allows for encryption of the information flow from client to server. Encryption in the opposite direction would require the client to possess another asymmetric key pair. • Symmetric encryption keys are easy to generate and can be refreshed for each session, which improves security. Even if a hacker were to break the symmetric key in one particular SSL session, it would be useless in the next. On the other hand, certified asymmetric key pairs are costly to generate and are refreshed less often.
A.3 Telephony The public switched telephony network (PSTN) has been around for more than a century, and in spite of digitalization and liberalization, has kept most of its hierarchical structure. At the bottom of the hierarchy are the central office exchanges, where subscriber lines terminate. These are interconnected by several levels of intermediate exchanges, culminating at the top of the hierarchy with the international exchanges.
07_appendix_4557.qxd
10/19/05
1:16 PM
Page 205
Key Technologies
205
A.3.1 Signaling An essential element of a telephone network is the messages sent between exchanges to set up a call. This is called signaling, which includes checking the status of the destination user and alerting, reserving, and committing circuits. Telephone networks now use a separate data network for call signaling. The separation of signaling and call allows the telephone network to negotiate all necessary resources before actually setting up the connections. This avoids setting up connections to busy or absent subscribers. Practically all networks in the world now use SS7, an ITU-T standard for digital signaling. SS7 specifies a highly reliable signaling network with an extensible protocol scheme for different telephony applications. These include key protocols such as the ISDN user part (ISUP) for telephony, mobile application part (MAP) for mobile-specific signaling, and intelligent networks application part (INAP), which are explained in the next section. A.3.2 Intelligent Networks Intelligent networks (IN) were invented by Telcordia (formerly Bellcore), and later standardized by the ITU-T, for providing VAS in telephony networks. A few examples of advanced call processing are call forwarding, caller ID, callwaiting, 800 numbers, televoting, and, of course, prepaid calls. The IN concept flows logically from the SS7 signaling architecture, whereby the call data is processed on a separate data network before the connections are set up. IN introduces a SCF to the signaling network, which allows service providers to control call processing with stored programs. When a call requires special treatment, for example, forwarding to another number, the telephone exchange asks the SCF to perform additional call processing and waits for instructions from the SCF to proceed. This procedure is called service triggering. An exchange connected to an SCF, and capable of triggering services, is said to have SSF. The interaction between SSF, which triggers additional call processing, and SCF, which performs it, forms the core of the IN concept. Figure A.8 shows that IN contains several additional functions: • Service management function (SMF) for deploying and managing services. • Special resource function (SRF) for processing voice circuits, for example, conference bridging or IVR. • Service data function (SDF) for storing service specific data. This function is often collocated with the SCF, unless there is massive specialized data involved.
07_appendix_4557.qxd
10/19/05
206
1:16 PM
Page 206
Implementing Value-Added Telecom Services
SDF
SCE
Service creation
SMF
Service management
SCF
Service control
Service switching SSF
SSF SRF
Figure A.8 Intelligent networks.
• Service creation environment (SCE) for creating services out of predefined components, called service independent building blocks (SIBs). The operator can host these functions in dedicated nodes (SCF in a service control point, SSF in a service switching point, SDF in a service data point, etc.), but can also collocate them with other functions. The combination of SSF, SCF, SDF, and SRF in one network element is often called a service node. The author’s book Next Generation Intelligent Networks from Artech House provides an extensive explanation of IN, and of OSA-Parlay explained briefly in the next section. A.3.3 OSA-Parlay Intelligent networks were designed in the early 1990s for delivering VAS in circuit-switched telephony networks, which were then mostly controlled by a single incumbent operator. Deregulation forced many operators to open their networks to third-party services, but IN was not designed to allow external access to its interfaces. OSA and Parlay have evolved from IN as an answer to this problem, and are seen by many as their natural successor. OSA and Parlay specify the interfaces
07_appendix_4557.qxd
10/19/05
1:16 PM
Page 207
Key Technologies
207
that allow third-party applications to control network functions and respond to network events. These interfaces are open, language and platform independent, and include security features. Figure A.9 shows the principle of OSA-Parlay: third-party applications can receive information about network events and control network resources through an external interface. A group consisting of BT (United Kingdom’s incumbent operator), Microsoft, Nortel, Siemens, and Ulticom first specified Parlay in 1998, and merged it a few years later with a similar specification from 3GPP, called open service access (OSA). OSA and Parlay are now available as one set of specifications, which we will refer to as OSA-Parlay. OSA-Parlay standardize two types of interface: the framework interfaces provide nonspecific access functions, such as authentication, service discovery, and monitoring; the service interfaces give access to specific network functions, such as call completion, messaging, mobile user location, or charging. Figure A.10 shows the OSA-Parlay architecture. The OSA-Parlay service interfaces provide access to service capability features (SCF, not to be confused with the SCF in IN!), units of high-level network functionality. The SCF
Third-party application server Network events
Control
OSA-Parlay Carrier network (PSTN, mobile, or IP)
Figure A.9 OSA-Parlay concept.
07_appendix_4557.qxd
208
10/19/05
1:16 PM
Page 208
Implementing Value-Added Telecom Services
Application servers Applications
OSA interface Service capability features Framework
Service capabilities
Service capability servers
HLR
MSC
WAP
Mobile network Figure A.10 OSA-Parlay.
encapsulate lower-level network functions that are not normally accessible from outside the network, like determining a user’s location or setting up a voice circuit. These SCF run on service capability servers (SCS), and there is a special server that offers the framework services. OSA-Parlay only specifies the interface of the SCF, not their implementation in the servers or the technology for accessing them. Table A.3 shows the OSA-Parlay SCF. The OSA-Parlay standard neither prescribes which interfaces a service provider must implement nor how to. A network provider can set any level of security it wants and can choose to enable or disable access to any service capability feature as it sees fit. Because different providers may offer different service capability features, OSA-Parlay offers a service discovery interface through which a third party can query which capabilities are available. Third-party applications run in application servers and can make use of service capability features through the OSA-Parlay interface. These application services can be anything from a large enterprise server to a PC in a garage-based start-up company, and connect to the OSA-Parlay interfaces with CORBA, SOAP, or any other distributed applications technology. OSA-Parlay allows third parties to create new services by integrating their enterprise applications with public network services, which was very difficult to achieve with IN. Examples of new services that can be done with OSA-Parlay are applications that deliver content dependent on location and terminal capabilities, enterprise-controlled policies, company-screened employee calls from mobile phones, virtual call centers, and content-dependent charging of download traffic.
07_appendix_4557.qxd
10/19/05
1:16 PM
Page 209
Key Technologies
209
Table A.3 OSA-Parlay Interfaces Feature
Short Description
Framework
Security, integrity, and management functions that are common to all service features
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
Presence and availability
Identity management, requesting presence and availability information, notification of presence and availability events
Generic messaging
Sending and receiving messages of any kind, manipulating mailboxes and mail directories
Terminal capabilities
Interrogating a terminal for its capabilities
Connectivity management
Negotiation and management of QoS and service-level agreements
Policy management
Setting and modifying policies, receiving policy events for policy-enabled services
Account management
Creating, deleting, and modifying subscriber accounts
Charging
Reservation and charging of units of volume or money against a subscriber account
OSA-Parlay is seen by many in the industry as the natural successor of IN, now that IN standardization has come to a virtual standstill in ITU-T, ETSI, and ANSI. Recently, Parlay and 3GPP have made efforts to combine OSAParlay and Web services (see Appendix A.1.5), which some system integrators consider a more versatile and IT-oriented alternative. The resulting Parlay X specifications provide simplified versions of some OSA-Parlay interfaces, in the form of Web services, specified in WSDL format.
A.4 Mobile Networks Mobile networks play a central role in this book, for their capacity to bring a wide range of value added applications and services through personal, mobile devices. Explaining mobile networks in detail goes beyond the scope of this book.
07_appendix_4557.qxd
210
10/19/05
1:16 PM
Page 210
Implementing Value-Added Telecom Services
This appendix provides a bird’s eye view of mobile networks, so as to understand their most basic principles. There are many mobile network standards. Europe, the United States, and Japan employ different incompatible networks, but these differ mostly in the radio network while their fixed-network structure is very similar. For this reason, this appendix concentrates on the 3GPP standards GSM and GPRS. A.4.1 Global System for Mobile Telecommunications The Global System for Mobile telecommunications (GSM) consists of three main components: the base station subsystem (BSS), the network switching subsystem (NSS), and the terminals or mobile stations (MS), as they are called in GSM. The BSS manages the radio resources. It consists of BSC, which run the software to manage radio channels, and BTS containing the actual transmitters and receivers. One BSC can manage the radio connections of several BTS. The NSS represents the core network of the GSM network. The key component in the NSS is the MSC, a telephony switch with extensions to handle mobile terminals. Apart from voice circuit switching, the MSC manages the location of subscribers and handover from one base station to another if the user moves during the call. 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) that holds essential subscriber information, including which VLR a subscriber is currently attached to. The HLR and VLR play an essential role in managing the mobility of subscribers in a GSM network. A GSM subscription is stored on a small smart card called the subscriber identity module (SIM), which is inserted in the terminal. Each subscription is identified by a unique identifier, the IMSI. The IMSI consists of a country code, network code, and subscriber identity, but it is distinct from the dialed number MS-ISDN. The reason to separate the MS-ISDN from the IMSI is to allow subscribers to change operators without changing their numbers (number portability). A.4.2 General Packet Radio System (GPRS) GSM was designed for circuit-switched voice, but people soon realized that circuit switching is an inefficient way of transporting data. 3GPP therefore standardized a way of using the existing GSM radio infrastructure for cellular packet data communications, called General Packet Radio System (GPRS). GPRS uses the same frequencies and radio technology as GSM, and therefore requires no changes to transmitter and receiver hardware in terminal base
07_appendix_4557.qxd
10/19/05
1:16 PM
Page 211
Key Technologies
211
Circuit-switched domain MSC
GMSC
PTSN, ISDN, or GSM
VLR BSC
MS BTS
HLR
PCU
Radio network
SGSN
IP
GGSN
Internet
Packet-switched domain Figure A.11 Cellular mobile network with circuit and packet switching.
stations. It only uses the GSM channels in a different way. Figure A.11 shows how voice-switched GSM and packet-switched GPRS can share the same radio resources. GPRS traffic (packet data) is fundamentally different from GSM traffic (circuit-switched voice), and so the GPRS core network is different from the GSM core network. Instead of the MSC, the GPRS core network contains the serving GPRS support node (SGSN), a packet router with additional functionality for mobility management (location updates and handovers). At the edge of the GPRS network, the gateway GPRS support node (GGSN) acts as a 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 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 to which a subscriber is attached. 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 a another IP packet that has as address the SGSN that the subscriber is attached to.
07_appendix_4557.qxd
10/19/05
212
1:16 PM
Page 212
Implementing Value-Added Telecom Services
A.4.3 Universal Mobile Telecommunications System GPRS has serious limitations in capacity and bandwidth, because it has to use the GSM radio interface, which was designed for voice rather than for highspeed data communications. 3GPP standardized the Universal Mobile Telecommunications System (UMTS) as a new-generation network for broadband mobile multimedia communications. The industry refers to UMTS as a 3G network, because it evolved out of GSM and GPRS (second generation) and analog networks (first generation). UMTS mainly differs from GSM and GPRS in the radio network part, where it uses another spectrum and different radio access technology. UMTS is compatible with both the GSM and GPRS core networks, to enable evolution from 2G networks. Even so, most operators will change their UMTS core network to an all-IP network that also carries voice communications. UMTS includes specific infrastructure to support multimedia sessions. The IMS is in essence a soft switch architecture that allows for the control of multimedia sessions over packet-switched connections. The United States and Japan have different 3G mobile network standards. Since they are similar to UMTS in the fixed-network part, however, many services will interoperate. A.4.4 CAMEL 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, why not just 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. The customized applications for mobile enhanced logic (CAMEL) functions are largely the same as that of IN. The SSF in the MSC triggers services to the SCF, which executes the service logic. But unlike IN, CAMEL has to take into account that a subscriber can be roaming in another network. Regardless of where the subscriber may roam, the SCF in the home network always treats the service. If the subscriber happens to visit another network, this means that the trigger may come from an SSF outside the subscriber’s home network. In the case of an outgoing call, the visited network’s MSC triggers the service. Yet an incoming call first arrives at the GMSC of the subscriber’s home network, which diverts it to the visited network (this is called tromboning in GSM). Both the GMSC of the home network and the MSC in the visited network can trigger services on incoming calls.
07_appendix_4557.qxd
10/19/05
1:16 PM
Page 213
SCF
213
Home network
P CA
CA P
MA
HLR
P MA
P
Key Technologies
Interrogating (usually home) network
Visited network
SSF
SSF
Gateway MSC
MSC
VLR
Figure A.12 CAMEL architecture.
GSM networks rely on the HLR to store subscriber location information and manage subscriber mobility. This has the consequence that the CAMEL SCF must communicate with the HLR for services that involve the user’s location. Figure A.12 shows the different interactions in CAMEL. The wireless IN (WIN) standard of the Telecommunications Industry Association (TIA) can be regarded as the U.S. equivalent of CAMEL.
07_appendix_4557.qxd
10/19/05
1:16 PM
Page 214
07_appendix_4557.qxd
10/19/05
1:16 PM
Page 215
Appendix B Standards This appendix lists some of the key standards that apply to the technologies described in this book. Whereas some standards have a long life span, others may lose relevance over time, or become superseded by other standards. For this reason, this list should be taken neither as definitive nor as complete. It is highly recommended that the reader check the status of a standard before using it. The standards have been listed in alphabetical order according to technological area.
B.1 CAMEL 3GPP TS 22.078 version 7.0.0, Customized Applications for Mobile Enhanced Logic (CAMEL) Service Definition (stage 1), March 2004 3GPP TS 23.078 version 6.4.0, Customized Applications for Mobile Enhanced Logic (CAMEL) stage 2, June 2004 3GPP TS 29.078 version 6.2.0, Customized Applications for Mobile Enhanced Logic (CAMEL) Application Protocol (stage 3), June 2004
B.2 Digital Rights Management ISO/IEC 21000-5:2004 Information Technology—Multimedia Framework (MPEG-21)—Part 5: Rights Expression Language, March 2004 OMA-DRM-V2_0-20040715-C, Digital Rights Management V2.0 Enabler Package, July 2004
215
07_appendix_4557.qxd
216
10/19/05
1:16 PM
Page 216
Implementing Value-Added Telecom Services
B.3 E-Commerce IETF RFC 3335, MIME-Based Secure Peer-to-Peer Business Data Interchange over the Internet, September 2002 IETF, MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2), Internet Draft, December 2004 IETF, FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet, Internet Draft, April 2005 ISO 9735, Electronic Data Interchange for Administration, Commerce and Transport (EDIFACT)—Application Level Syntax Rules, Volumes 1–10, 2002 OASIS, ebXML Registry Services Specification, version 2.0, December 2001 OASIS, ebXML Message Service Specification, version 2.0, April 2002 OASIS, ebXML Business Process Specification Schema, version 1.01, May 2001 OASIS, ebXML Collaboration Protocol Profile and Agreement Specification, version 2.0, September 2002
B.4 Intelligent Networks ITU Q.1221, Introduction to IN Capability Set 2 ITU Q.1223, IN Global Functional Plane Architecture for Capability Set 2 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
B.5 Location-Based Services 3GPP TS 22.071, Location Services (LCS); Stage 1 versions 3.5.0, 4.6.0, 5.4.0, 6.7.0 (March 2004) and 7.1.0, December 2004 3GPP TS 23.171, Location Services (LCS); Functional Description; Stage 2 (UMTS), version 3.11.0 3GPP TS 23.271, Functional Stage 2 Description of Location Services (LCS), versions 4.13.0, 5.13.0, 6.11.0 and 7.0.0 3GPP TS 43.059, Functional Stage 2 Description of Location Services (LCS) in GERAN, versions 4.6.0, 5.4.0 and 6.4.0
07_appendix_4557.qxd
10/19/05
1:16 PM
Page 217
Standards
217
3GPP TS 44.035, Location Services (LCS); Broadcast Network Assistance for Enhanced Observed Time Difference (E-OTD) and Global Positioning System (GPS) Positioning Methods, versions 4.1.0, 5.0.1 and 6.0.0 3GPP TS 48.031, Location Services LCS: Serving Mobile Location Center— Serving Mobile Location Center (SMLC—SMLC); SMLCPP specification, versions 4.1.0, 5.0.0 and 6.0.0 3GPP TS 22.935, Feasibility Study on Location Services (LCS) for Wireless Local Area Network (WLAN) Interworking, version 1.0.0 3GPP TS 23.871, Enhanced Support for User Privacy in Location Services (LCS), version 5.0.0 3GPP TS 32.271, Telecommunication Management; Charging Management; Location Services (LCS) Charging, version 6.0.0 3GPP TS29.199-09, Open Service Access (OSA); Parlay X Web Services; Part 9: Terminal Location, version 6.1.0 Open Mobile Alliance (OMA), Mobile Location Protocol (MLP), version 3.1, Candidate Enabler, OMA-LIF-MLP-v3_1-20040316-C, March 2004 Open Mobile Alliance (OMA), User Plane Location Protocol (SUPL), version 1.0, draft, OMA-TS-ULP-V1_0-20050315-D, March 2005
B.6 Messaging 3GPP TS 22.140, Multimedia Messaging Service (MMS); Stage 1, version 6.6.0, June 2004 3GPP TS 23.140, Multimedia Messaging Service (MMS); Stage 2, version 6.8.0, January 2005 3GPP TS 26.140, Multimedia Messaging Service (MMS); Media formats and codes, version 6.1.0, January 2005 3GPP TS 32.270, Telecommunication Management; Charging Management; Multimedia Messaging Service (MMS) Charging, version 6.1.0, January 2005 3GPP TS 23.041, Technical Realization of Cell Broadcast Service (CBS), version 6.2.0, January 2004 IETF RFC 1459, Internet Relay Chat Protocol IETF RFC 3920, Extensible Messaging and Presence Protocol (XMPP): Core IETF RFC 3921, Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence
07_appendix_4557.qxd
10/19/05
218
1:16 PM
Page 218
Implementing Value-Added Telecom Services
B.7 OSA-Parlay ETSI ES 202 915-4-1 version 1.2.1, Open Service Access (OSA); Application Programming Interface (API); Part 4: Call Control; Subpart 1: Call Control Common Definitions, European Telecommunications Standards Institute (ETSI), August 2003 ETSI ES 202 915-4-2 version 1.2.1, Open Service Access (OSA); Aplication Programming Interface (API); Part 4: Call Control; Subpart 2: Generic Call Control SCF, European Telecommunications Standards Institute (ETSI), August 2003 ETSI ES 202 915-9 v1.1.1, Open Service Access (OSA); Application Programming Interface (API); Part 9: Generic Messaging SCF, January 2003 ETSI ES 202 915-12 V1.2.1, Open Service Access (OSA), Application Programminng Interface, Part 12: Charging SCF (Parlay 4), August 2003
B.8 Streaming Content 3GPP TS 26.234, Transparent End-to-End Streaming Service; Protocols and Codecs 3GPP TS 26.244, Transparent End-to-End Streaming Service; 3GPP File Format (3GP) 3GPP TS 26.245, Transparent End-to-End Packet-Switched Streaming Service (PS); Timed Text Format 3GPP TS 26.246, Transparent End-to-End Packet-Switched Streaming Service (PSS); 3GPP SMIL Language Profile
B.9 WAP Push WAP-235-PushOTA-20010425-a, Push Over The Air (OTA) Protocol, WAP Forum (now Open Mobile Alliance) WAP-247-PAP-20010429-1, Push Access Protocol (PAP), WAP Forum (now Open Mobile Alliance)
08_acronyms_4557.qxd
10/19/05
1:26 PM
Page 219
Acronyms 2G 3G 3GPP AAC-LC ADSL AFLT AGPS AMR API ARP AS ASF ASN.1 ASP AVS B2B B2C BMP BSS BT BTS CAMEL CBC CBS CDF CDMA CDR CEL CEPT CGI
Second generation cellular mobile networks (e.g., GSM, D-MPS) Third generation cellular mobile networks (e.g., UMTS) Third Generation Partnership Project Advanced Audio Coding–Low Complexity codec asymmetric digital subscriber line advanced forward-link trilateration assisted GPS Adaptive Multirate codec application programming interface Address Resolution Protocol applicability statement Advanced Systems Format (Microsoft) Abstract Syntax Notation One Active Server Page (Microsoft) address verification system business to business business to consumer bitmap base station subsystem British Telecom base transceiver station customized applications for mobile enhanced logic cell broadcast center cell broadcast service channel description format code division multiple access call data record Contact Expression Language Conference of European Posts and Telegraphs Common Gateway Interface 219
EDI EDIFACT EDIINT E-OTD E-TDOA ETSI EU FCC FTP GGSN GIF GMLC GMSC GoS GPRS GPS GRIMM
10/19/05
1:26 PM
Page 220
Implementing Value-Added Telecom Services
Compact HTML Computer Interface to Message Distribution calling line identification Cable News Network coder decoder collaboration protocol agreement customer proprietary network information collaborative protocol profile Cambridge Positioning System Content Reference Forum CAMEL subscription information card verification value dynamic link library device management domain name system digital rights management digital subscriber line document type definition dual-tone multifrequency Digital Video Broadcasting Group time-division multiplex connection that supports 32 timedivision multiplexed channels of 64 Kbps (mostly used in Europe for connecting multiple phone lines to a central office) electronic document interchange Electronic Data Interchange for Administration, Commerce and Transport Electronic Data Interchange–Internet Integration Enhanced Observed Time Difference Enhanced Time Difference of Arrival European Telecommunications Standardization Institute European Union Federal Communications Commission (United States) File Transfer Protocol gateway GPRS support node Graphics Interchange Format Gateway Mobile Location Center Gateway MSC grade of service General Packet Radio System global positioning system Gateway Service Representative Internet Market Mobile Access Exchange
08_acronyms_4557.qxd
10/19/05
1:26 PM
Page 221
Acronyms
GSM H.263 H.264 H.323 HLR HTML HTTP ICANN ICMP IEEE IETF IGMP IMAP i-mode IMS IMSI IN INAP I/O IP IPDC IPDR IPv6 IRC ISDN ISMA ISO ISP ISUP IT ITU-T IVR IXC J2EE JAMES JPEG JSP LAN LATA LEC
221
Global System for Mobile telecommunications ITU-T video codec standard ITU-T video codec standard ITU-T standard for multimedia commonications over packet network home location register Hypertext Markup Language Hypertext Transfer Protocol Internet Corporation for Assigned Names and Numbers Internet Control Message Protocol Institute of Electrical and Electronics Engineers Internet Engineering Task Force Internet Group Management Protocol Internet Message Access Protocol information mode IP multimedia subsystem International Mobile Subscriber Identity intelligent networks Intelligent Networks Application Protocol input/output Internet Protocol IP datacast IP data record Internet Protocol version 6 Internet relay chat integrated services digital network Internet Streaming Media Alliance International Standards Organization Internet service provider ISDN user part information technology International Telecommunication Union– Telecommunications sector interactive voice response system interexchange carrier Java 2 Enterprise Edition Java Apache Mail Enterprise Server Joint Photographic Expert Group Java Server Page local area network local access and transport area local exchange carrier
08_acronyms_4557.qxd
222
LIF LMU MAP MAPI MGCP MIDI MIME MLP MLS MMS MMSC MOS MP3 MPEG MPLS MS MSC MS-ISDN MVNE MVNO NSS NTT OASIS ODRL OeB OMA OSA OSS OTA P2P PAP PDA PDF PDS PERL PHP PIN PIP
10/19/05
1:26 PM
Page 222
Implementing Value-Added Telecom Services
Location Interoperability Forum Location Measurement Unit Mobile Application Protocol messaging API Media Gateway Control Protocol—the acronym MEGACO has the same meaning Musical Instrument Digital Interface multipurpose Internet mail extensions Mobile Location Protocol Managed Location System (note that this is a product name, not a protocol or technology) multimedia messaging system multimedia messaging service center mean opinion score MPEG Audio Layer 3 Moving Pictures Expert Group multiprotocol label switching mobile stations mobile switching center mobile station ISDN number MVNO Enabling mobile virtual network operator network switching subsystem Nippon Telephone and Telegraph Organization for the Advancement of Structured Information Standards Open Digital Rights Language Open e-Book Forum (Consortium) Open Mobile Alliance open service access operations support system over the air person to person Push Access Protocol personal digital assistant Portable Document Format Portable Device Specification Practical Extraction and Report Language (Web programming language) hypertext preprocessor personal identification number partner interface processes
08_acronyms_4557.qxd
10/19/05
1:26 PM
Page 223
Acronyms
PKI POP PPP PSQM PSTN PTT PUC QoP QoS QTSS RARP RDF REL RLP RMI RNBD RNIF RNTD ROAP ROM RPC RSA RSS RTSP SAB SCE SCF SCP SCS SDF SDMI SDP SET SGSN SIM SIMPLE SIP SLC SLIA SLIR SMF
public key infrastructure Post Office Protocol Point-to-Point Protocol perceptual speech-quality measurement public switched telephony network post, telephone, and telegraph Public Utilities Commission (United States) quality of positioning quality of service QuickTime Streaming Server Reverse Address Resolution Protocol resource description framework Rights Expression Language Roaming Location Protocol remote method invocation RosettaNet business directory RosettaNet implementation framework RosettaNet technical directory Rights Object Acquisition Protocol read only memory remote procedure calls Rivest, Shamir, Adelman real simple syndication, or RDF site summary Real-Time Streaming Protocol service area broadcast service creation environment service control function (IN); service capability features (OSA-Parlay) service control point service capability servers service data function Secure Digital Music Initiative service data point SUPL enabled terminal serving GPRS support node subscriber identity module SIP for messaging and presence leveraging extensions Session Initiation Protocol SUPL location center standard location immediate answer standard location immediate request service management function
TA TCAP TCP TDMA TIA TINA TLD TLRR UBE UCC UCE UCP/EMI UDP UML UMM UMTS URL USF USSD UTC
10/19/05
1:26 PM
Page 224
Implementing Value-Added Telecom Services
Synchronized Multimedia Integration Language Serving Mobile Location Center Short Message Protocol short message (messaging) service short message service center SMS cell broadcast Simple Mail Transfer Protocol Simple Object Access Protocol SUPL positioning center Scalable Polyphony MIDI Structure Query Language special resource function signaling system number 7 service switching function secure socket layer service switching point secure user plane location stored-value account scalable vector graphics time-division multiplex connection that supports 24 channels of 64 Kbps (mostly used in America and Asia for connecting multiple phone lines to a central office) timing advance Transaction Capabilities Application Part Transport Control Protocol time division multiple access Telecommunications Industry Association Telecommunications Information Networking Architecture top-level domain Triggered Location Report Request unsolicited bulk e-mail Uniform Code Council unsolicited commercial e-mail Universal Computer Protocol/External Machine Interface User Datagram Protocol Unified Modeling Language UN/EDIFACT modeling methodology Universal Mobile Telecommunications System uniform resource locator Universal Service Fund (United States) unstructured supplementary services data universal time coordinated
08_acronyms_4557.qxd
10/19/05
1:26 PM
Page 225
Acronyms
U-TDOA UTF-8 VAS VASA VAT VLR VNO VNS VoIP W3C WAP WGS-84 WIN WLAN WMAN WML WSDL WSP WTLS WTO WTP WWW WYSIWYG XACML XHTML XML XMPP XrML
Uplink Time Difference of Arrival Unicode Transformation Format 8-bit value-added services Value Added Services Association value-added tax visited location register virtual network operator virtual network server voice over IP World Wide Web Consortium Wireless Application Protocol Worldwide Geodetic System 1984 wireless IN wireless local area network wireless metropolitan network Wireless Markup Language Web Services Description Language Wireless Session Protocol Wireless Transaction Layer Security World Trade Organization Wireless Transport Protocol World Wide Web what-you-see-is-what-you-get Extensible Access Control Markup Language Extensible HTML Extensible Markup Language Extensible Message and Presence Protocol Extensible Rights Markup Language
225
08_acronyms_4557.qxd
10/19/05
1:26 PM
Page 226
09_biblio_4557.qxd
10/19/05
1:30 PM
Page 227
Bibliography Castells, M., The End of the Millennium, The Information Age: Economy, Society and Culture, Vol. III., Cambridge, MA: Blackwell, 1997. Castells, M., The Power of Identity, The Information Age: Economy, Society and Culture, Vol. II., Cambridge, MA: Blackwell, 1997. Castells, M., The Rise of the Network Society, The Information Age: Economy, Society and Culture, Vol. I., Cambridge, MA: Blackwell, 1996. Christensen, G., P. Florack, and R. Duncan, Wireless Intelligent Networking, Norwood, MA: Artech House, 2000. Heine, G., GSM Networks: Protocols, Terminology, and Implementation, Norwood, MA: Artech House, 1999. Jain, R., F. Anjum, and J. L. Bakker, Programming Converged Networks, New York: Wiley, 2003. Kaaranen, H., et al., UMTS Networks, Architecture, Mobility and Services, New York: Wiley, 2001. Laudon, K. C., and C. Guercio Traver, E-Commerce: Business, Technology, Society, Reading, MA: Addison-Wesley, 2003. Mueller, S., APIs and Protocols for Convergent Network Services, New York: McGraw-Hill, 2002. Trosby, F., “SMS: The Strange Duckling of GSM,” Telektronikk Magazine, Telenor Nordic Mobile, March 2004, pp. 187–194. Walke, B., P. Seidenberg, and M. P. Althoff, UMTS: The Fundamentals, New York: Wiley, 2003. Weintraub, A., Content Management Providers: Timetable Towards DRM, Report M-13-7071, Gartner Group, Stamford, CT, July 2001.
227
09_biblio_4557.qxd
10/19/05
1:30 PM
Page 228
10_ata_4557.qxd
10/19/05
1:32 PM
Page 229
About the Author Johan Zuidweg manages research projects at Telefónica I+D and teaches computer science and telecommunications courses at the Universitat Pompeu Fabra in Barcelona, Spain. He has worked for almost 20 years in telecommunications research, development, and standardization, and has experienced the industry from all perspectives: the operator (KPN, the Netherlands, 1987–1994, and Telefónica, Spain, 2005–present), the manufacturer (Alcatel, France and Belgium, 1994–1999), and the IT systems integrator (Tecsidel, Spain, 2000–2004). Dr. Zuidweg is a technical expert in the area of 2G and 3G mobile networks and applications, and value-added service architectures such as IN, CAMEL, and OSA-Parlay. He is a member of the IEEE Computer and Communications Societies and the author of the book Next Generation Intelligent Networks (Artech House, 2002). Dr. Zuidweg holds an M.S. and a Ph.D. in computer science from Leiden University, Leiden, the Netherlands. The Web site for this book, http://www.implementingVAS.com, provides more information on the author and allows you to contact him for comments or questions. You can also send an e-mail directly to [email protected].
Customized applications for mobile enhanced logic (CAMEL), 13, 39–41, 45, 212–213 Cycos AG, 75 Cygnet Internet Services, 61 Darwin streaming server, 106 Data communications, 5 Data Protection Act (United Kingdom), 150 Deck of cards, 91 Device management (DM), 101 Diallers, 86–89 Dial Up Networking Manager (DUN Manager), 89 Digimarc, 119 Digital Equipment Corporation, 3 Digitalization of communications, 3–5 Digital rights management (DRM), 114–116 standards, 116–118 technology, 114 Digital subscriber line (DSL), 6 Dimensioning, 18–19 Directive on Privacy and Electronic Communications (EU), 151 Direct PopUp Advertiser, 73 Discount rate, 157 DoCoMo, 96–98 Document-type definitions (DTDs), 131 Domain name, 84 Domain name system (DNS), 51 Dorna Sports S.L., 109 Dot-com crisis, 10–11 DQDB, 5 DRM-enabled content business, 118–119 Drummond Group Inc. (DGI), 171 Dual-tone multifrequency (DTMF) tones, 88 Dynamic link library (DLL), 56 Earthcomber, 144 EasyShopMaker, 162 eBay, 10, 178 ebXML, 171–174 E-gold, 181 Electronic commerce, 15–16, 153–189 business-to-business transactions, 166–176 business-to-consumer transactions, 155–166 e-commerce models, 154 person-to-person transactions, 176–188
11_idx_4557.qxd
10/19/05
1:36 PM
Page 233
Index Electronic Data Interchange for Administration, Commerce and Transport (EDIFACT), 170–171 Electronic Data Interchange-Internet Integration (EDIINT), 170–171 Electronic document interchange (EDI), 167–170 Electronic mail (e-mail), 13, 49 e-mail notification services, 55–56 e-mail viruses and spam, 56–58 mailbox provisioning, 50–52 newsletters and e-mail publicity, 52–55 E-mail notification services, 55–56 Enhanced Messaging Gateway, 78 Enhanced Observed Time Difference (E-OTD), 124–125 Enron, 11 EntryPoint, 100 Erlang, Agner Krarup, 18 Erlang (unit of traffic flow), 18 Ethernet, 5 European Telecommunications Standardization Institute (ETS), 6 European Union (EU), and telecommunications, 9 EveryAuction, 179 Extensible HTML (xHTML), 91 Extensible Markup Language (XML), 71, 200–201 Extensible Message and Presence Protocol (XMPP), 71 Extensible Rights Markup Language (XrML), 115 FastPay, 181 FDDI, 5 Federal Communications Commission (FCC), 17 File Transport Protocol (FTP), 69 Firstgate AG, 85 Forrester, 14 Forward lock, 114 Fraud, preventing, 165–166 GALILEO, 127 Gaming, 15, 145–147 Gartner Group, 11 Gateway GPRS support node (GGSN), 110 Gateway Mobile Location Center (GMLC), 129
233
Gateway MSC (GMSC), 130 Gateway Service Representative Internet Market Mobile Access Exchange (GRIMM), 97 General Packet Radio System (GPRS), 67, 210–211 Geocaching, 145 GEOPRIV, 151 Gimkana location-based game, 147–150 Gizmondo, 146 Global Exchange Services (GXS), 176 Globallocate, 129 Global positioning system (GPS), 15, 126–127 Global System for Mobile telecommunications (GSM), 6, 210 Goldenbytes, 65 GoLive, 92 Google, 10, 50 GPA Technology, 61 Grade of service (GoS), 18 GSM/time division multiple access (TDMA) networks, 125 Guardian Angel application, 144 Gunslinger, 147 Hewlett-Packard, 3, 111 Highdeal, 111 Home location register (HLR), 40 Home Subscriber System (HSS), 138 Horde Internet Messaging Program, 52 Hypertext browser, 5 Hypertext Markup Language (HTML), 51 Hypertext Preprocessor (PHP), 51 Hypertext Transfer Protocol (HTTP), 51 IBM, 3 ICQ, 70 i-mode, 96–98, 103 IN Application Protocol (INAP), 31 Inetis, 92 InfoGate, 100 Information mode (i-mode), 96–98 Information technology (IT), 3 Instant messaging, 69–73 for business-to-consumer communications, 72–73 SIMPLE, 71–72 standards, 70–71 XMPP, 71
11_idx_4557.qxd
10/19/05
234
1:36 PM
Page 234
Implementing Value-Added Telecom Services
Institute of Electrical and Electronics Engineers (IEEE), 104 Intelligent networks (IN) concept, 5, 205–206 Interactive voice response (IVR) system, 25 Interexchange carriers, (IXC), 8 Interface Definition Language (IDL), 139 Internationale Mobile Subscriber Identity (IMSI), 132 International Telecommunication Union–Telecommunications (ITU-T), 28 Internet, 5–6, 10, 13, 191–200 person-to-person payments on, 179–181 Internet Control Message Protocol (ICMP), 192 Internet dumping, 86 Internet Engineering Task Force (IETF), 70 Internet Financial Network Inc., 100 Internet Group Management Protocol (IGMP), 104 Internet Message Access Protocol (IMAP), 52 Internet protocol (IP), 5, 6, 191–193 Internet relay chat (IRC), 70 Inxmail Professional, 55 IP datacast (IPDC), 105 IP data records (IPDRs), 110 IS-95, 6 Item-based charging, 85
Local exchange carrier (LEC), 8 Location architecture and interfaces, 129–141 combining MLP and SUPL, 136–137 Mobile Location Protocol (MLP), 130–133 OSA-Parlay, 139–141 Roaming Location Protocol (RLP), 137–139 secure user plane location (SUPL), 134–136 Location-based services, 14–15, 121–152 adding location value, 141–150 applications and content, 143–144 gaming, 145–147 Gimkana game, 147–150 location architecture and interfaces, 129–141 location techniques, 122–129 regulatory issues, 150–151 Location Measurement Unit (LMU), 130 Location techniques, 122–129 assisted GPS, 127–129 cell ID-based location, 123–124 Enhanced Observable Time Difference, 124–125 global positioning system, 126–127 Uplink Time Difference of Arrival, 126 Log file, 163–164 Logica, 61
Jabber, 71 Java Apache Mail Enterprise (JAMES), 56 JavaMail API, 56 Java Server Page (JSP), 54
Kabira Technologies, 78 Kagi, 58 Kannel, 92 Kapow!, 61 Killer applications, 23 KPN, 96 KVT Software, 56 Legal aspects, 17–18 Lernout & Hauspie, 11 Liberalization of telecommunications markets, 7–9 Europe and the rest of the world, 9 The United Kingdom, 9 The United States, 8 Local access and transport areas (LATAs), 8
11_idx_4557.qxd
10/19/05
1:36 PM
Page 235
Index instant messaging, 69–73 multimedia messaging services, 66–69 short message service (SMS), 59–66 unified messaging, 73–78 Microsoft Windows Media, 106 MicroTelco Regional Server, 29 Mobey Forum, 184 Mobile Application Protocol (MAP), 40 Mobile Electronic Transaction (MeT), 184 MobileLocate, 124 Mobile Location Protocol (MLP), 130–133 combined with SUPL, 136–137 Mobile networks, 6–7, 209–213 and commerce, 153 Mobile payment, 181–185 Mobile Payment Forum, 184 Mobile phones, 121 Mobile station integrated services digital network (MS-ISDN), 92 Mobile switching center (MSC), 39 Mobile virtual network operators (MVNOs), 12–13, 41–44 Mobipay, 185 Mogi, 146, 147 MoneyBookers, 181 Monthly charge, 156 Monthly minimum, 156 MotoGP.com, 109 Moving Pictures Expert Group Audio Layer3 (MP3) player, 7 Mozart, 69 MP3Guard, 119 MRS system, 75 Msitebuilder, 92 MSN Games, 73 MSN Messenger, 70, 72–73 M2U, 69 Multicast, 104 Multimedia messaging service, 66–69 MMS interfaces, 68 MMS standard, 67–68 Multimedia messaging systems (MMS), 14 Multiprotocol label switching (MPLS), 192 Multipurpose Internet mail extensions (MIME), 13, 78 MVNO Enabling (MVNE), 44 Neomail, 52 NetCom, 96 Netiquette (net etiquette), 56
235
Netscape Messenger, 70 Newsletters, e-mail, 52–55 Next Generation Intelligent Networks (Zuidweg), 19 Nippon Telephone and Telegraph (NTT) DoCoMo, 96–98 Nochex, 158 Nontechnical factors of telecommunications, 16–19 business plan, 16–17 dimensioning, 18–19 regulation and legal aspects, 17–18 NotificationMail, 56 NowSMS, 61, 68, 103 Now Wireless Limited, 61, 68 Oberthur Card Systems, 144 Office EDITION, 76 Oksigen Teknoloji, 78 Online auctions, 176–179 Online store, 160–162 direct payment links, 160 dynamic storefront systems, 161 virtual shopping cart, 161 Open digital rights language (ODRL), 115 Open eBook (OeB) Consortium, 116 Open Mobile Alliance (OMA), 185 Open Service Access (OSA)-Parlay standard, 5 Operations support system (OSS), 42 Optimal Telecom, 33 OSA-Parlay, 9, 13, 20, 206–209 charging interface, 185–188 generic messaging interface, 76–78 and location requests, 139–141 mediation interface, 111–113 prepaid mobile with, 44–48 prepaid telephony with, 33–38 OSA standard, 9 OsCommerce, 162 Over the air (OTA) configuration, 101 Packet Video, 108 Pages (CBS message), 65 Parlay Group, 5, 9 Partner interface processes (PIP), 175 Payment service provider, 155 PayPal, 10, 181 Personal computer (PC), 3 Personal digital assistant (PDA), 90 Personal identification number (PIN), 87
11_idx_4557.qxd
236
10/19/05
1:36 PM
Page 236
Implementing Value-Added Telecom Services
Person-to-person (P2P) transactions, 155, 176–188 mobile payment, 181–185 online auctions, 176–179 OSA-Parlay charging interface, 185–188 payment on Internet, 179–181 Phonotics, 56 Piracy, 113–114 PointCast, 100 Point of presence, 25–27 Point-to-Point Protocol, 86 Portable Document Format (PDF), 52 Post Office Protocol (POP), 51 Post, telephone, and telegraph (PTT) companies, 1 PPPay Ltd., 181 Practical Extraction and Report Language (PERL), 179 Premium rate SMS, 62–63 Prepaid fixed telephony, 24–38 basic point of presence, 25–27 with intelligent networks, 29–33 with OSA-Parlay, 33–38 voice over IP technology, 27–29 Prepaid mobile communications, 38–48 with CAMEL, 39–41 mobile virtual network operators, 41–44 with OSA-Parlay, 44–48 Prepaid services, 12–13, 23–48 prepaid fixed telephony, 24–38 prepaid mobile communications, 38–48 Progressive download, 107–109 Publicity, e-mail, 52–55 Public key infrastructure (PKI), 201–202 Public switched telephony network (PSTN), 27, 28 Public Utilities Commission (PUC), 17 Pull and push content, 82 Push access protocol (PAP), 101 Push content, 98–103 WAP push, 100–103 Web push, 99–100 Push over the air protocol, 101 Push proxy, 101 Quality of positioning (QoP), 132 Quality of service (QoS), 29 Quicknet Technologies Inc. (QTI), 29 QuickTime Streaming Server (QTSS), 106
RAC, 65 Radio Resource Control (RRC), 135 Radio Resource Location Services Protocol (RRLP), 135 Read only memory (ROM), 3 Real Networks, 106 Real-time streaming protocol (RTSP), 104 Redknee, 78 Re5ult, 63 82ask service, 63 Regulation, 17–18 Relay server (MMS), 68 Rights expression language (REL), 114 Risk Center, 85–86 Roaming Location Protocol (RLP), 136, 137–139 RosettaNet, 174–176 business dictionary (RNBD), 175 implementation framework (RNIF), 175 technical dictionary (RNTD), 175 RSS, 100 Screen Digest, 14 Search engine, 5 Second generation cellular mobile network (2G), 41 Secure socket layer (SSL), 161–162, 202–204 Secure user plane location (SUPL), 134–136 combined with MLP, 136–137 SendMail, 52 Server side processing, 195–197 Server side scripting, 164 Service area broadcast (SAB), 65 Service control function (SCF), 30 Service control points (SCPs), 5 Service data function (SDF), 30 Service switching function (SSF), 30 Serving GPRS Support Node (SGSN), 130 Serving Mobile Location Center (SMLC), 129 Session Initiation Protocol (SIP), 71 for instant messaging and presence leveraging extensions (SIMPLE), 71–72 Sharpreader, 100 ShopFactory, 162 Shortcodes, 62 Short Message Protocol (SMPP), 61 Short message service (SMS), 59–66 alerting services, 64–65
11_idx_4557.qxd
10/19/05
1:36 PM
Page 237
Index cell broadcast service (CBS), 65–66 premium rate SMS, 62–63 sending and receiving, 59–61 Short messaging service (SMS), 13–14, 182 Siemens INXpress Prepaid, 33 Signaling, 205 Signaling system number 7 (SS7), 4–5 Simpay, 185 Simple Mail Transfer Protocol (SMTP), 49–50 Simple Object Access Protocol (SOAP), 69, 197 Singtel, 147 Site visits, analyzing, 162–165 Skype, 6 SMS cell broadcast (SMS-CB), 65 SMS Forum, 61 SMS2Email, 103 Soft handovers, 124 Spam, 53, 57–58 Standard location immediate answer (SLIA), 137 Standard location immediate request (SLIR), 131, 136 Stored-value account (SVA), 184 Streaming content, 103–113 charging for, 108–109 media coding and decoding, 105 mediation, 109–111 OSA-Parlay mediation interface, 111–113 streaming for mobile devices, 106–107 streaming over IP, 104–105 streaming servers, 106 Subscriber identity module (SIM), 7 SIM card, 39, 42 Subscription-based charging, 85 SUPL enabled terminal (SET), 134 SUPL location center (SLC), 134 SUPL positioning center (SPC), 134 Swiftpass, 185 Switched telephony, 3–4, 6 Syntaxis iHub SMS and USSD gateway, 78 T&F Informa, 12, 14 Telcopay, 96 Telecommunications, 1–19 advances in computing technology, 3–7 liberalization of markets, 7–9 nontechnical factors, 16–19
237
opportunities for third parties, 12–16 rebirth of industry, 9–12 Telecommunications Industry Association (TIA), 11 Telephone, 1 Telephony, 1, 204 TeliaSonera, 96, 108 Teligent Prepaid, 33 Terrestrial digital television (DVB-T), 105 Texas Instruments, 3 Third generation cellular mobile network (3G), 41 Third Generation Partnership Project (3GPP), 5 Timing advance (TA), 124 T-Mobile, 96 Token bus, 5 Token ring, 5 Transaction fee, 157 Transatel, 44 Transcoders, 67 Transport Control Protocol over IP (TCP/IP), 50–51 Trident Telecom, 41 TruePosition, 126 Txtorder, 185 Umbrella cell, 123 UN/EDIFACT modeling methodology (UMM), 173 Unicast, 104 Unified messaging, 73–78 OSA-Parlay generic messaging interface, 76–78 setting up a service, 74–76 Unified Modeling Language (UML), 173 Uniform resource locator (URL), 62 United Kingdom, and telecommunications, 9 Office of Telecommunications, 9 United States, and telecommunications, 8 Universal Computer Protocol/External Machine Interface (UCP/EMI), 61 Universal Description, Discovery and Integration (UDDI), 171, 198 Universal Mobile Telecommunications System (UMTS), 129, 212 Universal Service Fund (USF), 17 Universal time coordinated (UTC), 132 Unsolicited bulk e-mail (UBE), 57 Unsolicited commercial e-mail (UCE), 57
11_idx_4557.qxd
238
10/19/05
1:36 PM
Page 238
Implementing Value-Added Telecom Services
Unstructured supplementary services data (USSD), 46, 182 Uplink Time Difference of Arrival (U-TDOA), 126 URL query strings, 164 User agent (MMS), 68 User Datagram Protocol (UDP), 192 Userland, 100 UUencoded (text-coded binary), 78 Value-added services (VAS), 5 Virgin Mobile, 43 Virtual network operatiors (VNOs), 9 Viruses, e-mail, 58 Visiongain, 11 Visited location register (VLR), 40 Vocatec, 6 Voice over IP (VoIP), 6, 27–29, 199 Walled-garden setting, 110 WAP Markup Language (WML), 182 WAP push, 100–103 WAP tunnel, 92 Watermarking, 114 Webmail, 50–52 Web push, 99–100 Web services, 197–198 Web Services Description Language (WSDL), 198 What-you-see-is-what-you-get (WYSIWYG), 92 WIFI, 104 Windows Messenger, 73 WinSMS, 61 Wireless Application Protocol (WAP), 90–96
billing WAP content through operator, 93–94 charging for WAP content, 92–93 gateways, 90–92 third-party WAP billing, 95–96 Wireless Data Protocol (WDP), 91 Wireless local area networks (WLANs), 11, 121 Wireless Markup Language (WML), 90 Wireless metropolitan area networks (WMANs), 121 Wireless Session Protocol (WSP), 92–93 Wireless transaction layer security (WTLS), 93 Wireless Transport Protocol (WTP), 92 Worldcom, 11 World Trade Organization (WTO), and telecommunications, 9 Worldwide Geodetic System 1984 (WGS84), 132, 140 World Wide Web (WWW), 5, 83–89, 193 and commerce, 153 dialers, 86–89 item- or subscription-based charging, 85 setting up Web site, 84–85 World Wide Web Consortium (W3C), 99 X.25, 5 XCAuction, 179 Yahoo Messenger, 70 Yankee Group, 13 Yellow Dragon Software Corporation, 174 Zapper Software, 119 ZenCart, 162
MANAGING PUBLIC SERVICES – IMPLEMENTING CHANGES
The work of a manager in a service organization is not the same as the...
MANAGING PUBLIC SERVICES – IMPLEMENTING CHANGES
The work of a manager in a service organization is not the same as the...
D O C U M E N T E D
B R I E F I N G
R Implementing PerformanceBased Services Acquisition (PBSA) Perspectives from an A...
An extensive study of the product application and services conducted by subject matter experts assessing the market will help product owners to make a wise decision.
The Great Telecom Meltdown
For a listing of recent titles in the Artech House Telecommunications Library, turn to the...
Transforming Mental Health Services: Implementing the Federal Agenda for Change
This page intentionally left blank
...
The Great Telecom Meltdown
For a listing of recent titles in the Artech House Telecommunications Library, turn to the...
. 2. When the receiver opens the mail, the mail client automatically interprets the HTML contents.1 This will result in a HTTP GET request to be sent for the dummy graphics file. The file contains only 1 pixel and is not visible to the receiver. 3. The HTTP server logs this HTTP GET event in the log file. The logfile entry includes the exact time of the request, but also the requesting machine’s identity and often additional information, such as operating system and browser. 4. The sender consults the information in the log file to find out when the mail was read, and from where. In many cases, the machine’s domain or IP address can pinpoint the geographical region or even the organization from where the request was made. Note that this technique will allow e-mails to be tracked even as they are forwarded, because steps 2 and 3 repeat every time another client opens and reads the mail. This can provide extremely interesting information about how a piece of mail propagates through the Internet. If instead of a direct reference to a 1-pixel graphics file, one uses PHP, CGI, Java Server Page (JSP), or ASP, it is even possible to send more information to the HTTP server, such as identification of the e-mail and its original destination. It is also possible to send a cookie with the 1-pixel graphics file, which allows for correlation with later clicks to the server. The addition of the invisible link to the 1-pixel graphics file is usually done automatically, either in the sending e-mail application, or by routing the email through a provider of tracking services, which will add this information to the mail. Note that the receiver of the e-mail may not be aware that the mail is being tracked. This raises certain privacy concerns, although in practice it is difficult to legally prevent this. From Figure 3.2, it is clear that it is relatively easy to protect oneself from e-mail tracking by switching off automatic HTML interpretation, or by disabling images in HTML.
