One document matched: draft-neumiller-obast-reqs-01.txt
Differences from draft-neumiller-obast-reqs-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 07:17:29 |