Broadband Internet Deployment in Japan

BROADBAND INTERNET DEPLOYMENT IN JAPAN Advanced Information Technology Series Editor Takashi Chikayama Volume 4 Pre...

Author: H. Esaki | H. Esaki | J. Mural | H. Sunahara

69 downloads 2256 Views 6MB Size Report

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

DOWNLOAD PDF

BROADBAND INTERNET DEPLOYMENT IN JAPAN

Advanced Information Technology Series Editor

Takashi Chikayama

Volume 4 Previously published in this series: Vol. 3. Vol. 2. Vol. 1.

S. Nakagawa, M. Okada and T. Kawahara (Eds.), Spoken Language Systems K. Okada, T. Hoshi and T. Inoue (Eds.), Communication and Collaboration Support Systems T. Saito and H. Esaki (Eds.), Gigabit Network

ISSN 1348-513X

Broadband Internet Deployment in Japan

Edited by

Hiroshi Esaki The University of Tokyo, Japan

Hideki Sunahara Nara Institute of Science and Technology, Japan

and

Jun Murai Keio University, Japan

Tokyo • Amsterdam • Berlin • Oxford • Washington, DC

Broadband Internet Deployment in Japan © 2008 Information Processing Society of Japan All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, without prior written permission from the publisher. ISBN 978-4-274-90640-4 (Ohmsha) ISBN 978-1-58603-862-5 (IOS Press) Library of Congress Control Number: 2008928589 Publisher Ohmsha, Ltd. 3-1 Kanda Nishiki-cho Chiyoda-ku, Tokyo 101-8460 Japan Distributor UK and Ireland Gazelle Books Services Ltd. White Cross Mills Hightown Lancaster LA1 4XS United Kingdom fax: +44 1524 63232 e-mail: [email protected] Japan Ohmsha, Ltd. 3-1 Kanda Nishiki-cho Chiyoda-ku, Tokyo 101-8460 Japan fax: +81 3 3293 6224 e-mail: [email protected] url: http://www.ohmsha.co.jp/index_e.htm

USA and Canada IOS Press, Inc. 4502 Rachael Manor Drive Fairfax, VA 22032 USA fax: +1 703 323 3668 e-mail: [email protected]

Far East jointly by Ohmsha, Ltd. and IOS Press

Netherlands and the rest of the World IOS Press Nieuwe Hemweg 6B 1013 BG Amsterdam The Netherlands fax: +31 20 687 0019 e-mail: [email protected] url: http://www.iospress.nl LEGAL NOTICE The publisher is not responsible for the use which might be made of the following information. PRINTED IN THE NETHERLANDS

Broadband Internet Deployment in Japan H. Esaki, H. Sunahara and J. Murai (Eds.) Ohmsha/IOS Press, 2008 © 2008 Information Processing Society of Japan. All rights reserved.

v

Series Editor’s Foreword The Information Processing Society of Japan (IPSJ) is the top academic institution in the field of information technology in Japan. It has about twenty five thousand members and promotes a variety of research and development activities covering all aspects of and closely related to information technology. One of its major activities is the dissemination of results from the cutting edge research conducted by its members to other members and also to society in general. Publications by IPSJ for this purpose include the IPSJ magazine, but the articles appearing in it are all in Japanese and might thus not be convenient for international readers. Some papers appearing in the IPSJ journals and transactions are written in English, but most are in Japanese, and are usually written on a specific topic for experts in a specific area. They are therefore often not suited to understanding the general research trends of an area. IPSJ has therefore decided to publish a book series in English, entitled “Advanced Information Processing Technology” to facilitate access to Japanese information in the field for international readers. Publication started in 1998, and the first three titles of the series were published by Gordon and Breach, Scientific Publishers Inc. In 2002, three more titles were published by Taylor & Francis. In 2003 a new series, with the title of “Advanced Information Technology”, was started. This series is published by Ohmsha and IOS Press. The series consists of independent books, each including top quality papers in a selected area of information technology, mainly from Japanese sources. The book titles are selected by the International Publication Committee of IPSJ. Each volume contains papers reporting original work and/or those updated from papers which have appeared in IPSJ journals and transactions or internationally qualified academic meetings. Survey papers to promote understanding of the state of the art in the area of technology are also included. As the chair of the International Publication Committee of IPSJ, I sincerely hope that the books in this series will contribute to a better understanding between Japanese and non-Japanese specialists and help them as they strive to improve the welfare of mankind. Takashi Chikayama Series Editor Chair International Publication Committee Information Processing Society of Japan

This page intentionally left blank

vii

Preface It could be said that the history of the internet in Japan started with JUNET (the Japan University NETwork). The operation of JUNET began in October 1984, connecting Keio University, Tokyo Institute of Technology and The University of Tokyo, and was concluded in October 1991, when it transferred to fully professional IP networks. When JUNET was concluded, the IP address and domain name management task were transferred to JNIC (now JPNIC). When JUNET started, we had collaborated closely with pioneers in the United States, namely the R&D of the BSD UNIX system, who designed the DNS system or global IP address and domain name management. In 1992, we tried to enter into professional and commercial internet operation. Globally, the year of 1992 is widely known as the year when the IETF community had to reform the IAB, due to the wrong governance of IPv6 (known as IP next generation at that time) standardization activity. But in Japan, 1992 is remembered as the year when the first commercial ISP (Internet Service Provider), IIJ (Internet Initiative Japan, www.iij.ad.jp), was established. Great efforts were necessary to obtain operational permission from the Japanese government in order to achieve this. In 1994, the WIDE project established the R&D consortium known as NSPIXP, to establish the platform and technology to exchange IP traffic among various IP networks efficiently and economically. 1992 is also known as the year when the volume of data traffic reached the same volume of voice traffic as that generated by the PSTN service, i.e., digital data communication had reached the position of a major player within the telecommunications system. In 1996, the NTT, the national flag telephone operator in Japan, launched their internet service, called OCN (Open Computer Network). At the time, corporate networks used very expensive leased digital lines, and most domestic customers were using a dial-up connection via the analogue PSTN service. Gradually, the ISDN service, INS64 for NTT, gained a market share of internet access technology. It was widely recognized that it was very costly to connect to and use the internet in Japan, due to the expensive PSTN and ISDN tariff. Actually, at the WIDE project’s 10th anniversary symposium a panel session was held, discussing why the Japanese internet was very expensive and why Japan was in fact an under developed country as regards internet infrastructure. Though NTT’s PSTN service and ISDN service were expensive, NTT aggressively promoted the deployment of FTTH (Fiber To The Home) environment. The progress achieved by NTT later resulted in the fast development and deployment of a broadband internet environment in Japan. Before implementing a FTTH solution for the domestic customer, we first had to replace the PSTN and ISDN access with ADSL access. ADSL technology has been in commercial operation since 1999, following technical evaluation and establishment at various events and organizations, such as Networld+Interop Tokyo. Voice over IP (VoIP) technology has been gradually introduced into the structure of the data transmission system. Full deployment of the ADSL system and service was triggered by the following two important actions.

viii

Firstly the government, under the Mori-cabinet, launched the e-Japan initiative. Prime Minister Yoshiro Mori announced the e-Japan initiative during his first keynote address at the opening of a Diet session, and in response to this address, the IT strategic headquarters was established in 2001. The second trigger was the start of Yahoo BB!’s nationwide ADSL service. Yahoo BB! fully exploited the opportunity to use the drycupper to build up their ADSL service. With these triggers, Japan has progressed towards becoming a cost effective broadband internet country. Indeed, in 2006 it was said of Japan that it is one of the most cost effective broadband countries and has one of the cheapest bit costs in the world. Japan is also well-known as a country with one of the largest penetration ratios for intelligent cellular phone systems. NTT DoCoMo has become very famous due to their amazing success in the cellular phone business, especially for the success of their “imode” service. This is one of the first data communication services on a cellular phone system. It was reported that in 2007, the total volume of data traffic in the cellular phone system in Japan became larger than that of voice traffic. Now, towards the year 2011, the telecommunications infrastructure is going to converge with broadcasting infrastructure. 2011 is being hailed as the first year of a fully digital age. The RF transmission of analogue TV programmes will be terminated in 2011, to migrate to a fully digitized broadcasting service. The legacy telephone service will migrate to the VoIP service. This is seen as the first milestone of the NGN (Next Generation Network). Also, surprisingly, the IPv4 address pool may run out for new address allocations around 2011. Japanese society has criticized peer-to-peer file sharing systems, such as Winny, due to a series of information leakage incidents. However, researchers have recognized that the development and deployment of peer-to-peer technology is a kind of logical consequence of the wide deployment of a broadband internet environment. Towards 2011, we may have to face the following technical challenges: 1. 2. 3. 4. 5. 6. 7.

Development and deployment of end-to-end architecture on the existing complex IPv4 based internet. Development of a Japanese infrastructure which is globally competitive and globally interoperable. Developing new applications and new business models in the ubiquitous networking environment. Development of an internet system as a social infrastructure. Integration with real-space (i.e. the integration of physical space and cyber space). NGN (Next Generation Network) and FMC (Fixed Mobile Convergence). Development and deployment of the unwired internet environment.

In order to progress the actions listed above, we must establish strong collaboration between industry and academia. As we can see, Japan has had a series of unique projects, e.g., NSPIXP, that differ from other countries. Since Japan is now a country at the leading edge of broadband and a ubiquitous networking environment, we have to demonstrate the success of internet deployment, as a showcase for future internet tech-

ix

nologies. We must be a pioneer for the rest of world. We believe that it is our responsibility and our contribution to global technological development.


xi

Authors’ List Editors; Dr. Hiroshi Esaki, The University of Tokyo Dr. Hideki Sunahara, Nara Institute of Science and Technology Dr. Jun Murai, Keio University Chapter 1 Editor/Author; Dr. Hideki Sunahara, Nara Institute of Science and Technology Dr. Hiroshi Esaki, The University of Tokyo Chapter 2 Editors; Dr. Kazuo Imai, DoCoMo Communications Laboratories USA, Inc. Dr. Masami Yabusaki, NTT DoCoMo Inc. Authors; Dr. Kazuo Imai, DoCoMo Communications Labs USA, Inc. ... 2.1 Mr. Chris Sachno, RIM Japan, Inc. … 2.2 Mr. Daizo Ikeda, NTT DoCoMo, Inc. … 2.3 Mr. Tomoki Shibahara, NTT DoCoMo, Inc. … 2.5 Mr. Kenya Kusunose, NTT DoCoMo, Inc. … 2.5 Dr. Masami Yabusaki, NTT DoCoMo, Inc. … 2.6 Dr. Masayoshi Ohashi, KDDI R&D Laboratories Inc. … 2.2, 2.4 Mr. Masashi Kawamura, KDDI Corporation … 2.4 Mr. Masaru Umekawa, KDDI Corporation … 2.4 Mr. Masaaki Koga, KDDI Corporation … 2.5 Chapter 3 Editor; Mr. Tomohiro Fujisaki, NTT Information Sharing Platform Laboratories Authors; Mr. Hiroyuki Ashida, its communications Inc. ... 3.1 Mr. Takashi Tanaka, NTT Access Network Service Systems Laboratories ... 3.2 Mr. Koji Yamaguchi, NTT Access Network Service Systems Laboratories ... 3.2 Mr. Akihiro Otaka, NTT Access Network Service Systems Laboratories ... 3.3 Chapter 4 Editor; Dr. Hiroshi Esaki, The University of Tokyo Authors; Mr. Shuji Nakamura, Mitsubishi Research Institute Dr. Osamu Nakamura, Keio University Dr. Akira Kato, The University of Tokyo

... 4.1 ... 4.2 ... 4.2

xii

Mr. Katsuyuki Hasebe, NTT Communications Dr. Naoto Morishima, Nara Institute of Science and Technology Dr. Yuji Sekiya, The University of Tokyo Dr. Noriyuki Shigechika, Keio University Mr. Satoru Matsushima, Soft Bank Telecom Mr. Hideo Ishii, Asia Netcom Dr. Ken-ichi Nagami, Intec Netcore Chapter 5 Editor; Dr. Hiroshi Esaki, The University of Tokyo Authors; Dr. Hiroshi Esaki, The University of Tokyo Mr. Masato Yamanishi, SOFTBANK BB Corp. Mr. Kuniharu Murakami, TV Bank Corp. Mr. Mitsuru Aoki, TV Bank Corp. Mr. Masato Yamanishi, SOFTBANK BB Corp. Mr. Kuniharu Murakami, TV Bank Corp. Mr. Mitsuru Aoki, TV Bank Corp. Mr. Takashi Uematsu, NTT West Chapter 6 Editor; Dr. Kensuke Fukuda, National Institute of Informatics Authors; Dr. Kensuke Fukuda, National Institute of Informatics Dr. Kenjiro Cho, Internet Initiative Japan Inc. Dr. Hiroshi Esaki, The University of Tokyo

... 4.2 ... 4.2 ... 4.2 ... 4.2 ... 4.3 ... 4.3 ... 4.3

... 5.1, 5.3, 5.4 ... 5.2 ... 5.2 ... 5.2 ... 5.3 ... 5.3 ... 5.3 ... 5.4

xiii

Contents Series Editor’s Foreword Preface Authors’ List

v vii xi

Chapter 1 Brief History of Internet Deployment in Japan

1 1 1 2 2 4 6 6 8 8 10 10 11 11 13 15

1.1. JUNET 1.1.1. Overview of JUNET 1.1.2. Routing by Domain Name 1.1.3. Introduction of Japanese Characters into the Internet System 1.2. Introduction of IP Connection in Japan 1.3. IP version 6 1.3.1. Initialization of IPv6 Activity at IETF 1.3.2. R&D and Deployment Activity in Japan 1.3.2.1. IPv6 Protocol Stack Development Activity 1.3.2.2. IPv6 Conformance and Interoperability Testing Platform 1.3.2.3. IPv6 Testbed Operation 1.3.2.4. IPv6 Promotion Council 1.3.2.5. IPv6 Commercial Operation 1.4. Commercial IP Networks References

Chapter 2 Mobile Internet Deployment in Japan 2.1. Overview of Mobile Internet in Japan 2.1.1. Introduction 2.1.2. Mobile Internet: A Definition and Its Basic Structure 2.1.2.1. Mobile Internet in Japan 2.1.2.2. Mobile Internet Structure and Network Architecture 2.1.3. Access and Network Infrastructure Evolution of the Mobile Internet 2.1.3.1. Public Mobile Communications Systems in Japan 2.1.3.2. New Broadband Wireless Access Systems for the Mobile Internet 2.1.3.3. Core Network Evolution 2.1.4. Protocols in Mobile Internet 2.2. Services for the Mobile Internet in Japan 2.2.1. i-mode Services 2.2.1.1. i-mode History 2.2.1.2. i-mode Services 2.2.2. EZweb Services 2.2.2.1. Overview of EZweb 2.2.2.2. Key EZWeb Services 2.2.3. Public Mobile Internet Services 2.2.3.1. FeliCa Services 2.2.3.2. QR Code Services

17 17 17 18 18 19 21 21 22 23 23 24 24 24 25 30 30 31 34 34 35

xiv

2.2.3.3. Disaster Message Board Service 2.2.4. Introducing Java Platform 2.3. 2nd Generation Cellular Networks (PDC-P) 2.3.1. Technologies for PDC-P 2.3.1.1. Target of PDC-P 2.3.1.2. Key Technologies 2.3.1.3. Network Configuration 2.3.2 i-mode Enabled System (PDC-P Application) 2.3.2.1. Target of i-mode 2.3.2.2. Key Technologies 2.3.2.3. Network Configuration 2.4. 3rd Generation Cellular Networks 2.4.1. W-CDMA/HSDPA + GPRS CN 2.4.1.1. 3G Component Technology 2.4.1.2. Evolution of Mobile Internet with 3G 2.4.1.3. The Realization of the Secure & Safety Mobile Network for Infrastructure 2.4.2. CDMA2000 / HRPD System (KDDI(au)) 2.4.2.1. CDMA2000 and Its Evolution 2.4.2.2. Introducing a Mobile Application Platform (EZplus and BREW®) 2.4.2.3. CDMA2000 IP Packet Network and Service 2.4.2.4. Device Authentication 2.4.2.5. User Authentication 2.4.2.6. IP Address Assignment 2.4.2.7. Packet Data Transfer 2.4.2.8. Accounting 2.5. Enhanced 3G Cellular Systems 2.5.1. All-IP Network for Diversified Radio Access 2.5.2. Convergence of Mobile Networks and the Internet 2.5.3. IP-Based Integrated Network Platform (IP2) 2.5.4. Ultra 3G 2.5.4.1. Beyond 3G 2.5.4.2. Torwards All IP 2.5.4.3. Convergence with Fixed Network 2.5.4.4. Evolution of Radio Access System 2.5.4.5. Access Independent Seamless Communication References

Chapter 3 Wired Access System 3.1. Overview 3.2. Cable Internet 3.2.1. Beginning of Cable Internet in Japan 3.2.2. Features of CATV in Japan 3.2.3. Standardization of Cable Modem System and Adoption 3.2.4. Channel Allocation and Connected Subscribers 3.2.5. Shift to Transmission Rate of more than 100 Mbps 3.3. xDSL Network 3.3.1. Configuration of Metallic Network 3.3.2. Features of DSL Technology

36 37 38 38 38 39 40 41 41 42 42 43 43 43 50 53 55 55 55 56 57 57 58 59 61 61 61 62 66 66 67 67 69 70 71 72 75 75 76 76 76 77 77 78 78 78 79

xv

3.3.3. Analog Transmission and Coding Technology 3.3.4. Technology for Extending 3.3.5. Technology for Increasing Transmission Rates 3.3.6. POTS Signal Superposing Technology 3.3.7. Example of DSL Service 3.4. FTTx Networks 3.4.1. IP and Optical Access Technologies 3.4.2. Optical Access Technologies 3.4.2.1. Overview of Access Network 3.4.2.2. Bi-Directional Transmission on One Fiber 3.4.2.3. Point-to-Point and Point-to-Multipoints 3.4.3. Optical Access Systems 3.4.3.1. STM-Shared PON System and pi-system 3.4.3.2. Media Converter and TS-1000 3.4.3.3. B-PON and G-PON 3.4.3.4. GE-PON 3.4.3.5. Video Distribution System 3.4.3.6. VDSL Systems for Condominiums 3.4.4. Services 3.4.4.1. Access Protocol 3.4.4.2. Fair Access 3.4.4.3. Priority Control References

Chapter 4 Backbone System 4.1. Backbone Systems 4.1.1. Current Situation of the Backbone 4.1.2. Domestic Backbone Connecting Method 4.1.3. Regional Structure of Domestic Backbone 4.1.4. Problems with Regard to Route Control Information 4.1.5. Problems with Regard to Route Control Technique 4.1.6 Prospect of Route Processing Technology 4.1.7. Traffic Demand Estimate by Area 4.2. NSIPXP; Next Service Provider Internet eXchange Project 4.2.1. History and Objective of NSPIXP 4.2.2. Architecture and Operational Policy 4.2.2.1. Resource and Intellectual Property 4.2.2.2. Routing Control 4.2.3. Bandwidth Control 4.2.3.1. Bandwidth Control Policy in NSPIXP 4.2.3.2. Traffic Volume and Appropriate Platform Selection 4.2.4. Traffic Volume at NSPIXP 4.2.5. Architecture of DIX-IE 4.2.5.1. Reliability 4.2.5.2. Scalability Against the Increase of Traffic Volume 4.2.5.3. Introduction and Operation of DIX-IE for Professional Operation 4.2.6. Services Provided by IX 4.2.6.1. DNS Service 4.2.6.2. News System Service

81 83 84 86 86 88 88 92 92 92 93 95 96 97 98 100 100 101 101 101 102 104 104 107 107 107 109 111 112 113 114 115 116 116 118 118 120 121 121 122 124 127 127 127 127 128 128 128

xvi

4.3. Operation of M-Root DNS Server 4.3.1. Background of Root DNS Server Operation in Japan 4.3.2. Initial Configuration 4.3.3. Anycast Operation 4.3.4. IPv6 Support at M-Root DNS Server 4.4. MPLS Backbone Deployment 4.4.1. Nation-Wide MPLS Backbone System 4.4.1.1. MPLS Networks in Japan Telecom 4.4.1.2. The “mpls ASSOCIO” – an Inter-Domain MPLS Service 4.4.1.3. Reliability 4.4.1.4. Future Extensions for mpls ASSOCIO Service 4.4.2. Global MPLS Enable Backbone System 4.4.2.1. Introduction 4.4.2.2. Overview of ANC MPLS-Enabled Backbone 4.4.2.3. ANC MPLS-Enabled Infrastructure Diagram 4.4.2.4. Conclusion and Further Work References

Chapter 5 Broadband Internet Applications 5.1. VoIP (Voice over IP) 5.1.1. VoIP Service Deployment History in Japan 5.1.2. Numbering and Service Quality Definition 5.1.3. Interoperability and Operational Configuration 5.1.4. Promotion and Deployment Activities 5.1.5. Challenges Around VoIP Service in Japan 5.2. Video over IP 5.2.1. Digital Video Streaming Technology 5.2.2. Consumer Digital Video Encoding Formats 5.2.3. High Definition Video (HDV) Format 5.2.4. Interfaces 5.2.5 Frame Discarding 5.2.6. Bandwidth and Reliability 5.2.7. Enhancement in DVTS 5.2.8 Adaption Requirements in Real-Time Streams 5.2.9. Unique Media Streaming Events 5.2.9.1. Internet Metronome 5.2.9.2. DMC Global Studio Project 5.2.10. IPTV 5.2.10.1. Overview of IPTV 5.2.10.2. Standardization of IPTV 5.2.10.3. IPTV and Security 5.3. Peer-to-Peer TV Broadcasting System 5.3.1 Issues and Features of Conventional IP Multicast Service Architecture 5.3.1.1. Unicast-Based Multicast 5.3.1.2. IP Multicast 5.3.1.3. OLM (OverLay Multicast) 5.3.2. Business Deployment of Peer-to-Peer TV Multicasting System 5.3.3. BBbroadcasting System 5.3.3.1. Mesh Topology Network

129 129 130 130 131 132 132 132 132 134 134 134 134 135 136 137 137 139 139 139 140 144 145 145 148 148 150 151 152 156 157 158 158 159 159 160 161 161 162 163 163 163 163 165 166 167 167 169

xvii

5.3.3.2. Local Cache Buffer 5.3.3.3. Bi-Directional Data Transmission 5.3.3.4. High Speed Partner Search/Resolve 5.3.3.5. Hybrid P2P 5.3.3.6. Service Security 5.3.4. Operational Performance of BBbroadcast 5.4. Wide Area IPv6 Access Network and Service 5.4.1. FLET’S HIKARI Premium Service 5.4.2. System Architecture of FLET’S Hikari Premium 5.4.2.1. Non-PPP Networking 5.4.2.2. End-to-End Architecture with CTU 5.4.2.3. Network Prefix Allocation to Customer Network 5.4.2.4. IPv6 Transport 5.4.2.5. Network Topology 5.4.3. Some Key Technology Components 5.4.3.1. IP Multicast 5.4.3.2. Security 5.4.3.3. High Quality Video Telephone Service 5.4.3.4. QoS (Quality of Service) 5.4.4. Home Network Accommodation via CTU References

Chapter 6 Characteristics of Residential Broadband Traffic in Commercial ISP Backbone in Japan 6.1. Overview 6.2. Introduction 6.3. Data Set and Traffic Group 6.4. Results of Traffic Analysis 6.4.1. Customer Edges 6.4.2. External Edges 6.4.3. Traffic Growth 6.4.4. Light-Users and Heavy-Hitters 6.4.5. Application Types 6.4.6. Regional Differences 6.4.7. Locality of Traffic Flow 6.5. Conclusion References Summary and Future Challenges

170 170 170 170 171 172 173 173 174 174 175 176 176 178 179 179 179 179 179 180 182

183 183 183 185 187 187 188 190 192 194 195 197 198 199 201



1

Chapter 1

Brief History of Internet Deployment in Japan 1.1. JUNET 1.1.1. Overview of JUNET As of March 2007, the penetration percentage of broadband Internet for residential home in Japan has reached at 95 %, and the number of residential broadband internet users has reached at 48.63 million. The history of Internet in Japan has started in September of 1984; connecting two computers via UUCP (Unix to Unix Copy Protocol) between Ookayama Campus of Tokyo Institute of Technology (www.titech. ac.jp) and Yagami Campus of Keio University (www.keio.ac.jp), only with 300 bps bandwidth. Mr.Jun Murai, who is respected as a “father of Japanese Internet” and sometimes is called as “Internet Samurai”, had moved from Keio University to Tokyo Institute of Technology in 1984. The first Internet connection in Japan was established, in order to achieve better communication among the computer science engineers and researchers, who had been in Keio University and in Tokyo Institute of Technology. More preciously, they wanted to interconnect “titcca” in Tokyo Institute of Technology and “kossavax” in Keio University. The author may remember it was some Saturday in September of 1984. Using this first UUCP connection, we had confirmed that the first electrical mail (i.e., e-mail) had been correctly exchanged between these two computers. Soon after the establishment of the first UUCP connection, we had started the NetNews service. We had serious discussion which kind of NetNews we should establish. Since, at that time, ARPAnet (Advanced Research Project Agency network) had operated “fa.*” (delived from From ARPAnet), we had named “fj.*” (meaning From Japan). This is the birth of the first nation-wide cyber community of “fj” news groups, in Japan. In October of 1984, “cut” at the University of Tokyo had joined to the network. At this time, the bandwidth was increased to 1,200 bps from 300 bps. Prof.Haruhisa Ishida of the University of Tokyo (www.u-tokyo.ac.jp) supported the vision of the UUCP network, where this network should be expanded and cover all the universities in Japan. And, this Japanese UUCP network was named as “JUNET” (Japan UUCP or UNIX or University or Universal or U.NETwork), and be extended to UNIX related companies and other research institutes and companies. Note that the privatization of Japanese telecommunication was achieved in April 1985, therefore, all the activities of the JUNET was very much ambitious and risky from the point of views of rgovernment regulation.

2

Chapter 1. Brief History of Internet Deployment in Japan

JUNET had been interconnected with CSNET in 1986 and the global e-mail and enews exchange environment had been established. Eventually, JUNET had established the original community for the Internet in Japan. 1.1.2. Routing by Domain Name At first, the email delivery in JUNET had adopted the source routing technique, which is the same routing technology as adopted in the UUCP system. The following is an example of the routing in JUNET email. koeavax!kossvax!titcca!jun This example means that the e-mail message is destined to a user “jun” at a host “titcca” in Tokyo Institute of Technology, via “kossvax” from the “koeavax”, that is the email’s originator. In order to send an email, every user has to know the exact route to reach at the destination node for the destination user. This means that the user or computer must know the exact topology of whole of network, where he/she or it sends the email. The topology information, that every node or user had to know, was not only their own network segment, but was also about other organization. Since the topology information had to very exact, with loose or abstracted topology information, the email had been never delivered correctly to the destination. Apparently, it was so inconvenient for the users. In USENET in USA, “uumap” has been used to resolve the exact route to reach at the destination host. On the contrary, JUNET had investigated in the email routing methodology using a hierarchical domain name system which was the improved version of the naming architecture of ARPAnet at that time The developed system at the JUNET has two root nodes, which are “titcca” at Tokyo Institute of Technology and “ccut” at the University of Tokyo, for the packet delivery. Since each root node should know all the network topology of whole JUNET, the packet was delivered to one of the root node when the source node did not know the exact route to reach at the destination node of the sending packet. The following is an example of email address in this new email system in JUNET. [email protected] JUNET had started to use this email address and email delivery architecture as a general service since 1985. At this time, JUNET was the first UUCP based network, which had adopted the email routing using the hierarchical domain name notation. Therefore, the operation at the JUNET was paid attention by the other network researchers and by the network other operators. 1.1.3. Introduction of Japanese Characters into the Internet System Along to the wide deployment of JUNET in Japan, the project to introduce the Japanese characters into the computer system had been progressed. In those days, there were major three Japanese character set development efforts. These were; x x

JIS (kanji-extension) code for communication Shift-JIS code for process code in the computers


x

3

EUC (Extended Unix Code) for AT&T UNIX system.

JUNET had progressed the activities so that every single applications running in the networks can run with Japanese character. Basically, the programs in those days assumed to use the ASCII code, while the eighth bit was frequently used for some proprietary purposes or did not accept the escape sequence. Therefore, the effort in JUNET had been started to resolve these technical issues. The outputs by these R&D activities by JUNET is summarized in IETF’s RFC1468, including the discussion of character code in it. Before the introduction of Japanese character into the X window system, we had to modify the corresponding software to handle the Japanese characters, while establishing the environment of Japanese character displaying and of Japanese character input. At that time, we had to have a host, that can handle Japanese characters, or to find out the appropriate Japanese character capable host. Therefore, it was general and implicit operation rule that we had to explicitly notify in the “Subject” field as (in English), (in Romaji), (in Kana) or (in Kanji). The comfortable Japanese characters displaying software environment had been delivered with X window system, which had been developed by Mr.Hiroshi Tachibana of Tokyo Institute of Technology. This X window system had used “k14” fonts set for displaying the Japanese characters. The development of “k14” fonts set had been initiated as the collaborative development by the organizations of JUNET, targeting on to be able to handle about 6,000 Japanese characters. Mr.Tachibana had provided the development tool kits for them, so as to achieve effective and consistent font development by distributed and collaborative way among the JUNET researchers. By the process of developing the tools and testing, he had completed the development of the fonts for about 3,500 Japanese characters, and this character set had been defined as the first level of Code of the Japanese Graphic Character Set for Information Interchange. After observing this amazing performance by a single researcher, Jun Murai, without any hesitation, asked Tachibana to work on the second level of Code of the Japanese Graphic Character Set for Information Interchange as well only by himself, not by the sophisticated network-based collaborative work. This font set K14 then long called ‘Tachibana font’ and has been used with many of X window distribution and other commercial products. This was the very first stage of multiple fonts display with the bit map display-based user interface of a computer system. The developed X window system had been extended so as to display 16x16 and 24x24 sized Japanese characters, as well. Simultaneously, the adaptation of TeX system, which is a welldeployed type set software, to Japanese character had been progressed, to transfer the development outputs to Dai Nippon Printing Co.Ltd (www.dnp.co.jp) with very low licensing royalty. In this system, we could use outline-fonts. As for the input of Japanese character, it was a challenge. This is because we needed the translation system from Katakana character to Kanji character. Since multiple Kanji characters may have the same Katakana character (and have the same pronunciation), the system had to be tricky that is completely different from ordinary English based UNIX system. Japanese people had introduced the translation system from Katakana character to Kanji character. The first Japanese character input system

4


would be the “Wnn”. “Wnn” had been developed so as to achieve the correct input for “Watashino Namaeha Nakanodesu”, which corresponds to “My name is Nakano” in Japanese. The Wnn system had been developed by the collaboration among Kyoto University, Keio University, Tateishi Denki (now as Omron Corporation, www.omron. co.jp) and ASTEC Inc.(www.astec.co.jp), which is now the AE Works Inc. The technical feature of the Wnn system is that Wnn system is its network oriented application architecture, i.e., client-server architecture. “jserver”, which the front-end application to accept the request of translation from Katakana character to Kanji character, so as to respond to send the translation result to the client application. Since the Wnn had been developed as a network oriented application, we could smoothly use and introduce the “kinput2”, which is an input method for X window system, “NEmacs or Mule”, which is the Japanese character extension of full-screen Emacs editor. The other technical feature of “Wnn” system is it’s open source development style. We had shared the dictionary of translation rules from Katakana character to Kanji character, as “pubdic”, among whole of JUNET community and “Wnn” users. The “Wnn” users had registered the words (vocabulary), whenever they had newly defined. The registered rules had been periodically aggregated into the source dictionary to be distributed to every “Wnn” servers on the network. Wnn and its descendant technologies has been used as the basis of the mobile telephone explosion, and the name Wnn still being used in the area.

1.2. Introduction of IP Connection in Japan Before 1988, when the WIDE project had initiated, the computer network in Japan was based on UUCP technology. JUNET using the UUCP has been widely deployed both in university campus networks and in corporate networks. Gradually, the technical interests on the networking using the IP technology had been developed. The JUNET community started its new action using the same three organizations (sites), which had initiated the JUNET with UUCP technology. This was the first IP network in Japan. These are Tokyo Institute of Technology, Keio University and The University of Tokyo. These three sites with the Iwanami company, which is an academic publishing company to interface with the industry sites, had been interconnected using the digital least lines (64 kbps link), to run the IP, in 1988, i.e., initiation of the WIDE project. In January of 1989, the WIDE IP network had been interconnected with NSFnet of USA by the support of NSCSIS with 9600 bps bandwidth, and been interconnected via Hawaii Island with 64 kbps bandwidth. The WIDE project represents Widely Integrated Distributed Environment, and is focusing on the R&D and deployment of IP networking environment in Japan. WIDE project has continuously contributed to the Japanese internet society, not only from the research and development of internet technology, but also from the internet system introduction and deployment point of view. By the trigger of launching of the WIDE project IP network, the other academic IP networks had been developed and deployed in Japan. In 1993, IIJ (Internet Initiative Japan Ltd.) and AT&T Jenes have started their commercial internet service in Japan. The internet service had been deployed both for corporate customer and for residential users. The launch of Windows 95 by Microsoft, which was installed TCP/IP protocol stack as a default, had accelerated the deployment


5

of internet access for the Japanese corporations and for the Japanese residential customers, due to so smaller technical difficulty to start the internet access. According to the deployment of internet access service providers, we had started to realize that we must establish the interoperability and reachability to every network providers. In order to achieve better internetworking and reachability among the network providers, the WIDE Project has initiated the first IX (Internet eXchange), called as NSPIXP-1, in 1994. The first IX (NSPIXP-1) in Japan had been installed in the head quarter building of Iwanami Shoten Publisher (www.iwanami.co.jp/) in downtown Tokyo. In order to operate the IP networks friendly with human being, the IP system has introduced the concept of hierarchical domain name structure for easier identification of interface with the corresponding IP address for human being. Actually, the interface is identified by the FQDN (Fully Qualified Domain Name), which is the combination of domain name and host name. In order to effectively refer to the FQDN to access the appropriate interface with the corresponding IP address, the IP system must have some methodology or system to resolve the IP address from the FQDN. The old IP system used the local dictionary, stored at “/etc/host”, where the administrator of the host registers the FQDN information and the corresponding IP addresses. This system had worked, if the scope of the network to communicate was relatively small enough. However, according to the growth of the IP system, the IP system had introduced the client-server type IP address resolution system. One of the widely adopted and being standardized system is the DNS (Domain Name System). DNS defines a hierarchical domain name space and its resolution process. The tree structured name space has been divided into many zones. Japan has the domain of “.jp”, which is the cc-TLD (country code Top Level Domain) allocated to Japan. WIDE group and JPNIC (and now with JPRS) has maintained the .jp DNS server. In order to resolve a given name, a client sends a DNS query message to a designated recursive server. It performs a resolution process and responds back the final result. The recursive server starts resolution process to send a query to one of the Root DNS servers, which is corresponding to the root node of the tree structured namespace. Each nameserver responds with the final answer if the server has the information requested or with the referral to other servers. Usually the Root DNS server responds with a set of information for Top Level Domain (TLD). All of the Root DNS servers were operational before 1994 when the 9th the Root DNS server started its operation in Stockholm. In 1995, it was discussed that a few Root DNS servers were to be added to comply with the development of the Internet in Europe and in Asia-Pacific region. WIDE Project had named as the operator of the very first Root DNS server in Asia-Pacific region through the discussion and started its operation in August 22nd 1997, as “M.ROOTSERVERS.NET”. In the second half of 1990’s, the internet access from the residential customers were by the dial-up connection, either using the PSTN modem and ISDN (Integrated Service Digital Network) offered by NTT. Since NTT offered flat-rate telephone fee in the late evening, called as “Tele-hodai”, the volume of internet traffic after 11:00 PM had suddenly increased. Due to the expensive access cost by the PSTN service, it was said that Japan is under-developing country associated with the internet service, around 1998.

6


Before entering into the FTTH solution for the residential customer, we had replaced the PSTN and ISDN access to the ADSL access. The ADSL technology has been in commercial operation since 1999, after the technical evaluation and establishment at various events and organization, such as Networkd+Interop Tokyo. And, in these days, the Voice over IP (VoIP) technology has been gradually introduced into the backbone data transmission system. We may recognize that the full deployment of ADSL system and service had been triggered by the following two important actions. The first action has been achieved by the government, i.e., launching the e-Japan initiative under the Mori-cabinet. Prime Minister Yoshiro Mori has announced the eJapan initiative during his first keynote address at the opening of a Diet session. According to this address, the IT strategic headquarter has established in 2001. As the agenda of IT strategic headquarter, it had been targeted that always-on broadband connectivity with 30 Mbps should be provided, and more than 10 million FTTH (Fiber To The Home) residential customers must be achieved. The second trigger was the start of Yahoo BB!’s ADSL service, in nation-wide Japan. Yahoo BB! fully used the opportunity to use the dry-cupper, as so to build up their ADSL service. Now, in 2007, the broadband internet connectivity environment had been deployed to reach at more than 95 % penetration for residential customer, either by ADSL or by FTTH.

1.3. IP version 6 1.3.1. Initialization of IPv6 Activity at IETF The current version of IP (i.e., IP version 4, IPv4) has been standardized as IETF’s RFC791 in 1981. This means that the Internet system has run with IPv4 for more than 25 years. When the IPv4 had been designed, the technical condition and the users of the Internet were truly different from the current situation. At first, the scale of network, from the view pints of geographical and numerical, has grown up significantly. When the IPv4 had designed, it had considered the number of nodes connected to the IPv4 Internet was far less than the number represented by 32 bits address length (roughly 4.3 billion). However, now, the total number of nodes, which has already connected to the IPv4 Internet, has been far larger than 4.3 billion. Since total number of nodes on the current IPv4 Internet is far larger than the 4.3 billion, the reuse of IPv4 address via NAT (Network Address Translation) has been widely adopted. Second, we have experienced many technical and operational changes due to many technical innovations. The following system assumption would be denied. 1. 2. 3. 4. 5.

User and end-station is poor processing capability and does not have enough intelligence Users’ terminal only turns on, when it’s needed Fixed terminal is far major and superior than mobile nodes “Service” must be provided either by provider or by enterprise Cost of transmission, store and copy, is not little, but negligible


7

In other words, the current Internet system is; 1. 2. 3. 4. 5.

End-stations operated by end-users have got enough computing capability and intelligence End-stations are always-on Mobile nodes is major stake-holder than fixed nodes Service can be provided by end-stations, e.g., overlay service Every node can easily copy, store and transmit the digital data

At the end of 1980’s, the IETF (Internet Engineering Task Force) had recognized these technical challenges, to start the technical discussion on next generation Internet Protocol. The followings were the technical and operational issues, which IETF had recognized. a) b) c) d)

Shortage of IP address Explosion of routing entries Security threads Manual configuration of nodes, especially for non-technical users’ accommodation e) Quality of service Actually, as of July 2007, the IPv4 address pool possessed by IANA (Internet Assigned Numbers Authority, www.iana.org) for new IPv4 address allocation for users’ requests has been less than 20 % against the all of available IPv4 address resource. The whole of Internet community has getting serious to introduce new version of IP, called IP version 6 (IPv6), as the professional and business operation. IAB (Internet Architecture Board, www.iab.org), which corresponds to the parent organization of IETF and IRTF, has officially announced to start the technical standardization activity of the next generation Internet Protocol, at the INET92 held at Kobe in 1992. Here, INET is the first technical conference associated with Internet technology and operation, created by ISOC (Internet Society, www.isoc.org). According to the decision and announcement by IAB, the IPng (IP next generation) working group has been established in IETF. IPng working group has had intensive technical discussion for many years. The following three candidates for IPng had been on the table. (i) TUBA (TCP and UDP with Bigger Addresses), RFC1347 (ii) CATNIP (Common Architecture for the Internet), RFC1707 (iii) SIPP (Simple Internet Protocol Plus White Paper), RFC1710 Finally, the slightly modified SIPP has been adopted as IP version 6 (IPv6), as described with RFC1883, in 1995.

8


1.3.2. R&D and Deployment Activity in Japan 1.3.2.1. IPv6 Protocol Stack Development Activity In Japan, many R&D organizations had progressed the implementation of IPv6 protocol stack. Under the leadership by the WIDE project, these R&D organizations had been encouraged to run the interoperability testing among their implementations, in order to accelerate the constructive technical feedback to their implementation. The WIDE project had established IPv6 working group in 1995. Under the leadership of Mr.Masaki Minami of Keio University, Dr.Kazuhiko Yamamoto and Mr.Keiichi Shima (who is the original implementer of “hydrangea” IPv6 protocol stack) of Nara Institute of Science and Technology, the WIDE project has proceeded intensive collaboration on IPv6 protocol stack implementation and on interoperability testing. At the IETF/ INET96 held in Montreal (Canada) in June of 1996, the WIDE project has agreed with Cisco Systems to establish the global IPv6 experimental testbed. This testbed had leaded to “6 bone”, which had been the shared IPv6 experimental network by all the IPv6 R&D community for long time. Here, the “6 bone” has been concluded in June of 2006, due to the completion of it’s mission. In order to establish the IPv6 technology and deployment as the professional platform, the WIDE project had progressed strategic activities since 1998. Here, the meaning of establishment of IPv6 technology includes not only the stable implementation, but also includes establishment of software architecture of IPv6 protocol stack in UNIX system, quality management platform and operational technology for actual professional network deployment in the industry. The following three action items had been recognized as the field where the WIDE project should explore. (1) Open and reference software implementation (i.e., KAME and USAGI projects) (2) Conformance and interoperability testing platform (e.g., TAHI project) (3) Live testbed with multi-vendor environment (e.g., JGN/JGN2, WIDE, Interop Tokyo) In 1998, the KAME (derived from “KArigoME”, which is the name of location the project had been proceeded) project had been established by WIDE Project. The mission of KAME project is unifying and delivering the IPv6 protocol stack as an open source and as a reference software implementation. This is aiming the same role as what the UCB (University of California Berkeley) BSD UNIX project had contributed to the development and deployment of IPv4 and of the Internet itself. The following organizations were the founders of KAME project.

Keio University The University of Tokyo IIJ (Internet Initiative Japan, Inc.) Fujitsu Limited Hitachi, Ltd. (The unit that participated in the KAME project has become ALAXALA Networks Corporation.) NEC Corporation


9

Toshiba Corporation Yokogawa Digital Computer Corporation (The unit that participated in the KAME project was transferred to Yokogawa Electric Corporation.) Yokogawa Electric Corporation In 1999, the KAME project had succeeded to unify the following three independent IPv6 open source into the single source. These were the protocol stack by INRIA of France, NRL (Naval Research Lab.) of USA and by KAME of Japan. Also, the IPv6 protocol stack had been integrated into almost all the major BSD UNIX distribution (e.g., FreeBSD, NetBSD) and into Macintosh OS X (i.e., “tiger”). The KAME project had been concluded in March of 2006, due to the completion of it’s project mission. In 2000, the WIDE project has established the USAGI (UniverSAl playGround for Ipv6) project. The USAGI project has the same project mission as the KAME project, though the target software platform is different, i.e., LINUX system. The following organizations were the founders of USAGI project. Keio University The University of Tokyo Mitsubishi Electric Information Network Corporation (The participants to the USAGI project has moved to Anchor Technology Inc.) Hitachi, Ltd. (The unit that participated in the USAGI project has become ALAXALA Networks Corporation.) IBM Japan Ltd., Nippon Ericsson K.K. NTT Software Corporation Sharp Corporation Toshiba Corporation Yokogawa Digital Computer Corporation (The unit that participated in the USAGI project was transferred to Yokogawa Electric Corporation.) Now, two engineers from USAGI project have served as kernel maintainer, who are Dr.Hideaki Yoshifuji (Keio University) and Mr.Yasuyuki Kozakai (Toshiba Corporation). Since 2003, the “nautilus” project has been operated by the WIDE Project. This project is for the R&D on mobile architecture with IPv6. The nautilus project covers Mobile IP, NEMO (Network Mobility) and MANET (Mobile Ad Hoc Network), while proceeding the collaboration with INRIA and HUT (Helsinki University of Technology). In May of 2007, the WIDE project has established the “HOTARU” project, which is aiming to develop the reference software implementation of IMS-SIP for IPv6 platform.

10


1.3.2.2. IPv6 Conformance and Interoperability Testing Platform TAHI Project has been established in October 1998. TAHI project is a twin project with the KAME project. The KAME project was developing the IPv6 protocol stack on BSD UNIX system, and the TAHI project is developing the conformance and interoperability testing platform, so as to improve the quality of KAME project IPv6 protocol stack. These two projects has run to each other, having a good technical interaction. TAHI project has been established by the collaboration among the following organizations. Yokogawa Digital Computer Corporation Yokogawa Electric Corporation The University of Tokyo The TAHI project has publically provided the open source IPv6 protocol stack verification environment for free. Any private and public organization can verify their IPv6 products using the TAHI testing suite. The TAHI project is playing the core function at the following two key programs to deploy the IPv6 technology to the industry. (1) IPv6 Ready Logo Program operated by IPv6 Forum (2) Certification working group operated by IPv6 Promotion Council Japan Especially, the IPv6 Ready Logo Program has been widely accepted as a De-facto IPv6 product verification platform by many public (e.g., NIST of USA and JATE of Japan) and private organizations. 1.3.2.3. IPv6 Testbed Operation In 1997, at the Networld+Interop Tokyo’97, the world’s first IPv6 multi-vendor demonstration network, as the SSD(Solutions Showcase Demonstrations), has been operated. Since 1997, Networld+Interop Tokyo (now as INTEROP Tokyo) has continued the most advanced network configuration with IPv6 and IPv4 dual-stack operation. In INTEROP Tokyo 2007, the native IPv6 segments for the “end-users” has been offered as the general service. The WIDE project has introduced the IPv6 technology into their own live testbed (called as the WIDE Internet) in 1998. In 1998, the WIDE project network has been transit to IPv4/IPv6 dual-stack environment. At that time, since there was no commercial router supporting the IPv6 function, the WIDE project has used the PC-based routers. In March of 1999, the WIDE project has had the experimental operation of the high quality (NTSC equivalent quality using Digital Video interface) real-time video multicasting service using the PIM-SM with IPv6. The experiences of IPv6 operation at the WIDE Internet had been transferred to the JGN (Japan Gigabit Network), operated by TAO (Telecommunications Advancement Organization of Japan). After the verification and debagging of interoperability among the commercial routers and switches since the April of 2001, the JGN had launched the IPv6 general service to Japanese network R&D community in April of 2002. The IPv6


11

R&D network has been transferred to JGN2 operated by NiCT (National Institute of Information and Communication Technology, www.nict.go.jp), which is a successor of JGN, which has 26 IPv6 NOC (Network Operation center) in nation-wide Japan. 1.3.2.4. IPv6 Promotion Council The IPv6 has been recognized as the important national strategic development by the first keynote address at the opening of a Diet session by the Prime Minister Yoshiro Mori on September 21, 2000 (http://www.kantei.go.jp/foreign/souri/mori/2000/ 0921policy.html). I shall boldly address the diverse range of issues we face, including the early realization of e-government, the computerization of school education and the development of systems compatible with the integration of communications and broadcasting, on the basis of discussion in the IT Strategy Council. We shall also aim to provide a telling international contribution to the development of the Internet through research and development of state-of-the-art Internet technologies and active participation in resolving global Internet issues in such areas as IP version 6 (IPv6). Accordingly, the IPv6 Promotion Council (www.v6pc.jp) has been established in October 2000. The IPv6 Promotion Council has defined the following strategic activities. 1. 2. 3. 4. 5. 6. 7. 8.

Establishment and Implementation of Basic Strategies to promote IPv6 domestically and globally Establishment and Implementation of IPv6 Transition Environment Verification and certification of IPv6 products and services R&D on advanced functions with IPv6 platform Development of applications and services over IPv6 platform Professional quality testbed operation Development of human resources for IPv6 deployment Establishment of global strategies

1.3.2.5. IPv6 Commercial Operation (1) IPv6 Commercial Operation by ISP Japanese ISPes has started their commercial or trial IPv6 service since around 2001. The followings are examples of time frame when the major ISPes has started their IPv6 service to the end-customers.

IIJ, Internet Initiative Japan : November 2001. NTT Communications: August 2002. KDDI : November 2002. Softbank BB! : February 2005. NTT Esat : January 2004. NTT West : April 2004.

12


As shown in figure 1-1, more than 5 million residential subscribers has been ready to start to use the IPv6 service, and more than 100 thousands of customers has already connected through the IPv6.

Figure 1-1. IPv6Service Penetration at Major ISPes in Japan as of Jan. 2007.

(2) IPv6 Commercial Operation in Private Networks The other commercial IPv6 service deployment is in the area of private networks. It has already been reported the examples of network deployment as the business operation. (a) IP-PBX Deployment by Freebit Co.Ltd (http://www.freebit.com/) Freebit has established the nation-wide private IP-PBX system using the SIP IPv6 in the fiscal year of 2004. The network has about 280 sites across the Japanese soil, and accommodates about 20 thousands VoIP terminals. The installation had started since April of 2004 to complete all the installation at the end of March 2005. They have adopted the PoE (Power on Ethernet) technology to VoIP terminals, and effectively use the IPv6 plug-and-play function. By means of IPv6 plug-and-play function (i.e., auto-configuration), the installation overhead and the number of misconfiguration during the installation has been significantly reduced. They have reported that the average number of mis-configuration per customer site has reduced from about 300 to single digit. This results to lead the reduction of installation cost for system integrator. Also, in the design process of every customer site, they have succeeded to establish only three design and installation manuals for all 280 sites. With their past experiences, they had to perform a custom-made system design for every single customer site, in order to save the IP address, when they used the IPv4 address in the system. After the introduction of VoIP system, they can manage the system, very effectively, due to the appreciation of global IP address allocation to every single VoIP terminal. The identification of terminal occurring the trouble can be instantly carried out, and the segregation of such a troubled terminal can be achieved very effectively and very immediately, without sending the expensive engineer to the site physically. As discussed above, by the adoption of IPv6 technology, they have succeeded the cost reduction for all the three operational phases; system designing, system installation and system operation.


13

(b) Online Convenience Store Development by FamilyMart FamilyMart, which is one of major convenience store chain in Japan, has announced the installation of IPv6 system into all of their stores in Japan, from February 2007. Every convenience store is going to be on-line store. They have 7,000 stores in Japan, and plan to install IPv6 service about 80 stores per day. Using the broadband IPv6 connectivity (i.e., IPv6 capable B-Flets provided by NTT East and West), VoIP terminal, Kiosk terminal, POS system and video advertisement system are going to be installed in the store. They are going to introduce high quality video multicasting advertisement program to all the stores in Japan, simultaneously.

1.4. Commercial IP Networks In 1992, there was a enthusiastic effort to start up the professional and commercial internet operation in Japan. IIJ (Internet Initiative Japan, www.iij.ad.jp), has been established after the significant and log time discussion with Japanese government. In order to obtain the operational allowance by the Japanese government, the people related with the IIJ had spent huge amount of efforts. In order to deploy the commercial IP network service provider, the WIDE project had recognized the shared testbed of IX (Internet eXchange), which interconnects the private and public IP networks. NSPIXP is the R&D consortium, established in 1994, in order to fulfill the practical technical investigation on the internet exchange system. 1994 is the year the commercial ISP service has launched by IIJ(Internet Initiative Japan, www.iij.co.jp), in Japan. Before 1994, we have had the internet, which are operated by R&D community, without any common internetworking point. This means that, in these days, the academic networks (e.g., TISN, SINET or WIDE) have been interconnected individually, i.e., private peering. We did not have the Internet eXchange (IX), which is the public peering point. The object of NSPIXP is to establish the architecture and operational technologies, to interconnect the academic and commercial IP networks. Since, before the establishment of NSPIXP, IP networks are interconnected by private peering, the AS path length among the network were long. This is because that each network could not peer with all the networks. Also, the quality of communication among the networks could not stable enough, since the network could not control the transit network(s) and the path reach to the destination network. By the introduction of IX (Internet eXchange) point in Japan, the networks could establish larger number of direct peering, than before, with lower facility cost. This is because, by the participation to NSPIXP, the network can establish multiple peering by the single physical circuit. NSPIXP has operated several IXes; NSPIXP-1 (Network Service Provider Internet eXchange Point-1), NSPIXP-2, NSPIXP-3, NSPIXP-6 and DIX-IE (Distributed IX in Edo), based on each R&D purposes. In 1996, the NTT, that is national flag telephone operator in Japan, had launched their internet service, called as OCN (Open Computer Network). In these days, the corporate networks used very expensive digital least lines, and the most of residential customers used the dial-up connection using the analogue PSTN service. Gradually, the ISDN service, called as INS64 for NTT, had got the market share for internet

14


access technology. In these days, it was widely recognized that it was very expensive in Japan to connect and to use the Internet, due to expensive PSTN and ISDN tariff. Actually, in the end of 1990’s, it has been widely recognized that the Japanese internet was very expensive and Japan was a kind of under-developing country regarding the Internet infrastructure development and operation. Though NTT’s PSTN service and ISDN service were expensive, NTT had aggressively progress the deployment of FTTH (Fiber To The Home) environment. This progress achieved by NTT results to the fast development and deployment of broadband Internet environment in Japan, as a result. Before entering into the FTTH solution for the residential customer, we had replaced the PSTN and ISDN access to the ADSL access. The ADSL technology has been in commercial operation since 1999, after the technical evaluation and establishment at various events and organization, such as Networkd+Interop Tokyo. And, in these days, the Voice over IP (VoIP) technology has been gradually introduced in to the backbone data transmission system. We may recognize that the full deployment of ADSL system and service had been triggered by the following two important actions. The first action has been achieved by the government, i.e., launching the e-Japan initiative under the Mori-cabinet. Prime Minister Yoshiro Mori has announced e-Japan initiative during his first keynote address at the opening of a Diet session. According to this address, the IT strategic headquarter has established in 2001. The second trigger was the start of Yahoo BB!’s ADSL service, in nation wide. Yahoo BB! fully used the opportunity to use the dry-cupper, as so to build up their ADSL service. The number of VoIP customers in Japan has increased linearly since 2003. The total number of VoIP customers has reached at more than 10 million at the end of 2005, and has reached 1.4 million at the end of 2006. The first professional and business VoIP service in Japan was not the end-to-end voice communication service, but was the trunking of voice traffic in the backbone transport system. Around the end of 1990s, with the trial VoIP service operations over the existing IP networks, it had been recognized so that VoIP service over the Internet were so poor for commercial service. However, in 2001, Yahoo BB! has started their Internet connectivity service with very cheap price (3,017 Yen per month) and with large available bandwidth (8 Mbps), so as to boot-strap the explosion of VoIP service in Japan. Also, Japan has started the professional quality real-time video delivery service to the broadband Internet residential customers. GYAO (www.gyao.ne.jp) by YUSEN and BB-TV! by Yahoo BB! (bb.yahoo.co.jp) would accommodate good number of customer base in Japan. As described in section 5.3, Yahoo BB! has succeeded the large scale high quality real-time video multicasting service using their differentiated peer-to-peer architecture. They have confirmed their peer-to-peer works well with about 50,000 clients. This would be a good proof and best current practice of worldfirst overlay realtime multicasting service using the peer-to-peer technology. With these triggers, Japan has progress toward the cost effective broadband Internet country. In 2006, it was said that Japan is one of most cost effective broadband, i.e., the cheapest bit cost in the world.


References [1] UUCP, http://en.wikipedia.org/wiki/UUCP/ [2] Keio University, http://www.keio.ac.jp/ [3] Tokyo Institute of Technology, http://www.titech.ac.jp/ [4] The University of Tokyo, http://www.u-tokyo.ac.jp/ [5] IETF, Internet Engineering Task Force, http://www.ietf.org/ [6] Dai Nippon Printing Co.Ltd , hjttp://www.dnp.co.jp/ [7] ASTEC Inc., http://www.astec.co.jp/ (currently http://www.rworks.jp/) [8] Omron corporation, http://www.omron.co.jp/ [9] IIJ (Internet Initiative Japan Ltd.), http://www.iij.ad.jp/ [10] Iwanami Shoten Publisher, http:// www.iwanami.co.jp/ [11] NSPIXP, nspixp.wide.ad.jp/ [12] JPNIC (Japan Network Information Center), http://www.nic.ad.jp/ [13] JPRS (Japan Registry Service), http://www.jprs.jp/ [14] NTT (Nippon Telegraph and Telephone Corp.), http://www.ntt.co.jp/ [15] IANA(Internet Assigned Numbers Authority), http://www.iana.org/ [16] IAB (Internet Architecture Board), http://www.iab.org/ [17] ISOC (Internet Society), http://www.isoc.org/ [18] KAME Project , http://www.kame.net/ [19] USAGI Project, http://www.linux-ipv6.org/ [20] Fujitsu Limited, http://jp.fujitsu.com/ [21] Hitachi, Ltd., http://www.hitachi.co.jp/ [22] ALAXALA Networks Corporation, http://www.alaxala.net/ [23] NEC Corporation, http://www.nec.co.jp/ [24] Toshiba Corporation, http://www.toshiba.co.jp/ [25] Yokogawa Electric Corporation, http://www.yokogawa.co.jp/ [26] Mitsubishi Electric Information Network Corporation, http://www.mind.co.jp/ [27] Anchor Technology Inc. , http://www.anchor.jp/ [28] IBM Japan Ltd., http://www.ibm.co.jp/ [29] Nippon Ericsson K.K. , http://www.ericsson.co.jp/ [30] NTT Software Corporation, http://www.ntts.co.jp/ [31] Sharp Corporation, http://www.sharp.co.jp/ [32] NiCT(National Institute of Information and Communication Technology), http:// www.nict.go.jp/ [33] JGN (Japan Gigabit Network), http://www.jgn.nict.go.jp/ [34] IPv6 Promotion Council, http://www.v6pc.jp/ [35] Yahoo BB! , http://bb.yahoo.co.jp/ [36] GYAO by YUSEN, http://www.gyao.ne.jp/

15



17

Chapter 2

Mobile Internet Deployment in Japan Mobile Internet is a typical example of effective collaboration between telecom’s mobile networks and the Internet. Mobile operators in Japan have been playing a leading role in promoting Mobile Internet services that introduce a new service concept and business models. This chapter introduces the basic concept and technologies for Mobile Internet with special reference to the development of mobile communication systems in Japan. Wireless access and networking technologies that support Mobile Internet are described based on their system evolution. Service platform functionality and protocol techniques featuring gateway functions between mobile networks and the Internet are also discussed as another key component of Mobile Internet construction. 2.1. Overview of Mobile Internet in Japan 2.1.1. Introduction In February 1999, a new data communications service branded as ‘i-mode’ was started by NTT DoCoMo, a mobile carrier in Japan. i-mode was the world’s first commercial Internet access service using cellular phones as end terminals. Although applications and content available for the i-mode service were not abundant in its initial phase of the service, people enjoyed the services since it was very convenient that one could access the Internet in a mobile environment. Two other carriers, KDDI㸦au㸧 and J-Phone (which was acquired by Vodafone and then by SoftBank), also started the same type of Internet access service soon after the i-mode deployment. As the three carriers made every effort to enhance their services to compete with each other, subscribers to the mobile Internet access grew very rapidly in Japan. A new non-voice service created by interconnection between the Internet and cellular networks has become an integral part of the mobile services. This interconnection also brought a new capability to the Internet, i.e. mobility that enables users to access the Internet anywhere, anytime. Thus, the service could be called Mobile Internet service. In March 2006, about 90% of cellular phones in Japan are capable of accessing the Internet and the number of Mobile Internet users is almost 80 million. Reflecting the rapid growth of Mobile Internet service in Japan, we describe in this chapter networking technologies that support the deployment of Mobile Internet service. The structure of this chapter is as follows: First, in section 2.1, we redefine the Mobile Internet in Japan describing its basic structure. Digital cellular mobile network evolution is described as the foundation for the Mobile Internet. New broadband access technology such as WiFi and WiMAX is briefly introduced as a candidate for alternate access technology for the Mobile Internet. Protocols specific to Mobile Internet access are also explained in this section. In section 2.2, we explain the service concept and business models provided by the Mobile Internet. Some specific applications and functional features from service providers in Japan are also introduced. Following these introductory sections, we describe the network infrastructure evolution

18

Chapter 2. Mobile Internet Deployment in Japan

that made Mobile Internet access efficient and useful. In section 2.3, the second generation (2G) mobile network structure is described featuring its packet switching network. Two types of 2G networks are deployed in Japan. Next in section 2.4, the third generation (3G) network structure is explained. As in 2G, two standards from the IMT-2000 family are deployed in Japan. The 3G networks enhance Mobile Internet capability with their wideband and multimedia service capabilities. In section 2.5, new access and core network systems are explained as enhancements of 3G systems. 2.1.2. Mobile Internet: A Definition and its Basic Structure 2.1.2.1. Mobile Internet in Japan Nomadic access to the Internet had been available well before 1999 for laptop PCs when people traveled around carrying their PCs with them. The access was achieved via a fixed line, i.e. LAN access or dial-up through a telephone line. Although it could be called nomadic, it was not convenient, since connectivity was limited and remote access from PCs was somewhat awkward for ordinary people. On the other hand, wireless Internet access was possible using a mobile phone as a dial-up tool. In this case, a circuit switched mobile network was used for remote access and the bit rate was very slow for data communications. Users of this wireless Internet access were mainly business users and the market did not grow. Another example of wireless data service is the short messaging service (SMS) and some content delivery services over cellular networks. In this service, a cellular phone was used as a data communications terminal and the services were closed within a mobile operator’s network, not connected to the Internet. Since a mobile terminal was used, it could be said that the services were mobile. In this sense, this could be called the first kind of mobile data services. It was not until the i-mode service appeared, however, that a mobile network interacted directly with the Internet.

Figure 2-1. Mobile Communications Market in Japan


19

A convergence between a mobile network and the Internet made its practical debut in Japan when i-mode service was started in February 1999. A cellular handset was used as a mobile terminal to enjoy typical Internet services such as Web browsing and emailing. To provide an AlwaysOn mode for Web browsing, packet switching was used as mobile network access. Typical protocols and Web description languages used on the Internet such as TCP/IP, HTTP and HTML were applied with only small revisions to realize an effective service convergence among cellular networks and the Internet. The services delivered by i-mode have been well accepted by cellular phone users in Japan because they are easy to access and convenient for everyone. Thus, the i-mode service by NTT DoCoMo and its equivalents, i.e. EZweb by KDDI (au) and Vodafone Live! by SoftBank (former Vodafone), took root in Japan and became major services for mobile operators (Figure 2-1). We would like to call it “Mobile Internet” when a cellular mobile network is used as an access network for the Internet and cell phones provide new types of converged mobile services to users. 2.1.2.2. Mobile Internet Structure and Network Architecture The Mobile Internet consists of existing (fixed) Internet and a mobile network which provides a mobile capability. These two networks are combined by two gateway function groups which are keys to create the concept of Mobile Internet services. The first function group is called Network Gateway which provides conversion functions for protocols that are used in the mobile network and the Internet. The second function group is called Service Gateway which provides portal functions for mobile users such as Web pages and email distribution. In this chapter, these two gateway function groups are called Mobile Gateway. The Mobile Internet structure is shown in Figure 22. Next, we describe the main characteristics of this structure.

Figure2-2. Mobile Internet Structure

The cellular mobile network consists of radio access and core networks. Terminal mobility is served through the collaborative operation of the physical, link and network layers of these networks. The end-to-end connection control over the mobile network is executed using phone numbers defined on the telecom networks. In order for a cell phone to be connected to the Internet, a logical channel is established between the cell

20


phone and the Network Gateway in the Mobile Gateway using the telecom connection control. Over the logical channel, information to/from the Internet is transferred using IP packet or other information formats. On the other hand, the Service Gateway in the Mobile Gateway is regarded as one of the end hosts of the Internet when it is viewed from the Internet side. Information transfer from the Service Gateway to any end host of the Internet is performed by IP routing using IP packet. Thus, there exists a difference among network layer protocols which provide connectivity on the mobile network and the Internet. The difference is processed and absorbed within the Network and Service Gateways. As for the end-to-end transport protocols, it had been pointed out that it would not be efficient to use the original transport protocols such as TCP in a wireless environment because it creates longer delays and higher bit error rates compared to wire-line networks. As a solution to this problem, a method of tuning TCP parameters in to wireless networks was developed. The method, called Wireless-profiled TCP (WTCP), was standardized in IETF as RFC3481 (“TCP over 2.5G and 3G Wireless Networks”) and other technology-specific RFCs. W-TCP is treated as an optional protocol for network operators. In the case of the Mobile Internet of NTT DoCoMo, the protocol is applied between cell phones and the Network Gateway. Protocol conversion between W-TCP and ordinary TCP over the Internet is performed at the Network Gateway. Regarding application layer protocols, mobile service-oriented protocols were developed considering requirements specific to wireless networks. The Service Gateway plays a role for terminating the mobile specific application protocols and transforming them into the existing Internet protocols if necessary. At the Service Gateway, various service provisioning functions are also provided in addition to protocol conversion functions. For example, a web portal for content

Figure2-3. Mobile Internet Service System Architecture (i-mode in 2G)


21

distribution and an Internet emailing system are furnished at the gateway. Information access management is given on a personal basis for content access charges and packet volume measurement. The Service Gateway thus forms a platform for Mobile Internet services. NTT DoCoMo branded the Mobile Internet service concept as ‘i-mode’ utilizing Service Gateway functions as its service platform. One of the main features of the i-mode service was a micro payment scheme for Internet content distribution, which enabled content providers to collect information fees from the large number of users on the mobile network. The content access of each user is monitored at the Service Gateway and its fee is added to the monthly communication charge for the user. This efficient and reliable fee collection scheme for content providers was also accepted well by consumers as a convenient micro payment system, which consequently fueled the expansion of i-mode service in Japan. Mobile Internet service provisioning architecture on a 2G mobile network is shown in Figure 2-3. 2.1.3. Access and Network Infrastructure Evolution of the Mobile Internet 2.1.3.1. Public Mobile Communications Systems in Japan In Japan, public mobile communications service was started in 1979 serving an analog cellular telephone system for automobiles. In 1993, a digital cellular system known as Personal Digital Cellular (PDC) was introduced by NTT DoCoMo. And in 1997, a packet switching system was added to the PDC system, and this was called PDC-P. Another digital cellular system called cdmaOne, which was developed and standardized in the USA as IS95, was introduced in Japan in 1998 by KDDI (au). As for the 3G mobile communications systems, the Wideband CDMA (W-CDMA) system was commercialized in Japan in October 2001 by NTT DoCoMo as the forerunner of 3G services deployment in the world. Vodafone also started its W-CDMA services in Japan from December 2002. Another 3G system, cdma 2000, one of the IMT-2000 family systems, was deployed by KDDI (au) in April 2002. 3G wireless access systems are being improved especially for high-speed data communications services. Enhanced 3G system studies have already been started at

Figure2-4. Evolution of Mobile Communication Systems in Japan

22


standardization bodies such as 3GPP/3GPP2. Furthermore, more advanced wireless access systems which could have maximum access rate of 1Gbps are being studied as the next generation (4G) system at research organizations in the world. Vision and framework for 4G wireless access systems have been studied at ITU-R, and service and bandwidth requirements were already described in its recommendation Rec. M1645. Actual systems investigations have also been progressing at several leading research organizations around the world. NTT DoCoMo in Japan has already announced its study results on 4G access technology, and they showed 1 Gbps and 2.5 Gbps cellular access capabilities in field trials in 2004 and 2005, respectively. Towards the year 2007 when the World Radio-communication Conference (WRC) 07 will be held in Geneva in October, discussions on new frequency band assignment for systems beyond IMT-2000 (now called IMT-Advanced) are being accelerated in national standardization bodies in Japan as well as at ITU-R. Stages in the evolution of mobile communication systems in Japan are shown in Figure 2-4. 2.1.3.2. New Broadband Wireless Access Systems for the Mobile Internet In recent years, wireless access technology such as the IEEE 802 Committee specified 802.11 wireless LAN (W-LAN), and 802.16 wireless MAN (W-MAN) has been actively studied for mobile network applications. Using access devices certified by the WiFi or WiMAX Forum, which are industry forums for defining W-LAN, W-MAN inter operability, it is anticipated that very cost-effective mobile broadband access services will become possible, though it may have a best-effort communications quality. This means that the access systems could be complementary or competitive to the cellular mobile access systems which basically intend to provide guaranteed services to all subscribers. As these new broadband access techniques could introduce more competitive environment in mobile networking services, the government in Japan (the regulatory authorities at the Ministry of Internal Affairs and Communications) is promoting studies on recommendable access systems and frequency band assignment for their commercial applications at Wireless Broadband Promotion Study Committee which was called by the ministry in late 2005. Regarding the hot-spot W-LAN service deployment in Japan, there were more than 7000 access points in Japan as of early 2005. Thus, wireless Internet access is already possible in major cities in Japan. As W-LAN devices are already equipped in most of the newly sold laptop PCs, people are enjoying Internet access carrying their PCs in a nomadic environment. Furthermore, a cellular and W-LAN dual access mobile phone became available in Japan in late 2004. The dual phone can be used as an extension phone in an office using VoIP over W-LAN. It can, of course, be used as a public cell phone outside the office. A kind of Fixed Mobile Convergence (FMC) service can be provided using this terminal. With regards to W-MAN access technology, IEEE 802.16 was enhanced for application to the mobile environment. Its standardization was completed in late 2005 at the IEEE 802 Committee and specified as IEEE 802.16e. A IEEE 802.16e system has already been in field trial by some service providers in Japan. Other mobile broadband access techniques such as IEEE 802.20 and a new Personal Handyphone System (PHS) are also proposed by some operators in Japan as candidate wireless broadband systems. It is expected that some of these techniques


23

will be selected as public wireless broadband systems under regulated frequency band assignment. They will play an important role for enhancing Mobile Internet services competing with or collaborating with enhanced 3G access technology. 2.1.3.3. Core Network Evolution In the mobile network, IP (Internet Protocol), which is the basic technology for the Internet, has been actively introduced into its core transport systems. This is because IP-based technology would bring cost effectiveness and smooth inter-operability with the Internet for service sharing. For 3G networks and beyond, how to introduce IP technology fully into mobile networks has actively been studied at various research organizations. Requirements and architecture for All-IP mobile networking have also been studied for standardization at 3GPP and 3GPP2. It is expected that uniform IP technology will bring smooth connectivity among various wireless access networks and the core transport network. It is also anticipated that differences between the Internet and the mobile network from the technical point of view will become negligible when a mobility function is introduced into the Internet and IP routing is deployed in the mobile network. However, they would remain different networks from business and operational points of view, as far as the requirements to the networks remain different. At this moment, it seems that the requirements from mobile communications carriers and Internet Service Providers (ISPs) are still not assimilated. Under such circumstances, the Mobile Gateway, which resides between the Internet and the mobile network, plays a key role for partitioning the two networks by providing functions such as charging, address management, personal certification, and security firewalls for mobile network subscribers. The Next Generation Network (NGN) discussions are becoming very active in Japan as well following the ITU-T initiative to coordinate NGN standards studies. NGN deployment means to reconstruct conventional telephony networks with IP technology, affording broadband and ubiquitous networking capabilities as well as flexible service development on the network. It is anticipated that fixed mobile convergence (FMC) will begin by deploying NGN. In Japan, however, it is not yet clear what type of architecture will be adopted in the network when operators try to introduce NGN capabilities, since each operator may have a different strategy in expanding its mobile and fixed network businesses. 2.1.4. Protocols in Mobile Internet To accommodate the wireless environment for mobile access, there are special requirements for mobile systems. Requirements are, for example, transmission volume reduction to cope with low bit rates and the larger latency of radio networks, processing load reduction for low-performance mobile terminals, and mobility management for various mobile capabilities. To satisfy these requirements, some specific mobile protocols have been introduced in addition to existing protocols for the Internet. As for the lower-layer protocols such as network and transport protocols, protocol standards have been studied mainly at ITU-T, 3GPP and IETF. On the other hand, higher-layer functions such as application layer protocols had been mainly studied at the Wireless Application Protocol (WAP) Forum. The WAP Forum originally specified a set of protocols (WAP) optimized and to be used exclusively on digital cellular networks.

24


Since it was recognized, however, that the information on mobile networks and on the Internet should be compatible, a new set of WAP standards (WAP 2.0) was developed and published in 2001, which has commonality with protocols used on the Internet. On the 3G mobile networks in Japan, Internet-compatible protocols are used for the future evolution of the Mobile Internet. In the future, mobile networks and the Internet could converge into one network as IP-related network protocols with generalized mobility are introduced and common application protocols are used for every communication device such as PCs, mobile phones and other portable devices.

2.2. Services for the Mobile Internet in Japan 2.2.1. i-mode Services 2.2.1.1. i-mode History As the Japanese mobile phone market began to mature in the late 1990s NTT DoCoMo developed an innovative mobile Internet platform with the aim of promoting a further evolution in mobile communications. Since its launch in February 1999 the i-mode service has attracted 45 million subscribers up to early 2006. Also, there are currently more than 95,000 Internet sites providing a wide variety of content. The i-mode service encompasses a number of different services and a wide range of innovative technologies, some of which are unique to the i-mode platform. The figure 2-5 below shows when these services and technologies have been introduced together with overall growth of in the number of i-mode subscribers. The i-mode business model synchronizes all aspects of the value chain, ensuring that content, quality, wireless technologies and user experience all evolve at an optimal

Figure 2-5. Timeline of the i-mode service


25

pace. The billing system is streamlined with NTT DoCoMo collecting information access fees on behalf of i-Menu-listed content providers. The business model provides a “win-win” relationship between the all parties involved in i-mode services whilst providing incentives to continue to improve the quality of products and services connected with i-mode. This business model is illustrated in the Figure 2-6.

Figure 2-6. The i-mode business model

Although the i-mode service is most famous as a Japanese service, i-mode services are also offered by a number of mobile operators outside of Japan. Starting with Germany in 2002 i-mode services have been launched throughout In Europe, Asia, the Middle East and Oceania with each country offering its own unique content and terminals. Up to mid-2006 i-mode services have been launched by 14 mobile operators in 14 different countries. From its beginnings as a 2nd Generation (2G) service offered over the Japanese standard PDC (Personal Digital Cellular) mobile network, i-mode services have progressed to being offered over NTT DoCoMo’s 3rd Generation (3G) FOMA (Freedom of Mobile multimedia Access) network (based on the global Universal Mobile Telecommunications System or UMTS standard). Services offered outside of Japan are also available over 2G GPRS mobile networks. The details of these services and the differences between i-mode services over 2G and 3G mobile networks are provided in the following chapters. 2.2.1.2. i-mode Services (1) Basic i-mode Services (a) Browsing Service The i-mode service is based around an internet browsing service tailored to i-mode capable mobile phones. Using the dedicated ‘i-mode button’ the user activates the i-

26


mode browser which accesses the i-mode portal. The user is then presented with a series of menus that enable easy access to the wide variety of services provided including Entertainment (e.g. ring tones, wallpaper, karaoke, games), Information (e.g. news, weather), Database (e.g. market data, local area maps and guides), m-commerce (e.g. e-tailing, tickets) etc… After activating the browser the user is initially presented with a series of menus which are navigated to access the desired content or services. These menus are presented as text encoded as a subset of HTML (HyperText Mark-up Language http://www.nttdocomo.co.jp/service/imode/make/content/html/) or xHTML (eXtensible HyperText Mark-up Language - http://www.nttdocomo.co.jp/service/imode/make/ content/xhtml/). Additionally, dependent on the capabilities of the mobile phone, content can also be presented in the Macromedia Flash Lite® graphics format, a subset of the original Macromedia Flash® format designed specifically for use with mobile phones (http://www.nttdocomo.co.jp/ service/imode/make/content/flash/). For secure communications SSL (Secure Sockets Layer - http://www.nttdocomo. co.jp/service/imode/make/content/ssl/) is also supported for i-mode services such as mcommerce, mobile banking or on-line stock trading. (b) Messaging Services (i-mode mail) As well as the browsing service the ‘i-mode mail’ messaging service is also a fundamental part of the i-mode service. The i-mode mail service is based on internet email and therefore each i-mode user has an email address associated with their mobile phone. As this service is based on email it is possible to communicate not only with other Japanese mobile phone users but also PC email accounts as well. Although based on internet email there are a number of differences between imode and standard internet email. This primary difference is the delivery mechanism. Unlike standard internet email clients that have to contact the email server and request new messages to be delivered, each i-mode mail message is delivered to a user’s mobile phone in real-time using a push mechanism provided by NTT DoCoMo’s mobile network. This push mechanism is one of the main factors in the dramatic success of the i-mode mail service compared to other mobile email services. In addition to the unique delivery mechanism there are a number of decorative features unique to the i-mode service. Mobile phones supporting i-mode provide a number of unique symbols and pictorial characters. The ‘decomail service also enables personalized graphics and/or fonts to be created and incorporated into i-mode mail messages. Similar to internet email service i-mode mail is also capable of handling a number of different types of attachments such as pictures, movie clips and Adobe PDF documents (http://www.nttdocomo.co.jp/service/imode/make/content/pdf/). (2) Advanced i-mode Services (a) i-shot Service This service enables users to send still pictures taken with their phone’s camera to other Japanese mobile phones, as well as personal computers. The same address as for normal i-mode mail is used for sending i-shot messages. An overview of the i-shot service is provided in the figure 2-7 below. Due to the restricted bandwidth of 2G PDC mobile networks pictures sent to NTT DoCoMo’s PDC users are stored within the network and a URL is sent to the mobile


27

Send picture information Send picture

i-mode mobile phone (2G) Retrieve picture using URL Weblink (Web to function)

i-shot mobile phone i-shot centre

URL Weblink embedded in an email

i-mode mobile phone (3G FOMA) Send picture as an attachment

Internet

PC or non-NTT DoCoMo mobile phone

i-mode centre

Figure 2-7. The i-shot service

phone to. This URL can then be used to access the picture either manually via the imode browser or, in the case of pictures sent between 2G i-mode handsets, the picture is retrieved automatically from the server when the email is received. However, when sending pictures to 3G FOMA handsets and personal computers the picture is sent as an attachment. In some cases 3G FOMA users may not wish the picture to be delivered to their mobile phone. Hence, the option to receive the message in the same way as 2G mobile phones is also provided. When sent as attachments the pictures are handled in jpeg format. (b) i-area Service The i-area service is a location information service that provides quick and easy access to content specific to a user’s current location area. For example, it can enable a user to check the local weather forecast, or access traffic information as well as maps of the local area. The i-area service automatically selects and displays appropriate i-mode content for the local area based on the location of the mobile phone’s serving base stations. (3) 3G FOMA i-mode Services With the introduction of the FOMA 3G mobile network i-mode services have evolved to make use of the enhanced capabilities of this system. One of the main differences between 2G i-mode services and 3G i-mode services is the introduction of video-based services. High-speed packet communication of the 3G FOMA network enables video content such as movie information, news and sports highlights to be provided. This type of video content service is known as “i-motion”. Movie clips for i-motion are supported in both the MP4 and ASF file format (http://www.nttdocomo.co.jp/service/imode/make/content/imotion/). (a) i-motion mail The i-motion mail service is an enhancement of the original i-mode mail service. This enables users to send video mails up to a size of 500 Kbytes. Videos sent via imotion mail are first temporarily stored on a server. The i-motion mail messages are

28


Figure 2-8. The i-motion service

received in the form of regular emails containing an URL link that needs to be clicked by the user for the video to be downloaded and played. Based on the capabilities of the receiving mobile phone the size of the video clip may be altered. Also, when an imotion mail message is received by a mobile phone that does not support i-motion mail, videos are automatically converted to sequential still images and played in this format.

Figure 2-9. Sending a video from a mobile phone compatible with the i-motion

(b) i-channel This service distributes the latest news, weather forecasts, sports, entertainment and other information to compatible i-mode phones. The information is displayed on the


29

standby screen of the mobile phone without any special operation and users can access to more detailed information with a press of a button. This service distributes the latest news, weather forecasts, sports, entertainment and other information to compatible imode phones. The information is displayed on the standby screen of the mobile phone without any special operation and users can access to more detailed information with a press of a button.

Figure 2-10. The i-channel service overview

(c) PushTalk The PushTalk service allows phones to be used like walkie-talkies for simultaneous, one-way communication between a pre-defined group of users. These groups can either be pre-defined (e.g. an ‘office’ group for corporate users) or created ‘ad-hoc’ by the user when establishing a communication session. The service is operated by the caller pushing the Talk button to display a directory of other users. After selecting one or more people, the caller presses the Talk button again for immediate, simultaneous connection to the other users. The caller holds down the Talk button while speaking, then releases it to let someone else speak (while the Talk button is pressed, the speaker cannot hear others talk). One person can talk up to 30 seconds at a time. If nobody speaks for 30 seconds, the service is automatically disconnected. While connected, each user’s screen lists all participating members of the group and the current speaker. During communications an icon indicates the current status (“standing by,” “in meeting,” etc.) of each of the parties.

30


Figure 2-11. The Push Talk service overview

(d) One-seg Digital Television Broadcast Service The One-seg Digital Television Broadcast service is an example of a converged broadcast and communication service. One segment of the 6 Mhz frequency allocated to terrestrial digital broadcast frequencies is allocated for mobile devices such as mobile phone and laptop personal computers. Similar to digital television it is possible to broadcast data in addition to the television images. Whilst receiving the digital television broadcasts it is also possible to connect to the mobile network to use data services related to the television program being received. This is possible using a split screen function within the mobile phone to enable a portion to be used to display digital broadcast content and a different portion to be used for the mobile data service (e.g. imode browser service). 2.2.2. EZweb Services 2.2.2.1. Overview of EZweb The EZweb service is a mobile web browsing service provided by KDDI (au). The EZweb service started in 1999 in conjunction with the release of the cdmaOneTM system. In its early stages, EZweb provided hundreds of pages through KDDI (au) official sites. However, with the increasing demand for mobile content, the number of sites has been drastically increased. Now EZweb provides a wide variety of content, like music, movies, program downloading, shopping, books and comics, navigation and e-learning, etc. In 2003, KDDI (au) offered a flat rate packet service. Since then, users have been able to enjoy packet services at a lower cost. In 2006, KDDI (au) announced a tie-up with Google to provide sophisticated mobile information search services. From a technological point of view, EZweb was designed based on the WAP protocol suite. Since the standardization of the WAP protocol had not been completed when the EZweb service started, the HDML language specification proposed by Unwired Planet was originally used for EZweb by KDDI (au), instead. The objective


31

of WML (HDML) in the WAP protocol was to efficiently utilize limited mobile resources like communication bandwidth and processing capabilities, so accordingly the specifications differ from HTML in some points. To fill such gaps, KDDI (au) decided to deploy XHTML Basic (more precisely, XHTML Mobile Profile + CSS) which was specified by World Wide Web Consortium (W3C) in December, 2000 as a subset of XHTML. XHTML Basic evolved into WAP 2.0 by supporting WML features, which are now widely deployed in most KDDI (au) mobile terminals. For ensuring security, SSL communication between a WAP 2.0 mobile terminal and the server is supported. At the first stage, an SSL channel could be only established between a mobile terminal and EZ server (KDDI’s dedicated server for EZweb). Now SSL channels can be set up between mobile terminals and any arbitrary server. Specifications for SSL are shown in Table 2-1. Table 2-1. SSL specifications SSL version

SSL version 3.0

Secret Key Cryptosystem

RC4 (40 bit)

RC4 (128 bit)

Public Key Cryptosystem

RSA (512 bit)

RSA (1,024 bit)

Signature algorithm

MD5

SHA1

Root certificates㸨

VeriSign Class 3 Primary CA

RSA Secure Server CA

*Those root certificates are incorporated into both WAP2.0 mobile terminals and EZweb servers

2.2.2.2. Key EZWeb Services (1) Mail service Before the cdmaOneTM service was deployed, a short messaging service (C-mail) was used to send and receive text mail. In 1999, an IMAP4-based email service started with the launch of cdmaOneTM. In 2000, the capability was expanded with the name of “@MAIL” to support the saving of messages within the mobile terminal and the exchange of attached files. The maximum number of characters in a mail was 5000 (about 10 KB). Now the mail service can deal with attached files up to about 500 KB. The content of attached files supports “Photo Mail” (up to five photos taken with handsets can be attached to an email and sent), “Movie Mail” (handsets can record smooth movie clips up to 15 seconds in length and users can simply attach those movies to an email and send them to their friends) or “GPS Mail Service” (GPS location information can be attached to a mail). In parallel, the short messaging service “C-mail” is still supported to provide pushtype message delivery, in which a maximum of 50 characters can be exchanged between au mobile phones. So far, a lot of spam has been sent to mobile domains, which has raised a serious problem. To cope with this problem, KDDI (au) stopped forwarding mails from the Internet to C-mail, started checking the authenticity of the sender’s address and restricted the total number of mails per day from one account, etc., thus making every effort to suppress spam.

32


(2) Contents Downloading Services (a) Music Downloading Service Among the mobile multimedia services, perhaps the most popular service is the content downloading & listening service. One typical service is Ring Tone service “CHAKUUTA®”, which allows users to download songs as ring tones and alarm sounds on their mobile phones. The file format of “CHAKU-UTA®” conforms to the AMC format (MP3 supported) and its typical length is about 15 to 20 seconds. It started from December 2002. Later on, in order to enhance the sound quality and support stereo, the Advanced Audio Coding (AAC) codec was also deployed to the “CHAKU-UTA®” service and it conforms to the .3g2 format, which is the standard music format in 3GPP2. From November 2004, by deploying a further enhanced audio codec High Efficiency AAC (HE-AAC), the “CHAKU-UTA full®” service started, where users can download and play entire, full-length, high-quality songs. In 2006, KDDI launched the “au Listen Mobile Service” or “LISMO”, a music service suite that will allow au mobile phones and PCs to share music by encoding CDs at a PC site or by downloading music from the “DUOMUSIC STORE”. Exchange of music play lists among friends is also supported. The “Listen and search” service identifies the name of a song by analyzing part of a sampled music clip via the microphone of the mobile phone. It guides a user to music downloading portal sites once the name is identified. Recently, another downloading service “EZ Talk Collection” started. It provides programs of around 10 minutes in length, such as live talk shows or English conversation lessons. (b) Movie Downloading/broadcasting Service The new digital TV broadcast service for mobile phones, “one-seg”, started in Apr. 2006. The bandwidth of one regular broadcast digital channel has been divided into 13 parts and one segment (one-seg) of each channel in Japan is used exclusively for mobiles. Currently, there are seven TV channels available. Moreover, in parallel to the TV program, one-seg also provides data streams, such as program-associated information, news, traffic information, etc. Regarding movie content downloading and browsing services, au provides “EZ movie”, the “EZ channel” service and “Flash®” content. “EZ movie” allows the downloading of high-quality movie clips by mobile phone. The clip format conforms to the 3GPP2 and AMC format. Maximum clip file size is 1.5 MB, or about 3 minutes in length. Users can view either downloaded or streaming movies. QuickTime® supports the 3GPP2 format, so viewing or encoding of EZ movie content on a PC is possible. From a 1X WIN mobile terminal, KDDI (au) supports the 3GPP format in capturing video as well as the 3GPP2 format, ensuring interoperability with other carriers.

Figure 2-12. EZ movie protocol stack


33

EZ Channel is a program distribution service enabling users to enjoy a variety of multimedia-heavy content (3 Mbps or less). By selecting and reserving a program on EZweb, content that is updated on a daily or weekly basis will be delivered to users automatically at midnight or in the early morning, taking advantage of broadband 1X EV-DO access. The content delivered can be replayed until the next content arrives locally without any wireless access. EZ Channel has adopted SMIL technology to combine movies, animation, still images, sound and text data in a flexible manner. On the EZ Channel service, on-line books and comics are delivered in a proprietary format. Users can enjoy such content with dedicated browsers. Lastly, there is an amount of “Flash®” content available on EZweb. Users can view animation created in FlashLite1.1®, which is tailored for mobile devices. All the services described above have deployed content rights management mechanisms to prevent the fraudulent use of downloaded content. (3) Positional Information Service using GPS (Global Positioning System). Positional information is one of the important features of mobile phones. In 2001, the gpsOneTM service started, in which the user’s current location is measured by GPS and is shown on a map. It enables the capturing of GPS satellites in a very short time by obtaining rough information for capture from a server based on the location information of the base station. Once the mobile terminal obtains the location information from the GPS satellites, it sends the information to a server to resolve an accurate location. If sufficient GPS satellites are not captured, Advanced Forward Link Trilateration (AFLT) technology or AFLT and GPS hybrid technology may be used. In AFLT, the distance between a mobile terminal and base stations is estimated using the CDMA pilot spread sequence. Based on the GPS positional information, several location-based services are provided by KDDI (au). For example, the GPS-MAP service provides the location of target objects on a PC screen at the remote sites of corporate customers, in order to improve transport management, sales and marketing activities and the dispatch of maintenance personnel. From October 2003, an autonomous GPS measurement method was deployed. In this method, a mobile phone makes network access initially to get GPS information. Once the GPS satellites are captured and GPS measurement starts, then no further

Figure 2-13. Example of EZ navi walk guidance

34


network access is necessary. Using this method, a real-time navigation service for pedestrians, “EZ navi walk”, was launched in 2003. It gives navigation guidance to pedestrians by showing the path to a destination with the help of voice guidance and vibrations (Figure 2-13). The destination information may be input using QR codes. Recently, since there has been a number of crimes (e.g., kidnapping) involving small children in Japan, effective ICT countermeasures are urgently needed. Based on this requirement, the “Safe Navi” service was started to allow parents to track the location of their children using a mobile phone equipped with GPS. Location identification in an indoor environment without GPS is a challenge. Recently, the BluetoothTM tag was developed to identify locations through Bluetooth enabled mobile phones. EZweb services have been expanding with a number of new features. The following are examples of installed functions: (4) Emergency BBS Service To deal with emergency situations, au provides the emergency BBS service. A user can upload messages to the BBS and let his/her family members or friends know his/her current status in case of an emergency. (5) Hello Messenger “Hello Messenger” is a message sharing service which allows text, photos and voice to be communicated in real-time among friends. (6) Duogate “Duogate” is a PC portal site which offers a number of services for handling mobile oriented contents. It includes “DUOBLOG”, a consolidated mobile and PC blog service, “DUOSNAP”, a photo uploading service with GPS information and “DUOALBUM”, for filing and sorting photos taken by mobile phone. (7) D EZ Felica EZweb also supports Felica service. Since this is basically the same service as provided by NTT DoCoMo, please refer 2.2.3 (1) for further information. (8) Two Dimensional Codes (QR codes) Two dimensional codes are capable of storing a large volume of data, up to about 4000 characters, as they work in two directions, horizontally and vertically. Handsets equipped with the new EZ Appli (BREW®) can read the two dimensional codes, printed on magazines, business cards and other items, and activate a wide range of functions programmed into the codes, such as data entry into address directories, databases and internet access. 2.2.3. Public Mobile Internet Services 2.2.3.1. FeliCa Services FeliCa (Felicity-Card - http://www.sony.co.jp/Products/felica/index.html) is a contactless IC card technology suitable for a variety of applications such as electronic transactions (e-money), identity/membership cards, electronic ticketing, electronic keys for the home or office. Based on the ISO standards ISO/IEC 15408 and ISO/IEC IS 18092 with a high level of security this technology is being applied in several areas of Japanese society such as electronic money (‘Edy service’ - http://www.edy.jp/) and commuter travel passes (‘JR Suica service’ - http://www.jreast.co.jp/suica/). This tech-


35

nology is not limited purely to IC card applications and is also being applied in a variety of consumer electronics products, the most prominent example of which being mobile phones. The multiple applications of FeliCa technology are consolidated with traditional mobile phone functions so creating a single ‘lifestyle-support’ device for the user. The Felica chips are implemented within mobile phones and used by placing the phone within approximately 10 cm of the FeliCa card reader. A dedicated application on the mobile phone interacts with the FeliCa system to allow the user to manage and monitor their usage of the FeliCa services.

On line purchases using e-money credit

Use as a ATM cash card or credit card

Use as home/office entrance key, employee identification

Use as membership card for loyalty schemes, club membership card

Electronic wallet for use in convenience stores, vending machines

Use as commuter pass, airline/train tickets

Use as electronic tickets for concerts, movies, theme parks.

Figure 2-14. Overview of the FeliCa services for mobile phones

There are several FeliCa based services provided in Japan such as the ‘Osaifukeitai’ (http://www.nttdocomo.co.jp/service/osaifu/index.html) offered by NTT DoCoMo and the EzFeliCa service offered by Au (http://www.au.kddi.com/ezweb/ service/ez_felica/). Further enhancements to these services are also available that enable the mobile phone FeliCa services to be combined other non-mobile phone based FeliCa services such as the JR Suica service and credit card services. Specific examples of these services include the ‘Mobile Suica’ service offered by JR East (http://www.jreast.co.jp/mobilesuica/faq/index.html) and the iD service offered by NTT DoCoMo (http://www.nttdocomo.co.jp/service/osaifu/id/index.html). 2.2.3.2. QR Code Services QR code (http://www.qrcode.com/) is evolution of bar codes from one to two dimensions. The QR code variety of 2 dimensional bar codes (also known as a matrix code) has become particularly prevalent within Japan. With its increased data capacity it is particularly suited to encoding information in the Japanese language because it is able to encode a greater number of Kanji characters than traditional bar codes. QR code is both an International ISO (ISO/IEC18004) and Japanese JIS (JIS-X0510) standard and has found a wide variety of applications in the mobile communi-

36


cations services. Mobile phones in Japan are able to both read these codes using the inbuilt camera to capture information such as the contact details on a business card or product information from a poster advertisement. Mobile phones are also able to generate QR codes to be read by other mobile phones or an external reader. One particularly novel application of QR codes is the Cmode service offered by NTT DoCoMo. The Cmode service combines i-mode mobile phones with mobile communication enabled vending machines. This is a points based m-commerce service. These points are obtained and used via the Cmode website or compatible vending machines. Local communication between the i-mode mobile phone and the vending machine is enabled using QR code images which are downloaded to i-mode mobile phones and read by the vending machine’s optical reader. The services provided by Cmode include: ticket sales, pay-per-download content (e.g. mobile phone wallpaper/ screen savers, ring tones), i-appli (Java) games, local area information etc...

Figure 2-15. The C-mode service using QR-code

2.2.3.3. Disaster Message Board Service Japan is one of the world’s most earthquake prone countries and is also prone to yearly typhoons and other natural disasters. Therefore, Japan has a substantial disaster management infrastructure including the Japan’s mobile internet services. NTT DoCoMo provides a disaster message board service to enable those residents in Japan during a natural disaster to keep in touch with friends and family. This service is provided in both Japanese and English with an extra option provided in the i-mode menu when a disaster or emergency situation occurs. Using this menu it is possible for a user to register their status. Friends and family can use the user’s phone number to check their status. Additionally, it is possible to send an email automatically notifying other (pre-registered) users.


37

Figure 2-16. Disaster Message Board service

2.2.4. Introducing Java Platform In addition to browsing services the use of Java® based mobile phone applications (also known as ‘applets’) has been prevalent in Japan since mid-2000. Although based around the same core J2ME CLDC (Java 2 Micro Edition Connected limited Device Configuration) platform developed by Sun Microsystems® and the use of http-based communication between mobile handset application and the server (for downloading the applets and interactions between the mobile phone applet and the server), there are some variations on the precise implementations of the application architecture for each of the services. Two prominent examples of Java Platform based services provided in Japan are the i-appli service provided by NTT DoCoMo and the EZplus Java service provided by Au. In general the Java service architecture is based on a client-server configuration similar to that for basic browsing services. An example for the i-appli service is shown in the figure below.

38


Figure 2-17. The i-appli service basic architecture

The applets are downloaded by the mobile phone in the Java execution environment for the particular service and after downloading the applets are run locally on the user’s mobile phone. Interaction with the network is undertaken to enable the applet to update its content or interact with a content server but it is also possible to utillise these applets without connecting to the mobile network. Some of the functionalities provided by Java platform based services include automatic stock, weather and transport information updates, mobile games as well as applications dedicated to mobile phone functions such as FeliCa based services (e.g. for e-wallet balance checking) described above. Java Platform based services have evolved as the popularity and diversity of the services has increased and the capabilities of mobile phones and mobile networks have improved. As a result several versions of the Java profiles used for these services have been developed. The NTT DoCoMo i-appli service Do-Ja (DoCoMo-Java) profile has four different versions (versions 1.x to 4.x - http://www.nttdocomo.co.jp/service/ imode/make/content/iappli/index.html) and the Au EZplus Java service has been developed in 3 phases. The more recent versions of the Java services enable the Java applets to interact with other mobile phone functions such as: Address book, call/mail history, camera, music player, FeliCa IC card. The size of applets that can be supported has also increased from an original 10 kB to 200 kB.

2.3. 2nd Generation Cellular Networks (PDC-P) 2.3.1. Technologies for PDC-P 2.3.1.1. Target of PDC-P In the 1990s, the deployment of the Internet, together with a rapidly increasing number of mobile subscribers, were laying the foundation for mobile computing. Taking this situation into consideration, a Japanese leading standard body the Telecommunication Technology Committee (TTC) in collaboration with major mobile operators and network vendors has established a fundamental standard for a mobile packet communications system, JJ-70.20, the “PDC Digital Mobile Communications Network InterNode Interface (DMNI) Signaling Method of Mobile Packet Communications System.” This standard includes two basic signaling methods: Packet Mobile Application Part


39

(PMAP) mobility and Mobile IP (application of IETF RFC2002 to a mobile packet communications). In March 1997, to create an environment that meets rapidly-growing demands from data communications, NTT DoCoMo launched commercial services over its developed packet mobile communications system based on PMAP mobility, or PDC-P, by incorporating packet switching functions into the second-generation circuit switching system PDC. The PDC-P based on PMAP mobility has achieved significant improvement in the use efficiency of radio frequencies by applying packet switching technologies, which does not occupy communication channels during periods of time when data is not being sent or received. Furthermore, an advantage of a communications channel not dedicated by a specific user allows volume billing according to the amount of transferred data rather than time spent connected. The result is that mobile users benefit from inexpensive services. 2.3.1.2. Key Technologies (1)Wireless Throughput Enhancement In the circuit switching system PDC, one mobile station is assigned a single slot of the three-channel TDMA. In PDC-P, a packet communication channel was newly defined based on the RCR-27 series of Association of Radio Industries and Businesses (ARIB) standards, which can be shared by multiple mobile stations in a random access manner. Also, PDC-P allows simultaneous access to all slots of the three-channel TDMA. For this reason, PDC-P has achieved the maximum speed of wireless transmission of 28.8 kbps. (2) Mobility Support In the event that a mobile station moves to an another zone and the quality of a packet communication channel deteriorates, the PDC-P network has the capability of switching to a packet communications channel of better quality in order to retain the connection. (3) Voice and Data Converged Service Provisioning A mobile station supports both voice and packet communications services. This enables mobile users to make use of the circuit switching system PDC and packet switching system PDC-P as needed. Also, PDC-P supports dual standby for voice and packet arrival as well as incoming voice call during packet communications for service selection flexibility. (4) Internet Access Control The tunneling protocol enables terminals to unconsciously gain access to Internet Service Providers(ISPs), and an Intranet via a mobile phone. IP addresses for data terminals are determined by the ISP or the Intranet, and the PDC-P network handles both static and dynamic assignment. PDC-P makes use of PMAP as a tunneling protocol using the Mobile Subscriber Number (MSN) that is assigned to each subscriber of the cellular network as a static connecting address. PMAP provides mapping of a MSN and the assigned IP address at each terminal. In PDC-P, terminals assigned a static IP address can receive incoming packets to the address from the Internet, while terminals with a dynamically-assigned IP address can receive incoming packets to the Mobile Subscriber Number (MSN) from the Internet.

40


2.3.1.3. Network Configuration (1) PDC-P Network Architecture The PDC-P network architecture is shown in Figure 2-18. The packet switching system PDC-P consists of two types of switching centers, Gateway Packet Mobileservices Switching Center (GPMSC) and Visitor Packet Mobile-services Switching Center (VPMSC). One of the distinguishing features of the architecture is cost reduction in CAPEX and OPEX achieved by sharing some elements with the circuit switching system PDC: the Home Location Register (HLR), and the Base Station (BS) and an inter-center transmission line. In the case of packet termination to a mobile station, a paging procedure is conducted by a Visitor Mobile-services Switching Center, (VMSC) in the PDC network.

Figure 2-18. PDC-P Network Architecture

(2) Concept of Virtual Sub-Networks Every ISP and Intranet connected to the PDC-P network has its own Network Identity (NID) assigned by the PDC-P network. By holding and distinguishing NID information that users are allowed to access, the PDC-P network provides suitable environments for a virtual sub-network. While the PDC-P network is a single physical network, it logically consists of multiple virtual sub-networks, where the ISP and the Intranet can take advantage of local IP address assignment and a high level of security.

Figure 2-19. Virtual Sub-Networks


41

Furthermore, PDC-P allows both closed network services where mobile stations can access only a single virtual sub-network and open network services where mobile stations can select a virtual sub-network to be connected every time they initiate communications. (3) PDC-P Protocol Stack Figure 2-20 shows the PDC-P protocol stack. PMAP was developed as an enhancement of TCAP and MAP defined for PDC. PMAP has a function of transferring endto-end data, including user packets. Furthermore, PMAP Transfer Capabilities Application Part(PTP) was newly specified to make use of PMAP as a transfer protocol over a commonly-used protocol TCP/IP. These protocols were defined as TTC standards, JJ-70.20 “PDC Digital Mobile Communications Network Inter-Node Interface (DMNI) Signaling Method of Mobile Packet Communications System.”

Figure 2-20. PDC-P Protocol Stack

2.3.2 i-mode Enabled System (PDC-P Application) 2.3.2.1. Target of i-mode NTT DoCoMo launched i-mode in February 1999 as a newly innovative service of mobile computing, enabling Internet access and email communications with a mobile phone. i-mode was developed based on the PDC-P network, which handles burst traffic in an efficient manner. Distinctive services, Internet access and i-mode email, are carried out based on two types of site connection services, information acquisition by mobile station request as a “Pull-type” service, and information distribution to a mobile station as a “Push-type” service. Pull-type services are driven by a packet origination sequence, while Push-type services are initiated by a packet termination sequence. Since TCP/IP, which has significant overhead, is not an appropriate data transfer protocol for a relatively small amount of data, such as text-centered information via email, Transport Layer Protocol (TLP) was newly developed. Also, there were widely used standards adopted for i-mode, such as HTTP as an application level protocol and HTML as a markup language. This makes content creation even easier, encouraging a great number of content providers to get into the market. The result was a significant expansion of the Mobile Internet market.

42


2.3.2.2. Key Technologies (1) Data Transmission Protocol TLP simplifies negotiation procedures and makes it possible to transmit control signals and user data at the same time, leading to efficient data transmission with small amounts of signals. While the TLP data transmission protocol designed for i-mode is terminated at a mobile station and the Mobile Gateway, TCP/IP, a protocol widely utilized on the Internet is applied in order to connect the PDC-P network to content servers. The Mobile Gateway converts both protocols interactively. (2) Service Enhancement The i-mode service allows information transfer between a mobile station and a content server over the commonly-used protocol HTTP. Furthermore, User Information Transfer Protocol (UITP) and Network Management Protocol (NWMP) were newly defined to provide i-mode-specific services and maintenance functionalities. These include notification of message termination to a mobile station, notification of packet communications initiation or termination to the Service Gateway, and notification of data delivery confirmation to the Service Gateway. 2.3.2.3. Network Configuration (1) i-mode Network Architecture Figure 2-21 describes an i-mode network architecture. The PDC-P network is fully applied to offer i-mode service, which consists of packet gateways, GPMSC, and Mobile Gateway. Mobile Gateway is composed of a Service Gateway and a Network Gateway Network Gateway terminates a TPL connection established by a mobile station and a TCP/IP connection set up by a Service Gateway, and connect them mutually; Service Gateway connects the PDC-P network to the Internet and provides functionalities for information delivery, email transaction, email storage, user and CP information management, and traffic billing.

Figure 2-21. Network Architecture for i-mode


43

(2) i-mode Protocol Stack The protocol stack for i-mode is shown in Figure 2-22. While the PDC-P protocol stack, shown in Figure 2-20, applies PPP as a data-link layer protocol over the PDC-P network, the i-mode protocol stack is simplified in order to achieve efficient communications by applying TLP, which functions as a transport layer protocol over the PDC-P network. Pull-type services and Push-type services are provided by applying HTTP over TLP to i-mode. Furthermore, i-mode-specific services and maintenance functions are put into services by applying newly-designed protocols, UITP/NWMP, which are terminated at the Network Gateway and the Service Gateway. SSL (Secure Sockets Layer) is used to ensure end-to-end security for i-mode.

Figure 2-22. i-mode Protocol Stack

2.4. 3rd Generation Cellular Networks 2.4.1. W-CDMA/HSDPA + GPRS CN 2.4.1.1. 3G Component Technology (1) Motivation and Background for 3G Introduction Since 1G and 2G cellular systems are based on different specifications in different countries, or different specifications are used even in one country or region, it was not possible to use one cellular phone in the entire world. The ITU therefore aimed to realize a global standard cellular system in the 3rd-generation (3G). This standard is called IMT-2000. Besides the standardization, IMT-2000 defined very high capability requirements compared with existing generations. For example, the required data transmission rate was 144 kbps even in fast travel conditions and up to 2 Mbps in stationary conditions. These requirements even exceeded the capacity of fixed lines at that time. NTT DoCoMo was one of the most active operators in the world for 3G realization. NTT DoCoMo has started 3G research and development ahead other vendors and operators, and succeeded in the launch of the world’s first 3G service named “FOMA (Freedom Of Mobile multimedia Access)” in October 2001. This 3G realization was a highly important event for the Internet history of the world, not only in Japan, and it dramatically increased the possibility of a mobile Internet. Though one of the reasons for NTT DoCoMo’s positive stance for 3G was that 2G’s capacity had

44


become heavily crowded because of the rapid increase of subscribers, the most important motive was that the company thought 3G had the potential to expand the capacity and possibilities of mobile services such as i-mode. At that time when the cellular phone was a tool only for voice communications in other countries, in Japan, the cellular phone was approaching the advent of a multimedia device, and an infrastructure that could maximize this potential was required. The first realization of true mobile multimedia was achieved by the FOMA service. The most distinctive difference between 2G and 3G is the data transmission rate. 3G’s high transmission rate has enhanced the variety and wealth of application services on the mobile platform. NTT DoCoMo’s i-mode initially started on the 2G platform, and offered only email and light browsing services. At the same time when 3G FOMA service was launched, i-mode was also launched on the 3G platform and provided various services which made the most of 3G’s capacity. In 3G i-mode, Web content became much more expressive (for example, mobile Flash and PDF technology), and enabled the transmission of much larger pictures, movies, music files, and more advanced game applications. The high capacity of 3G also made it possible to levy a flat charge for i-mode, an event that should make a special mention for the Mobile Internet of Japan. A description of each i-mode service is provided in the following section. IMT2000 technologies are introduced in this section. The first of them, IMT-2000 all network architecture is illustrated below.

Figure 2-23. IMT-2000 network architecture


45

(2) Main Technologies (a) W-CDMA Radio Technology As mentioned before, NTT DoCoMo was the first in the world to start 3G service, and then adopted W-CDMA radio technology standardized in 3GPP on the 2GHz radio frequency band assigned for IMT-2000. J-Phone (now SoftBank) started its 3G service on December 2002 with the same W-CDMA technology. In Europe, 3G with W-CDMA technology has been in service from 2003, and now in 2006, it is used in over 20 countries. Hereafter, W-CDMA 3G service will expand to most of the European, North American and Asian countries.

IMT-2000 IMT-2000 CDMA Digital Spread Mobile (W-CDMA, UTRA FDD) radio interface IMT-2000 CDMA Multi-Carrier (cdma2000) IMT-2000 CDMA TDD (UTRA TDD) IMT-2000 Single Carrier (UWC-136) IMT-2000 FDMA/TDMA (DECT)

Note: Names in “()”s are represented as general terms

W-CDMA specification Access mode DS-CDMA Duplex mode FDD Band width 5MHz Chip rate 3.84 Mcps Carrier interval 200 kHz Data speed - 2 Mbps Encode AMR(1.95 k - 12.2 kbps) Frame length 10, 20, 40, 80 msec Error-correcting code Turbo code,

Data modulation

Convolution code Downlink QPSK,

Spread modulation

Uplink BPSK Downlink QPSK,

Diffusivity ratio Base station synchronization

Uplink HPSK 4 - 512 Asynchronous (or synchronous) control

Figure 2-24. IMT-2000 family relations and Key specs of W-CDMA

46


3GPP investigates the evolution of the W-CDMA specification, and High Speed Downlink Packet Access (HSDPA) technology was established in Release 5. HSDPA is the technology that achieves up to 14 Mbps downlink speed by improving radio transmission efficiency, and NTT DoCoMo introduced this technology in mid 2006. (b) ATM At the beginning of the 3GPP release, the core network signaling system was based on the GSM/GPRS system, which is the mainstream system in Europe, and its enhancement to meet the requirements of new functions and capacity for IMT-2000. Circuit switching and packet switching functions were defined separately in the early core network, and it was defined that the bearer used in the core network was ATM or STM, and used in the radio access was ATM. NTT DoCoMo adopted ATM as the core network capability and developed a CS/PS combined switching system, although they were defined separately in 3GPP. It offers data transmission efficiency with the statistical multiplexing of voice and packet data. It also offers a high level of interaction between CS and PS domains effective in CS/PS interactive service processing such as location management and incoming call processing. (c) Multi Access While it is possible to use packet data service and voice service alternately in 2G network, it is not possible to handle both services simultaneously. NTT DoCoMo’s 3G system enables multi-access of both CS and PS services. This technology is applicable in various services, such as continuous data download during a voice call, and it also contributes considerably to real improvements in usability. (d) Preservation It is common for both mobile and fixed terminals to establish connections by dialing up

Figure 2-25. Preservation technology on layer model


47

to an access point. The always-on connection, however, became a standard for the fixed terminal users, due to the spread of ADSL and other broadband technologies in recent years, and this has led to improved user convenience, such as of the elimination of waiting time during dial-up and a reduction in procedures. In the mobile environment, on the other hand, always-on connections are not realistic from the viewpoint of radio resources. NTT DoCoMo thus offers a technology called ‘Preservation’. In this technology, connectivity resources (i.e., sessions in all layers) over the wired sections in the network and the upper layer sessions over the radio sections are maintained during a service, and only physical radio resources are released while there is no data transferred. It improves the efficiency in radio resource utilization and enhances service usability by shortening waiting time for reconnection. (3) Network Control (a) Network Configuration and its Evolution NTT DoCoMo introduced these basic technologies in its initial service as described above: W-CDMA for radio technology and ATM for core network capability. To achieve network implementation enabling prompt and effective 3G service provision, NTT DoCoMo adopted ATM multiplex transport using CS/PS integrated nodes. Since the bandwidth for data traffic demand was relatively insignificant and the major traffic was for voice calls at that time, NTT DoCoMo adopted the basic concept of “multiplexing PS network over a CS network” for network implementation. However, the bandwidth required for PS service made rapid progress and eventually exceeded the bandwidth required for CS service due to the gain in popularity of 3G service, advanced functionality of the handsets, and various broadband services tuned for 3G capability. Facing this situation NTT DoCoMo introduced the physically-separated CS and PS controlling nodes and an IP-based PS network as the next evolved network structure. This “PS-separation” enabled the low-cost, highcapacity PS network as a flexible measure for rapidly increasing PS traffic, and it became the basis for the provision of further advanced IP services. It also enables the evolution of Mobile Internet services based on the IP Multimedia Subsystem (IMS) technology. The evolution of the 3G infrastructure with IMS technology will be described in detail below. (b) Packet Switching and Routing The packet transmission system in IMT-2000 is based on the General Packet Radio Service (GPRS) system of the 2G mobile communications network and is functionally extended to match the characteristics of a broadband 3G mobile communications network. The tunneling technology as the basic control mechanism for mobile packet switched communications is outlined in this section. In the world of mobile communications, data transmission is not possible just with the simple IP address to identify a certain terminal, since mobile terminals move freely in the mobile communications network and its IP address changes accordingly. Hence the tunneling technology using additional addresses other than destination IP addresses is adopted in mobile communications. GPRS Tunneling Protocol (GTP) is defined as the tunneling protocol in GPRS networking. This tunneling protocol makes it possible to establish a logical connection (tunnel) for transport between Gateway GPRS Support Node (GGSN) and Serving GPRS Support Node (SGSN) with served terminals beforehand, and GGSN can send data packets received from an external network to this logical connection. When the termi-

48


nal moves to another area and is served by another SGSN, the logical connection is restablished between the new SGSN and GGSN.

Figure 2-26. Packet routing and tunnel management

(c) Session Management The Access Point Name (APN) is used to access an external network in the mobile originating session activation procedure in the PS domain. A handset puts an APN in a message for access to an external network. Domain Name Server (DNS), whose address resolution function is commonly used on the Internet, translates the APN to an IP address. If the handset has no signaling connection, it first sets up the connection. The handset then performs the authentication procedure via SGSN. If the handset is successfully authenticated, it sends a message for mobile originating with APN and QoS parameters. The SGSN receives the message and verifies if access to the APN and the QoS class is authorized by confirming information of the user profile. The SGSN concurrently translates the APN to the IP address of the GGSN and sets up GTP tunnel. The GGSN allocates the IP address to the handset and sends it to the SGSN with the acknowledgment message in the GTP tunneling setup procedure. The SGSN responds an acknowledgment message to the handset. When the handset receives the message, packet data transfer over the path between the handset and the GGSN becomes possible. In the mobile terminating session activation procedure, there are two cases. One is the condition in which an IP address is already allocated. In this condition, when the GGSN receives the IP address from an external network, the GGSN translates the IMSI corresponding to the IP address to the Home Location Register (HLR) address and then asks for the SGSN address under which the UE is camped. The GGSN sends the mobile terminating message to the SGSN. The SGSN then broadcasts a paging message to the UE. In the other case, no IP address is allocated. In this condition, the


49

GGSN uses the Mobile Station international ISDN number (MSISDN) to ask for the SGSN address under which the UE is camped and performs the same procedure as in the former case. In both conditions, the UE subsequently performs the mobile originating session activation procedure. (d) Network Gateway (NW-GW) Function In the packet switching system, NW-GW functions as interworking equipment between GGSN and Service Gateway (Service-GW). The mobile network and the Internet have different line traffic characteristics and service control methods. Particularly in a 3G system, the inter-conversion and inter-connection functions of gateway equipment have greater importance in boosting line throughput and providing more diverse services. 3G radio systems are characterized by wide bandwidth and a high data rate. If TCP is used for the transport protocol, the efficiency of radio resources declines and the network fails to maintain sufficient service quality. To address this problem, WTCP tuned for a 3G network was developed for the UE and NW-GW. Data transfer between the UE and NW-GW uses W-TCP, and between the NW-GW and ServiceGW it uses TCP. The NW-GW provides a protocol conversion function. The information delivery push system developed in 2G was followed in 3G. This service is provided by a linkage with the NW-GW, Service-GW, and Core-NW. The Service-GW sends a notification message to the NW-GW when a network pushes information to the UE. After the NW-GW checks to see if the UE is already connected or not, and if there is no connection, it sends a notification message to GGSN. After the UE connection is complete, the NW-GW sends a notification message to the UE and the UE performs follow-on actions in accordance with the message received (i.e. to get an email). The NW-GW then provides a billing control function. The NW-GW counts user packets and sends information to the billing system. NW-GW also provides the reverse billing function (operator charges to the content provider for user communication fee). It distinguishes and selects the charge target (i.e. charge to the content provider or the user) for each data packet based on the charging information from the Service-GW. The NW-GW then sends count data and billing information to the billing system. (e) Protocol Stack The following figure illustrates the i-mode browsing protocol stack as an example of a

Figure 2-27. Protocol stack on 3G system

50


packet switching service. User packets are encapsulated by the GTP within the core network, and the GW equipment terminates the TCP layer and transfers it to the WTCP. 2.4.1.2. Evolution of Mobile Internet with 3G (1) Roaming Overview The roaming service is a service that enables users to use their mobile phone even when they are outside the home operator network. The W-CDMA 3G network employs the enhanced core network of GSM that has been adopted in over 400 European and Asian operators. The W-CDMA network can therefore offer global roaming with the GSM network as well as the W-CDMA network. The roaming function enables users to use i-mode browsing or email services in foreign countries just as they do in their home country. (2) Outline of Roaming Session Control When a user connects to the i-mode service, the UE indicates the i-mode APN in the connection setup message. In the event of roaming out, the visited SGSN performs the “APN selection” process based on the subscriber’s profile obtained by the attach procedure (e.g. registration to the visited cellular network). As a result of the APN selection, the visited SGSN decides to connect to the subscriber’s home network, obtains the home GGSN IP address with DNS query, and sends a tunnel establish request to the home GGSN. The i-mode connection is then established via the home GGSN, enabling the notification of the roaming connection to the i-mode APN and the delivery of the specific content for roaming users.

Figure 2-28. Roaming session control

(3) Realization of VoIP Service by IMS IMS is now in the process of being introduced in mobile networks as an essential element for supporting future mobile multimedia services. NTT DoCoMo has supported IMS due to its high affinity with the Internet services, and the infrastructure makes it possible to provide advanced Internet services over mobile networks more quickly, easily, and cost effectively.


51

IMS architecture is based on IP technology (for example, on the GPRS network). Its basic system consists of Home Subscriber Server (HSS) which manages subscriber profiles and Call Session and Control Function (CSCF) which supports Session Initiation Protocol (SIP) call control. Application Server (AS) supports IMS application services, and the services are executed by CSCF’s SIP call control following AS’s indication. SIP is standardized technology popularly used on the Internet. Its introduction has two merits: easy support for Internet services and smooth inter-operability of IP services with other IP networks. IMS’s architecture can also be easily introduced to mobile networks due to its independence from radio access control technology and its lighter impact on existing mobile networks for separation service control from call control.

Figure 2-29. Functional entities of IMS and network architecture

(4) Push-To-Talk over Cellular (PoC) PoC is an example of a service using IMS technology. The infrastructure of PoC Service consists of CSCF, HSS, MRFC which provides PoC floor control functionality, MRFP which provides packet duplication functionality, and AS which provides PoC Group management functionality. TCP/IP and UDP/IP are used for the base protocol of PoC application protocols. SIP as a controlling protocol, RTP as a media transferring protocol and RTCP as a PoC floor control protocol have been adopted for half-duplex communications. In the IMS, SIP URI is used for user identification. When a PoC session initiator enters the phone number of an invited PoC user at their terminal, the PoC terminal of the originating side converts the number to SIP URI. Then, after the initiator dials, the PoC terminal of the originating side creates a packet bearer session. After session setup, the PoC terminal of the originating side executes an authentication and registers itself to the IMS network using the SIP REGISTER method. The SIP control becomes possible between the terminal and the network at this stage, and the terminal transmits the SIP INVITE method that includes the invited party’s SIP URI to the network. The CSCF that receives the INVITE method distributes the INVITE message to the AS and the MRFC based on information downloaded from HSS beforehand. AS performs

52


service authentication when it receives the INVITE method and MRFC reproduces the speech packet. In order to create a PoC connection, the PoC terminal of the terminating side needs to register to the IMS network. The CSCF retrieves the registration status of the terminating PoC terminal from HSS. When the PoC terminal of the terminating side has not been registered in the IMS network, by sending a SMS Push message to the terminal, the CSCF presses the establishment of the packet bearer session and the registration to the IMS network. As a result, it is possible to change the status of the PoC terminal of the terminating side even from idle status (non-registered to the IMS) to the status in which sending and receiving of SIP messages is possible. The PoC terminal of the terminating side receives the INVITE method when registered in the IMS network, and the invited PoC user receives the PoC call.

Figure 2-30. PoC service signaling flow

(5) Location Information (Customer Control) A mobile network provides mobility support to its users. Therefore a service to provide user location is in high demand. When a location information service is provided, the service is processed through the following steps: (1) location information request, (2) location search, and (3) location notification. The location services are categorized in two types: one is when the requesting and searched user is the same, the other is when a requesting user and a searched user are different. Currently, a new location service has been launched with the objective to check the safety of a searched user. In NTT DoCoMo’s case, it provides a location service that uses GPS to check the safety of children. Parents can check the location of their


53

children whenever they wish. In this service, parents send requests via the Internet. The requests received from the Internet are transferred to the children’s cellular phones via the mobile network. The results of the GPS measurement are sent back to parents via the Internet and the mobile network. In addition to the service above, location information can be sent to a Public Safety Answering Point (PSAP) when an emergency call is initiated from a 3G UE. PSAP is an agency that is responsible for answering emergency calls for emergency assistance from police, fire, and ambulance services.

Figure 2-31. Customer control service signaling procedures

2.4.1.3. The Realization of the Secure & Safety Mobile Network for Infrastructure (1) Background Due to the expansion and development of the Mobile Internet, the cellular phone has become a fundamental tool for Internet access (for collecting and distributing information). The cellular phone has evolved from a communications device to an information device, and is recently being seen as a lifeline tool. The Internet access function installed in a cellular phone is considered not as a supplementary service but a fundamental infrastructure. The “Internet access environment anywhere, anytime” which was once seen as a dream, is almost a normal environment in Japan. This network realizes not only high speed and large capacity but intelligent network control as well. A general traffic control policy to support lifeline networks is described in the next section. (2) Traffic Control Traffic control is a function that maximizes the capacity of a network by controlling the data flow on cellular-based mobile communication networks. With the limited availability of resources in an air interface, a certain level of traffic control is also required to maintain service quality for users. Adequate traffic control is thus considered important for the capacity control as well as the quality of communication for each

54


user. On a 2G mobile communications network, the volume of data transmission was not high and type of data that the traffic control needed was mainly voice services. Recently, however, multimedia and multi-purpose wireless access services have been increasing remarkably. More accurate traffic control models which allow efficient network utilization are therefore expected. The examples of the needs for traffic control is as follows: a) Congestion control at a special event It has been a Japanese custom in cellular-based mobile communications where many users use their cellular phones for New Year’s greetings, resulting in almost ten times the normal level of traffic for a few hours. Without appropriate traffic control in such situations, the networks suffer serious data congestion which may cause delays in service, or more crucially, it may lead to a system shutdown. Traffic control is necessary for faster recovery from such disastrous situations. Demand for data communications has also been high in recent years. Even the custom of New Year’s greetings has been shifting from voice communications to email. Thus, not only the function capable of handling voice traffic but also the functions that controls multimedia traffic are needed more quickly and seamlessly. b) Emergency call control Traffic control plays a very important role in emergency communication services as well. In the case of a serious disaster, traffic volume is expected to increase rapidly as cellular-based mobile communications may become the only tool for life-saving communications. Traffic control is expected to perform not only for normal data flows but also for reservation of resources for emergency calls. To provide effective telecommunications in any situation, NTT DoCoMo has launched a network system that embraces the concept of resource reservation and prioritization of calls, and has been working at 3GPP standardization provide a function to control voice traffic and data traffic independently. Such standardization would ensure success in placing emergency calls by providing accurate and specific traffic control, and maximize the capability of networks to provide effective telecommunication services.

Figure 2-32. Effective communication services with traffic control


55

2.4.2. CDMA2000 / HRPD System (KDDI(au)) 2.4.2.1. CDMA2000 and its Evolution “CDMA2000” is one of the IMT-2000 Radio Transmission Technologies registered at ITU-R in 1999 and is an evolution of the second generation cellular technology “cdmaOne”. “CDMA2000” is also called “Multi Carrier-CDMA (MC-CDMA)”. CDMA2000/ MC-CDMA with one carrier is called “CDMA2000 1X”. CDMA2000 1X has full backward compatibility with “cdmaOne”. Subsequently, “1xEV-DO (= HRPD)” and “1xEV-DV” have been standardized as an evolution of CDMA2000 1X in 3GPP2. 1xEV-DV supporting both data and voice is fully backward compatible with 1X, while 1xEV-DO is not fully compatible because its design is dedicated to and optimized for packet data transmission. KDDI (au) launched cdmaOne, offering up to 64 kbps, as a second generation commercial cellular system in 1998. It subsequently upgraded to CDMA 2000 1X, offering up to 144 kbps as an IMT-2000 system in 2002. In those days, high-speed internet services using ADSL was already popular in the fixed market, while emerging mobile internet services such as “i-mode” and “Ezweb” were becoming popular in the mobile market. Especially after 3rd generation cellular systems were introduced, the demand for high-speed data communication at a reasonable price has drastically increased in the mobile market. According to the mobile market demand above, in 2003 KDDI (au) launched 1xEV-DO offering up to 2.4 Mbps, which is the first all-IP based cellular system in Japan, in order to provide high-speed mobile internet services at a reasonable price. Furthermore, KDDI (au) is going to upgrade 1xEV-DO to 1xEV-DO Revision-A which is capable of QoS and high-speed uplink transmission. It is expected 1xEV-DO Revision-A will offer multimedia services, from VoIP to rich contents delivery services like VoD. 2.4.2.2. Introducing a Mobile Application Platform (EZplus and BREW®) (1) JAVATM (EZplus) Mobile application platforms have made significant progress. In 2001, KDDI (au) released the JAVATM based mobile application platform “EZplus”. The platform consisted of the JAVATM execution platform Kilobyte Virtual Machine (KVM) and a J2ME Connected, Limited Device Configuration (CLDC), which was designed for

Figure 2-33. EZ plus protocol stack

56


embedded devices and developed by Sun Microsystems. Mobile Information Device Profile (MIDP) and KDDI (au) specific profiles were placed on the platform. The specific profiles include retrieval of location information, C-mail communication, battery capacity, signal strength and device control of LED and backlights as phase I. In phase II, it supported the HTTP protocol and seamless switch from/to email and browser applications. In phase 2.5, it further supported simultaneous multiple music play and in phase 3.0, camera control and a 3D-polygon engine were supported. The maximum program size was 50 KB. (2) BREW® BREW® is a downloadable application platform promoted by KDDI (au) as an alternative to JAVATM. It started from 2003 and is now the mainstream platform in this field. BREW® operates faster since the platform is located just on the native layer so that devices can be accessed more directly than with the JAVATM platform. With these characteristics, BREW® is suitable for games and various new applications. Unlike JAVATM, in which only the HTTP/HPPTS protocol is supported, BREW® supports any communication protocol (e.g., push type delivery) without any predetermined gateway. At the same time, since there is a tradeoff between openness and security, BREW® set up an application verification program. An application which is created by an official BREW® developer is registered to a dedicated application downloading server (ADS) only if it passes the KDDI verification program. After that, the application is made available to users. 2.4.2.3. CDMA2000 IP Packet Network and Service CDMA2000 1X utilizes both a circuit-switched network and an IP packet network to provide multimedia services. The circuit-switched network for voice service is based on ANSI-41, which was applied for cdmaOne, one of the second generation cellular systems in Japan. The IP packet network has been deployed with compatibility between CDMA 2000 1X and 1xEVDO since cdmaOne deployment. The IP packet network is composed of Packet Data Serving Node (PDSN), Home Agent (HA) and Authentication, Authorization, and Accounting (AAA). The following focuses on an IP packet network.

Figure 2-34. CDMA2000 Network Architecture Overview


57

The CDMA2000 data service offers web services called “Ezweb” and e-mail to cellular handsets. Internet services and enterprise intranet services are also provided for both handset and PC users. The following 5 major functions realize IP packet data services: 1) Device Authentication by cellular operators 2) User Authentication by service providers 3) IP address assignment 4) IP packet data transfer (i.e., Mobile IP) 5) Accounting based on data volume and time 2.4.2.4. Device Authentication Since CDMA2000 1X as well as cdmaOne is voice service oriented system, devices are authenticated at Home Location Register (HLR) via BSC and MSC in packet data calls as well as voice calls. The device authentication keys used in the 1X system are “MIN/IMSI” and “ESN”. On the other hand, in the 1xEV-DO system, devices are authenticated by the authentication server called “Access Network AAA (AN-AAA)” using PPP and RADIUS protocol since 1xEV-DO is a packet service oriented system. The device authentication keys used in the 1xEV-DO system are “user ID” and “password”.

Figure 2-35. Device Authentication

2.4.2.5. User Authentication User authentication is the process by which service providers authorize the service. For “Ezweb” and e-mail services, KDDI (au) is the service provider. For internet access services, each ISP is the service provider. For intranet services, each enterprise

58


is the service provider. First of all, every packet data call from MS is connected to the access server called “PDSN”. Then PDSN queries the AAA server database (using a combination of the user ID and password) that each service provider manages, using the RADIUS protocol for user authentication.

Figure 2-36. KDDI (au) packet data network and service providers’ network

2.4.2.6. IP Address Assignment IP addresses are managed by either Service providers (case1) or KDDI (au) (case2). In the former case, the IP address is assigned statically or dynamically. In case of static IP address assignment, unique and permanent IP addresses corresponding to the mobile station are assigned. In the case of dynamic IP address assignment, IP addresses are dynamically assigned from pool addresses. (1) Service Provider Management KDDI (au)’s Proxy-AAA receives the assigned IP address in the RADIUS authentication response message from the service provider’s AAA server. The assigned IP address will be unique to the user or dynamic. KDDI (au)’s Proxy-AAA transfers the received RADIUS authentication response message to the PDSN which the MS has accessed. Then the PDSN transfers the Mobile IP registration request to the HA in the subnet to which the assigned IP address belongs to in order to ensure the mobility in parallel with the RADIUS authentication request message from the MS.The HA includes the IP address in its Mobile IP registration response and responds it to the PDSN. The PDSN informs the MS of the assigned IP address using the PPP protocol. (2) KDDI (au) Management In this case, the assigned IP address information is not included in the RADIUS authentication response message from the service provider’s AAA server. When KDDI (au)’s Proxy-AAA receives the RADIUS authentication request message from the PDSN, it designates the HA to the PDSN based on the domain of the user ID. Then the PDSN transfers the Mobile IP registration request to the designated HA during RADIUS authentication. The HA assigns the IP address for the user from its pool


59

addresses, then includes the IP address in its Mobile IP registration response to the PDSN. The PDSN informs the MS of the assigned IP address using the PPP protocol.

Figure 2-37. IP address assignment (Service Provider management)

Figure 2-38. IP address assignment (KDDI management)

2.4.2.7. Packet Data Transfer CDMA2000 adopts an IP tunneling scheme called “Mobile IP” to ensure mobility.

60


In general IP communication, the IP address is an indicator of the host and shows the subnet which it belongs to. When the host leaves the home subnet, IP packets cannot reach to the host. Mobile IP is the scheme to transfer the IP packets to the destination the host moves to by tying up HA with FA.

Figure 2-39. Outline of Mobile IP

In a CDMA2000 packet data network, PDSN -- the access server -- has FA functionality. Whenever an MS moves to a different PDSN/FA area and detects that the FA has changed, it sends an MIP registration update request message to the HA via

Figure 2-40. IP packet flow during packet data call


61

the new PDSN/FA. When the HA receives the MIP registration update request message, it updates the IP address of the PDSN/FA and then sends the MIP update response message back to the MS via the PDSN/FA. At the same time, the HA requests to release the previous session from the old PDSN/FA. The HA encapsulates IP packets arriving at its subnet and sends them to the PDSN/FA to which the MS moves. The PDSN receiving the encapsulated IP packets decapsulates and transfers them to the MS using a PPP session. From the MS perspective, it looks at IP packets addressed to the MS as they go through the tunnel (entrance: HA, exit: PDSN/FA). Another advantage of Mobile IP is to enable the division of its data network into smaller sub networks that each HA belongs to. Since IP addresses can be reused across sub networks, a huge number of mobile internet subscribers can be covered. Generally MIP does not require reverse tunneling (for IP packet transfer from host to data network); however the KDDI (au) data network requires the reverse tunneling because of its split/divided data network. 2.4.2.8. Accounting PDSN generates accounting records in real-time based on accounting related information obtained from both Radio Access Network (RAN) and the PDSN itself. Accounting records indicate the “amount of received/transmitted packet data” and the “period of communication/connection time” on a user basis. When the call is terminated, the PDSN transfers accounting records related to this call included in the RADIUS message to the service provider’s AAA server via KDDI (au)’s Proxy-AAA. Those accounting records are stored at both the KDDI (au) Proxy AAA and the service provider AAA. KDDI (au) adopts the accounting scheme based on the amount of packet data received/transmitted. On the other hand, internet service providers adopt an accounting scheme based on the period of communication/connection time. Recently, however, flat rate accounting plans are gradually becoming more popular than packet amount or duration based accounting. Although RADIUS based accounting is popular in packet data communication, KDDI (au) uses a different accounting scheme, i.e., URL based accounting, for the “Ezweb” and “Email” services that KDDI (au) offers. The URL based accounting is a packet amount based accounting scheme that is based on the combination of the IP address assigned to the MS and the URL of the contents included in IP packets. This accounting scheme enables more flexible accounting depending on content (URL).

2.5. Enhanced 3G Cellular Systems 2.5.1. All-IP Network for Diversified Radio Access The 3G cellular radio access system has been evolving since the first W-CDMA system appeared with the access speed of 384 kbps. The High Speed Packet Access ( HSDPA) system with 14 Mbps is currently being put into service. A higher speed radio access system with 30 Mbps (in vehicular movement) or 100 Mbps (in pedestrian movement) is being standardized under the name of work item “Long Term Evolution ( LTE )” in the 3GPP. Another 3G cellular radio access system has also been evolving from the first cdma-2000 system with 144 kbps. The 1xEV-DO Rev.A system with 3 Mbps is cur-

62


rently being put into service. A higher speed radio access system with more than 10 Mbps is being standardized in the 3GPP2. W-LAN as the hotspot radio access system has been gaining in access speed from the original 2 Mbps to about 50 Mbps currently, and 100 Mbps in the near future. WiMAX with 14 Mbps as a hotzone radio access system which allows vehicular movement is about to be commercialized. Moreover, a 4G radio access system with 100 Mbps (in cellular) and 1 Gbps (at hotspots) is to be standardized under the name of IMT-Advanced at the ITU-R. From now on, mobile network will accommodate diverse access systems including 2G/3G/4G cellular, W-LAN/WiMAX, FTTH/ADSL, and digital broadcasting based on All-IP networking as shown in Figure 2-41. It is very important to form an All-IP network architecture that can easily accommodate any novel access system and offer unique services through all access systems used by users. The architecture should place a common radio-independent function within the network and provide a standard interface with the access systems.

Figure 2-41. Future mobile network with diversified accesses

2.5.2. Convergence of Mobile Networks and the Internet Mobile networks have taken the role of providing mobile access to the Internet. The Internet itself has been a fixed network, and mobility has been managed by an external mobile network. The current mobile networks and the Internet have different network architecture principles and basic network controls as shown in Table 2-2. Mobile networks have


63

been handling key network controls such as QoS, Security, and Mobility within them as telecom networks. In other words, mobile networks are intelligent network-oriented. On the other hand, the Internet has been distributing the controls to end terminals. That is, the Internet is stupid network-oriented. Table 2-2. Difference between conventional mobile packet network and Internet Mobile packet network

Internet

Network Architectural Principle

Network Centric Control

End-to-end Distributed Control

(Intelligent Network)

(Stupid Network)

Network Control

Control with mobile terminal identity

Control with Terminal IP address

Mobile networks have been handling network control with mobile terminal telephone numbers (mobile terminal identity), while the Internet has been handling network control with IP addresses. The All-IP network aims at the convergence between mobile networks and the Internet. This network works as a sub-network within the future Internet. It handles network control with IP addresses in the same way as the conventional Internet. The network architecture principle is intelligent network-oriented. That is, the All-IP network handles network controls such as session management by the IMS, network QoS control, and network security management (access authentication and ciphering) in a network-centric way. A stupid network-oriented mobility management system has once been standardized under the name of Mobile IP in the IETF. In Mobile IP, when a Mobile Node (MN) is away from its home link and connects to a different outside link, it acquires a temporary address, Care-of-Address (CoA), over the link. The MN then updates its address in the Home Agent (HA) with the CoA. When a Correspondent Node (CN) transmits a datagram to the MN (Figure 242(1)), the datagram is transported first to the HA by the IP packet with the MN’s home address, IPMN. It is forwarded to the MN through a tunnel of CoA from the HA. In order to avoid so-called trombone routing via the HA, the Mobile IP allows optimum routing which transports the datagram directly to the MN by the packet with the CoA from the CN. For this routing, the MN informs the CN of the CoA. This leads to a critical problem on location privacy in which any CN can realize the MN location just by initiating a correspondence. A novel mobility management system based on network intelligence has been proposed to protect location privacy as shown in Figure 2-43. When an MN moves to another external area away from the home area, a temporary routing address IPARt is assigned by the Access Router (ARt) which covers the outside area. The ARt keeps the correlation (IPMN@IPARt) with the node address IPMN which is assigned semipermanently to the MN. Then, it informs the HA of the correlation. When a CN transmits a datagram to the MN, ARo covering the area where the CN exists inquires IPArt of the HA and keeps the correlation (IPMN@IPARt). The datagram is then transported to ARt by the IP packet with the routing address IPARt which is converted from the MN’s home address, IPMN at ARo. ARt forwards the datagram to the MN by recovering IPMN based on the correlation (IPMN@IPARt).

64


(1) Normal Routing

(2) Optimal Routing Figure 2-42. Mobile IP

Figure 2-43. Network-edge intelligent mobility management

This mobility management is now being standardized under the name of originally Network-based Localized Mobility Management (NETLMM) and then Proxy Mobile IP (PMIP) at the IETF. The All-IP network architecture to manage mobility among the existing 3G cellular radio, the LTE radio, and W-LAN/WiMAX is now being standardized under the name of System Architecture Evolution (SAE) at the 3GPP


65

(Figure 2-44). The NETLMM is regarded as a promising candidate for mobility management. A similar standardization on the All-IP network for the fixed network is being standardized under the name of Next Generation Network (NGN) at the ITU-T and ETSI TiSPAN. An architectural harmonization between the SAE and the NGN as shown in Figure 2-45 is expected in the future.

GERAN

Gb Iu

GPRS Core

PCRF

UTRAN

Rx+

S7 S3

S4

HSS S6

Evolved RAN

S1

MME

S5

Gi

P-GW

/S-GW

Evolved Packet Core S2

non 3GPP IP Access

Op. IP Serv. (IMS, PSS, etc…)

S2

WLAN 3GPP IP Acces

Figure 2-44. Logical high level architecture for the evolved system in 3GPP standard

Figure 2-45. Harmonization between the AIPN and the NGN

66


2.5.3. IP-based Integrated network Platform (IP2) NTT DoCoMo has been proceeding with R&D into IP-based Integrated network Platform (IP2) as their All-IP network, shown in Figure 2-46. IP2 consists of Core Transport NW, Network Control PlatForm (NCPF), and Service Support PlatForm (SSPF). Core Transport NW is an IP network that accommodates diverse radio access systems such as the existing 3G RAN WLAN/WiMAX and Super 3G/4G RAN. It manages mobility among radio accesses based on the NETLMM by the Edge Mobility Protocol (EMP). NCPF performs session management by the IMS, Mobility/User Profile management by the HSS, and QoS Management. All the interfaces between nodes over the Core Transport Network and the NCPF follows the SAE standard in the 3GPP㸬The SSPF also offers additional value for application services by servers of presence, location, and user preference.

Figure 2-46. IP2 (IP-based Integrated network Platform)

2.5.4. Ultra 3G First generation cellular systems evolved into the second generation due to the evolution from analog to digital. Second generation cellular systems evolved into the third generation due to the evolution from voice and low speed data communication mainly for text messages to multimedia. Next generation cellular systems are being explored for further high capacity/speed data communication. The Ultra 3G concept, which KDDI announced in June 2005, pursues not only a new cellular system which is capable of high speed data communication, but also a fixed-mobile convergence system. In other words, Ultra 3G includes fixed access such as ADSL and FTTH, as well as new radio access such as Mobile WiMAX and next generation cellular systems in addition to incumbent third generation cellular systems and Wireless LAN. The


67

evolution from third generation to Ultra 3G implies a different meaning from traditional cellular evolution caused by the introduction of a new radio access system. 2.5.4.1. Beyond 3G Providing integrated services contributed by various access systems is one of the most important features in the Systems Beyond 3G (often called Beyond 3G), which has been studied by ITU as the system to follow IMT-2000. One of the essential goals of enhanced 3G network is to offer attractive services and applications seamlessly over the packet-based core network with a variety of access systems that complement each other. Figure 2-47 describes the basic structure of Beyond 3G. As this figure shows, cellular systems such as IMT-2000 and IMT-Advanced, Wireless LAN, short range radio communication, digital broadcast, and fixed accesses connect to a common backbone network. Various services and applications are provided in a uniform and common manner with mutual interaction, not independently among access systems. Beyond 3G includes fixed access and implies the FMC concept, in which seamless services are provided without separation between fixed networks and mobile networks.

Figure 2-47. Basic structure of Beyond 3G

In order to construct this network, access independent communication service control mechanisms, so-called IP Multimedia Subsystem (IMS) and Multimedia Domain (MMD), take an important role. 2.5.4.2. Torwards All IP CDMA 1X WIN series handsets provided by KDDI (au) support CDMA2000 1xEVDO Rev.0 for best effort packet communication and CDMA2000 1X for circuit switch voice communication. When EV-DO Rev.A, which beefs up two-way multimedia communication, is introduced in late 2006, an all-IP real-time application will be realized. IMS and MMD play an important role in response to this radio communication technology evolution.

68


Figure 2-48 shows the standardization status of IMS and MMD, which are standardized in 3GPP and 3GPP2 respectively. The core content of IMS and MMD are coordinated to be identical. Products compliant with IMS Release 6 and MMD Release A will be available by 2007.

Figure 2-48. Standardization status of IMS and MMD

Figure 2-49 describes the MMD architecture overview. IMS/MMD is based on IP technology and pursues an all-IP network. Although IPv6 was mandatory in IMS in the initial version, IPv4 and IPv6 are optional in IMS and MMD at present.

Figure 2-49. MMD Architecture

IMS/MMD uses Session Initiation Protocol (SIP) for call control. Call control protocol has varied between fixed communication and mobile communication. Furthermore, each mobile communication system such as CDMA2000 and GSM/W-


69

CDMA has a unique call control protocol. Selecting SIP, which is the de facto standard for IP phone services, IMS/MMD is an access independent system. Services such as VoIP, IP video telephony, presence services, push to talk over cellular, and Internet games are assumed with IMS/MMD. These services can be provided without IMS/MMD. These services, however, can be easily combined using IMS/MMD. For example, Internet game sessions can be linked to video telephony. Figure 2-50 describes a service example, “context awareness”, in which services can be switched based on the user’s situation and preference. When a user receives a video call in an environment where he/she should refrain from speaking, he/she can answer using text chat. This “context awareness” service is a remarkable feature on top of “access independence”.

Figure 2-50. Service example “Context Awareness”

IMS/MMD is expected to be a platform to create new business opportunities. Furthermore, significant cost reductions are expected compared to the approach of adding a server based on a proprietary specification for each service, since IMS/MMD systems consist of servers based on a standard interface specification. The Home Subscriber Server (HSS) shown in Figure 2-49 integrates centralized subscriber database functionality, including subscriptions to each service, Home Location Register (HLR) functions and registration servers for IP telephony systems. Managing the unified database and being associated with various service servers, HSS will enable organic cooperation of each service and a reduction of operation and maintenance (O&M) cost. 2.5.4.3. Convergence with Fixed Network Future fixed networks are being studied under the name NGN (Next Generation Network). Although IMS/MMD has been discussed in the framework for future evolution of cellular networks, it isn’t limited to mobile communication. Now that the mobile communication business has rapidly become huge, NGN has adopted IMS/MMS. Thus, IMS/MMD is not only the future network technology for cellular networks, but also the fundamental technology in order to create an FMC (Fixed Mobile

70


Convergence) world where mobile communication and fixed communication are integrated. IMS/MMD pursues seamless access networks and access independent services. It will be deployed in radio communication, such as cellular and Wireless LAN and then fixed communication. 2.5.4.4. Evolution of Radio Access System In the CDMA2000 world, KDDI (au) started CDMA2000 1xEV-DO services in November 2003 with the CDMA 1X WIN brand. CDMA2000 1xEV-DO evolved from CDMA2000 1X and provides 2.4Mbps for maximum forward link (BTS to Mobile Terminal) data speed. It is used globally all over the world. CDMA2000 1xEV-DO has evolved into EV-DO Rev.A with reverse link (Mobile Terminal to BTS) enhancement and QoS (Quality of Service) support. KDDI will start EV-DO Rev.A commercial services in 2006. In the W-CDMA world, NTT DoCoMo started High Speed Downlink Packet Access (HSDPA) in August 2006. High Speed Uplink Packet Access (HSUPA) is in the pipeline as the uplink evolution of HSDPA. These technologies concentrate on packet communication. By assigning more radio resources to mobile terminals staying in a good radio environment, the system provides mobile terminals as high a data rate as possible. This mechanism will be inherited by next generation radio system. Cellular business new common carriers will differentiate services from incumbent operators due to their support of this enhancement mechanism. Ultra 3G includes next generation radio systems that will reduce cost per bit in addition to CDMA2000 1X and EV-DO Rev.A, which will play an important role as the radio access method to provide a nation-wide, seamless coverage base. (1) Next generation CDMA2000 While 3GPP is studying the further enhanced system, so-called Long Term Evolution (LTE), 3GPP2 published the system requirements of the next generation system as Enhanced cdma2000 phase 2 in May 2006. The Enhanced cdma2000 phase 2 was originated by a work item co-signed by 29 major operators and manufacturers led by KDDI. It is regarded as an evolution of IMT-2000, not as a system of IMT-Advanced; in other words 4th generation. It will achieve 500 Mbps maximum forward link (BTS to Mobile Terminal) data speed with a potential to enhance to 1 Gbps in the future and 150 Mbps maximum reverse link (Mobile Terminal to BTS) data speed. It also requires increased spectrum efficiency and VoIP capacity, connection time reduction, cell coverage enhancement and low transmission delay. (2) Broadband Mobile Radio Access System Now that fixed access has become broadband, demand for inexpensive broadband is steadily increasing. Mobile WiMAX emerged based on such a demand. It is a broadband mobile radio access system based on IEEE802.16e and is likely to proliferate all over the world. It can provide high speed broadband transmission and high spectrum efficiency due to the scalable OFDMA technology. Adding advanced antenna technology such as Adaptive Antenna System (AAS) and Multi Input Multi Output (MIMO), it is expected to increase data speed and the spectrum efficiency further. Since IEEE802.16e defines only the physical layer and MAC layer, the WiMAX Forum is responsible for system architecture and the upper layers, including the core network. It also focuses on the inter-operability of the system, not only the physical and MAC layer but also the upper layers. IEEE802.16e includes a lot of optional features in the physical and MAC layer. The WiMAX Forum defines some feature


71

subsets (called “profiles” in the WiMAX Forum) and creates inter-operability test programs and rules to certify a product. IEEE802.20 was regarded as an alternative technology, but its situation is now unclear, because activity was suspended until October 2006. 2.5.4.5. Access Independent Seamless Communication Creating good coverage areas is one of the key success factors in the cellular business. In Ultra 3G, several access systems converge, leveraging the merits of each system such as cost and throughput, and a seamless network fulfilling both low cost and high quality is created as a result. Figure 2-51 shows the blue print. The cellular system is the base to provide nation-wide coverage. The broadband mobile radio access system is overlaid on it, covering mainly metropolitan areas in which traffic volume is huge.

Figure 2-51. Access independent system

Fixed access and other access means such as hot spots are also provided. All access systems are organically converged and compensate mutually. The goal of Ultra 3G is to provide a seamless service in which users do not need to recognize which access system they are using. KDDI demonstrated seamless handover between EV-DO and Mobile WiMAX in February 2006. KDDI developed the seamless handover system for VoIP and video

Figure 2-52. Video Telephony Demonstration

72


telephony with a mutual cooperation between the radio layer, IP layer and the application layer. It was very difficult for people to perceive the handover interruption. Figure 2-52 shows a picture from the video telephony demonstration. There are some activities to standardize seamless handover. One example is IEEE802.21. IEEE802.21 defines three processes, (1) Event Services, (2) Information Services, (3) Command Services. For example, at first receiving an event where the radio quality is poor, secondly acquiring information on other available radio access and then sending a handover command. The core network of the mobile communication system is evolving into all-IP and converging with fixed communication systems, while new radio access systems are introduced. All the access systems are connected seamlessly, regardless of whether they are fixed or mobile. This is the completion of Ultra 3G.

References [1] K.Higuchi,H.Kawai, N.Maeda, H.Taoka and M. Sawahashi, “Experiments on Real-Time 1-Gb/s Packet Transmission Using MLD-Based Signal Detection in MIMO-OFDM Broadband RadioAccess,” IEEE J. Sel. Areas in Commun., Vol.24, No.6, pp. 1141-1153, June 2006. [2] “KDDI Trials Japan’s First Mobile WiMAX System - Verifies Functionality in an Urban Environment, Demonstrates Successful Connectivity with an ‘Ultra 3G’ Network,” http://www.kddi.com/english/corporate/news_release/2006/0216/index.html, August 29, 2006. [3] Fourth Generation Wireless Networks and Interconnecting Standards, IEEE Personal Communications, Vol.8 No.5, October 2001. [4] “All-IP Network (AIPN) Feasibility Study, Release7,” 3GPP TR 22.978 V7.1.0 (2005-06), “Service requirements for an All-IP Network (AIPN); Stage 1, Release 8,” 3GPP TS 22.258 V8.0.0 (2006-03) “System Architecture Evolution: Report on Technical Options and Conclusions,” 3GPP TR23.882, V1.1.0 (2005-09). [5] “NTT DoCoMo: i-mode,” http://www.nttdocomo.com/services/imode/, August 29, 2006. [6] “NTT DoCoMo: i-mode,” http://www.nttdocomo.com/services/imode/, August 29, 2006. [7] “Enjoy Contents: i-motion | Services | NTT DoCoMo,” http://www.nttdocomo.co.jp/english/service/imode/content/i_motion.html, August 29, 2006. [8] “Sending and Receiving Photo / Movie Mails: i-motion mail | Services | NTT DoCoMo,” http://www.nttdocomo.co.jp/english/service/imode/photo_movie/, August 29, 2006. [9] “i-channel | Services | NTT DoCoMo,” http://www.nttdocomo.co.jp/english/service/imode/ichannel/, August 29, 2006. [10] “i-mode Disaster Message Board Service in English | News & Press | NTT DoCoMo,” http://www.nttdocomo.co.jp/english/info/disaster/, August 29, 2006. [11] “PDC Digital Mobile Communications Network Inter-Node Interface (DMNI) Signalling Method of Mobile Packet Communications System,” Telecommunication Technology Committee, Apr 19, 2001. [12] A.Murase, A.Maebara, I.Okajima and K.Sasada, “Special Issue on Mobile Packet Data Communications System: 2 New Air Interface of Personal Digital Cellular Telecommunication System,” NTT DoCoMo Technical Journal Vol.5 No.2, pp10-15, Jul 1997. [13] K.Sasada, S.Kobayashi, M.Tokohara, N.Nakaima and H.Tatewaki, “Call Handling Function for Voice Terminating Call During Packet Communications,” NTT DoCoMo Technical Journal Vol.7 No.1, pp36-42, Apr 1999. [14] K.Nakamura, H.Kubosawa, M.Sotoyama and S.Kobayashi, “Special Issue of New Services: Development of IP Address Dynamic Assignment Method in the PDC Mobile Packet Data Communications System,” NTT DoCoMo Technical Journal Vol.5 No.3, pp16-19, Oct 1997. [15] M.Onuki, K.Kobayashi, K.Nakamura, S.Kimura and A.Miyazaki, “Special Issue on Mobile Packet Data Communications System: 1 Overview of PDC-P System,” NTT DoCoMo Technical Journal Vol.5 No.2, pp6-9, Jul 1997. [16] M.Takahashi, K.Sugiyama, A.Yokote, S.Sawayanagi and N.Sekizaki, “Special Issue of Packet Data Communications Service: Development of Selective Virtual Connecting Function at the PDC Mobile Packet Communications System,” NTT DoCoMo Technical Journal Vol.6 No.3, pp30-34, Oct 1998.


73

[17] S.Hirata, K.Sugiyama, M.Sotoyama, K.Fukasawa and I.Okajima, “Special Issue on Mobile Packet Data Communications System: 3 Network Architecture,” NTT DoCoMo Technical Journal Vol.5 No.2, pp16-20, Jul 1997. [18] M.Hanaoka, S.Kaneshige, N.Hagiya, K.Ohkubo, K.Yakura and Y.Kikuta, "Special Issue on i-mode Service: Network System", NTT DoCoMo Technical Journal Vol.7 No.2, pp16-21, Jul 1999. [19] M.Tokuda and K.Yakura, “Special Issue on advanced i-mode terminals: i-mode Protocol: Network System,” NTT DoCoMo Technical Journal Vol.9 No.1, pp27-31, Apr 2001.



75

Chapter 3

Wired Access System 3.1. Overview This section describes the situation of the wired Internet in Japan. Until the middle of the 1990’s, the dial-up connection was the main access method to the Internet. At that time, telephone rates in Japan were pay-as-you-go, and there were not so many dial-up users compared to the United States where the telephone rates were flat.

Figure 3-1. Number of Internet users and penetration rate

In 1995, a new telephone service, in which the rate at night for calling a specific telephone number in the same city became a fixed amount, was started, and the number of Internet users began to increase. In 1997, an always-on Internet service, which used a digital leased line of with a transmission rate of 128 kbps or less, began at the comparatively low price of about $350/month. At that time, the cost of a digital leased line with the same transmission rate was 10 times higher. However, for residential users, that cost was so expensive that the number of users remained a small. The situation changed completely after entering the 21st century. Broadband Internet access services (CATV and DSL) became widespread at a low price (about several thousand yen per month). The plan of the e-Japan government initiative also supported that trend. In particular, the number of DSL service subscribers rapidly increased. In addition, the percentage of market penetration of DSL service in Japan became higher than that of all other regions around the world in 2004. In 2003, optical fiber service started by the price lower than $100/month, and Internet access service with a maximum transmission rate of 100 Mbps began to spread to the residential households about 2003. The increase in the number of optical lines has passed that of DSLs in 2006.

76

Chapter 3. Wired Access System

This chapter explains the technologies of CATV, DSL, and FTTH as the main wired access technologies that support the broadband Internet Japan today.

Figure 3-2. Number of broadband contracts 1999 - 2005 From MIC “2006 White Paper on Information and Communications in Japan”

3.2. Cable Internet 3.2.1. Beginning of Cable Internet in Japan The communications technology of CATV was used for limited purposes such as control of amplifiers and water service inspection until the 1980’s. A cable modem product, which had bandwidth of 10 Mbps had been achieved in the 1990’s. The Cable Television Broadcast Law, which was the basic law of CATV business in Japan, was made less restrictive in 1993. Urban CATV operators with a 2-way communication function planned communication services such as telephone and Internet service, and Musashino-Mitaka Cable Television Inc. and CTY Co. Ltd. launched Internet services in 1996. 3.2.2. Features of CATV in Japan In the Cable Television Broadcast Law promulgated in 1973, only one CATV operator was authorized to operate in a city, town, or village. This regulation was abolished in 1993. However, most Japanese CATV operators are still small-scale companies that were under the influence of this law, and they have not grown in size since the law was abolished. Most Japanese CATV operators offer their Internet services separately as a regional ISP. The specifications such as hardware/transmission rate/service charges are different depending on the operator. The operators can satisfy different demands for


77

each area, and that is advantageous for supporting their subscribers. However, the service areas and business scale of Japanese CATV are small, and most operators have fewer than 200,000 subscribers and home passes. On the other hand, Jupiter Telecommunications (J:COM), Japan Cablenet (JCN), and Mediatti Communications merge several CATV companies as multiple system operators (MSO). 3.2.3. Standardization of Cable Modem System and Adoption There was no cable modem system standard in 1996 when Japanese operators started offering services, the sets of the terminal modem and CMTS (cable modem termination system) were fixed. The cable modem system is standardized in ITU-T J.112 and J.122 and produced in accordance with the DOCSIS (Data Over Cable Service Interface Specifications) spec, which was certified by CableLabs after 1998, and that is generally adopted. Table 3-1. Capacities of Cable modem systems Bandwidth LANcity

Com21

DOCSIS 1.0 DOCSIS 2.0

Modulation

Max Speed (Raw bit rate)

DS

6 MHz

QPSK

10 Mbps

US

6 MHz

QPSK

10 Mbps

DS

6 MHz

64QAM

30 Mbps (Ethernet IF of modem is 10BaseT)

US

1.6 MHz

QPSK

2.56 Mbps

DS

6 Mbps

64QAM,256QA

42.88 Mbps

US

0.2 - 3.2 Mbps

QPSK,16QAM

10.3 Mbps

DS

(same as DOCSIS 1.0)

US

0.2 - 6 Mbps

QPSK, 8, 16, 64QAM with S-CDMA, TDMA

30.96 Mbps

CATV operators were able to reduce their investment costs by adopting a cable modem system based on DOCSIS and were able to extend the choice of the terminal modems. In addition, the DOCSIS modem system achieved a transmission rate of more than 30 Mbps. Competition with other broadband services including ADSL became intense, and operators were forced to improve their level of service after 2002. Some operators launched an HSD (High Speed Data) service of more than 30 Mbps using DOCSIS in 2002. 3.2.4. Channel Allocation and Connected Subscribers The 2-way 770 MHz CATV system has spread throughout Japan. The upstream RF bandwidth is 5-55 MHz, and the downstream RF bandwidth is 70-770 MHz. CATV operators determine communication capacity by assigning upstream and downstream bandwidth to their cable modem systems. An operator using multiple cable modem systems assigns more than two channels for communication depending on the number

78


of systems. Subscribers connected to one HFC (Hybrid Fiber Coaxial) node share the capacity per port of the CMTS (cable modem termination system). Japanese CATV operators actively invest in their cable facilities and modem equipment. They increase the capacity of CMTS chassis and ports to achieve a highspeed data service of 30 Mbps class. 3.2.5. Shift to Transmission Rate of more than 100 Mbps Japanese operators demand technology to achieve a transmission rate greater than 100 Mbps in competition with other high-speed Internet services including FTTH. Some operators were interested in the technology to achieve high-speed data transmission using an RF bandwidth of 800 MHz -1 GHz, which was not allocated in CATV and BS-IF, but that technology did not spread because it could not connect to general CATV facilities. After 2005, the cable modem technology to increase transmission rates using multiple channels (channel bonding) was achieved, and CMTS vendors released their products with original specifications using channel bonding. The conventional CMTS achieves 42 Mbps per 256QAM channel; the CMTS using channel bonding can establish a capacity of more than 160 Mbps by bundling 4 channels at the same time. Some operators including Cable Television Kani have launched the ultra-high-speed service of 120-160 Mbps in 2006. DOCSIS3.0 was released in August 2006. DOCSIS3.0 standardizes the technologies achieved after DOCSIS2.0 including channel bonding and enables IPv6.

3.3. xDSL Network 3.3.1. Configuration of Metallic Network In Japan, the configuration of access networks is designed based on the use for telephone exchange, with metal cables used from an exchange station building to customers homes. From an exchange station building to an area runs a multi-pair underground cable that is called a trunk system. The underground cable that runs to the area is connected to aerial/underground cables in a distribution system at a division point called a feeder point. The feeder point established by NTT is a point at which a trunk system coming from an exchange station building is connected to a distribution area with customers considered as a unit. For cabling, the multi-pair cable is branched in some directions to cables of required pairs (small pair cable) at the feeder point. In urban areas, there are many underground distribution areas, and many building lead-in points from each of which a lead-in cable for a building is branched. Metal cables (2W (wire)) connect from an exchange station building to each customer’s home, like string telephone. Running from homes, 2W cables and are bundled stages by stage to reach an exchange station building. Metal cables are classified according to the means of insulation into the paper insulation cables and the polyethylene cables. Paper insulation cables are now not newly installed, but there are still some paper insulation underground cables. Such cables are inferior to polyethylene cables in the crosstalk property, which is an issue in the cables in Japan. Metal cables are divided according to the place of installation into underground cable and aerial cable. For each of the places, some types of metal cables different in


79

the diameter of the insulated conductor and the number of pairs are used. As a property of the metal cable, it has a higher resistance, as the diameter of its insulated conductor is smaller; on the other hand, a lower resistance, as the diameter of its insulated conductor is larger. To extend a transmission distance long, much more metal cables with a greater diameter of the insulated conductor might be used; however, it is more difficult to make such cables in the form of multi-pair cable and it cost higher to do so. So metal cables with smaller diameters of the insulated conductor (better for the efficiency in the number of customers connected) are used in sections nearer to exchange station buildings, but such cables with larger diameters of the insulated conductor in sections farther from exchange station buildings (i.e., where connected to smaller numbers of customers). This ensures higher efficiency. It is reflected in the fact that the only multi-pair underground cable that has insulated conductors 0.32 mm in diameter is a cable with 3,600 pairs of insulated conductors, and the aerial cables that have insulated conductors 0.9 mm in diameter do not include any cable with 400 or more pairs of insulated conductors, in the current equipment. A cable is composed in the form of some insulated conductors bundled. In NTT’s cable, 4W (4 wires), i.e., two pairs of insulated conductors for two customers, are bundled in a quad structure, and five quads, i.e., 10 pairs of insulated conductors, are bundled in a unit, for better efficiency. This unit is a minimum unit that can compose a cable, and there is more than one type of cable based on that unit. The quad structure has an effect of reducing crosstalk between adjacent customer lines.

Figure 3-3. Configuration of access network

3.3.2. Features of DSL Technology In Japan, the DSL service has explosively spread because existing metal cables in the access system that run from exchange station buildings to customers’ homes are used, so that the cost of service in the access section is reduced. The ADSL service has the following features. One of the features is that it takes a relative short time from an application of a customer until the opening of the service to the customer because the existing equipment is used. Another feature is that each service area is based on one

80


exchange station building with ADSL station equipment, i.e., which exchange station building a customer is connected to means possible/impossible provision of the service. However, there are cases where customers that are connected to a station with ADSL station equipment distant from their homes cannot be provided with the ADSL service because of large line attenuation. Another feature is that the ADSL service is a besteffort type of service, which is completely different from the idea on which the telephone service, which is provided by the same metal cables and is of high quality, is based. Nowadays best-effort types of service are quite common, which seems to be a reflection of penetration into the public of IP services, including ADSL. It also seems to be related to the quality of the mobile phone service, which has spread at the same time as ADSL. The telephone service uses a frequency band of 0-4 kHz in a metal cable, and the xDSL service provided in a system where it shares the same cable as the telephone service uses a frequency band of more than 4 kHz so that the xDSL does not affect the telephone service (i.e., those services do not interfere with each other). xDSL (x Digital Subscriber Line) is a generic service term for various digital subscriber-line systems, including ADSL, VDSL, HDSL and SSDSL, where high-speed digital data transmission is implemented by applying various coding/modulation technologies to the existing metal cables for telephone service. ADSL provides an upstream/downstream asymmetric communication through a single pair in a metal cable. ADSL uses a frequency band of 26-138 kHz for upstream transmission and 138-1,104 kHz for downstream transmission (based on Standard G.992.1, Annex C), with a rate of up to 1 Mbps for upstream transmission and a rate of up to 12 Mbps for downstream transmission, for a distance of some kilometers. VDSL, which is mainly used in inside

Figure 3-4. Difference in configuration between ADSL and VDSL


81

systems (in condominiums, etc.), provides communication through a pair of insulation conductors in a metal cable. VDSL uses frequency bands for upstream and downstream bands that are alternately stacked with the lowest band for upstream communication (this stack is called a band plan; Figure 3-5 is a band plan defined in G.993.1), with a rate of up to 30 Mbps for upstream transmission and a rate of up to 50 Mbps for downstream, for a distance of some hundreds of meters. For VDSL services, an optical cable is used from an exchange station building to a VDSL collective device in a condominium or apartment-house building, and an inside wiring (metal cables) is used in the condominium or apartment-house building. The latest VDSL technology has achieved a rate of up to 100 Mbps for upstream transmission and a rate of up to 100 Mbps for upstream transmission. VDSL achieves high rate communication by using higher frequency bands than ADSL; however, as mentioned above, in the high frequency bands used for VDSL, the line attenuation is high, so the transmission distance of VDSL is far smaller than that of ADSL. HDSL provides upstream/downstream symmetric communication through a pair of insulated conductors in a metal cable, with a rate of transmission of up to 1.5 Mpbs. SSDSL provides upstream/downstream symmetric communication through a pair of insulated conductors in a metal cable, with a rate of transmission of up to 1.5 Mpbs (based on Standard G.992.1, Annex H), and is resistant to crosstalk interference.

Figure 3-5. Band plan for VDSL (example of 4 bands) <Standard G.993.1>

The metal cable has larger line attenuation, as the frequency is higher and as the insulated conductor is thinner. Other factors to deteriorate transmission properties include a change of line impedance due to the connection of cables of different types, as discussed in Chapter 1, and the effect of bridge taps, as well as crosstalk noise from existing services, impulse noise, and the effect of induction from power lines. Crosstalk includes near-end crosstalk (NEXT), i.e., transmission from a customer’s home to an exchange station building (upstream) affecting another user in the neighborhood of the customer, and far-end crosstalk (FEXT), i.e., transmission from an exchange station building to a customer’s home (downstream) affecting another user in the neighborhood of the customer. Generally, the effect of near-end crosstalk (NEXT) on the transmission system is dominant. 3.3.3. Analog Transmission and Coding Technology Coding technologies are used in encryption/decryption for the purpose of information security, compression represented by JPEG/MPEG, etc., checking of reading from/

82


writing in a storage medium, modulation/demodulation technology for higher reliability, and many other aspects. Adding extra information (redundancy) to the main information to be communicated according to certain rules in transmitting it and using it for error detection or correction increases the reliability of communication. Coding technologies for analog transmission include source coding (Huffman coding) for higher efficiency in transmission and channel coding (Hamming coding/cyclic coding). Modulation systems used in xDSL mainly are CAP and DMT. The CAP (Carrierless Amplitude and Phase) system, which uses a single carrier to transmit information, is used widely in voice-band modems, but is not adopted in ADSL standards. The DMT (Discrete Multi Tone) system divides a frequency band used into relatively narrow bands for sub-channels, and transmits information through each sub-channel by means of the QAM (Quadrature Amplitude Modulation) system. A feature of the DMT system is that the transmission power and the number of bits that can be allocated can be decided for each sub-carrier independent of other carriers. As a result, it can achieve flexible ways of transmission to be highly resistant to noise according to the situation and signal attenuation frequency property of the metal cable, and the frequency characteristic on noise. Each sub-carrier in DMT is called bin, and the maximum number of bits carried per bin defined in Standard G.992.1 is 15 bit. In Japan, the spectrum management established by TTC (Telecommunication Technology Committee) to make it possible to have various systems using adjacent insulated conductors in the same metal cable is in operation. An idea of the spectrum management is that the metal cables have been originally constructed for providing the telephone service, so using additional transmission systems on them should not undermine the quality of the telephone service. Thus, the already introduced service in them should be protected. Accordingly a condition for introducing an additional system in metal cables is that the additional system will not affect the existing systems in them. The service provider proposes a spectrum mask used for an additional system to TTC to confirm that the system satisfies the above-mentioned condition. TTC has established “The Spectrum Management of Metallic Subscriber Line Transmission Systems” (JJ-100.01), which is now the third version in effect. JJ-100.01 has defined a line model for the purpose of determining the compatibility with the spectrum management, and the model was based on 0.4 paper insulation cable until the revision to the second version, but has been based on 0.4 polyethylene cable since then. The existing systems are divided into Classes A, B and C according to whether they should be protected or not. For Class A systems, standards for protecting such systems are established, and an additional system is required to conform to such standards when it is introduced.

Figure 3-6. CAP modulation system


83

Figure 3-7. DMT demodulation system

3.3.4. Technology for Extending Transmission properties of ADSL, which is served through metal cables, are poorer, with slowed transmission, as the distance between an exchange station building and a customer’s home is longer. When the distance is extended longer and longer, connection between the exchange station equipment (DSLAM) and the modem in home will finally become impossible. When the transmission distance is extended longer and longer, the sub-carriers (bins) on the higher-frequency side finally will not be able to carry bits because of the frequency characteristic on line attenuation, so the total number of bits that can be transmitted at one time will decrease and the transmission rate will be lower. The standards for ADSL provide that the lowest rate be 32 kbps for either of upstream and downstream transmission, so a system that cannot ensure the lowest rate of 32 kbps is not allowed to connect to the ADSL service. The transmission distance at which a system just becomes unable to be connected to the cable because of lowered transmission rates is called a synchronization limit distance. It is important to grasp the limit distance for signals from each system to reach in the provision of services for customers. G.992.1 (G.dmt), Annex C (ACERR) standard for ADSL provides for switching the pilot tone to the lower-frequency side, and the use of more than one TTR tone (ISDN signal synchronization). Switching the pilot tone from tone (bin) #64 to #48 avoids an event that, in spite of the condition that the number of bits to ensure a rate of 32 kbps can be carried, connection is impossible because a pilot tone (#64) cannot be

Figure 3-8. Transmission property of ADSL

84


exchanged. The use of more than one TTR tone is also provided for to avoid risks involved in the transmission/reception using a single frequency. The function of ACERR to extend transmission distance is applied only when it is confirmed that both the station equipment (DSLAM) and the modem are equipped with the ACERR function in the handshake procedure provided in G.994.1 (G.hs). The extension of distance by means of the ACERR function is a maximum of less than one kilometer. 3.3.5. Technology for Increasing Transmission Rates In Japan, many service providers have entered the ADSL service market and ADSL subscribers have rapidly increased since the introduction of ADSL because it is easy to construct the equipment to provide ADSL services. Competition among ADSL service providers has been intense. Initially, the competition was focused on how early such competitors launched higher speed services in downstream transmission for data downloading, which was a point of differentiation for them. There was a case where such competitors developed and introduced a new service in a short span of about half a year. During a long time of competition, the price competition also has been intensified, so the ADSL service in Japan is now provided at the lowest prices in the world. The number of ADSL subscribers is also the world highest second to China. (About 14 million subscriber lines in Japan as of December 2005) The ADSL standards include three types: Annex A as the specifications for North America, Annex B as the specifications for Europe, and Annex C as the specifications for Japan. In view of ADSL’s sharing of cables with the existing services and the environment for use of ADSL in areas where it is introduced, three types of specification are based on the characteristics of the respective regions. G.992.2 (G.lite), which was established as an ITU-T recommendation in June 1999, specifies a maximum rate of 0.5 Mbps and a maximum rate of 1.5 Mbps at a frequency band of 26-138 kHz and a frequency band of 138-552 kHz for upstream transmission and downstream transmission, respectively, and sets forth 12 bits as the maximum number of bits carried by each sub-carrier. The standard provides for an ADSL form of connection without splitters, and a way of switching the states momentarily according to whether the telephone is used or not used (fast retrain) on the assumption of the offhook state of telephone in a technical sense. G.992.1 (G.dmt) has provided for higher transmission rates. The ITU-T recommendation of June 1999 specified a maximum rate of 0.6 Mbps and a maximum rate of 6 Mbps at a frequency band of 26-138 kHz and a frequency band of 138-1,104 kHz for upstream transmission and downstream transmission, respectively, and sets forth 12 bits as the maximum number of bits carried by each sub-carrier. G.992.1 (G.dmt) added some options to meet the needs for higher rates for downstream transmission: one option where the maximum number of bits carried by each sub-carrier is 15 bits with faster frame processing (S = 1/2), by which the rate for downstream transmission can be increased up to 12 Mbps without changing the frequency band used, and the other option where the frequency band for downstream transmission is expanded from 138-1,104 kHz to 138-2,208 kHz with faster frame processing (S = 1/3), by which the rate for downstream transmission can be increased up to 24 Mbps. (G.992.1 Annex I) Furthermore, in Japan, where competition in terms of the transmission rate among ADSL service providers became quite intensified, even non-standard technologies based on G.992.1 (G.dmt) were adopted by them to increase such rate. Some examples of non-standard technologies are as follows. One example is to set the frequency band


85

Figure 3-9. Numbers of DSL lines by the country (top 10 countries) (Excerpted from The Dempa Shimbun Newspaper of June 12, 2004)

Figure 3-10. The diffusions of DSL by the country (top 10 countries) (Excerpted from The Dempa Shimbun Newspaper of June 12, 2004)

used for upstream transmission at 26-138 kHz and that for downstream transmission at 138-3,750 kHz, with the maximum number of bits carried by each sub-carrier increased to 16, with faster frame processing (S = 1/6), and with a maximum rate of 40 Mbps for downstream transmission. This technology sets the upper limit of the band for downstream transmission at 3,750 kHz to avoid interfering with the VDSL band plan. Another example is to set a frequency band of 26-483 kHz for upstream transmission and a frequency band of 26-3,750 kHz for downstream transmission, using an echocanceller technology to use the overlapping frequency bands for upstream and downstream transmission in order to increase the rate of upstream transmission. This technology was based on the background that the customer needs for data transmission

86


by means of ADSL services shifted from downloading files to both-way data transmission. This technology sets the maximum number of bits carried by each subcarrier at 18. There was heated discussion in TTC on the adoption of this technology. TTC established limits of distance from an exchange station building within which the provision of ADSL services are permitted in the spectrum management. 3.3.6. POTS Signal Superposing Technology The ADSL service is based on the shared use of cables with the telephone service. So the frequency bands for telephone line and those for ADSL are divided. To divide the former from the latter, splitters (for homes, Figure 3-11) to separate the telephone lines from the ADSL lines are adopted, and filters are used so that ADSL signals cannot affect the telephone lines and telephone signals cannot affect the ADSL lines. There are two types of filter: LPF (low-pass filter) that cuts the frequencies higher from the telephone band (4 kHz) and HPF (high-pass filter) that cuts the frequencies lower from the ADSL band. HPF, however, has little effect on ADSL because of the characteristics of the ADSL device, and therefore, the filters in current use are only LPF. Accordingly splitters can be made compact. A splitter is necessary both at station equipment (station equipment building) and a modem (customer’s home), and is installed as shown in Figure 3-12.

Figure 3-11. ADSL home splitter

Figure 3-12. Configuration of ADSL service

3.3.7. Example of DSL Service This section presents the growth of ADSL services and the market shares of the major ADSL service providers in Japan (Figures 3-13 and 3-14, as of December 2005). Such data is released by the Ministry of Internal Affairs and Communication on a quarterly basis. (Refer to URL: http://www.soumu.go.jp/joho_tsusin/joho_tsusin.html).


87

Figure 3-13. Number of ADSL service contracts (source: Communication White Paper 2005)

Figure 3-14. Changes in market shares of ADLS service providers (source: Communication White Paper 2005)

An example of an ADSL service provided in Japan is shown below. NTT publicly discloses the distance from an exchange station building to a customer’s home through the line information disclosure system. When a service provider receives an application from a customer, the provider is able to check whether it is able to provide the customer with its ADSL service through the system in advance.

88


Figure 3-15. Image of ADSL service (e.g.,NTT East Japan (http://flets.com/adsl/index.html))

3.4. FTTx Networks 3.4.1. IP and Optical Access Technologies The main features of optical transmission technologies are high speeds and long reaches. Therefore, these technologies were originally developed for the trunk networks of plane switching telephone networks (PSTNs). These technologies enabled


89

fully digitalized and simply configured PSTN trunk networks. On the other hand, the transmission technologies for the access lines of telephone services require transmitting only 4 kHz analog signals for analog telephone services and about 128 kb/s digital signals for ISDN (integrated service digital network) services. These can be achieved with metallic lines, so optical transmission technologies do not need to be used for conventional telephone services. The use of optical transmission technologies in the access networks of PSTNs is limited to user multiplexing equipment, such as central terminal, remote terminal (CT/RT) systems. A CT/RT system is shown in Figure 3-16. The RT is at a location remote from the CT in the central office. The RT is connected to hundreds of metallic telephone lines and is connected to the CT by optical fibers. The telephone signals for hundreds of users are carried in the optical fibers.

Central office (a) CT/RT system

RT

CT

Metallic lines

(b) pi-system

OLT

Optical fibers

ONU

Splitter Optical fibers

Figure 3-16. Systems for telephone service.

To provide broadband services, optical transmission would apparently be necessary. The first large-scale FTTH trial, Hi-OVIS project, was implemented in Japan from 1978 to 1986. At that time, no concrete broadband service was commercially available; however, people believed that FTTH would be necessary in the future. Optical fiber cables take a considerable amount of time and money to install, so carriers had to gradually install large numbers of optical fibers as an anticipatory investment before optical services would become prevalent. Therefore, the optical transmission technologies for access networks have been developed mainly for the telephone service to replace old metallic cables with optical fiber cables. However, the high cost of optical devices and cable installation limited the installation of optical access systems. The small amount of shipping of the optical systems kept the cost of optical devices high, and the high cost of optical devices limited the number of optical systems installed. In 1987, J. R. Stern et al. proposed a new concept called a passive optical network (PON) architecture [1]. It is based on an optical device in the central office and optical fiber sharing by multiple users, and it effectively reduces the cost of optical access systems. An outline of a PON system is shown in Figure 3-17(a). The optical line terminal (OLT) located in the central office is connected to multiple optical network

90


units (ONUs) using optical fibers and a splitter. In this system, the optical device in the central office and the optical fiber from the OLT to the splitter are shared by multiple ONUs. Therefore, the cost per user is dramatically reduced.

(a) P2MP Splitter

Fiber

OLT

ONU Single or double fiber (b) P2P Equipment in the customer’s house

Equipment in central office

Figure 3-17. Optical access architecture: point-to-multipoints and point-to-point

Using PON architecture, NTT (Nippon Telegraph and Telephone Corporation) developed the pi-system [2][3][4] in 1998. This is a “fiber to near the home” system for telephone service and costs the same as metallic lines. It is based on PON architecture, and one ONU is shared by multiple telephone lines. The pi-system is shown in Figure 3-16(b). The ONU is typically located on a telephone pole or on a wall of a condominium. Using the pi-system, NTT started to install optical fibers widely in the field; however, the wide diffusion of FTTH required a new broadband service on the optical fibers: Internet access. In early 1990s, the main method of accessing the Internet was dial-up. As the Internet access traffic increased, carriers had to increase the performance of their telephone networks. However, the telephone networks were not suitable for Internet access use. They were constructed for telephone traffic, and the traffic patterns and required bandwidth of the telephone networks are different from those of IP communication. To meet the demand for the increasing IP communications, carriers wanted to invest in IP networks instead of in telephone networks, and users wanted more bandwidth and always-on network access methods. Due to the consistency of these demands, commercial services using high-speed access technologies, such as ADSL, CATV, and FTTH, rapidly and widely spread. NTT started an ADSL field trial in 1988 and a trial ADSL commercial service in 1999. Many other companies also started ADSL simultaneously in Japan. An FTTH service was started in 2000 at 10 Mb/s by NTT. In the next year, NTT and other operators started 100 Mb/s FTTH services. The increase in the line rates of ADSL and FTTH services provided by NTT is shown in Figure 3-18. In Internet access services, ADSL is still a major player. Due to the strong competition, ADSL speeds have increased rapidly in the past 6 or 7 years, and the intervals between upgrades have become shorter and shorter. However, recently, users may be finding differences between the actual speeds and the advertised values. Therefore, they will


91

not want higher speed ADSL, and they will change their access lines to FTTH. On the other hand, FTTH services have been providing 100 Mb/s service since the early stage and continue to do so.

1999 2000 2001

FTTH

ADSL

2002 2003

2004

2005 2006 2007 1 Gb/s

100 Mb/s 10 Mb/s 47 Mb/s 40 Mb/s 24 Mb/s 12 Mb/s 8 Mb/s 1.5 Mb/s

500 kb/s 64 kb/s

ISDN Figure 3-18. Internet access speed evolution in Japan

The growth of broadband users in Japan is shown in Figure 3-19. The number of FTTH subscribers has been rapidly increasing. The number of ADSL users grew rapidly when it was first introduced; however, its growth slowed gradually. The number of ADSL users started decreasing in 2006. On the other hand, the number of FTTH users continues to grow gradually, and it exceeded that of ADSL in early 2006.

Number of subscribers (million) 16 14 ADSL

14.0M

12 10

8.8M

8 FTTH 6 4 3.6M CATV

2 0 Mar. 2002

Mar. 2003

Mar. 2004

Mar. 2005

Mar. 2006

Mar. 2007

Figure 3-19. Increase in broadband subscribers in Japan

92


3.4.2. Optical Access Technologies 3.4.2.1. Overview of Access Network An overview of an access network is shown in Figure 3-20. This shows a PON. An OLT is connected to an ONU through an inside optical splitter, underground feeder cable, aerial distribution cable, outside optical splitter, and drop wire. To make this configuration possible, fibers, plants, wiring, civil engineering, systems, and so on have been intensively researched and developed for more than 30 years. In this section, we describe the system.

Central Office Access point Customer’s house

IDM OLT Feeder point

Distribution Drop wire cable section

splitter

Feeder cable section

Figure 3-20. Configuration of access network

3.4.2.2. Bi-directional Transmission on One Fiber In optical access, the cost of the fiber is the majority of the total cost. Major carriers must provide optical fibers for other telecommunication carriers due to the fiberunbundling regulation in Japan. These fibers are called dark fibers, and they are charged per fiber. Therefore, to effectively use fibers and reduce monthly charges for their customers, optical access systems usually use bi-directional transmission in each fiber. If one-direction transmission on each fiber is adopted as a LAN configuration, the carrier has to charge twice for the access fibers. There are many technologies for bi-directional transmission, including direction division multiplexing (DDM), time compression multiplexing (TCM), and wavelength division multiplexing (WDM), as shown in Figure 3-21. DDM is the simplest way to multiplex bi-directional signals in one fiber. It can be used without an optical device for direction division. It can use the same optical components for the upstream and downstream directions. Therefore, DDM is the most cost-effective method. However, using this technology, a signal and a reflection cannot be distinguished. Therefore, DDM can be adopted only in an environment where the power of the main signal is larger than that of the reflection. In optical transmission, reflections cannot be avoided at fiber connecting points and connecters of the equipment. This limits the transmission distance. Therefore, DDM is not used for optical access systems.


(a) DDM

93

wavelength O1 O1

Transmit Receive

(b) TCM

wavelength

Timing for transmitting

O1 Time scheduling

Timing for receiving O1 (c) WDM wavelength Transmit Receive

O1

O2

Figure 3-21. Bi-directional transmission technologies

TCM is based on controlling the timing of upstream and downstream signals to avoid transmitting these signals simultaneously. TCM can use the same optical components for the upstream and downstream directions, and it avoids effects of reflection. In the early stage of optical access development, the cost of optical devices was a major part of optical access systems. Therefore, because TCM can use the cheapest optical components with 1.3 micron wavelengths, it was used for optical access systems. The pi-system, which will be mentioned in Section 3.4.3.1, is a TCMbased PON system. However, TCM is not suitable for high-speed and long-distance transmission. Due to the timing control of upstream and downstream signals, the line rate must be more than twice the signal rate. A waiting duration that is proportional to the transmission distance is necessary to avoid reflection, and this decreases the transmission efficiency. The signals have to wait for their transmission timing, causing delays. Therefore, today’s optical access systems of 100 Mb/s and 1 Gb/s adopt WDM. In WDM technology, upstream and downstream signals are divided by a wavelength. A 1.3-micron wavelength is used for upstream signals, and 1.55 microns is used for downstream signals for general optical access systems. A WDM filter is located in front of the optical receivers to receive either up or downstream signals. A WDM filter avoids reflection, and WDM technology does not require timing control of transmission, so it can achieve lower delay than that occurs in TCM. However, this technology requires an optical device (a WDM filter) and two kinds of optical transmitters. 3.4.2.3. Point-to-Point and Point-to-Multipoints There are two types of optical access configurations: point-to-point (P2P) and point-tomultipoints (P2MP). The configurations are shown in Figures 3-17 (a) and (b). P2P

94


means a 1-to-1 connection, and P2MP means a PON architecture. To reduce the fiber infrastructure and number of optical devices in the central office, P2MP is suitable for optical access networks. However, P2MP requires multiple access control functions. When the demand density is small, P2P might be advantageous. The principle of the operation of the P2MP system is shown in Figure 3-22. As described in Section 3.4.3, there are many kinds of PON systems; however, the principle of operation is the same for all of them. For downstream transmission, the OLT in the central office transmits signals in a broadcast manner. The ONUs in customers’ houses receive the downstream transmissions and extract the data that is addressed to each ONU. To ensure security, the OLT encrypts downstream data for each ONU. For upstream transmissions, the OLT controls the timing of the transmission of each ONU to avoid transmitting upstream data simultaneously. This control is called time division multiple access (TDMA). It means that the OLT receives upstream data from each ONU in a time series. To operate TDMA, the OLT must have a ranging function by which it measures the distance to each ONU. The OLT transmits the ranging signal to an ONU, and it measures the time until a response is received. Downstream signal multiplexing: TDM

A

A

A B A A B A C

B

A B A C

C

A B A C

OLT

ONU Upstream signal multiplexing: TDMA A

A A B C

B C

B C

OLT ONU Figure 3-22. Principle of P2MP system

For synchronous transmission mode (STM), fixed time slots and intervals are allocated to each ONU. The traffic of IP communication does not require a fixed bandwidth unlike with STM. Allocating bandwidth dynamically for ONUs that demand bandwidth is more effective for IP communication than allocating fixed bandwidths. To control bandwidth this way, dynamic bandwidth allocation (DBA) has been developed for PON systems. A schematic view of a DBA mechanism is shown in Figure 3-23. Each ONU that will transmit upstream data requests permission to transmit from the OLT, and the OLT dynamically calculates the timing of the transmission for each ONU based on these requests and sends permission to each ONU. The first DBA algorithm was developed on the STM-shared PON system by NTT, and


95

a DBA protocol was standardized in G.983.7 for B-PON systems by ITU-T and in IEEE 802.3ah for EPON systems. ONU

OLT Request

IP packet(s)

Bandwidth calculation and scheduling Permission (with transmission timing) Data (IP packets)

Figure 3-23. Basic DBA protocol

3.4.3. Optical Access Systems Many kinds of optical systems have been installed in the Japanese FTTH market for Internet access services. In this section, some major systems are described. The features of these systems are shown in Figure 3-24. The TS-1000 is a P2P system, and the STM-shared PON, B-PON, GE-PON, and G-PON are P2MP systems.

Target transmission length (m) 100k

IEEE802.3ah GE-PON (1000BASE-PX10,PX20), ITU-T B-PON, G-PON

TTC TS-1000

1000BASE-BX10

10k

100BASE-BX10 100BASE-LX10

1000BASE-LX10

1000BASE-LX

1k

Single-fiber (with OAM) Double-fiber (with OAM)

100BASE-FX Double-fiber 1000BASE-SX Twist pair cable

100 10BASE-T

10M

100BASE-TX

100M Bit rate (bit/s)

1000BASE-TX

1G

Figure 3-24. Features of optical access systems

96


3.4.3.1. STM-shared PON System and pi-system The STM-shared PON system [5][6] was developed in 1998 for Ethernet communication using the unused bandwidth of the pi-system, which was developed to provide telephone service. The pi-system [2][3][4] is a STM-based PON system that is configured with TCM-based bi-directional transmission on 45-Mb/s PON architecture, and it achieves 16 Mb/s of upstream and downstream STM transmission. POTS and/or ISDN services for 32 ONUs require about 6 Mb/s including STM and PON overhead bandwidth, so about 10 Mb/s of unused bandwidth remains on the pi-system. In the STM-shared PON system, the unused bandwidth is assigned as shared bandwidth for 32 ONUs, and it enables an effective Ethernet communication service. For fixed bandwidth assignment mechanisms such as STM paths, the assigned bandwidth for each ONU is about 300 kb/s (1/32 times 10 Mb/s). On the other hand, in the STM-shared PON system, an ONU can be assigned a maximum of 10 Mb/s when other ONUs are not sending Ethernet frames and a minimum of 300 kb/s when all other ONUs are sending frames. The STM-shared PON system was implemented with an algorithm for fair use of bandwidth. The frame structure of the STM-shared PON system is shown in Figure 3-25. In the periodic burst duration, the downstream frame and upstream frames are defined. A reflection avoidance duration is between the downstream frame and the group of upstream frames. An STM path for each ONU is assigned as a fixed channel, and shared channels are defined in the frame. Using the header part of the fixed upstream channel, an ONU sends bandwidth requirements, and the OLT sends permission to use a shared channel to an ONU using the header part of the shared channel. The ONU sends Ethernet frames using the assigned shared channel in the next burst duration. The OLT fairly assigns the permission to use the shared upstream channel to each ONU. Burst period Downstream frame

OLT

OH ONU 1

ONU n

Upstream frames ONU 1

Shared channel

ONU n

Shared channel

Fixed channel

OH (overhead) includes ONU number that can use upstream shared channel. In this case, it is ‘1’.

ONU-1

OH ONU 1

ONU n

Shared channel

In header part of each fixed channel, ONU sends bandwidth requirement.

ONU 1

Shared channel

Figure 3-25. Frame structure of STM-shared PON system


97

Downstream data are sent in a broadcasting manner, so the OLT sends Ethernet frames to ONUs in a fair queuing manner. 3.4.3.2. Media Converter and TS-1000 P2P architecture is effective for areas with low densities of users. Therefore, P2P systems were installed mainly in the early stage of FTTH deployment. For Ethernet transmission, P2P equipment is usually called a media converter because its basic function is to convert electrical signals to optical ones. However, in P2P systems for optical access services, media converter systems are not limited to converting mediums but have layer two or higher layer functions such as bridge functions and operation and administration management (OAM) functions. In 2002, the Telecommunication Technology Committee (TTC), which is the Japanese standardization body for telecommunication, published technical specification TS-1000 for 100 Mb/s P2P transmission on a single fiber for Japanese FTTH use. At that time, there was already a series of standards for the B-PON system; however, there was no standard for the P2P access system. Therefore, TTC developed the first specification for the Internet access P2P optical system in the world. TS-1000 is “Optical Subscriber Interface-100-Mb/s Single-fiber Bi-directional Interface by WDM.” Due to the wide spread of TS-1000-based P2P systems throughout the world, this specification was used as the specification of the physical layer of 100-Mb/s WDM transmission in the international standards of IEEE 802.3ah and ITU-T G.985. The layer structure defined by TS-1000 is shown in Figure 3-26. To use ordinary silicon chips of 100BASE-FX, TS-1000 defines new physical media dependent (PMD) and OAM sublayers and uses the physical coding sublayers (PCSs) and physical medium attachments (PMAs) of the IEEE 802.3 standard.

Media converter MAC bridge Repeater MII

OAM sublayer

MII

MII

PCS PMA PMD for single fiber Medium (SMF)

PCS PMA PMD Medium (UTP)

Figure 3-26. Layer structure of TS-1000

TS-1000 has three classes of about 10 km, 20 km, and 30 km transmission, classes S, Ar, and B, as shown in Table 3-2. Class S is the most popular specification in TS1000. Class S is defined to minimize the cost of optical devices such as laser diodes (LDs) and WDM filters for Japanese FTTH distance and fiber network conditions. It can use a multi-longitude-mode (MLM) laser such as a Fabry-Perot LD (FP-LD),

98


which costs less than a single-longitude-mode (SLM) laser such as a distribution feedback LD (DFB-LD) for both OLT and ONU. Table 3-2. Line-up of TS-1000 Class S

Class Ar

Class B

16 dB

21 dB

26 dB

Target reach

About 10 km

About 20 km

About 30 km

fiber

Single SMF

Single SMF

Single SMF

Laser

Multi longitude mode

Multi longitude mode

Single or Multi longitude mode

Power budget (includes penalty)

The operation administration and maintenance (OAM) function is necessary for optical access systems; but it is not necessary for local area network (LAN) systems. TS-1000 defines a new OAM function to monitor the status of ONUs, such as power supplies and the link status of ONUs, and to test the optical access link using loopbacks. In TS-1000, a new OAM frame with 12 bytes is defined. This OAM function is easy to implement using conventional Ethernet devices; however, it cannot be used for systems with different line rates and P2MP systems. Therefore, the OAM of TS-1000 was not adopted for the IEEE standard. For 1 Gb/s P2P optical access, 1000BASE-BX10 is given in IEEE 802.3ah. However, it is not widely used in Japanese FTTH because the demand for 1-Gb/s P2P access for mass use have not been so large in Japan, and 1000BASE-BX10 has dynamic range of about 10 dB, while TS-1000 class S has that of 16 dB. In 2007, TTC started to discuss a new 1 Gb/s P2P optical access specifications for Japanese FTTH services. 3.4.3.3. B-PON and G-PON The ATM PON system has been developed by the Full Service Access Network (FSAN), which is a group of carriers and makers of optical access systems, and has been standardized by ITU-T. The first Recommendation of ATM-PON was published in 1998, and many additional Recommendations and Amendments for ATM-PON have been published to perfect the ATM-PON system. In Japan, an ATM-PON system with upstream flows of 155 Mb/s and downstream flows of 622 Mb/s has been deployed for Internet access services, and the system is called broadband PON, or B-PON. G-PON is a next-generation PON system that has also been developed by FSAN and ITU-T. G-PON means “Gigabit-capable PON” and is standardized in the ITU-T G.984 series. The series of Recommendations for B-PON and G-PON are listed in Table 3-3. The line-ups of B-PON and G-PON are shown in Table 3-4. B-PON and G-PON have been developed to provide full services including TDM, ATM, and Ethernet services. To provide full services effectively, B-PON is based on ATM, and G-PON is based on a generic frame. Carriers in the USA aim to provide Internet access service, POTS, and T1 services using FTTH, so they are studying the installation of B-PON and G-PON systems, not media converter and GE-PON, which are only for Ethernet transmission. On the other hand, in Japan, FTTH has mainly been deployed only for Internet access, so only


99

Table 3-3. B-PON and G-PON Recommendations Title

B-PON

G.983.1

Broadband Optical Access Systems Based on Passive Optical Networks (PON)

G.983.2

ONT Management and Control Interface Specification for B-PON

G.983.3

Broadband Optical Access System with Increased Service Capability by Wavelength Allocation

G.983.4

A Broadband Optical Access System with Increased Service Capability Using Dynamic Bandwidth Assignment

G.983.5

A Broadband Optical Access System with Enhanced Survivability

G.983.6

ONT Management and Control Interface Specifications for B-PON System with Protection Features

G.983.7

ONT Management and Control Interface Specification for Dynamic Bandwidth Assignment (DBA) B-PON System

G.983.8

B-PON OMCI Support for IP, ISDN, Video, VLAN Tagging, VC CrossConnections and Other Select Functions

G.983.9

B-PON ONT Management and Control Interface (OMCI) Support for Wireless Local Area Network Interfaces

G.983.10

B-PON ONT Management and Control Interface (OMCI) Support for Digital Subscriber Line Interfaces

G.984.1

Gigabit-capable Passive Optical Networks (GPON): General Characteristics

G.984.2

Gigabit-capable Passive Optical Networks (GPON): Physical Media Dependent (PMD) Layer Specification

G.984.3

Gigabit-capable Passive Optical Networks (G-PON): Transmission Convergence Layer Specification

G.984.4

Gigabit-capable Passive Optical Networks (GPON): ONT Management and Control Interface Specification

G-PON

Table 3-4. B-PON, G-PON, and GE-PON B-PON Standard Layer 2

ITU-T G.983 series Frame

ATM cell Up

Data rate Down Layer 1

156 Mb/s, 622 Mb/s 156 Mb/s, 622 Mb/s, 1.25 Gb/s

G-PON

GE-PON

ITU-T G.984 series

IEEE 802.3ah

Generic frame

Ethernet frame

156 Mb/s, 622 Mb/s, 1.25 Gb/s

1 Gb/s

1.25 Gb/s, 2.4 Gb/s

1 Gb/s

Transmission distance

10, 20 km

10, 20 km

10, 20 km

Split ratio

64

64

More than 16

Line up

Class A/B/C

Class A/B/C

1000BASE-PX10, PX20

100


Ethernet transmission is required for optical access systems. This means that a fullservice optical access system is not necessary for Japanese FTTH services and Japanese FTTH services will go to IP-based full service such as VoIP (video over IP) and IPTV (IP television). Therefore, GE-PON systems have been widely deployed in the place of B-PON systems in Japan.

3.4.3.4. GE-PON GE-PON was standardized as 1-Gb/s Ethernet-based PON by IEEE 802.3ah task force in 2004. GE-PON is specialized for Ethernet transmission using technologies for Gigabit Ethernet. B-PON and G-PON are designed to provide full services, so these are ATM-based and generic-frame-based PON systems. In GE-PON, simple transmission technology tuned for Ethernet transmission is used for PON transmission. Ethernet frames themselves are transmitted in PON without being converted into ATM cells or generic frames. Features of GE-PON systems are shown in Table 3-4. In 2006, IEEE started to discuss a new specification for 10-Gb/s Ethernet based PON as IEEE 802.3av. In the task force, a new longer reach specification is discussed to meet Japanese environment. And co-existence with GE-PON and video distribution system is also discussed to realize smooth migration from the existing systems to the 10G-EPON system. The task force will finish standardization in 2009. 3.4.3.5. Video Distribution System There are two technologies to provide video distribution services using FTTH infrastructure. One is IP-based video distribution, and the other is based on radio frequency (RF) transmission. Both technologies are already deployed in Japanese FTTH services. IP-based video distribution is good for video-on-demand (VOD) service because IP is suitable for interactive communication. Broadcasting video distribution is possi-

ONU for IP

TV

OLT for Video

ONU for STB Video OLT for IP

Optical Fiber PC

HE

WDM ONU for IP

IP Network

WDM RF Video, 1.55 Pm IP Downstream, 1.49Pm

HE: Head End STB: Set Top Box

IP Upstream, 1.3 Pm Figure 3-27. Video distribution system using WDM


101

ble using IP multicast technologies; however, IP is not the only way to achieve broadcasting service. An overview of an RF-based video distribution system on an FTTH service is shown in Figure 3-27. The system is made possible by WDM technologies and RF video signals for hundreds of TV channels that are multiplexed on a fiber using a 1.55-micron wavelength. The wavelength allocations of B-PON, GPON, and GE-PON allow this video distribution wavelength. The RF signals can be distributed by splitting and amplifying; therefore, a cost-effective backbone network with optical splitters and amplifiers can be constructed. The RF signals can be received by a conventional TV without a special set top box (STB) such as an IP-STB. Using this RF-based video distribution system, the same service as CATV (community antenna television) can be provided on the FTTH infrastructure. 3.4.3.6. VDSL Systems for Condominiums To provide optical access services for condominiums, installing optical fiber cables is always difficult. Existing condominium buildings usually have no space for installing the additional cables. Therefore, in many cases of FTTH service for condominiums, optical fiber cables are installed in the entrance space of the condominium building, and the existing metallic cables for POTS are used as intra-building wiring. The configuration of an FTTH service for a condominium is shown in Figure 3-28. VDSL (Very high-bit-rate Digital Subscriber Line) technologies are used to provide highspeed services of up to 100 Mb/s. VDSL lines, multiplexing equipment, and an ONU are set in the entrance space of the condominium, and services for many subscribers are provided on one access fiber. Condominium VDSL Modem Central Office

OLT VDSL Switch ONU Optical Fiber

Figure 3-28. Configuration for condominium FTTH service

3.4.4. Services 3.4.4.1. Access Protocol The optical access system for an Internet access service provides an Ethernet interface. An OLT for Internet access usually has an Ethernet interface to connect to a service edge router. An example of an access network configuration is shown in Figure 3-29. To use the interface on the edge router efficiently with many users, a layer 2 switch (L2SW) is installed between OLTs and the edge router. The interface between the

102


OLT and the edge router has two types of L2 configurations. One is used to separate users by VLANs (virtual LAN), and the other is used to construct one L2 network domain for multiple users. OLT

L2SW

Edge Router

Ethernet

Ethernet Figure 3-29. Example of access network configuration

In the first configuration, users are separated by VLANs, so L2 connections between users are prohibited. An IP subnet is constructed for each user. This means that this configuration maintains security by prohibiting false IP addresses, L2 broadcast communication between users, and so on. However, this configuration requires many subnets per user and more than four times as many IP addresses as users. On the other hand, in the second configuration, multiple users use one IP subnet. This means the number of IP addresses can be minimized. However, some security problems can occur in this configuration. For example, an error in the IP address configuration of user equipment can cause interference in another user’s communication. If ARP, NDP, and DHCP packets are transmitted from one user to another, one user can set a false IP address to the other user’s equipment, and one user can act as an edge router. To prevent these security problems, some mechanisms are usually adopted in the access system, such as L2-broadcast filters between users and filters related to IP and MAC addresses. PPPoE and native IP are common access protocols. PPPoE is defined in RFC 2516 to transmit point to point protocol (PPP) over an Ethernet. Native IP means IP packets over an Ethernet frame. Using PPPoE, carriers can use an existing authenticate, authorize, and accounting (AAA) system, which is constricted for the dial-up access services, as a user and service management system for the broadband service. Therefore, Internet service providers who have already been providing dial-up services usually adopt PPPoE as the access protocol of their broadband access services. Using PPPoE solves the problem of the number of IP addresses in the per-user VLAN configuration because an IP address is assigned for each PPP connection. In the case of native IP, IP addresses and server addresses are configured to user equipment using DHCP. It is a very simple method of optical access because authentication is not necessary for the fixed wire access. 3.4.4.2. Fair Access When providing a public service, fairness should be maintained between users. As described in Section 3.4.2.3, PON systems have DBA mechanisms for upstream transmission control, and DBA enables fairness between users. In the access network


103

shown in Figure 3-29, the L2SW aggregates OLTs, and multiple OLTs are connected to one edge router. The L2SW is a bandwidth-narrowing point in the upstream 10 TCP sessions Single TCP session Switch

1.2 throughput

1.0 heavy user with 10 TCP sessions

0.8 0.6

general user with single TCP session

0.4 0.2 0.0 0

5

10

15

20

25

30

time (sec) (a) Unfairness caused by numbers of TCP sessions

High-speed traffic input of wire rate Low-speed traffic input of less than wire rate Switch Throughput (%) 100 95

High-speed input

90 85 80 75 70

Low-speed input

65 60

1

1.01

1.02

1.03

1.04

1.05

Bandwidth reduction ratio in the switch (b) Unfairness caused by implementing a L2SW Figure 3-30. Examples of unfair use

104


direction. To keep fairness between users, all bandwidth-narrowing points should have fairness control functions. In IP communication, network congestion is avoided mainly by congestion avoidance functions implemented in terminals. This concept generally works well on the Internet; however, differences between congestion avoidance algorithms or between performances of terminals cause unfairness. We will show three examples. The first is the coexistence of terminals with and without congestion avoidance mechanisms. TCP includes congestion avoidance mechanisms. When a TCP session and an UPD session with constant rate transmission join at a bandwidth-narrowing point such as a L2SW, the throughput of the TCP session decreases because of the congestion avoidance mechanism of the TCP. The second example is the coexistence of a multiple TCP session user and single TCP session user. The throughputs of a user with 10 TCP sessions and of a user with one TCP session are shown in Figure 3-30(a). When this user traffic joins at a L2SW, each TCP session decreases its transmission rate because of packet loss, and some TCP sessions are disconnected by the TCP algorithm. Therefore, the user with many TCP sessions will get more bandwidth than the user with a single session. The third example is related to the implementation of switches. To enable highspeed transmission, many switches are implemented to keep performance high for flows with high traffic rates. An example of unfairness caused by the implementation of a L2SW is shown in Figure 3-30(b). In this case, a traffic input with a wire rate and a traffic input with a low rate are output into one port on a L2SW. If the L2SW works in a fair manner, it will control traffic to maintain the packet loss rate or to maintain the bandwidth. However, in this L2SW, the packet loss of the traffic with lower rates is larger than that with higher rates. These examples show that heavy users tend to get more bandwidth in IP networks. Therefore, the public network services provided by carriers should have functions to control fairness between users. 3.4.4.3. Priority Control As described in Section 3.4.4.2, quality must be maintained at every bandwidthnarrowing point. IP is used for many kinds of communications such as Web, video distribution, and voice. For Web access using TCP, packet losses decrease throughput but do not reduce quality. However, for real-time transmission such as streaming video or voice distribution, packet losses reduce the quality of content. Therefore, networks should provide quality of service (QoS) functions. In access networks, the numbers of users are not so large compared with those of core networks, and the influence of a heavy user or a heavy traffic flow is large. Therefore, QoS functions are important in access networks. To provide real-time services on IPs with high quality, access networks must provide QoS functions with priority controls in the near future.

References [1] J. R. Stern et al., “Passive optical local networks for telephony application and beyond,” Electronics Letters 1987, vol. 23, pp. 1255-1257. [2] K. Harikae et al., “New Optical Access System (pi-system),” NTT review, vol. 10, no. 2, 1998, pp. 69-76. [3] K. Harikae et al., “The world’s first practical FTTH system,” Globecom ’98, 1998, pp. 171-175.


105

[4] Y. Shibata et al., “New Fiber to the near home system using PDS technology,” Globecom ’98, 1998, pp. 77-81. [5] N. Miki et al., “Optical Access System suitable for Computer Communication,” Globecom ’98, pp. 82-87, 1998. [6] Y. Fujimoto et al., “Transmission method using bandwidth-sharing for multi-grade high-speed access services,” proc. BAC ’99. pp. 15-21, 1999.



107

Chapter 4

Backbone System 4.1. Backbone Systems 4.1.1. Current Situation of the Backbone The rapid dissemination of video services like Gyao in addition to a P2P type application like Skype is putting pressure on the network resources established by other business enterprises, which is acknowledged as a big problem. Originally, the communication network in Japan was structured by interconnecting in a highly complicated manner the networks constructed by numerous private ISPs (Internet service providers), and the extent of the complexity of the interconnection was abruptly elevated due to the rapid expansion of broadband in 2002 and subsequent years. It is difficult to obtain an intended service without passing multiple networks or ASs. However, the service gained when passing an AS is arbitrarily established by the relevant ISP, making the rule opaque. This is the biggest reason for the rise in infrastructure free-ride complaints. In addition, it should be noted that it is difficult, or practically impossible, to determine the quantitative data, i.e. measurement of Internet traffic, that constitutes the basis for establishing the rule. Cooperation from some ISPs for integrated data measurement is not enough to accurately grasp the flow of Internet traffic in regional business (administration) units because the Internet is constructed on various communication systems and the system construction is not necessarily consistent with the administrative division. The communication systems used by the major ISPs are classified into two parts: backbone and user access. The former uses optical fibers, and the latter metal wire (telephone wire), optical fiber or wireless. Moreover, right holders independently exist for each such physical circuit with the border point of right established at the connecting device to which the circuit is connected and that is installed in an NTT building, on the top of a building or an electric pole, or in an indoor facility. Moreover, the communication system operated using those separately owned sections forms an extremely complicated construction due to the combination of the operation of an ISP’s own property and the operation of rented property. Each ISP uses the circuits that connect relevant areas by renting NTT’s optical fiber in units of cablecore or multiplexed wavelength. In addition, each ISP brings its communication devices to the NTT buildings in the areas in question and connects the rented circuits to them, by which the relevant areas are connected independently. What should be noted here is that ISPs bring in their communication devices arbitrarily. When the devices brought in are those that provide the connection of a data link layer of L2, which is generally called “switch,” relevant areas are connected by the L2, allowing any protocol in the upper layer. It follows that the L3, the upper layer of the L2, can be used as an Internet medium when it is the IP (Internet Protocol). The L3, however, need not be the IP. To sum up the matter, regarding the circuits that NTT rents out or that each ISP prepares itself, whether or not the method of connection between relevant communi-

108

Chapter 4. Backbone System

cation systems is an upper layer or lower layer (L2 or L3) is, due to its service characteristics, determined by the type of device the ISP brings in. This is where the measurement technique and measurement class of the Internet traffic is determined. In general, the upper layer makes it easy to perform measurement focusing on the status of the application and the lower layer tends to perform measurement of traffic at no more than the bit level. The level of compatibility between this measurement classification and an administrative regional unit determines how appropriate measurement can be realized for the administrative unit in question. Illustrations of ISP form are given below: Example A) NTT’s FLET’S ADSL and B-FLET’S are separated by an IP device (L3) at each NTT building, providing a basically very high compatibility between the NTT building and relevant administrative unit area. This means that areas are almost always separated by the L3. Example B) A certain ISP’s network is divided into regional block units (e.g. Kanto block, Kinki block, etc.), within which connection is made by data link L2. Seen from the aspect of the interconnection of the L3, the entire region appears to be a single network system. Example C) Another ISP makes an L3 connection only in units as large as East Japan and West Japan, making it difficult to grasp the Internet traffic quantitatively focusing on information “granularity” in administrative area units such as prefectural divisions. Thus, from the aspect of technical level with respect to the interconnection of a network system, the traffic at the L3, or the traffic due to the Internet protocol is not

Figure 4-1. Current status of ISP’s communication infrastructure (Rented circuits typically made of optical fibers)


109

necessarily dependent upon a region. In fact, most ISPs are operated independently of the prefectural administrative regional division. 4.1.2. Domestic Backbone Connecting Method Internet traffic is increasing incessantly in quantity and diversifying in nature. Traffic quantity continues to increase on a day to day basis, which is evident from the publicly disclosed IX (Internet exchanger) data. This is considered to be mainly due to the fact that the structure of expanding the use of access line, which stemmed from the development of broadband, has already been established, as shown below.

Figure 4-2. Structure of expanding Internet traffic

On the other hand, the diversifying nature of the traffic results from the change in the usage pattern of applications as shown below: x x x

Use of large capacity contents owing to the band broadening of access line Improvement of application performances thanks to the improvement of the processing ability at terminals Expansion of the communication form that enables users to transmit information, such as TV phone, the P2P application, etc.

Such quantitative and qualitative changes of traffic greatly influence the operation of the domestic backbone by ISPs and IXs. It is considered essential to appropriately promote the improvement of the domestic backbone by the demand estimate and planning based on the structural analysis of Internet traffic. To grasp the backbone demand under the existing circumstances, it is necessary to analyze the traffic routes and the peak traffic flow rate. This is, however, difficult in practice, the main reasons for which are that various connection methods are combined as shown below: A) Traffic exchange via IX: Each ISP connects itself to the IX, controlling traffic exchange between ISPs by the IX B) Private peering ISPs directly connect each other individually: ISPs arbitrarily connect each other (private peering) for traffic exchange not by way of the IX and the relevant ISPs individually negotiate with each other on traffic control

110


C) Transit to relay information via other ISPs: Relaying the traffic received from other ISPs to the final destination Backbones are formed according to a combination of the situation at a connection point and the convenience of businesses. Therefore, a measuring method accommodating these network structures is required to accurately grasp the traffic flow to the backbone. The questionnaires the Ministry of Internal Affairs and Communications implemented toward ISPs at the workshop show that the ratio of the above three connecting methods is approximately 1:1:1. However, it is difficult in practice to grasp the structure and status of the backbone from this result alone because (i) the response rate is as low as 10 %, which is too low to represent all of the ISPs, and (ii) the traffic structure and flow rate are changing incessantly.

Figure 4-3. Abstract of Network Topology

Figure 4-4. Capacity of circuits connected between major ISPs by type (Source: Prepared by MRI, based on the primary report of “Next Generation IP Infrastructure Workshop” sponsored by the Ministry of Internal Affairs and Communications, June 2004)


111

In addition, the information on backbone traffic is extremely important management information for ISPs’ and Ixs’ business activity, which makes the disclosure of detailed data difficult. This is also one of the reasons that makes the structural grasp of the Internet as a whole difficult. To estimate demand, therefore, there is no other choice but to assume new traffic generating sources, aside from the existing traffic, and to estimate the maximum potential demand from the potential intended use. 4.1.3. Regional Structure of Domestic Backbone Today the majority of domestic traffic is concentrated in Tokyo with a small part of it accommodated in Osaka and other regional IXs. This is because the backbone is established so that ISP businesses can conduct traffic exchanges around IXs situated in Tokyo. The traffic produced in respective regions passes through Tokyo in principle and then goes to the final destination except traffic that can either be accommodated in the regional IX as described above, or be processed in the same ISP facilities. This is not necessarily a good structure from the aspect of traffic exchange efficiency. When the proximity of an IX in Tokyo is hit by a major disaster, for instance, all traffic in Japan will be seriously affected. Moreover, a transmission from Sapporo to Aomori currently goes through Tokyo, which is not only inefficient in transmission, but also requires large capacity investment in IXs and ISPs due to traffic concentration in Tokyo. To improve this situation, a study has begun to disperse IXs all over Japan with a view to completing within a region processing traffic that can be processed within the region. The attempt is in progress in some regions. However, the existing Tokyoprocessing structure is still superior in efficiency at present and the regional IX does not function adequately as yet. Besides, aside from the Internet structure, there is the reality that economic activities and population are concentrated in Tokyo. Therefore, it is considered that a considerable amount of Tokyo-destined traffic will remain even after the regional IX has been established. The existing status of the domestic backbone has not been adequately disclosed. But judging from the questionnaires conducted by the Ministry of Internal Affairs and Communications toward ISPs, the connection capacity in Tokyo, Osaka and overseas IXs will be estimated as follows. It should be noted, however, that the IX capacity is not equal to the total backbone amount because traffic exchange is made not only through IXs, but also through ISP-to-ISP private peering around IXs. Also, no business or body has fully grasped the entire situation of ISP-to-ISP private peering though individual situations are grasped by the relevant parties, making it impossible to accurately measure the connection capacity around IXs. There is a view, however, that the total backbone capacity is equal to approximately 7 to 10 times the IX capacity. This view has been gained from the statements from ISP and IX businesses in which they cited this figure from their experience as a result of their operation. Use of this figure provides an estimated total domestic backbone circuit capacity of 2,300 Gbps (2.3 Tbps), which was derived from multiplying 230 Gbps (182 Gbps + 48 Gbps given below) by 10. Meanwhile, judging from the statements from ISPs, it can be assumed that approximately 70 % of the total traffic, including both upstream and downstream traffic, is occupied by the traffic between Tokyo and Osaka, although this figure may not necessarily reflect the reality due to an ISPs’ low response rate of 10 %. That Tokyo -

112


Osaka traffic occupies 70 % of 2,300 Gbps means that the backbone capacity between Tokyo and Osaka is approximately 1,600 Gbps. 䠐䠔䠣䠾䡌䡏

182䠣䠾䡌䡏 182䠣䠾䡌䡏㻞㻜㻜㻚㻜

㻞㻜㻜㻚㻜

㻝㻤㻜㻚㻜

㻝㻤㻜㻚㻜

㻝㻢㻜㻚㻜

㻝㻢㻜㻚㻜

㻝㻠㻜㻚㻜

㻝㻠㻜㻚㻜

㻝㻞㻜㻚㻜

㻝㻞㻜㻚㻜

㻝㻜㻜㻚㻜

㻝㻤㻞㻚㻜

㻝㻜㻜㻚㻜

㻤㻜㻚㻜

㻤㻜㻚㻜

㻢㻜㻚㻜

㻢㻜㻚㻜

㻠㻜㻚㻜

㻠㻜㻚㻜

㻠㻤㻚㻠

㻞㻜㻚㻜

㻞㻜㻚㻜

㻜㻚㻜

㻜㻚㻜

㻝

㻝

Figure 4-5. IX connection capacity in Tokyo and Osaka (and overseas) (Left: Tokyo; Right: Osaka and overseas) (Source: The primary report of “Next Generation IP Infrastructure Workshop” sponsored by the Ministry of Internal Affairs and Communications, June 2004)

4.7%

70.7%

ୗ䜚

16.1%

1.9%

6.6%

1.7%

㻜㻑

15.6% 7.0% 6.6%

69.1%

ୖ䜚

㻝㻜㻑

㻞㻜㻑

㻟㻜㻑

㻠㻜㻑

㻡㻜㻑

㻢㻜㻑

㻣㻜㻑

㻤㻜㻑

㻥㻜㻑

ᮾ㜰 ኱⚟ ᮾྡ ኱ྡ ᮾᮐ

㻝㻜㻜㻑

Figure 4-6. Current status of traffic between major regions (Source: The primary report of “Next Generation IP Infrastructure Workshop” sponsored by the Ministry of Internal Affairs and Communications, June 2004)

4.1.4. Problems with regard to Route Control Information How are ASs (or plainly ISPs and so forth) connected to each other? Nobody inside or outside Japan has fully grasped the complete picture of Internet topology. Nor are route information records (specifically how routes are connected at a given time) grasped. ISPs may possibly have a grasp but do not disclose it. Although the records of BGP (Border Gateway Protocol: one of the typical route control protocols between ASs) and OSPF (Open Shortest Path First: one of the typical route control protocols


113

within an AS) exist, the route processing is not grasped either in terms of space or time possibly because (i) ordinarily BGP is not disclosed and (ii) a specific means to process BGP and OSPF information has not been established yet (as mentioned above, incomplete grasp of Internet topology seems to be responsible for this). As a result, problems with the existing domestic backbone can be summed up as follows: A) Short-term Problems Response to problems that develop on the Internet tends to be of a stopgap nature. In most cases, an action is taken simply to divert the traffic to another route seemingly available at that time. Since it cannot be grasped in advance whether the new route has a sufficient frequency band, and the delay level is unquestionably low, another rerouting is required if the first rerouting is found unsuccessful. This makes it impossible to create a simulation to prepare for a disaster or line disturbance. B) Middle/long-term Problems It is in this state that simulation and verification of the structure, capacity and route processing policy of the network that can respond to the impending change in environment (*) with reference to the Internet is difficult. (*) The following changes are conceivable to name but a few: - diversification and increase in nodes and terminals connected to the network, - diversification and increase in users (class of users, use hour, etc.), - diversification and change in applications used in the network, and - occurrence of traffic and change in the distribution pattern caused by the above. These make it difficult to perform a quantitative evaluation to plan improvement of the backbone with its future in mind. 4.1.5. Problems with regard to Route Control Technique Problems regarding route control techniques, though partially related to the problems regarding route control information in the above, are as follows: A) Efficient Route Control At present, all packets are equally routed, or equally handled in terms of route control, regardless of applications, whether it is a real-time-based application (e.g. video camera, streaming, real-time control of devices, etc.), or non real-time-based application (e.g. web browsing, e-mail, etc.). In other words, “granularity” in route control is “coarse.” Therefore, there is the possibility that the existing route control cannot respond to the future increase in the use of real-time-based applications. Incidentally, the existing video distribution is performed by appropriately locating dedicated servers (edge servers) in the network to maintain its service quality. From the aspect of the total traffic, efficient route control as an entire network is required. At present, the Internet traffic in Japan is on the increase at a rate of 2 to 3 times a year. It is said that the traffic amount of a single provider is approximately 80 Gbps, and Japan as a whole a little less than 500 Gbps at the maximum as of the year of 2005. (According to the Ministry of Internal Affairs and Communications data, and the hearing)

114


To respond to this situation, the increase in circuit capacity and enhancement of routers and switches are required. There is a view, however, that, with the existing technology, such countermeasures will remain effective only for several years, which makes it important to conduct an overall review including the change in topology, and develop new technology (e.g. decentralized route processing, etc.). B) Robust Route Control The fact is that, due to ignorance of route information of the entire network, network administrators conduct route switching based on their experience and expertise, barely managing to maintain a stable operation when problems have occurred. Suppose, for example, when a problem occurs in the proximity of an AS to which he is connected, he changes the route control (amends the routing table) to avert the problem. In this case, it is unknown which route the packet originating from the change from his own AS takes to reach the target network or node. This means that the traffic may possibly encounter an inadequate bandwidth, a delay or another problem in the course of the changed route, offering uncertainty in robustness against problems or degradation in quality. In practice, a change of setting regarding the route control is performed, which is unnecessary if the status of the bandwidth, delay, interference, etc. are grasped with reference to the network toward which a route change is to be conducted. Moreover, these changes of route control are implemented independently at each point, which is inefficient from the aspect of optimization of the entire network. C) High Quality Route Control Installation of the existing TCP (Windows) with a large delay produces no throughput. Therefore, the same bandwidth produces a throughput of 100 Mbps in some regions, and a few Mbps in other regions. In particular, under the existing star-shaped structure with Tokyo at its center, there is sufficient throughput in the vicinity of Tokyo, but remarkably insufficient throughput in regions remote from Tokyo. This is why it is considered important to decentralize traffic, or establish a dispersive route control system. 4.1.6 Prospect of Route Processing Technology From the above, the existing situation and desirable future situation can be compared as follows through the prospect of route processing technology: A) Dispersive Route Controlling and Processing Technology Higher quality: under the existing star-shaped structure with Tokyo at its center, basically all traffic must go through the center (Tokyo), which may possibly lead to the development of a large delay in communication between two bases whose direct distance is short. => This can be averted by a mesh-like dispersive distribution. Securing redundancy: In the case of a star-shaped circuit, the occurrence of an interference in the proximity of the center may result in total failure of the entire network. => The same as above


115

B) “Finely-granulated (or detailed)” Route Control by Application Route control regardless of the application characteristics (e.g. real time nature, extension of communication range, etc.) may induce inefficiency. => Using a separate route control according to the application characteristics (e.g. real-time nature, form of the main use: local communication or Tokyo-centered communication, etc.) will contribute both to communication quality (e.g. delay) seen by users and to route control efficiency of an entire network (separation of local communication from nationwide communication). C) Grasp of Route Control Information The situation is that network maintenance is dependent on personal experience and knowhow due to the inability to grasp information on the route control (overall network structure, status of connection and frequency band in each route, etc.) => Grasping the route information in real time realizes more rational route control and network administration. Ignorance of the route control information makes it impossible to evaluate and simulate the current status of the capacity and efficiency of the entire network. => Grasping the route information and analyzing and developing a model will enable the evaluation and simulation. 4.1.7. Traffic Demand Estimate by Area Areas around Kanto such as Shinetsu, Tohoku and Tokai seem to be strongly connected to Kanto from the aspect of information life, taking on the appearance of being radially expanded from Kanto. In contrast, areas west of Kinki, including Chugoku, Shikoku and Kyushu, connect themselves to multiple areas without having a disproportionate relation to Kanto, taking on the appearance of a multi-centered network. This is considered to be related to the history of the construction of the Shinkansen and highway network and its present status. In West Japan, a high-speed traffic network was constructed in earlier times, which features its matured city activities. In East Japan, in contrast, those infrastructures have been constructed comparatively recently and there are few big cities. The difference between the two districts is exemplified in the area-to-area linkage structure in information communication demand. From now on, should a physical infrastructure construction, which will enhance an area-to-area linkage in real life, precede an information communication infrastructure construction? Or reversely, should an information communication infrastructure construction precede a physical infrastructure construction, by which we can estimate the tendency of an area-to-area linkage and its effect to improve the physical infrastructure including a new development and modification of the existing infrastructure? It can be said that we are now faced with a new dimension from the aspect of a country management policy. This is because our country is already experienced in the advent of creating enterprises and business styles that were previously inconceivable due to the dissemination of the broadband, which means that the preceded improvement in information infrastructure may well bring about a new change in area-to-area linkage in real life and industrial activities. It takes 5 to 10 years to improve a physical infrastructure. In contrast, it may take only one year to improve an information infrastructure. In addition, it is also possible to change dynamically the size of the infrastructure according to the size of the demand.

116


At present, such attractive contents as entertainment are concentrated in Tokyo, which makes the area-to-area linkage in regions other than Tokyo not apparent. When unique contents are developed in every region and they can be inter-distributed through the information communication infrastructure, however, it is thoroughly conceivable that the distribution of the contents will create factors that bring about a new change in the area-to-area linkage. Cuisine culture, health, art, performing art, history and climate, the natural environment, etc. are region-specific, distributable contents yet to be developed. The information life based on them may well bring about innovative changes in regional traffic structure.

Figure 4-7. An example of demand estimate by region from the aspect of final user needs

4.2. NSIPXP; Next Service Provider Internet eXchange Project 4.2.1. History and Objective of NSPIXP NSPIXP is the R&D consortium, established in 1994, in order to fulfill the practical technical investigation on internet exchange system. 1994 is the year the commercial ISP service has launched by IIJ(Internet Initiative Japan, www.iij.co.jp), in Japan. Before 1994, we have had the internet, which are operated by R&D community, without any common internetworking point. This means that, in these days, the academic networks (e.g., TISN, SINET or WIDE) have been interconnected individually, i.e., private peering. We did not have the Internet eXchange (IX), which is the


117

public peering point. The object of NSPIXP is to establish the architecture and operational technologies, to interconnect the academic and commercial IP networks. Since, before the establishment of NSPIXP, IP networks are interconnected by private peering, the AS path length among the network were long. This is because that each network could not peer with all the networks. Also, the quality of communication among the networks could not stable enough, since the network could not control the transit network(s) and the path reach to the destination network. By the introduction of IX(Internet eXchange) point in Japan, the networks could establish larger number of direct peering, than before, with lower facility cost. This is because, by the participation to NSPIXP, the network can establish multiple peering by the single physical circuit. NSPIXP has operated several IXes; NSPIXP-1 (Network Service Provider Internet eXchange Point-1), NSPIXP-2, NSPIXP-3, NSPIXP-6 and DIX-IE(Distributed IX in Edo), based on each R&D purposes. Table 4-1. Feature of NSPIXP systems NSPIXP-1 location

WNOCTOKYO

NSPIXP-2 KDDI Otemachi

NSPIXP-3 NTT Dojima IDC Noda OMP Minato

NSPIXP-6

DIX-IE

KDDI Otemachi

KDDI Otemachi

NTT Otemachi

@Tokyo Toyosu

NTT Dojima

NTT Otemachi MIND Nishi-Oi Abovenet Nihonbashi MCI Shinkawa

Number of Ports

8Î16Î32

30Î50

(10Mbps Ethernet)

(100Mbps FDDI), 70 (1GbpsEthernet)

64(1Gbps Ethernet)

48(100Mbps Ethernet)

64(100Mbps Ethernet)

16(10Gbps Ethernet) 160(1Gbps Ethernet) 64 (100Mbps Ethernet)

Number of ASes

26

62

23

55

75

Peering Policy

L3 WIDE transit Î L2 mesh

L2 Bi-lateral

L2 Bi-lateral

L2 Bi-lateral

L2 Bi-lateral

Operation period

1994-1997

1996-2002

1997-now

1999-now

2003-now

In 1994, NSPIXP-1 has installed at Tokyo NOC (Network Operation Center) of WIDE project. Using the NSPIXP-1, the academic traffic and academic traffic have been exchanged, and the R&D on how the traffic exchanging should be has been progressed. At the beginning, the peering were based on the layer 3 by the transition of WIDE project network. With this peering configuration, the participating network did not need to establish multiple peering to the internetworking networks, but establish only a single peering with WIDE project network so as to interconnect with other networks. However, this operational policy were modified to the layer 2 mesh peering by autonomous peering by the participants.

118


NSPIXP-2 has been established since 1996, based on the R&D results of NSPIXP1, so as to achieve robust and larger system throughput. The general service of NSPXP-2 has been started in 1997, while the operational site has been changed from WIDE Tokyo NOC to KDDI Otemachi. In 1997, NSPIXP-3 has been established so as to have geographical diversity of Japanese IX and for a kind of back up system of NSPIXP-2 in the different location. NSPIXP-2 was located in Tokyo, and NSPIXP-3 was located in Osaka. Technically, NSPIXP-3 were the first (geographically) distributed IX. NSPIXP-3 had two operational sites, at the beginning, and expanded to three operational points in 1999, while increasing the bandwidth from 100 Mbps to 1 Gbps. NSPIXP-6 has been established in 1999, in order to promote the IPv6 (IP version 6) technology. NSPIXP-6 has 55 participants, with pure IPv6 transport. In 2003, DIX-IE has taken over the NSPIXP-2, as the extension of NSPIXP-2. Though NSPIXP-2 had single peering point, DIX-IE had multiple peering points in downtown Tokyo (i.e., Edo). DIX-IE has six distributed peering sites. At the beginning, the interconnecting links among the distributed sites were 2-4 Gbps aggregated Ethernet link using the multiple 1 Gbps Ethernet links partially replaced by the 10 Gbps Ethernet technology.

Figure 4-8. Latest DIX-IE System Topology in Tokyo, Japan

4.2.2. Architecture and Operational Policy 4.2.2.1. Resource and Intellectual Property IX (Internet eXchange) has been operated since end of 1980s, in order to interconnect the computer networks, operated by federal and local governments in USA. These were such as NSFNET, NASA Science Network, DDN or BARRNET. As the IX, FIX and FIX-West are the first age of IX in the world. After the launch of commercial


119

ISPes, several CIX(Commercial Internet eXchange) had launched the operation for commercial ISPes. These activities were mainly focused on the establishment of operational policy and technologies, rather than the academic interests. After the conclusion of NSFNET operation at the end of 1990, the operation of the IX, such as NAP, which handled both academic and commercial networks has been common, i.e., exchange of traffic among academic networks and commercial networks. We could consider that the NSPIXP is the unique activity in Asia investing on such complex IX operation, which would the nature of the Internet system. As the operational policy of IX, there are with layer 2 and with layer 3. As for layer 2 IX, IX provides layer 2 connectivity for the participants, the participants autonomously establish the peering among the participants, whichever they want. As for layer 3 IX, IX operator provides layer 3 connectivity to the participants, i.e., all the participants establish the peering with the IX operator in order to obtain the connectivity to the participants. All the packet to the participants go through the IX operator as that IX operator is the common transit provider for all the participants to the IX. In layer 3 IX, the routing policy is determined by the IX operator. But, in layer 2 IX, the routing policy is determined by each participant. (1) Layer 3 IX Operation in NSPIXP-1 There are two reasons and objectives why NSOIXP-1 adopted the layer 3 IX policy. One was because of too high cost of international link and the other was to establish the operational skill and experiences in every single network operators. (a) We have had to avoid the routing via oversea ISP, since it consume too expensive international link. This means that we wanted to exchange the domestic traffic, locally. This is a strong reason coming from the economical and operational requirement. (b) The other reason why we adopts layer 3 IX policy was that we want to share the same operational issues among the participants, so as to establish the operational technology and personals in Japan. How to control the traffic and routes among academia an commercial ISPes were very important and serious political and technical issue, that we have had to solve. Also, when we adopted layer 3 IX policy, we could force all the participating network providers to exchange full routes between the IX provider (i.e., WIDE project network). This was the best contribution to every network operator, so as to establish their operational skill and experience.

Figure 4-9. Layer 3 IX Operation (in NSPIXP-1)

120


(2) Layer 2 IX Operation in NSPIXP After the layer 3 IX operation in NSPIXP-1, we had decided to transit the operational policy to layer 2 based operation, from layer 3 based operation. This is because of (a) establishment of operational skill and personal in the participating network operators to NSPIXP-1 and (b) increase of complexity of networks in Japan. Each network operator want to fulfill their own operational and routing policy. This could not achieve with layer 3 IX, but could do with the layer 2 IX. This means that the first stage of NSPIXP-1 was a kind of training for participating network operators and the second stage of NSPIXP was a true internet operation, that is based on autonomous operation by every network operator.

Figure 4-10. Layer 2 IX Operation (in NSPIXP-2,3 and in DIX-IE)

There are two types of physical architectures to interconnect the networks, with regard to the two peering policies, This means that we have two times two, equal four types, peering operations. (a) Interconnection via IX (b) Interconnection via private peering (i) Bi-lateral peering (ii) Transit peering With the bi-lateral, the peering is equal. But, with transit peering, the peering is not equal. The transit provider asks the transit cost to the subscriber network based on the link bandwidth and actually consumed bandwidth. The professional and practical operation of the Internet by the various network operators is the combination of the above operational policy. The IX operated by the WIDE project has been played important role in Japan. 4.2.2.2. Routing Control In the inter-domain routing, we adapts the BGP (Boarder Gateway Protocol) for routing control. BGP requires the 5-10 line configuration for each peering network. In the layer 3 IX, what the participant must do is only the configuration with the IX operator. However, in the layer 2 IX, the participant must configure multiple configuration with the peering networks. In the DIX-IE, the participants establishe many peering with the participants. The number of peering is saying about 50. As of 2005, the DIX-IE, the


121

number of participants is 75, and the available ports is 104. In average, the participant has the peering with about 70 % of participants. Many participants configure the AS path filter for appropriate route control. About 50 % of participants configure the AS path filter. AS path filter must be configured per peering. Therefore, the participating network operator must configure a lot of AS path filter. For the major transit provider, the number of AS path filter would be more than 1,500. The total number of AS path filter in the DIX-IE would be few decades thousands. For usual network provider, the number of routing path control is saying few decades thousands. In order to avoid inefficient individual routing policy control, there are some technical challenges, such as RS(Route Server) or IRR(Internet Routing Registry). In RS, the common routing policy is stored in the RS, so that the boarder router could refer to. In the IRR, also the information related with the routing is stored in the IRR server to be referred to by boarder routers. For both architecture, in order to avoid the inconsistent routing control configuration in the distributed boarder router, the commonly referred server is installed. Whether to introduce this kind of referred common database or not would be depends on the skill and ‘the’ policy of operation at each network operators.

Figure 4-11. Number of Peerings in DIX-IE versus number of ISPes

4.2.3. Bandwidth Control 4.2.3.1. Bandwidth Control Policy in NSPIXP The bandwidth control in the NSPIXP did basically depend on the participants, autonomous bandwidth/traffic control by the participants. It was called as “fuse”, in these days. Each operator manages it’s own bandwidth. There was a bandwidth control based on PVC using ATM technology, to maintain the available bandwidth for the peering network. How to control and manage the traffic volume has been always the important technical and operational issue for the Internet and IX operation.

122


4.2.3.2. Traffic Volume and Appropriate Platform Selection When we had started the NSPIXP-1, the total traffic volume, each ISP generated, were about T1, that is 1.5 Mbps. This means that the total traffic in Japan was about 10 Mbps. Therefore, we could accommodate whole of Japanese Internet traffic with 10 Mbps switch. However, according to the increase of traffic volume, we had to transit to higher capacity of platform in NSPIXP, that was the transition to NSPIXP-2 for us. In the NSPIXP-1, we have introduced two Ethernet switches, while these two switches are interconnected by FDDI, that was the final system configuration of NSPIXP-1. In 1997, we have transit to NSPIXP-2 from NSPIXP-1, so as to provide larger bandwidth to network providers in Japan, since the T1 link (1.5 Mbps) were too small bandwidth for the network providers in Japan. Also, at that time, the number of providers, which want to connect to NSPIXP were reached to more than 20. The followings are the key operational policy of NSPIXP-2. (1) NSPIXP-2 never participates in the peering and routing policy, that participants apply. The routing arrangement is left to participating network providers decision. NSPIXP-2 just provides the layer 2 connectivity. (2) NXPISP-2 never apply bandwidth control in the IX fabric. Using the physical link to be connected to IX fabric, the participating network providers can apply their own flow control and bandwidth control, however they want. (3) The switching fabric of NSPIXP-2 provides best-effort and high quality packet switching service to participating network providers. Figure 4-12 gives the system configuration of NSPIXP-2 applying the FDDI technology as the layer 2 switching technology. FDDI is full duplex layer 2 technology with 100 Mbps throughput for each direction. Since the NSPIXP-1 provided 10Mbps Ethernet link to the participants, the NSPIXP-2 provided 10 times larger bandwidth to the participants. Also, the FDDI switch fabric has the “dual home” function, for redundant switching fabric configuration. Through the application of dual home function at NSPIXP-2 switching fabric, the higher operational robustness could be achieved. For example, by the application of dual home function, we could easily update the firmware of switching fabric without service unavailability for the participants. This is because we could fulfill the firmware updating one-by-one, since one fabric could continue the service while the other is rebooting for firmware updating. In NSPIXP-2 operation, we have observed the “head of line blocking”, due to the FIFO queue management at the output queue in the switching fabric. We have consider the technical solution in DIX-IE, that is the successor of NSPIXP-2.

Figure 4-12. FDDI switch configuration in NSPIXP-2


123

Table 4-2 shows the number of ports for each media type, which participating network providers use. Since the media type and it’s bandwidth is not the same, “headof -line” phenomena would easily occur. In order to avoid the head-of-line blocking, flow control for the egress traffic (for participating network provider), i.e., ingress traffic for DIX-IE fabric, should be applied to. Figure 4-13 shows the traffic volume for each port. As shown, the traffic volume has large variance, from few Mbps to few Gbps. DIX-IE operators carefully monitor the traffic volume and pattern for each port, in order to manage the traffic in DIX-IE. Sometime, the connecting interface point to the switching fabric would be reallocated, in order to avoid traffic congestion (e.g., head-of-line blocking) in the switching fabric. This is very hard task, since we could not find out the optimal solution for the system and the system is not closed system. This reallocation of connecting ports has been carried out, when we have the major system updating. It would be about in one or two years. Table 4-2. Number of ports for media type Media Type

# of ISP

10 Mbps Ether

2

100 Mbps Ether

24

1 Gbps Ether

71

10 Gbps Ether

7

㻵㼚㼜㼡㼠

㻻㼡㼠㼜㼡㼠

㻹㼎㼜㼟㻞㻜㻜㻜㻝㻤㻜㻜㻝㻢㻜㻜㻝㻠㻜㻜㻝㻞㻜㻜㻝㻜㻜㻜㻤㻜㻜㻢㻜㻜㻠㻜㻜㻞㻜㻜㻜 Figure 4-13. Average Traffic Volume Per port in DIX-IE

In order to better traffic control, it would be better to monitor the source port and destination port pair for every single packet. However, due to the technical difficulty, we only monitor the total ingress and egress traffic volume of each port. As the latest trial, we have start to use the sFlow technology, which is based on sampled traffic monitoring.

124


4.2.4. Traffic Volume at NSPIXP In this subsection, we show how the traffic volume of NSPIXP system has grown. Figure 4-14 shows the data since the start of NSPIXP-2 operation. The figure shows the total ingress traffic volume to IX switching fabric. Figure 4-15 shows the same traffic

Figure 4-14. Traffic Volume in NSPIXP-2 (DIX-IE)

Figure 4-15. Traffic Volume in NSPIXP-2 (DIX-IE) with log-scale


125

data, but with log-scale for vertical axis. As shown liner line in the figure, the traffic looks increase exponentially. Traffic = b eat Here “a” is about 0.657. Before at the end of 2004, the traffic has increased twice larger in one year, i.e., 100 % increase per year. On the contrary, after 2005, the increase ratio of traffic may look slightly decreased. This would be because of saturation of broadband new subscribers in Japan, and would be because of the increase of private peering among commercial ISPes and commercial IXes. Figure 4-16 shows the traffic pattern in a day from 2000 to 2005. Due to the increase of always-on users in Japan, the variance of traffic volume in a day looks be decreasing and the traffic in the mid-night to early morning has increased.

Figure 4-16. Daily Traffic Pattern observed at NSPIXP-2

Figure 4-17 shows the total ingress traffic at NSPIXP-3, which is located at Osaka. Here, from July 2001 to October 2002, we only have the data of average traffic volume. Also, from October 2002 to March 2003, we do not show in the figure, since we had monitored the wrong data. Figure 4-18 shows the traffic volume with log-scale in virtual axis. As you can realize, the traffic increase in NSPIXP-3 since 2004 is far smaller than that of NSPIXP-2/DIX-IE. We consider that this is because of the private peering among major ISPes has increased and major ISPes may not need two public peering points, i.e., NSIPXP-3/DIX-IE and NSPIPX-3. As shown in figure 4-17, the coefficient value (“a”) is 3.91007 exp(-8) for after 2004, and is 1.59964 exp(-8) for before 2004. The increase speed of total traffic at IX may tend to decrease. However, the traffic increase speed in Japan is not decreasing. Professional ISPes tend to increase the

126


Figure 4-17. Traffic Volume in NSPIXP-3 in Osaka

Figure 4-18. Traffic Volume in NSPIXP-3 in Osaka with log-scale

private peering points to distribute the traffic geographically and topologically. Even, they may try to exchange the traffic locally based on geographical topology. This may be because that the processing capability of switching fabric would be smaller than the


127

total traffic volume generated by users in Japan. This means that we may have to establish new IX architecture, that can process far larger amount of traffic volume. 4.2.5. Architecture of DIX-IE In this subsection, we describe the architecture of DIX-IE, that is the current main IX system for NSPIXP. 4.2.5.1. Reliability Figure 4-8 shows the overview of DIX-IE system configuration. The six switching fabrics are distributed in downtown Tokyo. These six of distributed layer 2 switching fabric are interconnected with the redundant links among the sites. Basically, every site has multiple links, that had different fiber paths. Basically, the DIX-IE system uses DF(Dark Fiber). The reason why we use the Dark Fiber for the interconnecting links is to achieve the flexibility on the types of datalink technologies. Dark Fiber is the transparent link, so that you can pick up the latest, appropriate or state-of-art datalink technology at that time. Also, in the some sites in DIX-IE system, DWDM technology is applied to. DWDM system can provide protected datalink between given site pair. At each site, two switching fabric are installed for robust operation. Two switching fabric are connected to the different fiber, in order to avoid the “single-pointof failure”. This kind of full dual implementation of system component is the fundamental implementation policy of DIX-IE. In DIX-IE, we adopt IEEE802.1w (RSTP; Rapid Spanning Tree) protocol to avoid temporal loop and to achieve faster convergence against the component failure. 4.2.5.2. Scalability against the Increase of Traffic Volume In order to come up with the increase of traffic, DIX-IE adopts link aggregation technology in many links. Using the link aggregation, fine grain available bandwidth among DIX-IE sites can be achieved, e.g., 1 Gbps, 2 Gbps and 3 Gbps with GbE interface. In the DIX-IE system, we adopt the IEEE802.3ad for link aggregation. Also, using the DarkFiber system connecting the sites is also to achieve scalability associated with the available bandwidth. Using the Dark Fiber, we can use the state-of-art datalink technology, that is available at that time. 4.2.5.3. Introduction and Operation of DIX-IE for Professional Operation The start of general service of DIX-IE was April of 2003. However, we have started the technical consideration and preparation since 2000. In order to start the general service, we had spent about three years. This was because of high technical and architectural challenges. Especially, the interoperability among the switching fabric from the various different manufactures had required a lot of time and efforts to fix the technical problems. Each distributed site use it’s own partner switching fabric, therefore, in the whole of DIX-IE system, there are many types of switching fabric and interface. The most time consuming and difficult technical issue was the co-existence of IEEE802.3ad and IEEE802.1w. This is the co-existence of link aggregation and dual home operation. There are wide variety of implications among manufactures regarding the implementation. In practice, as for IEEE802.3ad, there is algorithmic inconsistency

128


of STP algorithm with link failure or is the sequential inconsistency on establishment of link aggregation between the switching fabrics. Also, we have experienced the fall back operation of IEEE802.1w, when the IEEE802.1w was coexist with IEEE802.1d, within the same BPDU(Bridging Protocol Data Unit). This leads to slower system convergence, even though we applied the IEEE802.1w for rapid spanning tree convergence. In the DIX-IE, the system operators fulfill several operations. These are (a) fine grain traffic distribution using link aggregation technique, (b) Segmentation of 802.1w and 802.1d to avoid the BDPU interoperability problem, (c) control of MTU size, and (d) monitoring the traffic volume of each interface. Also, in order to come up with the traffic distribution for the multiple hop among the switching fabrics, we used the hashed MAC address in order to achieve finer (i.e., less than 1 Gbps for given source and destination MAC address pair) granularity of traffic distribution. For co-existence of 802.1w and 802.1d with high speed spanning tree convergence, we let small and short the Max Ave value and ForwardDelay value in the switches, so as to avoid the link flapping against the link failure and against the topology change. In order to allow the MPLS operation over the DIX-IE, we adopt the jumbo frame option, as well. Since the DIX-IE is distributed layer 2 switching system, there are some new technical issues, which were not observed in the NSPIXP-2. There are, for example, larger affect of multicast packet, BGP route advertisement via the un-expected peering router. Also, recently, the DIX-IE must accommodate both IPv4 and IPv6 packets, stably. 4.2.6. Services Provided by IX NSPIXP system has offered some additional services to pure layer 2 switching, since IX is convenient platform to provide common service to participating network providers. 4.2.6.1. DNS Service DNS service is very important common and basic service for all the network providers. Especially, the quality of root DNS service should be equal to all the network providers, in order to offer the same level of query response latency. Based on this consideration, we have offered the root DNS service at the NSPIXP from the beginning. As of 2005, 59 service providers are peering with the root DNS segment. Also, after the introduction of anycast operation in root DNS system, NSPIXP system has offered F-Root Server, I-Root Server, K-Root Server. NSPIXP has also offered some cc-TLD DNS service such as .jp. 4.2.6.2. News System Service The service offering of NetNews has been offered in NSPIXP for long time. Since the NetNews is using a relaying the bulk data among the NetNews participants, offering the NetNews in the NSPIXP could achieve better efficient data relaying among the NetNews participants. The number of NNTP sessions were 40 in 2001, and were 32 in 2005.


129

㻠㻘㻜㻜㻜

㻟㻘㻡㻜㻜

㽒㼒㽐㻬㽒㼍㽒㽿㽒㽹㽒㽡

㻟㻘㻜㻜㻜

㻞㻘㻡㻜㻜

㻞㻘㻜㻜㻜

㻝㻘㻡㻜㻜

㻝㻘㻜㻜㻜

㻡㻜㻜

㻞㻜㻜㻡㻚㻟㻚㻝㻡

㻞㻜㻜㻡㻚㻞㻚㻝㻡

㻞㻜㻜㻡㻚㻝㻚㻝㻡

㻞㻜㻜㻠㻚㻝㻞㻚㻝㻡

㻞㻜㻜㻠㻚㻝㻝㻚㻝㻡

㻞㻜㻜㻠㻚㻥㻚㻝㻡

㻞㻜㻜㻠㻚㻝㻜㻚㻝㻡

㻞㻜㻜㻠㻚㻤㻚㻝㻡

㻞㻜㻜㻠㻚㻣㻚㻝㻡

㻞㻜㻜㻠㻚㻢㻚㻝㻡

㻞㻜㻜㻠㻚㻡㻚㻝㻡

㻞㻜㻜㻠㻚㻠㻚㻝㻡

㻞㻜㻜㻠㻚㻟㻚㻝㻡

㻞㻜㻜㻠㻚㻞㻚㻝㻡

㻞㻜㻜㻠㻚㻝㻚㻝㻡

㻞㻜㻜㻟㻚㻝㻞㻚㻝㻡

㻞㻜㻜㻟㻚㻝㻝㻚㻝㻡

㻞㻜㻜㻟㻚㻥㻚㻝㻡

㻞㻜㻜㻟㻚㻝㻜㻚㻝㻡

㻞㻜㻜㻟㻚㻤㻚㻝㻡

㻞㻜㻜㻟㻚㻣㻚㻝㻡

㻞㻜㻜㻟㻚㻢㻚㻝㻡

㻞㻜㻜㻟㻚㻡㻚㻝㻡

㻞㻜㻜㻟㻚㻠㻚㻝㻡

㻞㻜㻜㻟㻚㻟㻚㻝㻡

㻞㻜㻜㻟㻚㻞㻚㻝㻡

㻞㻜㻜㻟㻚㻝㻚㻝㻡

㻞㻜㻜㻞㻚㻝㻞㻚㻝㻡

㻞㻜㻜㻞㻚㻝㻝㻚㻝㻡

㻞㻜㻜㻞㻚㻥㻚㻝㻡

㻞㻜㻜㻞㻚㻝㻜㻚㻝㻡

㻞㻜㻜㻞㻚㻤㻚㻝㻡

㻞㻜㻜㻞㻚㻣㻚㻝㻡

㻞㻜㻜㻞㻚㻢㻚㻝㻡

㻞㻜㻜㻞㻚㻡㻚㻝㻡

㻞㻜㻜㻞㻚㻠㻚㻝㻡

㻞㻜㻜㻞㻚㻟㻚㻝㻡

㻞㻜㻜㻞㻚㻞㻚㻝㻡

㻞㻜㻜㻞㻚㻝㻚㻝㻡

㻞㻜㻜㻝㻚㻝㻞㻚㻝㻡

㻜

Figure 4-19. Traffic Volume of NNTP Traffic with GigaNews

4.3. Operation of M-Root DNS Server 4.3.1. Background of Root DNS Server Operation in Japan Domain Name System (DNS) defines a hierarchical name space and its resolution process. The tree structured name space has been divided into many zones. Each zone doesn’t overwrap with others, and a set of name servers are associated with it. A node which has at least one child zone has a set of referral, each of which is actually the name and IP address(es) of the name server which is authoritative on the child zone. In order to resolve a given name, a client sends an DNS query message to a designated recursive server. It performs a resolution process and responds back the final result. The recursive server starts resolution process to send a query to one of the Root DNS servers, which is corresponding to the root node of the tree structured namespace. Each nameserver responds with the final answer if the server has the information requested or with the referral to other servers. Usually the Root DNS server responds with a set of information for Top Level Domains (TLDs). Then, the recursive server queries to one of the TLD servers indicated by the Root DNS server. The recursive server caches the result to provide quick answer to the future queries. The set of Root DNS servers is the key of the DNS resolution process and their stable operation and good reachability is essential because virtually all of the applications over the Internet depend on the DNS. All of the Root DNS servers were operational before 1994 when the 9th Root DNS server started its operation in Stockholm. In 1995, it was discussed that a few Root DNS servers were to be added to comply with the development of the Internet in Europe and in Asia-Pacific region. WIDE Project had named as the operator of the very first Root DNS server in Asia-

130


Pacific region through the discussion and started its operation in August 22nd 1997, as “M.ROOT-SERVERS.NET”. 4.3.2. Initial Configuration As specified in RFC2010, a Root DNS server is better to attach to a major Internet exchange through a router. One of the reasons why WIDE Project was picked as the operator of a Root DNS server was that there was a major Internet Exchanges in Tokyo, i.e., NSPIXP2. In the first configuration, a router was attached to NSPIXP-2 via a FDDI. A couple of PentiumPro 200 MHz servers were configured as primary/backup via routing protocol. When the primary server crashed, the router changed its routing table to direct the queries to the backup server within a minute.

Figure 4-20. M-Root Server Configuration in 1998

In 1998, JPIX, which is another exchange point, offered us a router with FDDI connection to its switching fabric. By introduction of another fastethernet hub as shown in Figure 4-20, it had no single point of failure except the power supply, which was highly reliable as a part of data center facility. At the end 1999, the servers were upgraded twice and the router was upgraded as well. In 2001, it has connected to another commercial internet exchange, JPNAP. In 2002, another set of cluster has been installed in Osaka so that M-Root DNS server could continue the service, even when there were catastrophic in Tokyo area. 4.3.3. Anycast Operation Since 1999, it had been discussed in IETF that DNS servers can be operated with anycast. In anycast, more than one servers are operated with exactly the same service, and advertise the reachability through a routing protocol. In this case, it is expected that the routing system delivers a query to the nearest server instance to provide shorter round-trip time to the client when the servers are installed on different network topology or geographic locations. It is also expected that the total server performance improves as multiple server instances run in parallel in multiple locations. In anycasting there is no guarantee that queries orignated by a single host are delivered to a same server, when routing change happens or a router performs perpacket (rather than per-flow) based load balancing. So it is not recommended to apply anycasting to TCP based applications especially, when the session lifetime is longer. In the DNS, most of the regular queries are done in UDP, and anycasting introduce no


131

serious problem. It may possible to use TCP in the DNS query, however, host requirements RFC specifies that a host must send an UDP query first. Root zone is carefully managed so that no truncation is occur, which could force the client to fall back to TCP. In M-Root DNS server, anycasting was introduced in 2001. In the configuration shown in Figure 4-19, both routers had the same server selection policy to direct queries to PC1 when it was operational. By changing the policy on Router-2 to prefer PC2, queries arrived at Router-2 from JPIX were processed by PC2, while other queries were processed by PC1. We called this configuration as “anycast in a rack”. Anycast with geographical distribution has been implemented by 5 Root DNS servers (C, F, I, J, and K) in 2003 as a measure of a DDoS attack observed in Oct 22, 2002. In M-Root, the first remote anycast cluster were operational in July 2004. It was installed at KINX, which has been the only layer-2 IX in Seoul. In August 2004, a separate cluster for JPNAP started operation in Tokyo, and another anycast cluster were operational in Paris, attached to two layer-2 IXes, SFINX and PARIX. By adding one more anycast cluster in San Francisco attached to PAIX, M-Root DNS server has 6 active clusters including 3 clusters in Tokyo as well as a backup cluster in Osaka. 4.3.4. IPv6 Support at M-Root DNS Server As the IPv4 address space is being exhausted within several years, it is necessary to prepare the transition to IPv6 in every aspect of the Internet. A Root DNS server is not an exception. M-Root DNS server obtained an IPv6 prefix of 2001:dc3::/35 from APNIC in July 2003, and started advertisement of the prefix in a few months in Tokyo. So if a client sends a DNS query in IPv6 to its service address, 2001:dc3::35, the client gets the response exactly the same as in IPv4. But this configuration is currently useless because no IPv6 address has been registered in ROOT-SERVERS.NET zone nor root.cache hint files. A user can add the IPv6 address to his root.cache file manually, however, modern DNS software including bind developed by Internet Systems Consortium 2 perform priming process. It sends a DNS query of QNAME = ., QTYPE = NS, QCLASS = IN, in order to obtain the up-todate list of the Root DNS servers. So hand-crafted addresses won’t be used for regular DNS queries. In order to allow clients to use IPv6, it is necessary to add AAAA records to ROOT-SERVERS.NET zone. By the way, the priming response packet is 436 byte long excluding UDP and IP headers. The maximum size of DNS message when UDP is used is 512 byte. So only two AAAA addresses can be inserted the priming response. In order to allow all of the AAAA addresses (the priming response size can grow up to 774 byte), use of EDNS0 [5] is suggested. In EDNS0, a client add an OPT pseudo-RR to indicate to the server that the client is able to receive a bigger UDP response. So in order to introduce IPv6 service in the Root DNS servers, it is encouraged to upgrade the DNS software to support EDNS0 as well as IPv6. But care must be taken because some firewall devices block bigger (more than 512 byte) UDP DNS packets.

132


4.4. MPLS Backbone Deployment 4.4.1. Nation-wide MPLS Backbone System Recently in Japan, many service providers have deployed the MPLS [11] system in their IP backbone networks. The most of business applications applying the MPLS technology in these service providers are the VPN [12][14] and the Traffic-Engineering [13]. Especially, the VPN service, which adapts the MPLS technology, has generated and explored huge business cases for their corporate customers, as the enterprise networking solution. On the contrary, the service providers have adopt the MPLS Traffic-Engineering framework, in order to improve their network operation cost, by the reduction of required network resources (e.g., amount of switches and routers), or by the optimization of network performance, especially so as so come up with the rapid and huge development and deployment of broadband access internet environment to every single customer. In this section, we describe the development and deployment of a nation-wide MPLS backbone system by Japan-Telecom , as an advanced and differentiated MPLS backbone service in Japan. 4.4.1.1. MPLS Networks in Japan Telecom In 2000, Japan-Telecom has launched the IP-VPN service[12] using MPLS technology, which is the first commercial MPLS product in Japan. In 2002, Japan-Telecom has launched the world’s first MPLS service, named “mpls ASSOCIO”[15], which provides the wide area Internet-Exchange function, by means of the MPLS userinterface to the customer network. These two different services have shared the common MPLS backbone network platform, i.e., service convergence into a single network entity by the adoption of MPLS technology. Moreover, both of the general internet service and the layer 2 Ethernet VPN service have commonly offered over the MPLS enabled network. For the internet connectivity of “ODN”, the MPLS technology enables the TrafficEngineering so as to optimize the usage of network resources, and achieves the rapid recovery against the link or node failure. These efforts by the adoption of MPLS technology have achieved the stable network operation in the backbone network. The wide-area Ethernet service, called as the “Wide-Ether,” uses the VPLS technology [14] that is one of the technical solutions to construct the virtual private LAN over the MPLS backbone. 4.4.1.2. The “mpls ASSOCIO” - an Inter-Domain MPLS Service The “mpls ASSOCIO” is the world’s first commercial service product that offer the transparent MPLS LSP (Label Switched Path) interface to the customer. Also, the mpls ASSOCIO offers the inter-domain LSP connection to the customers. Since the mpls ASSOCIO can offer the transparent wide area connectivity for inter-domain network operation, the mpls ASSOCIO can be the wide area IX (Internet eXchange) platform, called as the MPLS-IX [16]. The Next-Generation IX consortium [17] had progressed the research and development on the MPLS-IX architecture. Here, the Next-Generation IX consortium

: currently, Softbank Telecom


133

is the project in Japan to discuss and establish the Next-Generation Internet Exchange architecture. Japan Telecom has been contributed to the Next-Generation IX consortium for the development and deployment of technical discussion in the consortium. The MPLS-IX architecture achieves the following innovative features. (1) Protocol Independency The traditional IX is constructed with the specific “single” data-link media and corresponding protocol, such as Ethernet or ATM. For example, the IX using the Ethernet media can not offer the peering capability using the ATM protocol, since ATM and Ethernet are the different data-link media. In the MPLS-IX, service providers can establish the peering over the different data-link using the MPLS LSP. Over the MPLS LSP, any type of data-link protocol can be offered between the peers. This (data-link) media and protocol independency, the customer can select any datalink media, according to their preference or to their policy. Or, the customer will be able to use the best cost effective or best performed data-link media, at that time in the future. (2) Distributed Peering without any Geographical Restriction Comparing with the legacy peering service, that requires physical circuit showing up the peering point, the MPLS-IX system can provide a flexible peering, with regard to the geographical location, with low cost. This is because the MPLS-IX provides a kind of virtual managed peering connectivity among the peering sites, while sharing the expensive physical network infrastructure. (3) Constructing Inter-IX and Hierarchical IX Since the MPLS LSP can traverse any data-link media even though the data-link segment is terminated, the MPLS-IX can inter-connect the traditional IXes that are geographically distributed. We can say this environment as the Inter-IX environment. With the Inter-IX environment, we can configure the hierarchical IX network, where the traditional IXes are connected as leaf segments and the MPLS-IX is as a core segment. The “mpls ASSOCIO”, that is the commercial service offered by Japan-Telecom as the MPLS-IX service, defines the user-interface to provide MPLS LSP to the customers. The mpls ASSOCIO user-interface can be used not only for virtual connection for IX peering, but can be also for other various purposes. This means that a service provider can easily and flexibly configure the interdomain virtual peering backbone based on MPLS LSP among it’s peering partners, as well as the intra-domain data-link media free backbone. For inter-domain MPLS LSP service, the mpls ASSOCIO provides the assured and secured data transport, with accounting in per LSP basis. In addition, mpls ASSOCIO offers an unique charging policy for the provision of inter-domain transport service. The service charge is defined by combination of the number of LSPes that the service provider used, and of the bandwidth that the service provider consumes. This means that the service charge is independent from the geographical distance or the cable length among the peering points, while the access cost of traditional IX for the customer network tightly depends on the geographical distance to the IX location. This is because that, with traditional IX, the customer must take care the data-link connectivity to the IX point from the customer network and the cost of data-link depends on the geographical distance.

134


4.4.1.3. Reliability Since the L2/L3 VPN and the mpls ASSOCIO has been designed for accommodating the enterprise VPN service, the system must have higher reliability for the network operation and for the service provision. As an objective system reliability, we have targeted five-nines (99.999 %) or six-nines (99.9999 %) service availability. In order to achieve this high reliability, the mpls ASSOCIO evaluates and adopts various operational techniques. As a typical example, we have evaluated the FRR (FastReroute) [27] technology. FRR is one of rapid failure recovery solution, called as Local Repair. FRR requires configuring the backup LSP against the primary LSP in backbone network. When a failure occurred in the network, which includes the primary LSP, the traffic is rapidly reroute, so as to avoiding the failure point(s). With the FRR, we have confirmed that the recovery can be run within less than 50 msec. Comparing with the reliability of MPLS backbone without FRR configuration, we can significantly improve the MPLS backbone operation reliability. Applying the other operational techniques as well as FRR, the MPLS service networks has achieved 99.9999 percent of service availability, which is highly required by the enterprise customers’. 4.4.1.4. Future Extensions for mpls ASSOCIO Service Initially, the MPLS backbone network operated by Japan Telecom has offered the IPVPN service for the enterprise customer. Using the same physical network platform, we have provided the MPLS LSP service for inter-domain data-link media independent virtual connectivity among geographically distributed service providers. Also, the MPLS service network achieves high operational and service reliability, satisfying the enterprise customers’ requirement. As the future extension toward the year of 2011, we must accommodate the multicasting and broadcasting services. At the IETF, a new technology, named P2MP (Point-to-Multipoint) LSP using MPLS [18] for multicast transport has been in standardization progress. The MPLS network operated by Japan-Telecom has already applied the P2MP technology in order to provide multicast VPN service. We must establish the best current practice for professional P2MP service operation. It will make new proposal to how network can help to the broadcast application. Since the mpls ASSOCIO offers both inter-domain and intra-domain data transport service, we must offer both inter-domain and intradomain multicast transport service using the P2MP LSPes. 4.4.2. Global MPLS Enable Backbone System 4.4.2.1. Introduction In recent years, Multi Protocol Label Switching (MPLS)[20] had been recognized as one of the most capable transport technologies. Service Providers (SPs) launched MPLS Virtual Private Network (VPN) services, such as Layer2 VPN, Layer3 BGP/MPLS VPN[20] and utilize MPLS Traffic-Engineering (TE)[13] for traffic management. Asia Netcom (ANC)[19] inaugurated the deployment of a new global MPLS infrastructure in 2003. The motivation of this new MPLS/IP network deployment was because of the change of company's ownership. With this situation, an


135

Autonomous System (AS) Number, Peering, customers and network assets had to be made independent from the previous parent company which is an US Tier-1 ISP. Finally, ANC built a completely new global BGP/MPLS VPN network and the Internet transit backbone. From a security standpoint, the MPLS-VPN network and the Internet infrastructure are physically and logically separated so that we can protect the MPLSVPN network from unexpected traffic due to Distributed Denial of Service (DDoS) attacks and other security vulnerabilities of the Internet. At present time, the ANC’s MPLS infrastructure is providing BGP/MPLS VPN, Layer2 VPN for VPN customers and utilizing MPLS-Traffic Engineering (TE) for traffic management on the Internet access service backbone. The infrastructure interconnects major cities of Japan, Hong Kong, Singa-pore, Korea, Taiwan, Philippines, Malaysia, Thailand, Australia, New Zealand, US and Europe. In Asia, the ANC’s MPLS infrastructure was built on top of ANC own two submarine cable systems, EAC and C2C. In the next subsection, the overview of the network design policy and configurations of ANC’s Internet backbone has been discussed. Our global network coverage and another features are described in the following subsections. 4.4.2.2. Overview of ANC MPLS-enabled Backbone (1) MPLS Infrastructure Physical Design ANC’s MPLS-enabled Internet infrastructure is a multi-vender environment consisting of Cisco and Juniper equipment. The ANC Point of Presence (POP) is basically designed according to our standard policy. The routers are organized in a functional hierarchy as depicted in Figure 4-21.

Figure 4-21. Router function and hierarchy

Basic components at an ANC POP consist of Customer Gateway (GW) routers and Core (CR) routers. The Internet access customers connect to the network by being directly attached to GW routers at the POP. CR routers aggregate the traffic of multiple GWs and forward it to either GW or other CR over MPLS-TE LSPs. In the data plane, GW-CR is pure IP transport, and between CR-CR is MPLS label based packet transport. Inter-POP circuits use SDH/SONET or Gigabit Ethernet (GE) circuits. So the size of ANC’s backbone bandwidth is from STM1 (155 Mbps) to multiple STM16 (2,488 Mbps). The 10 GE backbone will be turned up in a few months. Intra-POP circuits use SDH/SONET circuits only due to fast error detecting function that inherent in SDH/SONET specifications.

136


(2) Routing Configuration The IGP routing protocol, Intermediate System-Intermediate system (IS-IS) [21][22][23] is running on the ANC’s MPLS infrastructure. For the control plane configuration, IS-IS is single Level-2 hierarchy. In Japan, OSPF[24] is the more popular routing protocol over IS-IS for the IGP of ISP’s backbone. However, ANC has selected IS-IS since IS-IS is operated by many of US Tier-1 ISPs and has many experimental feedbacks and real evidence of IGP in very large global ISP backbones. The Border Gateway Protocol (BGP) [25] is operating to perform external, internal routing information exchange. ANC has chosen BGP route-reflector and client design for the iBGP route distribution methodology after the evaluation of BGP confederation design. In addition, The ANC Internet domain of IPv4 was assigned AS10026 as Autonomous System number. (3) MPLS LSP Configuration MPLS-TE LSPs are established using both of Constraint-based Shortest Path First (CSPF) algorithm and the explicit setting which specify hop-by-hop IP address to build a LSP. LSP operation is relatively complex. Since the number of LSPs increase based on the number of Global MPLS Enabled Backbone Deployment 3 Nodes (N), the total LSPs is defined as N(N-1). However, CSPF is good to relieve the operational workload to maintain LSPs since the CSPF algorithm selects the physical best-path for the LSP to set up automatically based on the Traffic Engineering DataBase (TED) which is composed of IGP metric, Shared Resource Link Group (SRLG), Link Color, and reserved bandwidth. From another aspect, the explicit LSP path achieves intentional optimal routing, in particular the ability to perform non-uniformless traffic balancing among multiple LSPs. This capability is ideal for avoiding congestion on IP backbone since sudden Internet traffic increases and decreases occur often. Furthermore, international capacity is still expensive, therefore explicit LSP methodology is quite efficient in order to optimize the international capacity. (4) Class-Of-Service Configurations ANC did not attempt to deploy the Class-of-Service (CoS) feature to the Internet backbone. However we had deployed the CoS feature to MPLS-VPN network. In order to guarantee the demand of service quality, ANC is providing five different CoS levels. MPLS-VPN customers can request ANC to prioritize the business-critical traffic, Voice, Video traffic and another various IP traffic. In the MPLS-VPN backbone, the Per Hop Behavior (PHB) CoS process with Weighted Random Early Detection (WRED) and Modified Deficit Round Robin (MDRR) is in place. The CoS classification distinguisher is only the MPLS EXP bits value since MPLS EXP bits can be controlled by the Service Provider at the LSP head-end. 4.4.2.3. ANC MPLS-enabled Infrastructure Diagram Figure 4-21 shows the ANC Global network diagram. MPLS-VPN PEs and Internet access GWs/CRs are deployed to those POPs. GWs were deployed to various Internet exchange (IX) points to establish public peering, as well as private peering. Also several PEs have established MPLSVPN NNI’s with VPN business partners at multiple locations.


137

Figure 4-22. ANC Global Network Diagram

4.4.2.4. Conclusion and Further Work In this subsection, the design and configuration of ANC’s MPLS infrastructure is described. MPLS is obviously an efficient protocol, especially the MPLS-TE feature which provides ISP’s with a new methodology of backbone traffic optimization, capacity management as well as feasibility of Fast ReRoute[26] deployment. Furthermore, the MPLS protocol provides a basis to adapt new services and new solution on the optical network infrastructure. ANC is managing two Asia-Pacific Submarine Cable Systems, one is EAC, and the other is C2C. In order to utilize two independent cable systems with minimum investment for Layer 3 services, we have been explored IP over optical submarine cable using MPLS features for multi-service platform. The design is that Layer3 equipments are to connect to Submarine Line Terminal Equipment (SLTE) directly in order to eliminate legacy SDH/SONET equipment from IP network infra-structure. Another interesting direction for technical study is the new optical network technology deployment on the existing two submarine network. GMPLS/ASON, Ethernet packet over Optical are potential candidate to develop feature-rich and fully meshed submarine networks. We are conducting the further investigation into new optical network technologies as well as MPLS over Optical solution.

References [1] P. V. Mockapetris. Domain Names { Concepts and Facilities. RFC1034, November 1987. [2] P. V. Mockapetris. Domain Names { Implementation and Specification. RFC1035, November 1987. [3] T. Hardie. Distributing Authoritative Name Servers via Shared Unicast Addresses. RFC3258, April 2002. [4] R. T. Braden (ed). Requirements for Internet Hosts { Application and Support. RFC1123, October 1989

138


[5] Paul Vixie. Extension Mechanisms for DNS (EDNS0). RFC2671, August 1999. [6] Yuji Sekiya, et. al,. “Root and ccTLD DNS server observation from worldwide locations,” Proceedings of Passive and Active Measrement 2003, pp.117-129, April, 2003. [7] Brain Kantor, Phil Lapsley, “Network News Transfer Protocol,” RFC977, IETF, February, 1986 [8] Y. Rekhter, T. Li, “A Border Gateway Protocol 4(BGP-4),” RFC1771, IETF, March, 1995 [9] R. Mondeville, “Benchmarking Terminology for LAN Switching Devices,” RFC2285, IETF, Febrary 1998 [10] P.Phaal, S.Panchen, N.McKee, “InMon coporation’s sFlow: A method for monitroring traffic in switched and routed networks,” RFC3176, IETF September 2001 [11] E.Rosen, et al. “Multiprotocol Label Switching Architecture,” RFC3031, Internet Engineering Task Force, January 2001. [12] E.Rosen, et al. “BGP/MPLS IP VPN,” RFC4364, Internet Engineering Task Force, February 2006. [13] D. Awduche, et al. “RSVP-TE: Extensions to RSVP for LSP Tunnels,” RFC3209, Internet Engineering Task Force, December 2001. [14] M.Lasserre, et al. “Virtual Private LAN Service Using LDP,” Internet-Drafts, Internet Engineering Task Force, June 2006.(draft-ietf-l2vpn-vpls-ldp-09.txt) work in progress. [15] Japan Telecom “mpls ASSOCIO” Web site, http://www.associo.jp/english/index.html [16] Ikuo Nakagawa, Hiroshi Esaki, Yutaka Kikuchi, Kenichi Nagami, “Design of Next Generation IX Using MPLS Technology,” IPSJ Journal, Vol.43, No.11, November 2002. [17] Next-Generation IX consortium, http://www.distix.net/ [18] Seisho Yasukawa, “Signaling Requirements for Point to Multipoint Traffic Engineered MPLS LSPs,” RFC4461, Internet Engineering Task Force, April 2006. [19] Asia Netcom http://www.asianetcom.com/ [20] E.Rosen, A.Viswanathan, R.Callon, “Multiprotocol Label Switching Architecture,” IETF RFC3031, January,2001. [21] R.Callon, “Use of OSI IS-IS for Routing in TCP/IP and Dual Environments,” IETF RFC1195, December,1990. [22] “Intermediate System to Intermediate System IntraDomain Routing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473),” ISO DP10589, February, 1990. [23] H.Smit, T.Li, “Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engieering (TE),” IETF RFC3784, June, 2004. [24] J.Moy, “OSPF Version 2,” IETF RFC2328, April, 1998. [25] Y.Rekhter, T.Li, S.Hares, “A Border Gateway Protocol 4 (BGP-4)” IETF RFC4271, January, 2006. [26] P.Pan, G.Swallow, A.Atlas, “Fast Reroute Extensions to RSVP-TE for LSP Tunnels,” IETF RFC4090, May, 2005.


139

Chapter 5

Broadband Internet Applications 5.1. VoIP (Voice over IP) 5.1.1. VoIP Service Deployment History in Japan The first professional and business VoIP service in Japan was not the end-to-end voice communication service, but was the trunking of voice traffic in the backbone transport system. Since the VoIP technology does not require the legacy digital hierarchy in the transport system and voice traffic can share the bandwidth among the other data traffic, the bit cost effective larger bandwidth link can be used for voice transmission, compared with the legacy TDM-SDH/SONET based PSTN backbone system. This is because the 64 kbps based channelized TDM multiplexing requires intermediate aggregation and de-aggregation equipments between the backbone transport link, e.g., international sub-marine cable, and is far expensive than the IP multiplexing system with VoIP technology. VoIP technology had been used in order to reduce the voice transmission cost in the backbone area. There had been some VoIP trials using the existing IP system in the existing ISP networks, since the end of 1990s. However, at that time, due to the lack of enough bandwidth and priority queuing technology in the commercial network equipments, it had been recognized that VoIP service over the Internet were so poor for commercial service. However, in 2001, Yahoo BB! has started their Internet connectivity service with very cheap price (3,017 Yen per month) and with large available bandwidth (8 Mbps). Yahoo BB! ; Other ISPes;

3,017 Yen per month, 5,000 -- 6,000 Yen per month,

8.0 Mbps 1.5 Mbps

When Yahoo BB! has started the ISP service, the VoIP service, called BB-Phone, has been automatically included as the default service. The BB-Phone service has used the 0ABJ number, which is conventional telephone number (i.e., E.163/E.164). This number usage, using 0ABJ number for VoIP service, may be tricky from the view point of telecommunication regulation defined by MIC of Japanese government. Usually, it was assumed that the VoIP service uses 050 number, that is allocated for VoIP service. As for the signaling architecture and protocol, the BB-Phone system used MEGACO/MGCP. After the large deployment of Yahoo BB! service, Yahoo BB! has started to use also the 050 number for BB-Phone service. In these days, the followings give which signaling protocol each typical ISP adopts. Here, NTT, KDDI and Fusion had used H.323 first, then migrate to SIP. H.323; Biglobe (www.biglobe.ne.jp), Nifty (www.nifty.com) SIP; eAcess (www.eaccess.net), NTT (www.ntt.co.jp), KDDI (www.kddi.com) MEGACO/MGCP; Plala (www.plala.or.jp), Yahoo BB! (www.bb.yahoo.co.jp)

140

Chapter 5. Broadband Internet Applications

Here, when Yahoo BB! has started their IP service, they have provided (rented) the access router to the customer. There was a big technical problem regarding the access router provided by Yahoo BB!, that would be called as Annex A problem. Yahoo BB! had used the ASDL modem with the Annex A, that was adopted in North America, thought Yahoo BB! has now migrated to Annex C based ADSL modem. Other providers have used the Annex C. The argument and discussion was about the interference between TCM-ISDN and ADSL signal of Annex A. This is because of Japanese (proprietary) technical specification of ISDN called as INS64. Due to this interference, a significant degradation of throughput has occurred. After the trigger of VoIP service and broadband Internet service by Yahoo BB!, Japan has achieved one of the best broadband Internet environment in the world, and has deployed large number of VoIP system for the residential customer and for the corporate customers. The first wave of broadband Internet was using the ADSL with VoIP service. Since around 2004, NTT group has stared the FTTH solution with IPPhone (VoIP) service, called as Hikari-Denwa (with direct translation, this is Optical Telephone). The system architecture would be the same as the previous ADSL based VoIP service. However, the Internet access can be with far larger bandwidth than the ADSL access. Also, NTT could take over the VoIP service from ADSL providers. Now, all the carriers are going to progress toward the NGN, Next Generation Internet, with IMS-SIP. It would be said that NGN will be able to improve both CAPEX (Capital Expense) and OPEX (Operational Expense), by the adoption of IP technology. However, the other (or true) motivation for the carriers would be due to the discontinuation of ATM switch supplying from the vendors. They “must” migrate their telephone service network from ATM to the other platform. VoIP platform, that carries voice signal using IP packet transport, was recognized as the feasible solution. When (wired) carriers consider the architecture of VoIP platform, they adopt the IMS architecture discussed and defined by 3GPP/3GPP2 consortium, which is for cellular phone system. This means that wired network imported the network architecture from wireless network, and finally, the architecture of wired and wireless platform used the same architecture and protocol. This would leads to the FMC (Fixed Mobile Convergence) operation. NTT has demonstrated the NGN field trial since the end of 2006, and has announced to start the business operation from spring of 2008. As shown in Figure 5-2, the number of VoIP customers has increased linearly since 2003. The total number of VoIP customers reached 10 million at the end of 2005, and has reached 1.4 million at the end of 2006. Finally, the cell phone integration with WiFi technology started to introduce the VoIP technology into the mobile system. Especially, the integration of cellular RF access and WiFi into the handset had introduced the VoIP service with SIP for enterprise customer. Also, the government announcement in the fall of 2007 of encouraging the unbundling between handset business and carrier service may accelerate the VoIP service using the WiFi by mobile handsets. 5.1.2. Numbering and Service Quality Definition Initially, it was assumed that VoIP service would not have enough QoS, compared with conventional PSTN service. Therefore, Japanese government (i.e., MIC, Ministry of Information and Communication) had tried to allocate dedicated telephone number space for VoIP service. This numbering space has the 050 prefix, which has been defined in October of 2002. For example, in Japan, 090 and 080 is dedicated for


141

cellular phone system. As mentioned above, Yahoo BB! did not use 050 number, when they had started their VoIP service. When the VoIP technology had been well developed and had been mature, the QoS for VoIP service was getting better and was comparable with conventional PSTN service. Then, MIC has started to allow to use all the telephone number to VoIP service, whenever the VoIP service satisfy the following QoS performance objectives. Also, based on the R-value, end-to-end delay, call failure rate and the availability of emergency call, three classes and numbering prefixes has been defined, as shown in Table 5-1. Table 5-1. Definition of Class for VoIP service

Class A

R-value

End-toend delay

Call failure rate

80–

~100 ms

ӌ0.15

80– ~150 ms

Class B

50–

~400 ms

Telephone number

Yes

0AB~J

No

050

Yes

0AB~J

Yes/no

050

No

050

ӌ0.15

70– Class C

Emergency call

ӌ0.15

- R-value (general voice transmission quality rate) is the figure indicates the comprehensive transmission quality of VoIP (ITU-T G.107). - R-value and delay values are considered satisfactory when 95 % of the samples are satisfied.

Also, Figure 5-1 shows an abstracted network configuration of typical VoIP service network.

Figure 5-1. Typical VoIP service network in Japan

142


Figure 5-2. Increase of VoIP service users in Japan

Figure 5-3. Breakdown of IP Phone number


Figure 5-4. IP Phone number shares by carriers

Figure 5-5. IP Phone number in operation (as of end of Nov. 2004)

143

144


Figure 5-6. VoIP Gateway Topology in BB-Phone system in Yahoo BB!

5.1.3. Interoperability and Operational Configuration As usual, Japanese carriers had defined their own technical specification associated with SIP. This means that each provider defines it’s own profile and some proprietary extension against SIP, in order to enclose the customer to their network. With IPv4 SIP based VoIP system in Japan, each system did not have any interoperability for NNI and for UNI. In order to interconnect their VoIP network, they must use legacy and conventional PSTN switch among these VoIP network, i.e., SIP signaling message is only for each closed VoIP system. In order to solve this situation, JPNIC (Japan Network Information Center, www.nic.ad.jp) and WIDE Project (www.wide.ad.jp) has established the VoIP/SIP Interoperability Task Force in December of 2004. This task force has had the collaboration and cooperation with SIP Forum, SIPit, MSF and IPCC for international, with TTC and Telecom Service Association for domestic. Founder of this task force included 26 of private companies, 8 NPOs and 3 universities. This consortium has run many interoperability testing among carrier’s VoIP system, and had four exhibitions with operational demonstration. Based on the results through activity, some VoIP networks have succeeded the transparent interoperability with SIP signaling, without any PSTN switch between the VoIP networks.

Figure 5-7. Logo of VoIP/SIP Interoperabiliy Task Force


145

Since 2006, the international interoperability testing has been progressed with ISPes in Thailand and in Singapore, so as to establish the global scale inter-domain operational technology and interoperability among the various VoIP related equipments manufactured by different countries. HATS (Harmonization of Advanced Telecommunication Systems), which belongs to TTC (Telecommunication Technology Committee), has run the interoperability among the CPE (Customer Premises Equipment) devices, such as IP-PBX and VoIP terminal in campus network. 5.1.4. Promotion and Deployment Activities In 2004, Telecom Service Association (www.telesa.or.jp) has established VoIP Promotion Committee (www.telesa.or.jp/committee/voip/). VoIP Promotion Committee holds series of technical seminars, demonstration at commercial conferences / exhibitions, or interoperability testing. Also, market research related with VoIP technology has been progressed. IPTPC, IP Telephony Promotion Center (http://certification.iptpc.com/), has established originally by NEC corporation (www.nec.co.jp) and Oki Electric Industry Co.Ltd (www.oki.com). The rest of current steering member companies of IPTPC are Hitachi Ltd.(www.hitachi.co.jp), Fujistu Ltd.(www.fujistu.co.jp), Iwatsu Electric Co.Ltd. (www.iwatsu.co.jp), Panasonic Communications Co.Ltd.(panasonic.co.jp/pcc/). IPTPC has run the certification program for the engineers. IPTPC has recognized Japan did not have enough number of VoIP engineers and we must encourage the skill up of telephone engineers, who are potentially related with VoIP system installation, operation and management. We need System Engineer (SE), marketing and sales engineer/person, constructing and installation engineer/person, and system designer. In order to achieve the goal mentioned above, IPTPC has established the certification program. Three typed of certified engineer are defined in the program. x VoIP Advisor x VoIP Designer x VoIP Constructor Also, in order to learn the (at large) VoIP technologies, series of e-learning based educational program has run by IPTPC. These are; x VoIP Startup x VoIP Basic x VoIP Advisor x VoIP Designer x VoIP Mobile x VoIP Security 5.1.5. Challenges around VoIP Service in Japan Japanese VoIP service has got large market penetration, especially to residential customers. This means that VoIP service deployment in Japan has completed the first stage, and is going to the next stage. The followings are the technical and business challenges, which we recognize at this time. Some of challenges have been already in progress.

146


(1) Hikari Denwa Service The first wave of VoIP service was using the ADSL infrastructure. Since around 2004, NTT group has stared the FTTH solution with IP-Phone (VoIP) service, called as Hikari-Denwa. The system architecture would be the same as the previous ADSL based VoIP service. However, the Internet access can be with far larger bandwidth than the ADSL access, since the required bandwidth by the residential and corporate customers are getting larger and larger. Also, the professional VoIP service by carriers has experienced serious operational failures in 2006. This experience has delivered the technical and operational improvement on their VoIP service network architecture. For example, the SIP servers in their backyard has been distributed, based on this experiences. (2) NGN All the major carriers are going to progress toward the NGN, Next Generation Internet, with IMS-SIP. It is said that the NGN must provide mission critical VoIP service, such as emergency calls as a public service. Since NGN plans to replace all the PSTN service to VoIP technology, the NGN VoIP system must achieve high reliable operational quality that would be different level compared with the current VoIP system. Also, NGN is aiming the FMC (Fixed Mobile Convergence) operation. As for FMC operation, there are some critical policy and regulation to carried out. Especially, NTT has a lot of regulation to provide the service to residential customer and to network providers. (3) IPv6 Introduction The existing VoIP service in Japan is based on IP version 4 (IPv4), rather than IP version 6 (IPv6). However, we must seriously consider the introduction of IPv6 technology in the VoIP service platform. This is because it is said that the IPv4 address, which will be able to be allocated to, will run put around 2011 (http://ipv4.potaroo.net), and new VoIP node will not able to obtain new IP(v4) address. Since this is the serious matter of business and service continuation, many VoIP service providers starts to consider how to come up with the IPv4 address run out.

Figure 5-8. Cost Reduction by IPv6 technology for each phase


147

One of the practical solution, which has already been in operation, is large scale VoIP system in nation-wide dormitories run by Freebit Co.Ltd(www.freebit.com). They adopt IPv6 technology for the brand-new VoIP system, which accommodate about 20 K VoIP terminals over 280 sites in Japan. Due to the auto-configuration function of IPv6 address and global address networking, they succeeded to reduce large amount of design and operational cost. Operation cost includes; installation, troubleshooting and daily management. For example, it is reported that they reduced the number of mis-configuration in the installation phase from about 300 per site in average to less than 10, i.e., reducing to less than 3 %.

Figure 5-9. Cost reduction in network design and installation phase

(4) HOTAL Project It is said that NGN and next generation mobile system will use IPv6 and IMS architecture. In IMS architecture, the enhanced SIP will be used as the signaling protocol. This enhanced SIP for IMS is a modified version from simple and original SIP specified by IETF. The existing VoIP system does not have enough interoperability among the networks and among the terminals. This would be because of (a) different technical profiling per provider, (2) lack of open reference software implementation. Now, since we have to challenge to new IP version (i.e., from IPv4 to IPv6) and to new SIP protocol, we want have enough interoperability. In order to contribute to achieve this objective, WIDE project has establish the HOTAL project, which develop the IMS-SIP open referenced software. The project is run as a consortium from various organizations; NAOJ(National Astronomical Observatory of Japan), NiCT(National Institute of Information and Communication Technology), NTT-AT, SIProp Project, Softbank Telecom, Fujitsu, NEC, NEC-AT, Fusion Communications, IntecNetcore, Keiko University and The University of Tokyo. (5) Introduction to Cell-Phone System Finally, the cell phone integration with WiFi technology started to introduce the VoIP technology into the mobile system. Especially, the integration of cellular RF access and WiFi into the handset has introduced the VoIP service with SIP for enterprise customer. Also, the government announcement in the fall of 2007 of encouraging the unbundling between handset business and carrier service may accelerate the VoIP service using the WiFi by mobile handsets.

148


5.2. Video over IP 5.2.1. Digital Video Streaming Technology Computation and communications have been steadily moving toward our living platforms, where everyone uses some kind of the Internet aware devices and appliances and carries intelligent and portable devices such as portable notebook computers (notePCs) and PDA’s. Growth of Laptop computers and PDA’s as well as the Internet infrastructure itself is the good proof of influencing the network aware embedded world. Continuous development of portability enhancement and increasing digital processing power, we see ever growing use of powerful microprocessors running sophisticated, intelligent control software in a vast array of devices including continuous media like digital video cameras, high bandwidth network devices such as a Gigabit Ethernet. Other than legacy computing devices, cellular phones, information appliances, digital home game machines have been getting intelligent and equipped themselves with networking facilities. The Internet, which is the global digital infrastructure, enables communication environment regardless of data types. For example, text based chat, IP telephony, and video conferencing are generally used with ease. There are numbers of Real-Time video transport applications for various platforms, and they are used globally. The Internet has spread widely, and achieved being a global information infrastructure. However, bandwidth for home network connectivity are still very narrow, this is known as the last one mile problem. Most video and audio transport applications aim to be suitable for any network environment. Moreover, many video and audio transport applications focus on users at the home network environment. Table 5-2 shows the typical resolution of Video streams, its memory, and network bandwidth requirements excluding packetizing costs. Table 5-2. Resolution and its contents

Resolution

Pixel Dot

32Bit 1Frame (Bit)

30fps byte

Bandwidth bps

640x480

307,200

1200K

35.16M

281M

800x600

480,000

1875K

54.93M

439M

1024x768

786,432

3M

90M

720M

1280x1024

1,310,720

5M

150M

1200M

1600x1200

1,920,000

7.32M

219.6M

1.72G

1920x1080

2,073,600

7.91M

237.3M

1.85G

1920x1200

2,304,000

8.78M

263.4M

2.06G

3960x2400

9,504,000

36.25M

1087.5M

8.50G

Bandwidth of typical digital video image which has a resolution of Rx and Ry, color resolution of n, and its frame rate f, can be calculated as shown in Table 5-1. Dt = (Rx Ry)nf


149

The existing video conference systems are designed considering narrow bandwidth. To adapt to very narrow bandwidth, many video systems use highly compressed data format to reduce bandwidth usage. For most compression method, the level of compression is a trade of between quality and bandwidth. To realize high level of compression, quality of video is degraded by using nonreversible compression method. The compression method used by most of existing video conference systems degrades quality to achieve high compression. High compression of video data was required due to lack of bandwidth. However, the bandwidths of IP based network system are growing massively, and will be wide enough to transport high quality video without high compression. For example, LAN (Local Area Network) infrastructure of 100 Mbps and 1 Gbps Ethernet has become popular. On global IP network, increase in bandwidth of backbone network is massive, compared to the LAN infrastructure. High performance network switching technology has been already accomplished for IP stream with 10+Gbps Ethernet. In such networks, bandwidth capability for sending high quality digitized video streams without high compression, are acceptable. Compared to the bandwidth used at the backbone network, bandwidth for access links of the last one mile are still narrow. Thus, adaptation to various bandwidths must be considered. Figure 5-10 shows one of the earliest video streaming event held in 1996, An Internet World Exposition. During the event, video and audio streaming application “StreamWorks” developed by Xing Technology Corporation is was used. To adapt into narrow last one mile network infrastructure connected into each house, streaming bandwidth is limited to either 22 kbps for modem users, 56 kbps and 112 kbps for ISDN users, and 240 to 360 kbps for “Broadband” users. Encoder device of “StreamWorks” consists of custom hardware video encoder which has composite video and stereo audio input. The custom encoder cards compresses and encodes the video into inter-frame MPEG compression streams. Lack of computational power for both encoder and decoder clients, as well as its limited network bandwidth, resolution of video stream, frame rate and audio quality was poor.

1996 Internet World Exposition

Figure 5-10. Video Streaming during Internet World Expo 1996

150


5.2.2. Consumer Digital Video Encoding Formats Irreversible data compression technique which can effectively compress video and audio data, are used for most systems. Video compression technique can be classified into two categories, 1) intra-frame compression, and 2) inter-frame compression. Intraframe compression only does compression for each of the video images independently. On the other hand, inter-frame compression calculates the difference of the video image, and reuses the data when the difference is small. Effective compression can be realized by using the inter-frame compression technique, and popular video format such as MPEG uses inter-frame compression. However, inter-frame compression requires large calculation cost. Moreover, it requires buffering which causes delay. The buffering is required for calculating the difference of the video image, when encoding and decoding. Video compression can be roughly classified into two categories, 1) hardware compression processed by especial hardware device, and 2) software compression. Hardware compression can realize high speed and Real-Time compression. However, it requires especial hardware device, which can sometimes raise the cost of the system. Software compression does not require special hardware device. However, it requires high computational power for its encoding and decoding process. Since the existing video conference systems available today are designed to use in narrow bandwidth, many systems use hardware MPEG, MPEG2, MPEG4 and H.264 based codec. Digital Video (DV) Format Digital Video (DV) is currently one of the most widely used Standard Definition (SD) formats for compression, storage and processing digital video. Its advantages are high quality (e. g. for NTSC, it uses resolution 720 x 480 with 30 or 29.97 frames per second), very low degradation of image quality in multiple recompression due to multi-generation editing, relative affordability of DV-enabled devices with IEEE.1394 interface (motion cameras, converters, recorders, etc.). DV compression uses 4:1:1 sampling for NTSC and 4:2:0 for PAL format and utilizes intra-frame compression only. Audio is compressed together with video and uses sampling frequency of 32 KHz, 44.1 KHz, or 48 KHz and 12, 16, or 20 bits quantization. Bandwidth requirements are 25 Mbps for video over IEEE-1394 and additional 1.5 Mbps for audio. DV format uses DCT (Discrete Cosine Transform) and VLC (Variable Length Coding) for video compression. Inter-frame compression technique as of MPEG1 and MPEG2 are not used in the DV format. Thus, implementation of operation such as fast-forward and rewind are easy to realize compared to the formats that use intraframe compression. Moreover, the DV format is Real-Time, compared to MPEG that uses inter-frame compression technique and requires buffering for both encoding and decoding. The DV format is widely used for both consumer and professional. Consumer level DV equipments can be obtained anywhere, and can be purchased at low cost. The DV format is designed for magnetic tape media. DV Format is specially optimized for enhancing the characteristics in recording digital video and audio data using helical scan magnetic tape systems. Several minor formats are designed for various purposes on both of consumer and professional format. DV format is the most popular format for consumer and professional because of its small tape media size (6.3 mm, 120 min/cassette), full digital recording capability, appropriate cost compared with 8 mm camcorder and easy to configure non-linear editing system linking to PC.


151

The linking to a PC is done by IEEE1394 interface. Figure 5-11 shows the summary of DV Format.

• Digital Video (DV) Format – IEC61834 (1999) • Resolution䠖720x480(NTSC) 25.146Mbps • Audio 1.536Mbps – 48kHz/16bit 2 channel – 32kHz/12bit 4 channel

– Frame Compression using DCT

• Magnetic Tape Media – DV Cassette – mini-DV Cassette

Figure 5-11. DV Format

5.2.3. High Definition Video (HDV) Format Uncompressed video and especially high-definition (HD) video requires complex and extreme quantity of memory space since stream bandwidth that needs to be processed. Therefore many manufacturers have devoted substantial effort to create compression algorithms that reduce bandwidth while maintaining certain level of quality. Such compression induces latency issues especially when involving more than a single frame at a time. So called inter-frame compression, however allows achieving higher image quality compared to intra-frame compression only.

• High Definition Digital Video (HDV) – Canon, Sharp, Sony, Victor (2003)

• Resolution – 1280x720 (720p) 19.7Mbps – 1440x1080 (1080i) 25Mbps • 1080/25p 1080/30p 1080/24p

– Audio䠖48kHz/16bit 2 channel • MPEG1 Audio Layer2 (384Kbps)

– MPEG2 • Inter Frame Compression

– DV, mini-DV Figure 5-12. HDV Format

152


The inter-frame approach has been chosen for HDV compression, which is designed for compression of HD video with resulting bandwidth compatible with DV video to facilitate storage of HDV stream on DV tapes. Similar to DV, HDV is also designed for transmission over IEEE-1394 interface. The HDV format is actually just an MPEG-2 stream based on 8-bit color space with 4:2:0 sampling, resolution of 1440 x 1080, interlacing and 60:1 compression. In order to achieve the same bandwidth as DV stream (to avoid recording time reduction with DV cassettes), it uses inter-frame compression across 6 frames and thus it induces additional latency. Figure 5-12 shows the summary of HDV Format. 5.2.4. Interfaces With birth of digital video camera and its consumer video appliances, digital interface such as IEEE1394 or Universal Serial Bus (USB) are equipped to PCs. Both IEEE1394 and USB are required interface approved in PC System Design Guide published by Microsoft Cooperation and as a result, it is the most popular interface for digital connection. (1) IEEE1394 IEEE1394 is a high speed serial bus interface which is standardized in 1995 by “IEEE1394 Std.1394-1995 IEEE Standard for a High performance Serial Bus.” With some extension in protocol, IEEE Std.1394b-2002 is standardized in 2002. IEEE1394 has following characteristics. x x x

x

Bandwidth IEEE1394 Std.1394b-2002 states S3200 mode capable up to 3.2 Gbps bandwidth capability. Supports isochronous data transfer. Connector and Cables There are two kinds of IEEE1394 connectors: 6 pins and 4 pins. 6 pins connector includes the power distribution lines. Line specifications IEEE1394 Std.1394b-2002 specification states maximum cable length up to 100 m.with maximum of 16 serial connections. Daisy chain or tree based device connections are allowed. Each bus can connect up to 63 nodes, or by using the bridge, maximum of 1023 nodes can be connected. Hot Swap support IEEE1394 supports hot swap of devices during the powered condition. IEEE1394 resets the bus when node is either connected or disconnected, thus resulting topology update. Node ID will be autonomously re-generated once topology has been changed.

Isochronous and Asynchronous transfer are supported in IEEE1394 x Isochronous transfer mode Data can be transported up to 80 % of its bus utilization. Each data transfer occurs every 125 micro seconds. Data does not reply acknowledgement when sent to the destination. Used for Real-Time aware data transfer x Asynchronous transfer mode Old fashioned transfer mode using bus request and bus control. Receiver will reply acknowledgement packet when packets are arrived.


153

(2) USB Universal Serial Bus (USB) is developed to replace legacy PC interface. Standardization of USB started on January, 1996 (USB 1.0) which is replaced by USB1.1 with errata correction. In April 2000, High speed USB is standardized as USB2.0. USB has following characteristics. x x

x

x

Bandwidth USB2.0 supports maximum bandwidth of 480 Mbps in high speed mode. Connectors and cables There are two kinds of connectors: either host connector (A Jack) or device connector (B Jack). Cable consists of 4 wires: 2 for power supply, and 2 for signal lines. Line specifications Maximum cable length is 5 m. Supports tree topology device connectivity supporting up to 127 devices. HUB can be interconnected up to 6 layers. Host (usually a PC) has host controller. Hot Swap support

Compared to IEEE1394, USB supports 4 different transfer modes. x Isochronous transfer mode x Interrupt transfer mode x Bulk transfer mode x Control transfer mode By using USB or IEEE1394 interface, digital video consumer appliances can easily be connected to a PC resulting an easy generation of digital video and audio streams. By packetizing these streams in to IP, it is possible to send video and audio streams via networks without any analog format conversion capable of sending high quality video and audio streams. Figure 5-13 shows the methods of incorporating consumer video appliances sent over the network via digital interface.

Figure 5-13. DV transport system (DVTS)

154


(3) DVTS DVTS developed by member of WIDE Project is based on a high quality video and audio transport application using consumer Digital Video (DV) as an interface for encoding and decoding. DVTS is designed and implemented DVTS to meet the following conditions. 1) 2) 3) 4)

Real-Time high quality video will not require especial hardware low calculation cost

DVTS consists of a sender and a receiver. The sender application is called “dvsend” and the receiver application is called “dvrecv”. It is assumed that the host using dvsend has an IEEE1394 interface, and a DV device (a DV camera) is connected using the IEEE1394 interface. dvsend receives DV data via the IEEE1394 interface, encapsulates the DV data using RTP (Real-time Transport Protocol), and sends the RTP packets to dvrecv using IP. DVTS can be used with both IPv4 and IPv6. The RTP stream consumes about 30 Mbps of network bandwidth. Using DVTS, high quality video transportation over the Internet can be realized with low cost. DVTS is an isochronous application connected by the network, with requirements of strict deadlines in packet forwarding. dvsend Figure 5-14 shows the overview of dvsend. dvsend receives DV data via IEEE1394 and encapsulates the DV data into RTP. dvsend waits for an IEEE1394 packet that

Figure 5-14. Overview of dvsend


155

contains DV data. The DV data sent from DV equipment has an IEEE1394 header. The IEEE1394 header is removed, and the DV data is buffered within dvsend. Multiple numbers of 80-byte-long DV DIF blocks will be packed into a RTP packet, and sent to dvrecv. Each RTP packet from the same video frame will include the same value of RTP time stamp. Transition from one video frame to the next is indicated by a change in the RTP time stamp. Thus, DV/RTP receiver will not rely on particular packets for video frame transition. dvrecv Figure 5-15 shows the overview of dvrecv. The dvrecv application receives RTP packets sent by dvsend, reconstructs the DV data into a DV frame, and sends the reconstructed DV frame out via the IEEE1394 interface. In the DV format, the DV/IEEE1394 packets must be sent continuously. To send DV/IEEE1394 packets continuously, dvrecv consists of two processes, 1) DV/RTP packet receiver process and 2) IEEE1394 packet sender process. Both processes share the DV frame buffer using a shared memory. The DV/RTP packet receiver process receives the DV/RTP packet from the network continuously. DV data included in the received packets will be reconstructed to a DV frame. The reconstructed DV frame will be passed to the IEEE1394 packet sender process. The IEEE1394 packet sender process sends out the DV frame to the connected DV equipment via IEEE1394 continuously. RTP does not ensure the packet’s reach ability to the destination. Thus, tolerance to packet loss and jitters is required. dvrecv does frame buffering to absorb jitters. Though the large size of DV frame buffer suppresses jitter effect, it will increase the play out delay. The number of DV frame buffer can be selected considering the network situation and requirement when starting dvrecv. There are 2 error concealment strategies for packet loss. 1) if a packet loss is detected, display the previous DV frame that is complete. 2) If a packet loss is detected, use the related data from the previous DV frame. In DVTS, the latter strategy is used. Since every DV data consists of 80-byte-long DIF blocks, it is very easy to find the related data from the previous DV frame. When a packet loss is detected at dvrecv, the related DIF block from the previous DV frame is used in stead of the DIF block the dropped packet contains. The packet loss detection is done when transition from one DV frame to the next is indicated in the DV/RTP stream. The

Figure 5-15. Overview of dvrecv

156


transition of the video frame to the next is indicated by the change in the RTP time stamp field. When a transition from one video frame to the next is indicated, the data of the DV frame is sent out from the IEEE1394 interface. When a DV data of the next DV frame arrives from the RTP stream, it is overwritten in previous buffer of the DV frame. Thus, the former DV data will be used for the area where the DV data does not arrive. When a duplicated data arrives for the same DV data, it is simply overwritten. Using this mechanism, the last DV frame will be displayed when the RTP stream stops. The DV audio data are flushed every time after it is written to the IEEE1394 interface. Due to the fact that replacing the same audio data multiple times only causes noise. Thus, when a RTP packet that contains a DV audio data is lost, the corresponding part will be left ? flushed. 5.2.5 Frame Discarding Sending every DV data received from the IEEE1394 interface consumes over 30 Mbps bandwidth. When there is less bandwidth available for the network infrastructure, DVTS needs to adjust its bandwidth usage. The DV format does not use inter-frame compression technique. Thus, video frames can be discarded without difficulty. In the implementation compression of DV/RTP stream is realized by discarding video DV DIF blocks. The audio DV DIF blocks will be sent continuously. When the no picture frame discarding is done, both video and audio data are sent. When 1/2 rate picture frame discarding is done, the video data will not be sent once every 2 DV frames. When 1/3 rate picture frame discarding is done, the video data will only be sent once every 3 DV frames. This compression does not increase cost of the system. Additional complicated compression techniques ware not implemented since it can lead the entire system to require costs. The bandwidth consumed by DVTS traffic is shown in Table 5-3. The bandwidth measurement was done for both IPv4 and IPv6. 525-60 system was used for this measurement. Table 5-3. Traffic of DV Stream on IPv4 and IPv6 Frame Rate

Bandwidth IPv4 (Mbps)

Bandwidth IPv6 (Mbps)

1/1

30.47

31.70

1/2

15.72

16.83

1/3

11.48

11.84

1/4

9.01

9.33

1/5

7.54

7.83

1 / 10

4.74

4.87

1 / 20

3.26

3.39

1 / 30

2.79

2.90


157

5.2.6. Bandwidth and Reliability Because of the characteristic of low delay and DV format, DVTS is suitable for video conference with the same standard definition video quality. Although DVTS consumes 30 Mbps, it is being generally utilized due to the dissemination of high speed DSL and FTTH. However, the current best-effort Internet is heterogeneous, and does not guarantee Quality of service (QoS). Therefore, network congestion occurs in according to the network condition, which causes the disruption of video and audio. For a stable streaming quality, a sender must dynamically adjust the transport method according to the network condition. However, deciding the appropriate transmission method like a reduction of consumption bandwidth, Automatic Repeat reQuest (ARQ), and Forward Error Correction (FEC), is a real challenge for a Real-Time streaming. Real-Time streaming is usually transmitted over RTP carried on top of IP and UDP, and RTCP sent with RTP supports “Rate Control” as one of the fundamental functions to adjust the transmission rate based on the capacity of the available bandwidth or to adapt to network congestion. ARQ is used to recover packet loss by sender retransmission of the loss packet. In Real-Time streaming, low delay is important, which means that a sender and receiver cannot generate the large amount of buffer. Therefore, Real-Time streaming cannot often apply ARQ. There is another technology, by which a sender adds redundant data to its steam and a receiver detects and corrects errors being happened during transmission without the need to ask the sender for additional data. As its typical approach, a “Forward Error Correction (FEC)” algorithm has been notably used in various applications. In end-to-end model, Real-Time streaming generally tries to keep stable streaming quality in according to the change of network condition. When network congestion occurs and causes packet loss, a sender must execute a supportive packet loss avoidance and quality adaptation mechanism, such as Frame Rate Control and Dynamic FEC. If a sender can not adjust transport method, packet loss severely effects on streaming quality. Rate Control such as Frame rate control is used to reduce the consumed bandwidth by discarding Video data. A sender can quickly execute this method, which means that the delay does not become very long. Therefore, Rate Control is the most important method for congestion control. Changing the rate of compression is not suitable for Real-Time streaming, because it takes more time to execute. As its typical approach, FEC scheme is so suitable for Real-Time streaming that Many streaming applications have applied it. Because, a sender decide the appropriate FEC encoding rate, by which a receiver can quickly recover packet loss to maintain streaming quality without receiver reporting action. As a way of another technology, there is network resource management technology. One of its major protocols is “Resource reSerVation Protocol (RSVP)”, which reserves network bandwidth between a sender and a receiver for data transmission. “Class-Based Queuing (CBQ)” is a resource sharing mechanism that shares the bandwidth on a link in packet networks. Both require resource management mechanisms at the network equipment level, where requiring a gateway to accommodate an essential component is hard to assume and lacks the flexibility of communication. It is difficult to adopt these techniques for common streaming architecture used over the wide-spread Internet.

158


5.2.7. Enhancement in DVTS (1) Redundant Audio Transmission By sending the DV audio data multiple times, robustness of DV audio data can be obtained. The network bandwidth used by the DV audio data is trivial compared to the DV video and system data. Thus, it is scalable to send DV audio data multiple times. (2) TCP-Friendly Congestion Control for DVTS Most Real-Time application uses UDP as a transport layer protocol. UDP does not have a congestion control mechanism. Thus, UDP coexistence with TCP, which has a congestion control mechanism, is being impossible. To resolve this issue, application level congestion control is required, when using UDP as a transport layer protocol. By implementing congestion control mechanism within DVTS, TCP-friendly Real-Time video and audio transmission can be realized. DVTS will use as much bandwidth as possible when there is no other traffic within the network. However, when congestion occurs within the network, it reduces use of network bandwidth. Reduction of network bandwidth is done by discarding picture frames from the sender application dynamically. By reducing use of network bandwidth during network congestion, DVTS is TCP-friendly, and the use of network bandwidth will be fair. However, this scheme requires packet loss to be detected to trigger the adjustment mechanism. The packet loss on Real-Time video and audio transmission will result to malformed output on the video and audio. Thus, TCP-friendly Real-Time video and audio transmission applications are not deployed. Mathematically making the Real-Time video and audio trans-mission TCP-friendly can be realized. However, since packet loss can decrease the quality of video and audio drastically, a bandwidth estimation mechanism that can work before large number of packets losses, are required. (3) Packet Lossless TCP-Friendly DVTS using ECN TCP-friendly DVTS can adapt to available bandwidth and share bandwidth with commodity traffic. However, TCP-friendly DVTS can not stabilize its traffic. When TCP-friendly DVTS shares network bandwidth with other traffic, the traffic sent is increased and decreased periodically like TCP traffic. The increase and decrease of DVTS traffic is caused by the rapid change of picture frame rate. Packet loss is caused periodically after the picture frame rate is increased. The periodical packet loss decreases the quality of video and audio. This problem is caused because TCP-friendly DVTS rely on packet loss for congestion detection. By using ECN, network congestion can be detected without packet losses. 5.2.8 Adaption Requirements in Real-Time Streams To keep stable streaming quality and effectively utilize network resource in end to end model, it is necessary for a sender to adapt the best combination between Frame rate and FEC encoding rate. A congestion control mechanism would be indispensable to avoid packet loss. Rate control is often used as congestion control. By reducing the consumed bandwidth and sending data within the network bandwidth, the disruption of video and audio is solved. However, more reducing transmission rate cause ineffectively use of network resource, which means that the best possible quality streaming cannot be provided. One of the notable and possible approaches is “TCP friendly rate control”; it behaves fairly with respect to coexistent TCP flows in order to provide a promising mechanism


159

for avoiding severe fluctuations in the transmission rate. While it ensures fairness with competing TCP flows, the throughput of non-TCP flows does not exceed the throughput of a conformant TCP connection under the same conditions, where this condition is not reasonable for DV streaming that consumes high bandwidth. FEC is effective especially for streaming applications because it adds redundant information to packets in order to allow a receiver to correct missing packets without retransmission requests. This redundancy level is defined as FEC encoding rate, which is decided by a Bit Error Rate (BER) of the receiving side and the previously used encoding rate. FEC rate control is used to change the redundancy of data; its higher value increases the possibility of recovering the stream but increases the amount of traffic. Intellectual decision is given in this mechanism. Analysis in relates to packet loss recovery. An FEC mechanism is effective for a streaming application especially when lost packets pattern are “pulse” through the stream of packets, or when network condition is unstable or changed at frequent intervals. This analysis inspires us to monitor the FEC recovery rate in the stream to expect the network condition, because the packet loss is recovered only when it is lower than the FEC encoding rate. For instance, if FEC does not completely recover the lost packets during streaming for a certain period, it implies that the network congestion may not be converged and more rate control would be needed. Thus, to keep stable streaming quality and effectively utilize network resource in end-to-end model, it is necessary but very difficult for a sender to adapt the best combination between Frame rate and FEC encoding rate. 5.2.9. Unique Media Streaming Events With capability of streaming high quality video and audio streams, countless demonstrations and events are organized in the Internet world. 5.2.9.1. Internet Metronome An experimental remote jazz jam session with uncompressed HDTV over the Internet was conducted on September 21st as a Grand Final event of the Aichi Exposition 2005. Professional jazz musicians located at the venue of Aichi Exposition and at SARA in Amsterdam have made the jazz jam session with new mechanisms called as “Internet Metronome” and “delay-control unit” using an international “lightpath”. This was the first music collaboration using a new methodology and one of the challenging demonstrations to transport the uncompressed HDTV streams with timing control under the current software and hardware architectures. “Internet Metronome” and “delaycontrol unit” enabled to make a tempo using and controlling delay, and “lightpath” minimized the network jitter. Using these new mechanisms and technology, the musicians could play with new music collaboration environment over the Internet with long communication delay, and enjoyed remote jazz jam session at both ends. There are several researches on the music collaboration over the Internet. Large delay, jitter, other communication parameters, and audio video quality are main focuses on those researches. For example, SoundWIRE Project has been discussed about the method of audio synchronization and reliable professional quality audio streaming. This experimental jazz jam session on the Aichi Exposition 2005 was the first music collaboration with long-haul Internet with lightpath technology for minimized the jitter.

160


While the trials of previous music collaborations like SoundWIRE Project tried to identify the allowance delay over the Internet, they didn’t accept the large delay in a long distance communication. Our strategy was different from those previous music collaborations. We explicitly consider the delay over the Internet, and did not ignore the delay. “Internet Metronome” with “delay-control unit” provided a new music collaboration environment over the Internet with long delay. Internet Metronome made a tempo using the delay. It was demonstrated that the musicians were able to play with this new music collaboration environment. In this paper, the “Internet Metronome” and “delay-control unit” for “lightpath” technology are described in the following the sections. The experimental remote jazz jam session at the Aichi Exposition 2005 between the venue and Netherlands with result of the international lightpath configuration is also described. The “lightpath” technology provides the provisioning services for the Internet applications. i-Visto is used as uncompressed HDTV streaming for the experimentation. The i-Visto has buffer of only two frames. This means that the i-Visto can not work in a large jitter environment. In the normal situation, there is large jitter on the Internet between Japan and Netherlands. The success on the experimental jazz jam session realized and proofed the availability of the “lightpath” technology. 5.2.9.2. DMC Global Studio Project The research institute for Digital Media and Content at Keio University (DMC) was launched in 2004. It has two objectives: to promote the creation of contextual digital

Figure 5-16. DMC Studio


161

content and to develop research, encourage and international distribution, develop human resources in cooperation with other institutions in the world. DMC Global Studio Project is one of the projects in DMC. It was started in 2005 to achieve DMC objectives. The project is designing the Global Studio architecture and operating global studios. DMC Global Studios are operated by several organizations. In July 2007, there are 3 Universities and 2 other organizations are running the Global Studio with DMC. Each partner organization provides at least one Global Studio to participate the project. By providing resources, partner organization can use other partner’s Global Studio. With this mechanism, professor or researcher of participate organization could use the resources at other organizations. The DMC Global Studio project is also collaborating with SOI-Asia project. The SOI-Asia project is a human resource development project in Asian countries. Global Studio is open for it. SOI-Asia professors could teach their student from any Global Studio they want to use. Figure 5-16 shows the studio constructed world-wide. 5.2.10. IPTV 5.2.10.1. Overview of IPTV The definition of IPTV is approved by ITU-T FG-IPTVF in October, 2006. In this agreement, IPTV is defined as a service which transports television, video, audio, text, picture images, and data through IP networks. Transport network also requires reliability factors such as QOS, QOE and security features. Setting a standard for IPTV would be difficult since there are multiple areas to cover, as meaning of IPTV is broad, and the IP infrastructure are initially not meant to be transporting audio and video when constructed. IPTV delivery network infrastructure are assumed to be managed by ISP, constructed with core network using CDN technology, and optical fiber or ADSL connection to the access network of their clients. Figure 5-17 shows the typical IPTV service infrastructure.

STB

Headend Content Delivery Network ( CDN ) Management Server

STB Home Gateway Access Network

INTERNET STB

Figure 5-17. IPTV Overview

162


On IPTV systems, video and audio are encapsulated in an intermediate packetized layer, which is video format agnostic called Transport Stream (TS). It is defined in the MPEG2 systems standard and assures synchronization, signaling and security. Transport mechanism for IPTV is based on RTP IP multicast. Contents, especially, the video streams, are compressed by MPEG2, or H.264 format encapsulated into MPEG2TS packet. This is a trend technology used to transport digital broadcast and cable television. As of now, MPEG2 SDTV is a main stream of IPTV, which will soon be replaced by H.264 HDTV. This TS solution as a widely deployed solution that has been used for ages, but it also brings an additional overhead to the network, where bandwidth becomes a scarce resource as we get closer to the clients, and it lacks flexibility and scalability. Another solution consists in putting directly the video data inside the RTP packets without the TS encapsulation. IETF has issued much standardization to achieve this for different video formats. It has the advantages of consuming less bandwidth, allowing more flexibility and scalability and enabling new features and services easily. Digital Video Broadcasting (DVB) forum has issued a standard for the TS based approach; the Internet Streaming Media Alliance (ISMA) has issued specification using the non TS based approach. One of the reality issues on implementation of IPTV is the infrastructure environment. Especially channel zapping may cause network bandwidth shortage in some of the home network. Major western countries have ADSL network infrastructure for the last one mile connection. Maximum throughputs of their network are limited to 20 to 30 Mbps. Fiber connected network infrastructure seen in Japan, have access capability of up to 1Gbps, but limited to 100 Mbps. Bandwidth capable of sending most of the channel to adapt channel zapping capability is a challenge with limited bandwidth. In year 2005, there are more than 3 million clients connected to some kind of IPTV services. Currently, most of the IPTV services are live TV and VoD services. In the near future, personal contents, community contents generated by SNS, communication and collaboration combination with multiple media will grow together as one whole service assuming more than 45 million clients gathered in the infrastructure in 2010. 5.2.10.2. Standardization of IPTV Standardization of IPTV is driven by ITU-T Focus Group (FG) IPTV. The mission of FG IPTV is to coordinate and promote the development of global IPTV standards taking into account the existing work of the ITU study groups as well as Standards Developing Organizations, Forums and Consortiums. The first meeting of FG IPTV was held in July 10th to 14th, 2006 in Geneva. In this meeting, initial IPTV has been defined as follows. “IPTV is defined as multimedia services such as television / video / audio / text / graphics / data delivered over IP based networks managed to provide the required level of QoS / QoE, security, interactivity, and reliability.” Six working groups is initially constructed as follows, WG1: Requirements and Architecture of IPTV WG2: QoS and Performance WG3: Service Security and Content Protection WG4: IPTV Network Control Aspects WG5: End Systems and Interoperability Report


163

WG6: Middleware, Application and Content Platforms 5.2.10.3. IPTV and Security Current broadcast uses ARIB STD B25 Digital Right Management (DRM) content protection. This technology uses CAS to authenticate the clients and descramble the content. There are 2 categories to make IPTV contents protection system. 1) protection the network access via AAA service, 2) the media itself protection via CA or DRM method. All access from the subscribers are connected to the SMS (Subscriber Management System) and BS (Billing Server) to request the access bill to the each subscriber of IPTV. After receiving the media, storing and re-distribution to other CODEC, transfer to the other display devices are controlled by DRM. In IP infrastructure, it is generally expected that content is viewable immediately after selecting channel, for instance, channel zapping. For this reason, it is desirable to use a time-limited licensing that is compatible with broadcast methods.

5.3. Peer-to-Peer TV Broadcasting System 5.3.1 Issues and Features of Conventional IP Multicast Service Architecture Due to the rapid and significant technical improvement on video compression algorithm, processor, CPU capacity and silicon memory, we can enjoy the high quality video playing and processing without any special hardware or accelerator, but just with a plain and ordinary PC platform. Though the professional providers had tried realtime video delivery to large number of customers in the past, they have experienced the following technical difficulty. (1) Quality; Available or affordable bandwidth per customer was 100-300 Kbps (2) Quantity; Maximum number of customer is 1,000-10,000 When the available bandwidth is 300 Kbps, the quality of video image is worse than the conventional analogue TV program or the video tape video (e.g., VHS), even if we used the latest video compression technology. Also, the maximum number of customers of 10,000 is far smaller than the capability of legacy broadcasting system. This system feature is derived by the use of conventional CDN (Contents Delivery Network) technology or by the use of legacy unicast technology. In the following subsections, we summarize the issues and features of available multicast service architectures. 5.3.1.1. Unicast-based Multicast † Every single client node receives data directory from server node using the unicast transmission service. [Benefits] (1) Does not require any special equipment, software nor configuration † Though there are some different definitions of “Unicast-based multicast,” it means simple server-client based live streaming service using a unicast technology in this section.

164


Since unicast packet transmission is used by many applications, the IPS does not need to install any special equipment in their network (2) Error recovery against packet loss Since the TCP can be applied to for unicast based multicast service, the provider could offer error-free multicast service. TCP manages the flow for per customer, and it’s packet retransmission capability against packet loss recover the transmission error. Even when UDP is applied to, many applications using the UDP socket implement own error check and recovery function between server and client. This means that network does not need to achieve 100 % of packet delivery to the customer, but the server node works for 100 % data delivery to the client node. (3) Applicable to all the ISP Unicast IP packet transmission can be universally available among almost all of ISPes, and ISPes maintain the global and universal IP packet delivery among them. Therefore, we do not need to care about if which ISP the client node belongs to. (4) Stable, associated with implementation and operation As for the network equipment, client node and server node, the interoperability has been well established. Also, as for the network operation, the network operator and residential customer should be well familiar with the configuration and management of unicast communication. Important point is that, with unicast service, the routing entries at the routers in the network are not affected by end-customer’s equipments. (5) Friendliness with firewall router and NAT router There are a lot of security software and hardware product, these are familiar with unicast communication from following reasons. 1. Connection is initiated by client node to server, not client-to-client nor serverto-client 2. TCP/UDP port number used by server node is generally fixed [Drawbacks] (1) Required bandwidth at server Server node must transmit a lot of exactly the same data toward the different destination client nodes. This means that the required bandwidth at the server is proportional to the number of client nodes. For example, with an 300 Kbps/user flow for 10,000 client nodes, server needs 3 Gbps bandwidth. For 100,000 client nodes, 30 Gbps bandwidth must be provided to server. For future larger bandwidth provision, it is impossible to provide by single site, in practice. (2) Required bandwidth in network As for the bandwidth in the network, the required bandwidth resource in the network is the summation of (bandwidth) x (transmission-distance) for all the client flows. (3) Slow response against zapping The latency to start the play of received data has strong dependency on the amount of initial buffering at client node. When the packet transport jitter is large, we must have larger initial buffering. Also, when the client provides the error-free data transmission, it must run the data re-transmission against the lost packets. In order to execute the packet re-transmission, reasonably large initial buffering is mandated. In many unicast implementations, the initial buffering are saying few decades seconds.


165

As discussed above, the unicast based multicast service is stable for implementation and operation, while achieving the ISP-independent service offering. Therefore, many service providers use unicast based multicast service. However, the bandwidth requirement against the increase of per-flow bandwidth (due to the increase of video quality), and the increase of client nodes is getting serious in these days. Though CDN is introduced, in order to solve this operational issue, CDN is still client server and unicast based architecture. In other words, the CDN is not essential architecture to solve the technical and operational issues of unicast based multicast service. 5.3.1.2. IP Multicast In the IP multicast, the intermediate node, i.e., router node, plays important role, as well as server node and client node. Server can send only one IP packet, even when the number of client nodes is so large. The intermediate nodes run several protocols (e.g., IGMP, DVMRP, PIM-SM), associated with multicast service. Based on the information obtained by these special protocols, the appropriate intermediate nodes (i.e., multicast routers and switches) relay the received (multicast) IP packets to make appropriate number of copies and to forward the received (multicast) IP packets. [Benefits] (1) Required bandwidth at server The required bandwidth at the server side does not increase, even when the number of client nodes increases. Not only does not increase the required bandwidth, but also the required bandwidth could be the same amount as client node requires. (2) Required bandwidth in the network Since the IP packet is copied at the intermediate nodes (i.e., multicast routers and switches), the total bandwidth resource can be (far) smaller than the unicast based multicast, in general. (3) Response time against zapping Server does not directly transmit the IP packet to the client nodes. Although the IP multicast system may be hard to achieve error-free data delivery, the system does not need to run the error-correction/recovery function. Also, the client node does not have large initial buffering, since the initial buffering is only come up with the packet transport jitter, which is not generally large. In practice, the zapping latency in the IP multicast system is generally less than one second. [Drawbacks] (1) Needs multicast capable equipments and software R&D on the IP muticast technology has been progressed more than 20 years. However, the development of IP multicast network is with M-Bone, which is an overlay network with IP tunneling. Also, the development of M-Bone is mainly at the academic networks, and is not common at commercial ISPes. The primary reasons why the commercial ISPes hesitate the introduction of IP multicast service are (a) not all the equipments are IP multicast ready, and (b) some additional configuration is required for ISP operators. If the ISP does not turn on the IP multicast, multicast IP packet is discarded. (2) Hard to provide error-free data delivery Since the server does not maintain the per-flow data delivery, it is hard to achieve error-free data delivery for IP multicast service. In order to provide better quality

166


for multicast packet, the priority control for packet discard and transmission scheduling is frequently applied to. This control is better than best effort, but not true error-free. (3) Hard to achieve ISP-independence operation When an ISP does not turn on IP multicasting, the received IP packet from the neighbor ISP must be discarded. This means that, when a client node belongs to the ISP that does not turn on IP multicast, server can not offer the IP multicast service to this client node. (4) Stability of operation and implementation The largest concerning for the ISP operator is that, in IP multicast service, the routing entries in the ISP router will naturally affected by the behavior of client nodes. According to the participation and withdrawing of client node, the (multicast) routing entries shall be changed. This means that it would be hard to maintain the operational and control initiatives by the ISP operator. ISP operator wants to avoid to afford the capability of routing entry control to the clients, in order to maintain the controllability of the network. Yet, another reason is lack of operational experiences for ISP operators. (5) Hard to co-exist with firewall and NAT routers Many firewall routers and NAT routers do not aware of IP multicast service. The default behavior of un-awared router is just discarding the received packet. In order to come up with these routers, additional equipments or configuration, e.g., IGMP proxy, is required. As discussed above, the pros and cons of IP multicast and unicast based multicast is just symmetric. 5.3.1.3. OLM (OverLay Multicast) OLM is applying the Peer-to-Peer (P2P) technology for multicast service. Server transmits the IP packets to some selected client nodes. These selected nodes forward the received IP packets to the other clients node. This packet forwarding algorithm can be applied to, recursive way for scale up to accommodate large number of client nodes. The packet transmission in the OLM system is by unicast, in general. [Benefits] (1) Required bandwidth at server is constant In the OLM system, server transmits only to selected client nodes. By the controlling the number of these client nodes of constant, the required bandwidth at server can be maintained as constant value. (2) Does not need special equipment Since each packet transmission between server-client and client-client is by unicast, no special equipments in the network is required. (3) Error-free packet delivery The packet transmission among client nodes and server is TCP, the error-free packet delivery can be achieved. (4) ISP-independent service delivery Since the packet transmission is by unicast, service can be easily expanded to the other ISP.


167

[Drawbacks] (1) Large zapping latency As well as the unicast based multicast, OLM system provides error-free packet delivery among nodes. This means that every node must run the data retransmission against the lost packets. In order to execute the packet re-transmission, reasonably large initial buffering is mandated. Moreover, OLM needs an extra latency to search the node(s), who takes care of the packet retransmission. (2) Stability of service Since OLM does not have enough operational experience, the operational stability and the stability of software would not enough as the conventional multicasting (i.e., unicast-based multicast and IP multicast). Also, since the OLM does depends on the co-operation of end-users’ equipments, the system would generally lead to less reliability and stability. (3) Efficiency of network resource usage When the hierarchical relation/topology of OLM packet delivery tree is the same as the physical network topology, the network bandwidth resource would be used most efficiently. However, when these topologies is not the same, the network resource would be used inefficiently. (4) Friendliness with firewall routers and NAT routers Many firewall routers and NAT routers allow out-going connections, but not incoming connections. This behavior may restrict packet transmissions between clients. As discussed above, it seems that OLM could basically solve the some serious issues of unicast based multicast and IP multicast, while inheriting the benefits of these multicast service architecture, while the latency of response against zapping would become worse than these two legacy multicast service architectures. 5.3.2. Business Deployment of Peer-to-Peer TV Multicasting System TV Bank corporation, www.tv-bank.com, is providing the TV multicasting service based on OLM technology for all ISPes. TV bank corporation provides contents delivery technologies and procures the professional contents to be delivered (i.e., contents aggregation). The contents delivery technologies provided by TV bank corporation are; (1) Head-end system, which is contents collection from contents holders (2) VoD contents delivery system (3) Semi-Realtime multicast contents delivery service using the OLM technology, called as “BBbroadcast” system ‡. 5.3.3. BBbroadcast System BBbroadcast system has been developed by TV bank corporation and Roxbeam Media Network (China). The system composed by server and client software. The endcustomers install the Bbbroadcast’s client software to join to the OLM network. Realtime video is provided with live-streaming fashion with TV quality. Streaming file is ‡

Bbbroadcast is registered trademark of TV Bank Corp. in Japan.

168


developed only on the memory space, i.e., the streaming file is never developed on the disk space. This is important feature for contents holders and for content service providers. Also, many technical features, e.g., contents query or buffering, are quite different from many un-professional File-Sharing applications, e.g., Winny. Server system of BBbroadcast is composed by the following three components. (1)

Package server; server feeding the original content to the BBbroadcast’s network. (2) Delivery supporting server; servers copying and forwarding the contents to the down-stream delivery supporting server or to the client nodes. (3) Boot server; server providing sufficient information for newly joining client node. Here, newly joined client node would play delivery supporting server and play other client node. As for packet server and boot server, one active server must run for each multicast channel. The package server obtains the media data of corresponding multicast channel from Windows media server, to transmit the data with the data format of BBbroadcast system. This server also encrypt the data in BBbroadcast system to protect the contents data from malicious usage by the customers. The delivery supporting server copies and forwards the contents data toward the downward. Package server is the root of contents delivery tree, and the delivery supporting servers are the intermediate nodes in the content delivery tree. Fast establishment or configuration of an optimal or an appropriate content delivery tree is the key of efficient operation for the OLM system. Boot server is providing the sufficient configuration information, in order that a client node can join to the Bbbroadcast’s network. In initial stage, the client node login

Courtesy of TV Bank Corp. Figure 5-18. Boot sequence of client node in BBbroadcast System


169

to boot server and obtains partner list. This list contains information of some delivery supporting servers and other clients, where the newly joined node should connect to. After the initial stage, the client nodes exchanges their partner list with each other periodically, and finds better partner autonomously. Client software is composed by BBbroadcast module (P2P engine) and it’s control module (Active X control). When the client node access the web page of content delivery, BBbroadcast module is executed by the JavaScript sent from the web page. Since the BBbroadcast system is an P2P system, which depends on the end-users’ nodes to provide service, the intelligent mechanism/algorithm must be implemented for enough robust and stable service provision. In order to satisfy this requirement, BBbroadcast system adapts the following techniques. (1) (2) (3) (4) (5) (6)

Mesh topology network Local cache buffer Bi-directional data transmission High speed partner search/resolve Hybrid P2P Service Security

5.3.3.1. Mesh Topology Network For content data delivery, BBbroadcast system does not use simple tree topology, but use the mesh topology. Though the tree topology is optimal and efficient associated with the usage of network resource (i.e., bandwidth), the tree topology has single point of failure. In a tree topology, by a single failure, the whole of contents delivery system beyond the failure node does not work. On the contrary, with the mesh topology network, we can avoid the single point of failure. This is because the multiple (or alternative) content delivery path(s) is provided, against some node failure, while the system can not achieve effective resource usage. In the BBbroadcast system, many optimization mechanisms are introduced to establish effective mesh topology, rather than too simple full-mesh topology, which is very inefficient, associated with the usage of network resource.

Courtesy of TV Bank Corp. Figure 5-19. Mesh topology for robust service

170


5.3.3.2. Local Cache Buffer In BBbroadcast system, the streaming file is developed only on the memory space, i.e., the streaming file is never developed on the disk space. This is to avoid the illegal copy at the customer nodes. This is important feature for contents holders and for contents service providers. Also, many technical features, e.g., contents query or buffering, are quite different from many un-professional File-Sharing applications. The video data is buffered at the memory space in the PC, to fulfill the packet retransmission against the packet loss among the PCs. This is the fatal benefit of BBbroadcast against the IP multicasting, which uses UDP packet transmission to be hard to fulfill the packet retransmission so as to achieve error-free multicast data delivery to the client nodes. BB broadcasting used “hop-by-hop”, not the end-to-end between content server and client node, TCP among client nodes, to achieve error-free multicast data delivery. Also, the local buffer plays an important role to improve the system robustness against short time network failure. The customer nodes, which use some unstable link such as ADSL or WiFi, experience temporal quality degradation on multicast data transmission. Even in the case where the node handover between wireless access and wired access, the local buffering improves the quality of multicast data delivery among the client nodes. 5.3.3.3. Bi-directional Data Transmission In the conventional P2P system, the client node, which wants to obtain some file, firstly resolves the (target) node, which contains the target file, then accesses the target node to request the file transmission to the client node. Therefore, when the node containing the target file is sitting in the NAT segment, some special communication protocol must be used or some proxy node must be installed in the non-NAT segment. This is called uni-directional data transmission. On the other hand, in BBbroadcast, all client node basically has same data since BBbroadcast is live streaming system. So, what the client node does is trying to find out the accessible client nodes, which should have the target data. Also, there is no direction regarding the TCP session among the client nodes. Many residential customers in Japan use NAT router to connect to the network. In this environment, conventional P2P system may not work well. However, BBbroadcast system works well, even when there are a lot of NAT router segments. 5.3.3.4. High Speed Partner Search/resolve When a new client node joins to the network, the client node wants to connect to the networks as fast as possible. In order to do this, the system should provide some hints regarding the partner nodes, which accept in-coming connections. This is especially important for the client nodes, which are sitting in the NAT segment. In BBbroadcast system, this hint information is accommodated in the boot server or in the already connected client nodes. Here, using these information, the better network topology establishment can be achieved rapidly. 5.3.3.5. Hybrid P2P In the actual operation, it is frequently occured that the newly joined client node needs large latency to find out appropriate partner nodes or the node, to which the newly joined client node tries to connect, is overloaded because the full number of client


171

nodes have already accommodated or because the available bandwidth to transmit the multicast data to the client nodes has already become too small. Therefore, before finding an appropriate partner node, the newly joined client node obtains the streaming data directly from the special server node, which is called as delivery supporting server. After enough number of connections with the partner nodes are established, the connection with the delivery supporting server is released. This means that, before joining to the BBbroadcast P2P network, the client node uses unicast based client server architecture. By means of this operational transition (from unicast based client server operation to BBbroadcast peer-to-peer operation), the same latency so as to join to the Peer-to-Peer network can be same the legacy unicast based client server system. 5.3.3.6. Service Security In BBbroadcast system, two of service security are considered. One is to protect the copyright contents from dishonest or illegal malicious client node, from the view point of appropriate copyright management in the system. The other is so called channel hijacking, where a malicious user behaves as a server of BBbroadcast system. (1) Protecting the Copyright Contents from Dishonest or Illegal Malicious Client Node BBbroadcast system can use the same content protection technology, as the one conventional unicast based multicasting system uses. Since the delivery of the contents in the BBbroadcast system is transparent, the original contents management and protection function can be used for all the client nodes. Usually, we use the Microsoft Windows Media DRM technology. (2) Protecting from Channel Hijacking All the transmitting data in the BBbroadcast system is encrypted and authenticated by RSA public key algorithm. The key, called as channel key, is generated per broadcast channel. The public key for the channel key is distributed by P2P system itself, and the public key is encrypted and authenticated by another key. The key to encrypt the channel key is also encrypted and authenticated by 3rd key, called as the system key. The public key for the system key is saved in the client node, during the installation process. The public key per channel is encrypted by secret key of system key, to be delivered via the P2P system. The secret key of system key is strictly managed with off-line fashion, so that the key can never be put on the network. The secret key of channel key is saved in the package server, and the client node encrypts and authenticates the transmitting data using this secret key. Client node checks the received data using this public (channel) key. When the data is encrypted using wrong key, the received data is discarded. In order to hijack the channel, somehow, you must obtain the key, or replace the public key saved in the client node; this is practically hard to fulfill. Also, the BBbroadcast system itself is examined by third party auditing. By these technical and operational considerations, we try to establish sufficient service security for the end users.

172


5.3.4. Operational Performance of BBbroadcast BBbroadcast has run the public beta testing since June of 2005, and run more than 600 public events. In the events, we have transmitted 768 Kbps multicasting streaming. The important performance evaluation matrix is the consumed bandwidth at the server, against the number of clients. The behavior of consumed bandwidth should be small enough, even when the number of clients increases rapidly. (1) Instantaneous Number of Clients The maximum instantaneous number of clients for the BBbroadcast system was 48,545 on October 11, 2006. The contents was play-off game of professional baseball. The peak was observed at 21:20 with 48,545 clients. Then, the consumed bandwidth at the server was about 7 Gbps. When we did the same broadcasting with unicast based multicast service, we needed 37.3 Gbps. This means that, by the use of BBbroadcast technology, we could save more than 80 % of bandwidth at the server. Also, even though the number of clients increased with time, the consumed bandwidth at the server could remain the same level.

Courtesy of TV Bank Corp. Figure 5-20. Performance of BB Broadcast system (October 11, 2006)

(2) Total Number of Clients The other event was September 27, 2006. The total number of clients during the event was 124,089. The contents was also another professional baseball. We observed the peak at 21:50, the number of clinets were 35,183. The maximum consumed bandwidth was about 6.6 Gbps. Since the expected bandwidth with legacy unicast based multicast was about 27 Gbps, we could reduce about 75 % of bandwidth at the server. Also, again, even though the number of clients increased with time, the consumed bandwidth at the server could remain the same level.


173

Courtesy of TV Bank Corp. Figure 5-21. Performance of BBbroadcast system (September 27, 2006)

5.4. Wide Area IPv6 Access Network and Service 5.4.1. FLET’S HIKARI Premium Service “FLET’S Hikari Premium” service, whose system design has been discussed since around 2002, has been started a general service since March of 2005 by NTT West (www.ntt-west.co.jp). Here, “Hikari” means “optical” in Japanese, and NTT West covers whole of west-half Japan. FLET’S Hikari Premium is the access service menu provided by NTT West, as succeeding their ISDN, ADSL, and Ethernet service based on fiber access. As of June 2007, the number customers of FLET’S Hikari Premium has reached around 2 millions. Basically, the access network is build with the GE-PON technology. For residential customer, 100 Mbps (Fast Ethernet) is provided called as Family-Type, and for corporate customer, 1 Gbps (Gigabit Ethernet) is provided called as EnterpriseType. These services are quite different from the previous services, since the whole of network is based on IPv6 technology, called as wide-area closed IPv6 network. FLET’S Hikari Premium service has backward compatibility against the legacy services, while replacing the basic transport technology to IPv6. The reason why we have introduced IPv6 technology is to achieve (1) scalability for large number of always-on customers, (2) less operational cost, (3) less investment on network equipments, and (4) broadband application using wide-band feature of fiber access Especially, simple network configuration leads to less operational cost for large scale access network provider.

174


Figure 5-22. FLET’S Premium Network Structure

5.4.2. System Architecture of FLET’S Hikari Premium 5.4.2.1. Non-PPP Networking Legacy access networks use PPP (Point-to-Point Protocol) technology. At the network accommodating the end-customers uses PPPoE (PPP over Ethernet) tech-nology, in order to run the layer 3 independent authentication, and the network accommodating the ISP uses IP tunneling protocol encapsulating the PPP packets. Between PPPoE segment and IP tunneling segment, we need a interworking equipment, called as BAS (Broadband Access Server) . BAS works well, when the number of subscribers is not so large and when the subscribers were not always-on. Also, especially, the BAS based PPPoE architecture will not work efficiently for peer-to-peer application. FLET’S Hikari Premium adopt IP version “6”, rather than IP version “4”, since the access network must accommodate tens of million subscribers. IP version 4 was fine for legacy systems, that has few million subscribers, however we considered IP version 4 will not appropriate for the succeeding access network.


175

Figure 5-23. Conventional access network architecture

Figure 5-24. Architecture of FLET’S Premium network

5.4.2.2. End-to-End Architecture with CTU The access service provider must provide wide spectrum of service types to various types of customers, with low cost. IP network (or the Internet) has proofed the success of end-to-end architecture. In IP network, whenever you attached new equipments at the edge of the network, you can start the new service, using the plain and common IP transport platform. The existing access network was not single platform, but was composed by multiple (physical) networks, that adopt different networking technology (e.g., ATM, Ethernet, SDH, Frame Relay). From the start, FLET’s has been built with IP technology in its core network, we have flexibility while considering Layer2 (PPP) service. We have removed PPP and BAS from the access network, and have introduced CTU (Customer Terminal Unit) while providing the IP tunnel between CTU and NTE(Network Termination Equipment). You can realize that the function of BAS is absorbed by CTU, to remove the intermediate equipment in the access network. CTU, which is installed in each customer site, has a lot of function that had been installed in the intermediate equipments in the network. Also, when we introduce new function, we had to install new function or equipment in the access network. The important point of pushing back these functions into CTU from intermediate equipment is to reduce the amount of load to process the functions on these equipments. The intermediate equipment must take care large number of customers, but the CTU takes care only one customer. We reached the conclusion that the “CTU” approach as distributed processing design leads reducing CAPEX in our case.

176


One of important functions of the CTU is QoS (Quality of Service). In the previous network, we do not have fully functional QoS, especially diff-serve, since the CTU has QoS function (i.e., DSCP marking for diff-serve and CoS marking in VLANtag), which is off-loaded approach compared to performing those mark-remarking tasks on the concentrated equipment. The rest of the network just care about packet scheduling based on DSCP value or CoS value. Therefore, the CTU is so called one of reliable edge routers. 5.4.2.3. Network Prefix Allocation to Customer Network CTU is a router, rather than bridge or switch. In the previous access network, TA (Terminal Adaptor) installed at the customer’s site was bridge or switch. When the customer wants to connect their home “network”, they must use NAT box. Without NAT box, the IP address of end-station attached to the home “network” at the customer site would always change, whenever it connects to the network. Also, the IP address allocated to the end-station may belong to the same (layer 3) network segment of other customers’ end-stations. In other words, the customer site could not be delegated any layer 3 network segment from the network. In order to delegate the layer 3 network segment to the customer site, we adopt IP version 6 technology with DHCP-PD (DHCP-Prefix Delegation). CTU obtains /48 IPv6 address space from the network via DHCP-PD. Also, the network segment in the customer site can request /52 IPv6 address space from CTU, so that customer site can has multiple layer 3 IPv6 network segments.

Figure 5-25. Operation of Address Allocation

5.4.2.4. IPv6 Transport FLET’S HIKARI Premium adopt IP version “6”, rather than IP version “4”, since the network must accommodate tens of millions subscribers. IP version 4 was fine for


177

legacy systems, that have few million subscribers, however we considered IP version 4 will not appropriate for the succeeding network. The network is built by IP routers and adopts a native IPv6 transport, so as to build a simple network configuration. However, with some technical restrictions, we partially use an IPv4 transport in the backbone area. The following six points are the reason why we adopt IPv6. (1) End-to-end IP Address Transparency For the application developer, they must come up with NAT environment, when we use IPv4. When the network provides clean end-to-end transparent IP packet transport service, the application can easily use the IP transport without any extra consideration. Especially, the peer-to-peer application service, e.g., VoIP (Voice over IP), is not easy, in general. Also, for the IP multicasting service, the transparent IP transmission has some technical and business benefits. Operation of IP multicasting with NAT is hard, by nature. Also, especially for professional video contents (e.g., movie or music), the contents provider want to identify the end-node, in order to charge to them against their participation to multicast service or unicast VoD Service. They need some method to identify end-node by some unique identifier. (2) Accommodating Always-on Customer Nodes Nowadays, large portion of end-nodes connect to the network with always-on fashion. For the always-on environment, it would be easier to allocate fixed IP address to each end-node, rather than to allocate IP address dynamically. This is because, anyway, the required number of IP address for always-on environment with dynamic IP address allocation would be same as the one of fixed IP address allocation. Yet, another reason why to adapt fixed IP address allocation would be insufficiency of PPPoE, i.e., pure and native IP packet transport is simpler, when we allocate fixed IP address to endnode. Here, precisely speaking, we do not allocate individual fixed IP address to each end-node so far, but we allocate IP address prefix to each customer network (/48). Using the fixed IP address prefix, the end-node generates it’s own IP address (e.g., using it’s MAC address). (3) Large IP Address Space When we accommodate 30 million subscribers, we need at least 25 bits of IP address space. In practical network, we need 27 or 28 bits IP address space, due to un-optimal network configuration associated with size of each network segment or future expansion and extinction. All of network operator knows that we can not use the IP address space with 100 %. The address allocation design and the usage ratio of allocated IP address is the trade-off between operational cost against address reallocation and address usage ratio. In the reality, it would be said 50 % of address usage, or even less when we go hierarchical routing policy. The number of subscribers will increase against the time. Even the number of subscriber lines is saturated; the number of accommodated end-nodes in the network will increase. This is because the customer network will accommodate new end-node, after it is connected to the access network. However, you don’t have to do prefix-delegation with enough address space will free address provisioning of each sub-line. From this point of view, the allocation of network prefix to the customer network with IPv6 is good technical solution. Yet, anther benefits of IPv6 is (a) easy to allocate multiple IP addresses to single physical interface, and (b) can allocate any size of network prefix.

178


We allocate /48 network prefix to the customer network. Therefore, the customer network can use 16bits space for further sub-netting. We concluded this is enough for all the customer network. The FLET’S HIKARI premium network uses initially /30 IP address space, then now uses /21 IPv6 address space, since December 2004. (4) IP Address Filtering using Fixed IP Network Prefix Allocation For each subscriber line, the network allocates unique and fixed IP network prefix (/48). In this sense, the IP network prefix works as locator of customer network. When the network receives an IP packet, that does not have corresponding IP network prefix to the customer network, the received IP packet is discarded. This means that the endnode in the customer network can not spoof the source IP address. This would be equivalent to the authentication of customer access, to achieve secure network access from the customer network to the other customer. (5) Less Operational Cost Since we can be allocated large address space from RIR (i.e., APNIC), the initial IP address allocation can be take into account the future network growth, so as to plan the long term IP address allocation strategy without IP address re-allocation. This means that we could minimize the overhead or effort of IP address block re-allocation, that is one of large operational effort. The IP address (block) re-allocation effort is getting so harder for the larger network size. Also, since the behavior of network and routing entry in the routers could be simpler, the easier network management could be achieved. This particular feature comes from the reason why the IPv6 technology can provide far larger address space to the provider. Also, since the available IP address space is larger, we can configure the network with hierarchical manner, which is familiar with telephone operators. Yet, another benefit via the adaption of IPv6 technology, associated with less operational cost, is due to the segmentation of network via layer 3 switches (i.e., routers). When we have large scale layer 2 network, e.g., large scale Ethernet switch (access) network, the access network must experiences frequent broadcasting in a large scale layer 2 network segment, when ARP cache in the switches or end-nodes are missed. By using the layer 3 switches (i.e., routers), the access network could result to reduce the amount of broadcasting messages sent in the access network. 5.4.2.5. Network Topology In order to make the network simple, all the link from edge router are 10 Gbps. This is from the view point of bit cost, i.e., 10Gbps link achieves the cheapest bit cost, and the easier hierarchical network topology capability. At the edge router, more than thousand subscriber links are accommodated, and are aggregated into single 10Gbps up-link (link pair). We have tried to make the network topology simple as possible. Therefore, the network topology is simple hierarchical, with fixed address prefix allocation to each network segment. The access network segment between edge router and CTU, where we may not be able to expect enough statistical multiplexing effect, has fair queuing function as so to provide quality of service for each subscriber line. We designed so that each customer line yields, at least 4Mbps of video stream receive. We concluded that simple fair queuing is least cost regarding the network operation and management with today’s


179

technology. There would be other alternatives, e.g., change/modify the accommodation point according to the traffic volume of each customer. 5.4.3. Some Key Technology Components 5.4.3.1. IP Multicast FLETS’s premium has turned on the IP multicast service from the beginning. When we have consider if we use IP multicasting around year of 2002 or 2003, IP multicasting with IPv6 has not stable enough nor professional quality. However, we concluded that the network needs the IP multicasting, so as to provide effective large volume of contents delivery. IPv6 multicast service is basically for enterprise customers, at this time. The customer access line, who joins the IP multicast service, is configured manually using MLDv2. In other words, the IP multicast packet is never transmit to the customer access line, who is not subscribe as IP multicast customer, in order to avoid unnecessary packet transmission in the access network. The geographical multicast region is managed by SSM scope, and the multicast channel is identified and managed by (S,G) pair, where S is source IP address and G is IP multicast group address. 5.4.3.2. Security Since we assume all the end-nodes are always-on connecting to the network, the CTU should have enough security function and the CTU should be maintained by the network provider, i.e., firewall pre-set. Also, FLET’S HIKARI premium service provides the security applications (only for Microsoft Windows client) to customer’s end-node, as the bundled license to the customer. 5.4.3.3. High Quality Video Telephone Service FLET’S HIKARI premium service provides a high quality video telephone software running with MS Windows XP using IPv6 transport. The quality of highest video stream is equivalent as standard TV, i.e., VGA resolution with 30 fps, with MPEG-4 coding. The required bandwidth is 4 Mbps. As for the session layer protocol SIP and RTP is used. 5.4.3.4. QoS (Quality of Service) QoS function is implemented at all the aggregation point (i.e., edge router), where the subscriber lines to the end customer sites. The QoS functions are Diff-Serv and fair queuing. One of important functions is QoS (Quality of Service and queuing capability) per service. In FLET’S HIKARI premium system, the CTU has QoS function (i.e., DSCP marking for diff-serve). Therefore, the core network just care about packet scheduling based on DSCP value. In the access network beyond the edge routers, the fair queuing is also applied to on the top.

180


Figure 5-26. QoS Control (FQ and PQ)

5.4.4. Home Network Accommodation via CTU We must assume that home network has both IPv4 and IPv6 with various network configurations. The most common case is where IPv4 private network is connected via IPv4 router. In this case, CTU works as the broadband router, with the functions of ISP/VPN tunneling, NAPT/NAT, SPI, Firewall, UPnP, DNS proxy and DHCP server (IPv4). As for the ISP/VPN tunneling, it is IPv4 in IPv6 tunneling. ISP/VPN tunneling is terminated at NTE. CTU can establish 5 tunnels concurrently at maximum in family-type service. The authentication of ISP/VPN tunneling is challenge and response with user ID and its password, forwarded to RADIUS server of ISP or VPN. Here, the target NTE (ISP/VPN) and the authentication info are provided via Web interface by the customer, in advance. We assume that, STB(Set Top Box) will be installed commonly in the home network under CTU. This STB can use both IPv6 and IPv4. Also, the system with this, CTU allow to have other multiple IPv6 communications on its firewall. As for multicasting, CTU works as MLD proxy and performs multicast packet snooping so as to avoid unnecessary multicast packet transmission.


Figure 5-27. Functions of CTU (1/2)

Figure 5-28. Functions of CTU (2/2)

181

182


CTU, that is corresponding to the gateway to the Internet from the customer network, runs SPI (Statefull Packet Inspection) and firewall functions. The configuration and firmware update of CTU are managed by on-line update server in this IPv6 network. Also, the security updates of virus-check application for PC are provided by on-line update server in this IPv6 network. HTTP-proxy has been implemented in CTU for IPv4 PCs to access those servers on IPv6.

References [1] A. Ogawa, K. Kobayashi, K. Sugiura, O. Nakamura, and J. Murai, “Design and Implementation of DV based video over RTP,” Proc. of Packet Video Workshop 2000, May 2000. [2] K. Kobayashi, A. Ogawa, S. Casner, and C. Bormann, “RTP Payload Format for DV (IEC 61834) Video,” RFC 3189, January 2002. [3] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” RFC 3550, July 2003. [4] J.C. Bolot and A. V. Garcia, “Control Mechanisms for Packet Audio in the Internet,” Proc. of IEEE INFOCOM, March 1996. [5] S. Floyd and V. Jacobson, “Link-sharing and Resource Management Models for Packet Networks,” IEEE/ACM Transactions on Networking, Vol.3, No.4, pp.365-386, August 1995. [6] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, and S. Jamin, “Resource ReSerVation Protocol (RSVP) . Version 1 Functional Specification,” RFC 2205, September 1997. [7] S. Floyd and K. Fall, “Promoting the Use of End-to-End Congestion Control in the Internet,” IEEE/ACM Transactions on Networking, Vol.7, No.4, pp.458-472, August 1999. [8] M. Handley, S. Floyd, J. Padhye, and J. Widmer, “TCP Friendly Rate Control (TFRC): Protocol Specification,” RFC 3448, January 2003. [9] J.C. Bolot, H. Cr´epin, and A. Vega-Garcia, “Analysis of Audio Packet Loss over Packet-Switched Networks,” Proc. of ACM NOSSDAV ’95, April 1995, New Hampshire,USA. [10] SoundWIRE Project, http://ccrma.stanford.edu/groups/soundwire/delay_p.html,As of Oct, 2005. [11] Chafe C. et al, “A Simplified Approach to High Quality Music and Sound over IP,” Proc. Workshop on Digital Audio Effects (DAFx-00), Verona, Italy, pp. 159.163, 2000. [12] Nathan Schuett, “The Effeects of Latency on Ensemble Performance,” CCRMA Department of Music, Stanford Univ, May, 2002. [13]Tokeaki Mochida, Keiji Harada, Mitsuru Maruyama, “The i-Visto XG: Uncompressed HDTV Multiple Transmission System,” IEICE Technical Report, NS2005-44, pp. 25.28, Jun, 2005. [14] SOI. WIDE Project School Of Internet Working Group. http://www.wide.ad.jp/project/wg/soi-j.html, as of 2006. [15] Research Institute for Digital media and Content. Keio University http://www.dmc.keio.ac.jp/studio/, as of 2006.


183

Chapter 6

Characteristics of Residential Broadband Traffic in Commercial ISP Backbone in Japan 6.1. Overview This paper reports the characteristics of the residential broadband traffic in the commercial ISP backbone network in Japan.We analyze two types of traffic traces: month-long aggregated traffic logs for different traffic groups from seven major ISPs which accounts for about 40 % of the total traffic in Japan, and week-long sampled Netflow logs from one ISP. Our main findings are as follows. (1) the aggregate residential broadband (RBB) customer traffic volume in our data set exceeds 150Gbps on average, as of Nov. 2005. The estimation of the total nationwide RBB customer traffic volume is 581Gbps, and the annual traffic growth rates are 100-120 %. (2) About70 % of the RBB customer traffic volume is constant all the time. The rest corresponds to the daily fluctuation pattern caused by human activity. (3) The peak hours of the RBB traffic volume are the prime time hours (21:00-23:00), completely different from the academic usage and the RBB customer usage before introducing flat-rate pricing. Moreover, the traffic during the daytime on weekends is much higher than that during weekdays. (4) The traffic pattern of the backbones is dominated by the RBB customer traffic patterns, so that the traffic patterns of traditional office users are obscured in the backbones. (5) International traffic volume accounts for 30 % of the total traffic volume of the external edges across the ISPs. The private-peering traffic is 1.5 times larger than the major IXes traffic. Thus, by using only the IXes data as reference, it would likely lead to an underestimation of the total traffic volume. (6) The traffic volume in a given prefecture is roughly proportional to the population of the prefecture. In addition, the probability of finding a heavy-hitter is constant and independent of the regional difference. (7) Top 4 % of customers account for 75 % of the total traffic volume, and send/receive more than 2.5 Gbytes per day. (8) 63 % of the total traffic volume involves domestic user-to-user communication, and most of the traffic volume is concentrated in the metropolitan areas. 6.2. Introduction The availability of residential broadband (RBB) access has been increasing in Japan over the past few years, as well as in other ICT-developed countries. Figure 6-1 (a) represents the growth of the number of broadband access subscribers (i.e., Digital Subscriber Line (DSL), CATV, Fiber to the Home (FTTH)) from a report released by the Ministry of Information and Telecommunication (MIC) in Japan [7]. We can confirm a rapid increase in the number of DSL subscribers in 2002-2004. However, from 2005-2006 the growth of DSL subscribers is saturated. Instead of DSL, the

184

Chapter 6. Characteristics of RBB Traffic in Commercial ISP Backbone in Japan

number of FTTH subscribers has drastically increased recently. Indeed, Japan by far leads other countries in FTTH penetration [4], and can be regarded as a model of the widespread deployment of symmetric residential broadband access. As of the beginning of 2006, the number of residential broadband subscribers reached 24 millions which correspond to about 40 % of households.

(a) (b) Figure 6-1. (a) Growth of number of residential broadband subscribers and (b) growth of aggregated peak rate at major Japanese IXes

As a result of the widespread deployment of the residential broadband access, the total traffic volume of commercial backbone networks rose rapidly. Figure 6-1 (b) indicates the growth of the aggregated peak traffic rate at the major Japanese IXes (JPIX[1], JPNAP[2], and NSPIXP[3]). As shown with the solid line, the traffic volume sharp bends at 2002, synchronized with the growth of DSL subscribers, and there is no indication of saturation through the observed period. It will likely approach 250Gbps by the end of 2006. Also, the dotted line shows the annual growth rate of the aggregated traffic volume. The growth rate peaks (400 %/year) around the middle of 2002; this period conforms to the “IT bubble” in Japan. Even for the past two years, the traffic volume still has stably grown at 140 %/year. Thus, these results point out that the total traffic demand from end-users has not yet been satisfied, though commercial ISPs have deployed more and more bandwidth in their backbones. Although we have already seen a drastic growth in backbone traffic volume, it is difficult to plan for the future because residential broadband traffic is undergoing a transformation; the evolution of lower-cost and higher-bandwidth access line technology and that of the emergence of new applications. Specifically, we do not fully understand the traffic characteristics in the nationwide backbone networks in Japan, although each ISP has its own internal traffic information. In such situations, it is essential for us to understand from various perspectives the effects of growing residential traffic. However, it is also a non-trivial task from both the technical and political aspects to obtain data from commercial ISPs. In particular, to disclose the internal traffic information to other ISPs is one of the most crucial problems for ISPs. In order to seek out a practical way to investigate the impact of residential broadband traffic on commercial backbone networks, we have formed a study group comprised of specialists including members from seven major commercial ISPs in Japan. Our goal is to better understand the macro-level impact of residential broadband traffic on ISP backbones. Thus, we are trying to obtain a clearer grasp of the ratio of residential broadband traffic to other traffic, the changes in traffic patterns, the behavior of the


185

heavy-hitters, and the regional differences across different ISPs as well as the dominant application types used by customers. Such statistics will provide reference points for further detailed measurements and analyses. In this report, we discuss the findings in our data sets from the viewpoint of the impact of residential broadband traffic on ISP backbones.

6.3. Data Set and Traffic Group There are several requirements in order to solicit ISPs to provide traffic information.We need to find a common data set that all the participating ISPs are able to provide. The data set should be coarse enough not to identify sensitive information about the ISP but be useful enough to reveal the macroscopic behavior of the residential broadband traffic. The data sets should be summable in order to aggregate them with those provided by other ISPs. We found that most ISPs collect interface counter values of almost all routers in their service networks via SNMP, and archive perinterface traffic logs using MRTG [6] or RRDtool [5]. Thus, it is possible for the ISPs to provide aggregate traffic information if they can classify the router interfaces into a common set.

Figure 6-2. Traffic groups

Our focus is on traffic group crossing ISP boundaries that can be roughly divided into customer links as well as external links like peering and via IXes. From the viewpoint of ISPs, we categorized the interfaces of the routers in ISPs into the following six traffic groups (Figure 6-2). (A) Traffic relating to customer edges (A1) Residential broadband (RBB) customer lines, including DSL, CATV, and FTTH.

186


(A2) Non-RBB customer lines, corresponding to customer lines other than RBB customers,such as leased lines, data centers, and dialup lines. These lines also mayinclude the RBB customers behind the leased lines (i.e., 2nd or 3rd level ISPs). (B) Traffic relating to external edges (B1) External 6 IXes, consisting of links for six major IXes (JPIX, JPNAP and NSPIXP in both Tokyo and Osaka). 4 Characterization of Residential Broadband Traffic in Commercial ISP backbones (B2) External domestic. This group includes the external links where both link-ends are within Japan, but except for 6 IXes (i.e., reginal IXes, private peering, and transit). (B3) External international. (C) Prefectural. RBB links divided into 47 prefectures in Japan. These links are served by two RBB carriers. In particular, our main interest is on (A1) RBB (residential broadband) customers, because we expect that the traffic usage of RBB customers largely affects the characteristics of the backbone traffic. The total customer traffic is (A) = (A1) + (A2). The (B1) external 6 IXes and (B2) external domestic are used to estimate the coverage of the collected data set. Additionally, the (B1) data set is comparable to the data directly taken from the 6 IXes in order to check the reliability of our data sets for estimating the growth rate. The (B2) set mainly includes private peering links, so that we can investigate the ratio of such a hidden traffic volume to the IXes traffic volume. The (B3) set is useful in estimating the ratio between the domestic and international traffic volumes. The total external traffic is (B) = (B1) + (B2) + (B3). The (C) prefecture links are for investigating the regional differences of the traffic usage. This group consists of only 2 major residential broadband carriers because of the service availability, i.e., the other carriers do not provide prefecture-based link aggregation. Group (C) is a subset of (A1). The resolution of the original month-long traffic logs is two hours due to the restriction of MRTG data format. We developed a perl script to read a list of MRTG and RRDtool log files per interface, and aggregate traffic for the 2-hour resolution. We provided the script to the ISPs so as to create aggregated traffic traces by themselves. This is an important issue for our collaboration because none of the ISPs would disclose their internal traffic data per interface. For the aggregation of the traffic volume based on the traffic groups, ISP operators also had to take into account the direction of a link as well as the classification of each router interfaces to the traffic groups. Finally, we summed up the directed aggregated traffic trace from each ISP to the total monthly aggregated traffic trace per traffic group. An aggregate trace consists of sets of 3 tuples (timestamp, inbound bytes, and outbound bytes). The direction (inbound and outbound) of traffic is defined by the view from the ISPs.We have been measured monthlong traffic traces six times over the past 21 months; September, October, and November in 2004, May, and November in 2005, and May in 2006. The traffic data were provided by seven major Japanese ISPs; IIJ, Japan Telecom, KOpticom, KDDI, NTT Communications, POWEREDCOM, and SOFTBANK BB. However, due to the complicated configuration of the network in ISPs, the (A2) non-


187

RBB customers and (C) prefectural data were provided from four participating ISPs. In the following analysis, we mainly use the traffic traces in Nov. 2005. Besides the aggregate traffic traces, we also obtained sampled NetFlow traces from one of the participating ISPs to quantify the behavior of the residential traffic in more detail. These week-long traffic traces, whose sampling rate was 1/2048, were captured at the links of residential broadband customers over DSL and fiber lines, February and July in 2005. By translating from the assigned IP addresses to the corresponding customer IDs, we can identify the inbound and outbound traffic volumes per customer with specific attributes such as line type (DSL or fiber) and the prefecture. Moreover, the raw data contains the TCP and UDP port numbers, so that we could investigate the dominant application types (protocol breakdown) used by customers. We analyzed the traffic traces in Jul. 2005.

6.4. Results of Traffic Analysis 6.4.1. Customer Edges We at first show the weekly behavior of RBB customers in Figure 6-3. Note again that the direction of traffic is from the ISP’s view; the inbound (in) traffic is from the customers to the ISPs (i.e., uploading in the customer view), and the outbound (out) traffic is from the ISPs to the customers (i.e., downloading in the customer view). For the weekly data, we took the average of the same weekdays in the month, except for national holidays. The points of interest are as follows. 1. The mean traffic volumes as of Nov. 2005 are 145 Gbps inbound, and 193 Gbps outbound. The peak traffic volume for a 2-hour resolution exceeded 250 Gbps. Moreover, the inbound and outbound traffic volumes are closely symmetric, taking into consideration the bandwidth ratio between the inbound and outbound traffic in ADSL.We believed the myth that the broadband customers usage is mainly for downloading a variety of contents, that is, the traffic demand from customers is asymmetric. However, our results clearly show that this does not hold for the current Internet. 2. The peak hours of traffic volume during a day were shifted to 21:00-23:00. Before the emergence of a residential broadband access line, the peak hours were 23:0025:00 because a carrier provided a flat rate service only during the midnight hours. These results suggest that the traffic demand of customers on Internet services were simply restricted by the cost issue, and nowadays the use of the Internet has become

Figure 6-3. Weekly residential broadband customer traffic (A1)

188


casually similar to watching TV during prime time, as a result of the diffusion of cheaper full-day flat-rate broadband access service. The larger traffic volume during the daytime on weekends than that for weekdays also supports this view. 3. Despite a diurnal variation in the traffic volume, 70 % (? 120 Gbps) of the traffic volume is constant at any time during the day or night, implying that the source of traffic is categorized into two patterns; human-activity dependent (e.g., webbrowsing and email) and human-activity independent (e.g., p2p file sharing). The former appears in the daily variation, and the later contributes to the constant part. Figure 6-4 indicates the weekly behavior of non-RBB customer traffic, consisting of leased lines, data centers, dial-up lines, and 2nd and 3rd level ISPs. Most of the traffic patterns of the non-RBB customers (i.e., the peak hours, symmetric volumes, and 70 % of constant volumes) 6 Characterization of Residential Broadband Traffic in Commercial ISP backbones resemble those of RBB customers, although the mean traffic volumes are different. Note that the number of participating ISPs are different in (A1) and (A2), that is, we cannot compare both of them, qualitatively. One clear difference between them is the high daytime activities for non-RBB customers; this is likely due to the business usage in data centers and on leased lines.

Figure 6-4. Weekly non-residential broadband customer traffic (A2)

6.4.2. External Edges We now focus on the external edges across ISPs. In order to characterize the domestic traffic behavior, Figure 6-5 represents the weekly domestic traffic behavior of the (B1) 6 major IXes and the (B2) other domestic lines, including the other IXes and private peerings. It is visually apparent that both domestic traffic behaviors are dominated by the traffic patterns of the RBB customers. On the other hand, the traffic behavior to/from international lines has completely different characteristics as shown in Figure 6-6. The inbound traffic (i.e., from other countries to domestic) is 1.4 times bigger than the outbound traffic, indicating a clear asymmetric usage. In addition to the asymmetric nature, we emphasize that the peak hours of the inbound and outbound traffic volumes are the same, and that the weekly inbound traffic patterns resemble those of the RBB customers. Basically, the daily patterns of both the inbound and outbound Characterization of Residential Broadband Traffic in Commercial ISP backbones 7 traffic are characterized by the RBB customers living in the Japanese standard time. Thus, most of the outbound traffic volume is likely traffic triggered from domestic ends (i.e., connection initiation). However, we can also see a constant traffic volume over 30 Gbps even in the outbound traffic. This


189

Figure 6-5. Weekly 6IX (B1) and domestic traffic (B2)

Figure 6-6. Weekly international traffic (B3)

Figure 6-7. Traffic breakdown of external edges

represents the existence of non-negligible downloading traffic from domestic ends to other countries. Figure 6-7 illustrates the traffic breakdown of the external edges. The domestic traffic volume (B1 + B2) accounts for about 70 % and, the share of the international traffic volume is about 30 %. In general, it is difficult to estimate the (B2) other

190


domestic traffic volume (especially, the private peering traffic) since the ISPs would not disclose their routing policies and internal data. Consequently, the ratio between (B1) and (B2) is useful in estimating the hidden traffic volume. In our data, the other domestic traffic volume is about 50 % bigger than that of the 6IXes. Thus, it has a risk of underestimation when calculating the nationwide traffic volume from only the IXes data due to such hidden traffic volumes. However, generally big ISPs like our participating ISPs tend to directly connect to each other by private peering to reduce the traffic via IXes, but small ISPs do not. Hence, our estimated ratio might be biased toward the higher value for applying to small ISPs. 6.4.3. Traffic Growth Here, we examine the growth rate of the mean traffic volume from the data collected over the past 21 months. Figure 6-8 depicts the growth of the mean traffic volume for each traffic groups. In the all groups, the traffic volumes increase 120-150 % per year. The estimations are roughly consistent with the annual growth rate (140 %) of the IXes’ peak rate directly measured by the IXes. In particular, the difference between the inbound and outbound volumes in the (A1) RBB customer traffic becomes larger for the last 12 months. This is likely because the ISPs have recently warned their customers not to use P2P software after information leaking incidents occurred through the P2P software, leading to a decrease in the uploading traffic from customers.

(a) customer edges

(b) external edges Figure 6-8. Traffic growth of five traffic groups for (a) customer edges and (b) external edges


191

However, further observation and analysis are needed to quantify this issue, as well as the estimation of the growth rate. In order to identify the growth pattern of traffic volume in detail, Figure 6-9 (a) displays the Characterization of Residential Broadband Traffic in Commercial ISP backbones 9 weekly inbound RBB customer traffic in Nov. 2004 and Nov. 2005. The traffic volume has increased 1.26 times over this period, nevertheless the daily traffic patterns closely resemble each other. In fact, in the normalized traffic volumes, which are subtracted by the mean value, there are very few difference between the two sets of data as shown in Figure 6-9(b). Furthermore, in a given time period, the traffic volume in 2004 is larger than the corresponding traffic volume in 2005. Thus, the growth of the traffic is only affected by the constant volume part, concluding that the contribution of human-activity dependent customers is much smaller than that of the human-activity independent ones.

(a) original

(b) normalized data. Figure 6-9. Comparison of weekly inbound RBB traffic in Nov. 2004 and Nov. 2005.

Moreover, we intend to estimate the nationwide traffic volume of RBB customers in Japan. For this, we have to determine the traffic share of the seven participating ISPs from all ISPs in Japan. Fortunately, this is fixed by comparing our (B1) 6IXes traffic volume measured from the ISP side to the total traffic volume directly measured at the six IXes. Figure 6-10 displays this relationship; each plot corresponds to the difference in measurement month. The plots follow a clear linear relationship whose slope is 0.43. Thus, our seven ISPs’ traffic volume accounts for 43 % of the total IXes traffic volume over the most recent 21 months. From this result, we estimated the mean nationwide RBB traffic volume in Japan as 384 Gbps (184 Gbps / 43 %), and the peak RBB traffic volume for a 2-hour resolution as 581Gbps (250 Gbps / 43 %) as of

192


Nov. 2005. This is the first estimation of the nationwide traffic volume based on a widespread observation. From another point of view, the linear relationship of the traffic volume suggests that there is very little bias concerning the growth of the traffic volume between ISPs.

Figure 6-10. Traffic share of participating ISPs in all ISPs in Japan

6.4.4. Light-users and Heavy-hitters In the following subsections, we investigate in detail the macroscopic behavior of residential broadband customers by using the sampled Netflow data. First, we focus on the traffic volume sending/receiving per user during the day. Figure 6-11 depicts the cumulative distribution of daily traffic per user in log-log scale from the sampled Netflow data. The plots exhibit a slower decay with a cutoff point around 2.5 Gbytes/day (230 kbps). This point corresponds to top 4 % customers. Thus, 96 % of the customers send/receive a traffic volume less than 2.5 Gbytes/day. This type of the cutoff point expects to represent a boundary between the different usage patterns of customers, therefore, we refer to the customers using more than 2.5 Gbytes as heavyhitters, and to the rest as light-users in this report. For light-users, the inbound traffic volume deviates from the outbound traffic volume around 10 Mbytes. The 50 % percentile of inbound traffic (10 Mbytes) is ten times smaller than that of the outbound

Figure 6-11. Cumulative distribution of daily traffic per user


193

traffic (100 Mbytes). Thus, this suggests that the traffic usage of light-users is asymmetric. For heavy-hitters, a few customers exchange more than 100 Gbytes per day, and we cannot confirm a clear asymmetric nature in this region. The mean traffic volume per user for our data sets was 430 Mbytes/day (40 kbps) for inbound and 446 Mbytes/day (41 kbps) for outbound. From the figure, we emphasize that it is a misinterpretation to discuss the traffic demand of customers from the mean traffic volume, because the distribution is slowly decayed; 90 % of customers send/receive less than the mean traffic volume. Figure 6-12 is another view of the previous figure, focusing on the relationship between the cumulative ratio of heavy-hitters and the cumulative ratio of the traffic volume. The plots indicate that the top 4 % of customers contribute 75 % (inbound) and 55 % (outbound) of the traffic volume; the top of 10 % customers account for 95 % and 85 %, respectively. Therefore, the impact of most customers on the backbone traffic is negligible. This is just a winner-takes all phenomenon.

Figure 6-12. Cumulative heavy-hitters v.s. cumulative traffic volume

To better understand in more detail the per user behavior, in Figure 6-13, we show the scatter plot of inbound and outbound traffic in a log-log scale. In this figure, each plot corresponds to each individual customer. A clear positive correlation exists here.

Figure 6-13. Scatter plot of daily traffic usage

194


For < 109 bytes of outbound traffic, the outbound traffic is ten times larger than the inbound traffic, i.e., this asymmetric nature shows that the usage of the downloading data from customers is dominant in this region. On the other hand, we can observe two regions in the higher outbound traffic ( > 109 bytes). One is the same tendency of the lower region (i.e., the downloading is ten times larger). The other is that the inbound and outbound traffic volumes are almost balanced. Namely, a certain ratio of the traffic demand from customers is potentially symmetric, consequently, more migration to the FTTH access lines will lead to more uploading traffic from customers to the backbones. 6.4.5. Application Types Here, we investigate some typical applications used by customers. Table 6-1 represents the protocol breakdown of the traffic volume for all customers in the sampled Netflow data. 12 Characterization of Residential Broadband Traffic in Commercial ISP backbones In our data, well-known port services, whose port number is less than 1024, only account for 14 %, although the TCP service accounts for 97.5 %. Namely, we do not have any clear evidence what the 79 % traffic volume is. In other words, currently, it is hard to estimate the application types of traffic flow from the TCP/UDP port number. We can confirm some of the port numbers used by P2P software in higher ports, but, these are “well-known” ports for the connection management used by such software. Thus, the data transfer of them is likely hidden within the 79 % traffic volume. This result also reminds us that dominant application types change in time; web service only accounts for 9 % now, although it was the dominant application of the Internet a few years ago. Furthermore, more deployment of RBB access lines will create a greater opportunity for the emergence of a new bandwidth consumption application that we have not yet considered. Table 6-1. Protocol breakdown

We also investigate the protocol breakdown for light-users and heavy-hitters. It turned out that the traffic volumes for TCP port numbers less than 1024 account for 30.7 % for lightusers, and 5.1 % for heavy-hitters. The percentages of the top 5 port


195

numbers for light-users are http (80: 24.7 %), winmx (6699: 1.8 %), ftp-data (20: 1.4 %), rtsp (554: 1.1 %), and gnutella (6346: 1.1 %). The application usage of lightusers has been closer to the traditional type, as expected; however, unidentified port numbers still have appeared in more than 50 % of the traffic volumes, and also the ratio of well-known port numbers used by P2P software has not drastically decreased. Thus, P2P software is still working on the certain ratio of “light”-user’s PCs. We determined the boundary between light-users and heavy-hitters by the distribution of traffic volume. Nevertheless, this result suggests the difficulty in splitting the customers into two clear groups. Probably, the users of P2P software are widely spread between lightusers and heavy-hitters, and the hours of use for P2P software might be a control parameter to determine the traffic volume over 5 orders of magnitudes. Conversely, it might be easy to migrate from light-users to heavy-hitters with the casual use of P2P software. 6.4.6. Regional Differences In the previous subsections, we analyzed the macroscopic traffic characteristics. Here, we Characterization of Residential Broadband Traffic in Commercial ISP backbones 13 examine the regional differences in traffic patterns. Using the SNMP data of traffic group (C), we depict weekly traffic behavior of both metropolitan and rural prefectures in Figure 6-14. For the metropolitan prefecture, the daily behavior during the weekdays is intrinsic, compared to the behavior of RBB customers. During the daytime, the outbound traffic volume is 1.5 times higher than the inbound traffic volume. Indeed, the 2nd-highest peak hours in a given day appeared between 11:00-13:00, and the volume is close to that for the peak hours. These hours are consistent with the usage patterns of the traditional business and academic usages. Namely, in the metropolitan prefecture, the traffic pattern is compound of two types of activities;

Figure 6-14. Weekly traffic behavior in metropolitan and rural prefectures

196


residential broadband customers and business customers (e.g., SOHO and small companies) using RBB access lines. On the other hand, in the rural prefecture, there is no such daytime activity, and the traffic behavior is close to the aggregated RBB customer’s behavior.

Figure 6-15. Cumulative distribution of daily traffic per user in (a) metropolitan and (b) rural areas

To discuss the regional differences in traffic patterns in more detail, Figure 6-15 (a) and (b) represent the cumulative distribution of the traffic volume per user for both the metropolitan and rural prefectures, respectively. These data are constructed from the sampled Netflow data, and a subset of the data of all the customers used by plotting Figure 6-11. In spite of the difference in the number of samples, there is no clear difference in the functional form between them, including the location of the cutoff points. Consequently, there is no difference in the component ratio of the light-users and heavy-hitters between the metropolitan and rural prefectures. Furthermore, we focused on what kind of relationship exists between the traffic volume to/from a prefecture and the population of the prefecture. This relationship is one of the metrics representing the level of nationwide deployment of broadband access lines. Figure 6-16 (a) represents the population of a prefecture and the corresponding mean traffic volume from the SNMP data. The plots are approximately linear, i.e., the traffic volume from/to the prefecture is proportional to the population. Thus, the mean

Figure 6-16. Traffic volume in prefecture-level; (a) population versus traffic volume and (b) cumulative distribution of traffic volume


197

traffic volume per user is constant and independent of the size of population, This fact indicates that the probability of existence of heavy-hitters is not affected by the location (metropolitan or rural areas). Accordingly, there is no clear regional difference in the deployment of the RBB access lines at the prefectural level. Similarly, we plot the cumulative distribution of the traffic volume in a prefecture. The plots conform to a slowly-decayed distribution, close to a power-law. The customers in most of prefectures account for only a small amount of traffic, nevertheless,those in only a few prefectures generate most of traffic volumes. This result represents a strong concentration of the traffic volume to a few prefectures. However, these characteristics come from the fact that the traffic volumes are proportional to the population as shown in sub-panel, indicating that the distribution of the population itself is slowly decaying. 6.4.7. Locality of Traffic Flow Finally, we intend to quantify the geographical effect of the traffic usage from the viewpoint of the traffic flow. For this purpose, we used the sampled Netflow data, and two geo-IP databases; Cyber Area Resarch Inc’s SUTFPOINT and Digital Envoy’s Netacuity. The former database maps the address blocks of the domestic residential customers to their perspective prefectures, but it does not cover the non-residential addresses such as data-centers and leased-lines. The addresses not covered by the former database are classified simply into either domestic or international by the latter database. Thus, although domestic mainly corresponds to the datacenters and leased lines in Japan, it also includes the residential address blocks not listed in the geo-IP databases. Table 6-2 is the traffic matrix of three traffic groups; residential broadband user (RBB), other domestic (DOM) and international (INTR) categorized by the two databases. The vertical and horizontal directions correspond to the source and destinations of the traffic volume, respectively. It turned out that the user-to-user traffic volumes (from RBB to RBB) accounted for 63 %, probably generated by P2P software. Another point to note is that 90 % of the traffic volume remained within the domestic area; this is plausibly due to closely connected P2P super nodes with high bandwidth, because P2P nodes tend to select other peers by their link bandwidth. Thus, most upload/download traffic are via these domestic nodes. Another reason might be the language and cultural barriers of Japan. However, from this data, we cannot confirm the asymmetric nature in the international traffic. Table 6-2. Traffic matrix: ALL (total), RBB (residential broadband), DOM (other domestic), and INTR (international)

Figure 6-17 indicates the traffic matrix of Japan’s 47 prefectures; this is the breakdown of the user-to-user traffic in Table 6-2. The vertical and horizontal axes correspond to the source and destination prefectures, respectively. Each value in the matrix is a traffic volume normalized by source prefectures. The paler values represent

198


the larger volumes and the darker ones weaker volume. It is visually apparent that the traffic volume tends to concentrate to the metropolitan areas such as Tokyo, Aichi, Osaka, and Fukuoka. Interestingly, we can confirm the visible correlation within the same prefecture with the diagonal white dots, although the neighboring prefectures have no correlation. These traffic volumes inside a prefecture might reflect the activity of information exchange/sharing within the local community.

Figure 6-17. Traffic matrix of 47 prefectures normalized by source prefecture

6.5. Conclusion We reported on the characteristics of residential broadband traffic in commercial ISP backbone networks in Japan, from large-scale observations over a 21-month period. We first characterized the traffic patterns of RBB customers. The total nationwide RBB customer traffic volume in Japan was estimated as 581Gbps as of Nov. 2005, and with an annual growth rate of 120-140 %. The weekly traffic patterns of RBB customers have completely changed from academic and traditional business traffic patterns; the inbound and outbound RBB customer traffic was almost symmetric, and their peak hours were shifted to 21:00-23:00. The behavior of the RBB customer traffic were broadly categorized into two types; human-activity dependent and independent. The former contributed to the daily fluctuation in traffic volume, although the latter accounted for 70 % of the constant RBB traffic volume. Then, we focused on the traffic behavior of the external edges across the ISP boundaries. The private-peering traffic was 150 % larger than the 6IXes traffic, consequently, it would be underestimation to estimate the nationwide traffic volume only from the observation of 6IXes. In addition, the International traffic accounted for 30 % in the total traffic volume. Similarly, from the per customer analysis, the traffic volume between the RBB customers and the international one accounted for 10 %. Thus, the most of the traffic was closed within a domestic area, possibly resulting from domestic P2P super nodes closely connected each other, as well as language and cultural barriers.


199

Concerning the regional differences, from the SNMP data the traffic volume in a prefecture was proportional to the population of it. Thus, the probability of finding a heavy-hitter is constant and independent of the prefectures. In fact, there was no clear difference in the distribution of traffic volume per user for metropolitan and rural areas from both the SNMP and sampled Netflow data. However, we also observed strong traffic localities; 63 % of the traffic volume is user-to-user in domestic areas from the sampled Netflow data. Within the user-to-user traffic, the destination of traffic was strongly concentrated on metropolitan areas. An important point of the per-customer behavior to mention was that the mean traffic volume is not appropriate as a performance metric, because the cumulative distribution of the traffic volume was highly skewed. Our result showed that the top 4 % of customers were involved in 75 % of the total traffic volume. For light-users, the traffic was asymmetric, so the downloading traffic is ten times larger than the uploading traffic. On the other hand, for heavy-hitters, we observed symmetric traffic volumes as well as asymmetric volumes. Thus, certain sorts of traffic demand of customers on the Internet service are symmetric, and this will be a potential and significant source of traffic growth even in the future. It is difficult to predict the future growth of the traffic volume. Traffic volumes could increase more and more because of the casual use of P2P software although the ISPs have warned customers not to use such software. Similarly, streaming services are one of the emerging bandwidth-consuming applications. On the other hand, some ISPs have intended to restrict the available bandwidth for heavyhitters. In the future, we will continue collecting aggregate traffic logs from participating ISPs in order to report the statistics as a reference. We are also planning to do per-customer traffic analysis from other ISPs.

References [1] Japan Internet Exchange Co., Ltd. http://www.jpix.co.jp. [2] Multifeed JPNAP service. http://www.jpnap.net. [3] NSPIXP. http://nspixp.wide.ad.jp. [4] OECD Broadband Statistics, December 2005. http://oecd.org/sti/ict/broadband. [5] T. Oetiker. RRDtool: Round Robin Database Tool. http://ee-staff.ethz.ch/-oetiker/webtools/rrdtool/. [6] T. Oetiker. MRTG: The multi router traffic grapher. In USENIX LISA, pages 141-147, Boston, MA, Dec.1998. [7] Growth of the number of residential broadband subscribers (in Japanese). http://www.soumu.go.jp/s-news/2006/06006 2.html, 2005.



201

Summary and Future Challenges The deployment of broadband Internet in Japan has been achieved, at least, from the view point of available bandwidth for the users (both for corporate and residential) and of the number of subscribers. After the challenge and success of deploying the broadband internet environment, Japan looks to face the following two critical issues for further evolution and revolution of ICT infrastructure. One is about adaption to the running out of IPv4 address pool and IPv6 introduction/deployment, and the other is the NGN (Next Generation Network) defined by ITU-T and by 3GPP/3GPP2. Of course, both issues are not only the issue for Japan, but are also for every country on the globe. However, since Japan has established one of richest broadband internet environment and having the aggressive R&D activities both on IPv6 and NGN, all other countries would be observing the actions and results in Japan. (1) Adaption to the Running out of IPv4 Address Pool and IPv6 Introduction/deployment It has been reported by some Japanese commercial providers that the average number of IP address allocated has been significantly increased according to the deployment of broadband Internet. With the dial-up era, a single IP address had been shared by about ten subscribers. On the contrary, with the broadband internet environment, single subscriber tends to use more than one IP address. This means that the number of IP addresses (or size of IP address pool), which each ISP must have, has increased more than ten times, and it has been still increasing. For example, the wide deployment of VoIP (Voice over IP) service would be one of general and ordinary application, which each subscriber wants to have the global IP address. Also, many peer-to-peer applications and interactive game want to use the global IP address. By the report by the Geoff Huston of APNIC, it is reported that IPv4 address pool at RIR will dry up around middle of 2011. Since we do not have enough time for this X-day, we have to develop and have to deploy the system, which can accommodate both IPv4 and IPv6, simultaneously, while avoiding the fatal operational problem due to the run out of IPv4 address pool. Many stake-holders, including Japanese government, has discussed the practical system solution and strategy. (2) NGN (Next Generation Network) It is said that NGN uses the IP (i.e., Internet Protocol defined by the IETF) technology as it’s core transport technology. As the middleware, it is said that the NGN uses the SIP (Session Initiation Protocol), which has been also “originally” defined by the IETF. However, regarding the SIP, 3GPP/3GPP2, ETSI/TISPAN and ITU-T have modified (and “improved”) the protocol and system architecture. Apparently, cellular phone providers would intend to introduce the IMS/SIP into their next 3G network and into their 4G network. Also, toward the FMC (Fixed Mobile Convergence) service, the wired network providers would be interested in the introduction of IMS/SIP into their next generation network. However, even when the protocol specification of IP is the same among the NGN and the “Internet”, the system architecture and operational policy would not be the same. Also, the local adjustment on technical specification in each country and by the provider may happen. At least, with regard to SIP with IPv4 for VoIP service, each VoIP provider defines their own protocol profile, leading to the

202

Summary and Future Challenges

in-interoperability among VoIP service provider network. We should avoid such a case with the introduction/deployment of NGN. It would be interesting and is critical point that NGN is deployed as (i) an AS network in the context of Internet, or as (ii) one of large cloud datalink network (such as ATM network), or as (iii) different network from the “Internet” internetworked via so called “gateway”. As described and discussed in this article, Japan looks to establish an unique community, regarding the Internet deployment activity. Academia, industry and government have maintained productive collaboration and discussion, toward the best practical network development deployment and innovation. The author believes that Japan will find out the best practical solution and it’s development and deployment, which will be a valuable contribution to the rest of globe.

Broadband Internet Deployment in Japan

Civil Society and the Internet in Japan (Routledge Contemporary Japan)

Broadband Internet: Access, Regulation and Policy

Japan and the Internet Revolution

Middleware Networks: Concept, Design and Deployment of Internet Infrastructure

Broadband communications

Broadband Bible

Middleware networks: concept, design, and deployment of Internet infrastructure

Broadband: Should We Regulate High-Speed Internet Access?

The Beginner's Guide to Broadband and Wireless Internet

Japan

An Anthropologist in Japan

Femtocells: Technologies and Deployment

Mastering Windows 7 Deployment

Mastering Hyper-V Deployment

Six Sigma Deployment

Japan

Japan

Shakespeare In Japan

Femtocells: Technologies and Deployment

Mastering Hyper-V Deployment

Japan

Japan

Japan

Conflict in Japan

Japan in Crisis

Nationalisms in Japan

Corporate governance in Japan

Japan (Asia in Focus)

Windows Vista Deployment

Mastering Hyper-V Deployment

Broadband Internet Deployment in Japan

Civil Society and the Internet in Japan (Routledge Contemporary Japan)

Broadband Internet: Access, Regulation and Policy

Japan and the Internet Revolution

Middleware Networks: Concept, Design and Deployment of Internet Infrastructure

Broadband communications

Broadband Bible

Middleware networks: concept, design, and deployment of Internet infrastructure

Broadband: Should We Regulate High-Speed Internet Access?

The Beginner's Guide to Broadband and Wireless Internet

Japan

An Anthropologist in Japan

Femtocells: Technologies and Deployment

Mastering Windows 7 Deployment

Mastering Hyper-V Deployment

Six Sigma Deployment

Japan

Japan

Shakespeare In Japan

Femtocells: Technologies and Deployment

Mastering Hyper-V Deployment

Japan

Japan

Japan

Conflict in Japan

Japan in Crisis

Nationalisms in Japan

Corporate governance in Japan

Japan (Asia in Focus)

Windows Vista Deployment

Mastering Hyper-V Deployment

Recommend Documents