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:

   The list of Internet-Draft Shadow Directories can be accessed at:

   This document is an individual contribution for consideration by the
   CRAPS BOF of the Internet Engineering Task Force.  Comments should be
   submitted to the 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


   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
            Inter-IP domain mobility
   MAP      Mobile Application Part
            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

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

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

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 (, 3GPP2
   (, MWIF (, or 3G.IP (

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

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

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

       Phone: +1 847-576-9624

      Randall R. Stewart
      Cisco Systems, Inc.
      24 Burning Bush Trail
      Crystal Lake, IL 60012

       Phone:  +1 815-479-8536

      Qiaobing Xie, Ph.D
      Network Architecture & Technology
      Motorola, Inc.
      1501 W. Shure Drive, Room 2309
      Arlington Heights, Illinois 60004

       Phone:  +1 847-632-3028
         Fax:  +1 847-632-6733

      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

       Phone:  +1 847-632-5654

      John Loughney
      Nokia Research Center
      PO Box 407
      FIN-00045 Nokia Group

       Phone:  +358 40 749 9122

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

Neumiller et al.          expires December 2000                [Page 10]