INTERNET DRAFT Phillip D. Neumiller Category: Informational Peter Lei Title: draft-neumiller-obast-reqs-01.txt Qiaobing Xie Date: June 2000 Motorola, Inc. John Loughney Nokia, Inc. Randall Stewart Cisco Systems, Inc. Open Base Station Transport (OBAST) Requirements Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. This document is an individual contribution for consideration by the CRAPS BOF of the Internet Engineering Task Force. Comments should be submitted to the obast-list@cig.mot.com mailing list. Distribution of this memo is unlimited. Copyright (C) The Internet Society 1999. All Rights Reserved. Neumiller et al. expires December 2000 [Page 1]
INTERNET DRAFT June 2000 Abstract This document outlines the requirements for a set of open IP based protocols enabling seamless mobility across diverse radio access networks. This document begins by stating some architectural tenets upon which the requirements for the OBAST protocol set are based. Furthermore, what the authors currently believe to be the eventual desirable wireless Internet architecture is described. This architecture is shown to enable a common protocol set that we refer to as open base station transport (OBAST). Table of Contents 1.0 Introduction 1.1 Terminology 2.0 Review of Architectural Tenets 2.1 Simplicity 2.2 OBAST is Open and Universal 2.3 OBAST is Forward Looking 2.4 OBAST is a Protocol Set, However, It Implies Architectural Change 2.5 OBAST Promotes Seamless Mobility 2.6 OBAST Promotes Peer-to-Peer Protocols 2.7 OBAST Promotes IPv6 and MIPv6 Everywhere 2.8 OBAST Will not Re-invent or Invent AAA or QoS Mechanisms 2.9 OBAST Recognizes Other Important Standards 2.10 OBAST shall be Air Interface Agnostic 2.11 OBAST Shall Work Diligently on Micro-mobility 2.12 OBAST Shall Attempt To Remain Agnostic to Call Processing 2.13 OBAST Shall Make the Most out of SCTP 3.0 Baseline OBAST Implied Architecture 4.0 References 5.0 Acknowledgements 6.0 Authors' Addresses 7.0 Full Copyright Statement Neumiller et al. expires December 2000 [Page 2]
INTERNET DRAFT June 2000 1.0 Introduction This document lists requirements for a protocol set enabling access points and/or base stations, of different radio access network types, to communicate with each such that seamless handovers may occur between these radio nodes. We refer to this protocol set as: Open Base Station Transport (OBAST). There are fundamental architectural tenets that facilitate "seamless roaming". We shall review those first by speaking in terms of what OBAST is and isn't. 1.1 Terminology AP access point BTS base transceiver station CDG-IOS CDMA Development Group-Inter-Operability Standard CDMA Code Division Multiple Access GSM Global System for Mobile communications OBAST Open Base Station Transport IuPs Macro-mobility Inter-IP domain mobility MAP Mobile Application Part Micro-mobility intra-IP domain mobility PSTN Public Switched Telephone Network RAN Radio Access Network RNC Radio Network Controller SDU Selection Distribution Unit SS7 Signaling System 7 TIA Telecommunications Industry Association UMTS Universal Mobile Telephone System WLAN Wireless Local Area Network WPAN Wireless Personal Area Network 2 Review of Architectural Tenets 2.1 Simplicity There is a huge amount of commonality between the SS7 ISUP/IS-41 [1,2] and GSM MAP [9] signaling sets used for inter-system mobility in classical cellular deployments. There is also a large amount of functional overlap at the Telecommunications Industry Association (TIA) reference points above A-bis (the point of base station attachment to the rest of the network), where IuPs [3], GSM A-bis [4], and CDG-IOS (IS-634) [5] all play a role on UMTS, GSM systems, and CDMA systems respectively. There are several micro-mobility proposals including Cellular IP [6], hierarchical Mobile IP [7], EMA [8], HAWAII, and IAPP [10] (now an IEEE standard) for 802.11 access. Neumiller et al. expires December 2000 [Page 3]
INTERNET DRAFT June 2000 The inter-network protocols between deployed cellular systems will likely remain in place for a long time. However, by pushing all radio related behavior down into the BTS or AP, OBAST hopes to simplify the "top of the access point protocol" and eventually provide seamless roaming between wireless personal area networks (WPANs), wireless LANs (WLANs), and next generation cellular networks. 2.2 OBAST is Open and Universal The current situation in radio access networks is that they are closed and require complicated protocols to inter-network, if internetworking is possible at all. OBAST seeks to open up radio access networks to provide the same kind of internetworking that has been so successful in the wired world. The history of the Internet has proven that open protocols have a distinct technological advantage, because they are developed, reviewed, and implemented, by a broad group of network experts. A distinct economic advantage can be gained from openness, because open protocols tend to encourage competition around the quality of the implementation rather than around comparisons of feature sets that may or may not be of benefit to users. We believe these properties will hold for the wireless Internet as well. Historically, RANs have been tightly coupled to the core cellular network so that cellular equipment could not be easily replaced without extensive modification to the core network as well. The existing 3G standards are propagating this architectural tendency forward, but in a world where wireless options are multiplying, such closed non-inter-networking solutions become less and less viable. The OBAST architecture attempts to push "all" radio control and knowledge to the base stations so that a common and universal inter- access point or inter-BTS mobility protocol can be created. We believe that this protocol is only useful if it gains critical mass on the global Internet. We feel it can evolve with the global Internet in such a way as to someday abolish the need for core networks and radio specific standards. 2.3 OBAST is Forward Looking The momentum behind existing 3G standards may discourage deployment of any OBAST protocols in existing cellular networks. However, we believe greenfield 3G markets and WPAN deployments and WLAN investments could potentially benefit immediately from its adoption. It is our ambition to make OBAST a protocol set supporting the most advanced, scalable, and forward looking wireless Internet architecture. Neumiller et al. expires December 2000 [Page 4]
INTERNET DRAFT June 2000 2.4 OBAST is a Protocol Set, However, It Implies Architectural Change For OBAST to meet its goals, it requires a change in the way wireless networks have been classically designed. The primary architectural changes are (1) the BTS or AP becomes the one and only building block of the radio access network, (2) All radio control terminates at the BTS or AP and nothing radio specific creeps out above the BTS or AP. 2.5 OBAST Promotes Seamless Mobility Having a common protocol for micro-mobility and macro-mobility, AAA, and QoS, independent of access network type is OBAST's primary end goal. Facilitating the fixed to wireless network transition is also part of the ultimate end goal, but not a primary focus. OBAST will focus first on a protocol set, borrowed from other standards as much as possible and invent only where white spaces exist. 2.6 OBAST Promotes Peer-to-Peer Protocols Peer-to-peer protocols imply that no master or slave is assumed. OBAST will support the concept of elected call anchors that follow the mobiles as they move through "a sea of BTSs or access points". The call anchor has the responsibility of terminating the radio portion of the call. The call anchor is also responsible for orchestrating handover requests for the mobile. The call anchor is the point of selection and distribution when macro-diversity is required. 2.7 OBAST Promotes IPv6 and MIPv6 Everywhere OBAST could be made to run over IPv4. However, being a new protocol we wish to architect it to run over IPv6 primarily and this is what we will focus on. We will also promote the use of Mobile IPv6 [12] clients everywhere to enable enhanced macro-mobility. 2.8 OBAST Will not Re-invent or Invent AAA or QoS Mechanisms Every attempt to will be made to be agnostic to these protocols where possible. OBAST may eventually need to endorse or provide minimal AAA and QoS mechanism negotiation to facilitate seamless handovers. Much work is being done in this area, so OBAST will defer incorporating AAA or QoS mechanisms into its protocol set until after the seamless mobility issues have been resolved. 2.9 OBAST Recognizes Other Important Standards The pilc [13], Mobile IP [7, 12], cnrp [14], slp [15], zeroconf [16], aaa [17], manet [18], diffserv [19], intserv [20], rsvp [21], pint Neumiller et al. expires December 2000 [Page 5]
INTERNET DRAFT June 2000 [22], sip [23], rohc [24], IETF working groups all contain work useful to making OBAST happen. OBAST does/ will not replace/ dilute/ change efforts under way in 3GPP (www.3gpp.org), 3GPP2 (www.3gpp2.org), MWIF (www.mwif.org), or 3G.IP (www.3gip.org). 2.10 OBAST shall be Air Interface Agnostic OBAST will enable seamless roaming between WLANs (eg 802.11), WPANs (eg Bluetooth), and macro-cellular (eg EDGE [25], 3G-1X [26], etc). As such, OBAST must not favor any particular radio type over another. OBAST recognizes that there are going to be LOTS of competing radio technologies making their debut over the next few years and many portable devices will support multiple RF interfaces. 2.11 OBAST Shall Work Diligently on Micro-mobility OBAST supports the ideas behind IAPP (but not necessarily the implementation). OBAST is looking critically at CellularIP, HAWAII, EMA, and the work going on in the mobileip working group that will be speeding up mobileip hand-overs. OBAST will be flexible enough to support multiple negotiable micro-mobility schemes but may have to choose one as a minimum required protocol set to support "seamlessness". 2.12 OBAST Shall Attempt To Remain Agnostic to Call Processing Session initiation methods like SIP must be somewhat transparent to OBAST. It is not clear how this can be best done and this is considered a challenge. 2.13 OBAST Shall Make the Most out of SCTP OBAST will support the use of SCTP (sigtran) [11] for inter-radio node signaling and possibly for transport applications (yet to be determined). 3.0 Baseline OBAST Implied Architecture Using OBAST implies a new (at least to cellular and WLAN standards) view of the "Wireless Internet architecture". This architecture has two component types: routers (that make up the global Internet), and base stations / access points. In this view, the edge routers themselves could possibly have radio cards and be OBAST compliant. We feel that the scalability for routers has been proven on the global Internet. Radios, as edge devices, must respect this fundamental nature of the Internet architecture. The figure below shows the relationship between these simple components. (Global Internet) Neumiller et al. expires December 2000 [Page 6]
INTERNET DRAFT June 2000 | . . . | OBAST OBAST | | AP BTS <- OBAST enabled Radio Access Nodes The radio coverage, for the OBAST BTS (shown above), may engulf that of the AP, implying a vertical handover being required in this scenario. OBAST must facilitate vertical, horizontal, soft and hard handovers at the radio and at the servicing network layer when required or optimal. 4.0 References [1] "Cellular Radiotelecommunications Intersystem Operations: Intersys- tem Handoff Information Flows," IS-41D.2, TIA/EIA, December 1997. [2] "Cellular Radiotelecommunications Intersystem Operations: Sig- nalling Procedures," IS-41D.2, TIA/EIA, December 1997. [3] "Technical Specification 3rd Generation Partnership Project; Tech- nical Specification Group Radio Access Network; UTRAN Iu Interface: General Aspects and Principles". 3G TS 25.410 V3.1.0, January 2000. [4] "Base Station Controller - Base Transceiver Station (BSC-BTS) interface; Layer 3 specification", GSM 08.58, ETSI [5] CDG-IOS (IS-634) [6] A. Campbell et al., "Cellular IP", draft-ietf-mobileip-cellu- larip-00.txt. IETF Work in Progress, January 2000. [7] C. Perkins, Editor. "IP Mobility Support". RFC 2002, October 1996. [8] A. O'Neill, G. Tsirtsis, S. Corson, "Edge Mobility Architecture", draft-oneill-ema-01.txt, IETF Work in Progress, March 2000. [9] "Mobile Application Part (MAP) specification", GSM 09.02, ETSI [10] IEEE Pending Standard. [11] R. Stewart et al., "Simple Control Transmission Protocol". draft- ietf-sigtran-sctp-10.txt, IETF Work in Progress, June 2000. [12] David B. Johnson, C. Perkins, "Mobility Support in IPv6". draft- ietf-mobileip-ipv6-12.txt, IETF Work in Progress, April 2000. Neumiller et al. expires December 2000 [Page 7]
INTERNET DRAFT June 2000 [13] S. Dawkins, G. Montenegro, M. Kojo, V. Magret, "Performance Impli- cations of Link-Layer Characteristics: Slow Links". draft-ietf- pilc-slow-03.txt, IETF Work in Progress, March 10, 2000. [14] N. Popp, M. Mealling, L. Masinter, K. Sollins, "Context and Goals for Common Name Resolution", draft-ietf-cnrp-goals-01.txt, IETF Work in Progress, April 28, 2000. [15] E. Guttman, C. Perkins, J. Veizades, M. Day, "Service Location Pro- tocol, Version 2", RFC 2608, June 1999. [16] M. Hattig, "Zeroconf Requirements". draft-ietf-zeroconf- reqts-03.txt, IETF Work in Progress, March 2000. [17] Aboba et al., "Criteria for Evaluating AAA Protocols for Network Access". draft-ietf-aaa-na-reqts-05.txt, IETF Work in Progress, April 2000. [18] S. Corson, J. Macker, "Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations". RFC 2501, January 1999. [19] S. Blake et al., "An Architecture for Differentiated Services". RFC 2475, December 1998. [20] J. Wroclawski, "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997. [21] B. Braden et. al., "Resource Reservation Protocol (RSVP) - Version 1 Functional Specification", RFC 2205, September 1997. [22] S. Petrack, L. Conroy, "The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services". RFC 2848, June 2000. [23] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, "SIP: Ses- sion Initiation Protocol". RFC 2543, March 1999. [23] Mikael Degermark, "Requirements for robust IP/UDP/RTP header com- pression". draft-ietf-rohc-rtp-requirements-02.txt, IETF Work in Progress, June 2000. [25] "ETSI Technical Report: Digital cellular telecommunications system (Phase 2+); Enhanced Data Rates for GSM evolution (EDGE)". BSS GSM 10.59-1, January 1998. [26] "Introduction to cdma2000 Standards for Spread Spectrum Systems", IS-2000.1.A, EIA/TIA Neumiller et al. expires December 2000 [Page 8]
INTERNET DRAFT June 2000 5.0 Acknowledgements Special thanks to James Kempf of Sun Microsystems for much input on MWIF activities and contributions to the OBAST mail list. Special thanks to Pat Calhoun also of Sun Microsystems for editing and formatting this document and his countless contributions to the OBAST mail list. 6.0 Authors' Addresses Questions about this memo can be directed to: Phillip Neumiller Wireless Personal Area Networking Motorola, Inc. 1750 Golf Road 6th Floor - IL103 Schaumburg, IL 60173 USA Phone: +1 847-576-9624 E-Mail: Phillip.Neumiller@Motorola.com Randall R. Stewart Cisco Systems, Inc. 24 Burning Bush Trail Crystal Lake, IL 60012 USA Phone: +1 815-479-8536 E-Mail: rstewart@flashcom.net Qiaobing Xie, Ph.D Network Architecture & Technology Motorola, Inc. 1501 W. Shure Drive, Room 2309 Arlington Heights, Illinois 60004 USA Phone: +1 847-632-3028 Fax: +1 847-632-6733 E-mail: QXIE1@email.mot.com Peter Lei Network Architecture & Technology Motorola, Inc. 1501 West Shure Drive, #1301 Neumiller et al. expires December 2000 [Page 9]
INTERNET DRAFT June 2000 Arlington Heights, Illinois, 60004 USA Phone: +1 847-632-5654 E-mail: Peter.Lei@motorola.com John Loughney Nokia Research Center PO Box 407 FIN-00045 Nokia Group Finland Phone: +358 40 749 9122 E-mail: john.loughney@nokia.com 7.0 Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this docu- ment itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of develop- ing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The lim- ited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS- CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Neumiller et al. expires December 2000 [Page 10]