Mobile IP Working Group Yingchun Xu (editor) Internet Draft WaterCove Networks May, 2001 Rajesh Bhalla Ed Campbell Karl Freter 3Com Corporation Eileen McGrath Hadwen Alcatel Gopal Dommety Kirit Joshi Cisco Systems Parviz Yegani Ericson Wireless Communication Inc Takeo Matsumura FUJITSU Atsushi Teshima HITACHI Ltd. Lee Dong Hyun HYUNDAI Electronics Naoto Itoh IDO Corporation Kimihiro Ohki KDD Corporation Byung-Keun Lim LG Information & Communications,Ltd Peter J. McCann Thomas Towle Lucent Technologies Jay Jayapalan Motorola Inc. Peter W. Wenzel Carey B. Becker James Jiang Nortel Networks Shota Shikano Oki Electric Industry Co., Ltd. Woojune Kim Yong Chang Bill Semper Samsung Electronics Ltd. Jun Mo Koo SK Telecom Mark A. Lipford Frederic Leroudier Sprint PCS Jim Gately USWest Advanced Technologies Mobile IP Based Micro Mobility Management Protocol in The Third Generation Wireless Network Xu et al. Expires Nov. 2001 1 May 2001 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 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 obsolete by other documents at anytime. 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. Abstract This document defines extensions to the Mobile IP protocol [1] to allow mobility management for the interface between a radio network and a packet data network in the third generation cdma2000 network. Mobile IP requires link layer connectivity between the Mobile Node and the Foreign Agent. This draft proposes a protocol for achieving this when the physical layer terminates at a point distant from the FA. In particular, this protocol applies to cdma2000 networks where the physical layer terminates at a Radio Network Node (RNN) and the FA resides inside a separate Packet Data Serving Node (PDSN). The PDSN is responsible for establishing, maintaining, and terminating the link layer to the Mobile Node. A RNN is responsible for relaying the link layer protocol between a Mobile Node and its corresponding PDSN. The interface between the RNN and the PDSN is called the RP interface. This interface requires mobility management for handling handoff from one RNN to another without interrupting end to end communication. It also requires the support of the link layer protocol encapsulation. 1. Introduction This document defines extensions to the Mobile IP protocol [1] to allow mobility management for the interface between a radio network and a packet data network in the third generation cdma2000 network. Mobile IP requires link layer connectivity between the Mobile Node and the Foreign Agent. This draft proposes a protocol for achieving Xu et al. Expires Nov. 2001 2 May 2001 this when the physical layer terminates at a point distant from the FA. In particular, this protocol applies to cdma2000 networks where the physical layer terminates at a Radio Network Node (RNN) and the FA resides inside a separate Packet Data Serving Node (PDSN). The PDSN is responsible for establishing, maintaining, and terminating the link layer to the Mobile Node. A RNN is responsible for relaying the link layer protocol between a Mobile Node and its corresponding PDSN. The interface between the RNN and the PDSN is called the RP interface. This interface requires mobility management for handling handoff from one RNN to another without interrupting end to end communication. It also requires the support of the link layer protocol encapsulation. The messages used for mobility management across the RP interface include Registration Request, Registration Reply, Registration Update and Registration Acknowledge. Both Registration Request and Registration Update messages MUST be sent with UDP using well-known port number 699. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119]. 2. Glossary CDMA Code Division Multiple Access FA Foreign Agent HA Home Agent MN Mobile Node PDSN Packet Data Serving Node RNN Radio Network Node RP Interface between the RNN and the PDSN 3. cdma2000 Network RP Interface Overview The high level architecture of a third generation cdma2000 network RP interface is shown in Figure 1. +---------+ +---------+ +---------+ | | | | | | | RNN |----RP------| PDSN |---------| HA | | | Interface | | | | +---------+ +---------+ +---------+ /|\ | Visited Access Home Network | Provider Network | | \|/ +--------+ Xu et al. Expires Nov. 2001 3 May 2001 | Mobile | | Node | +--------+ Figure 1: The Third Generation cdma2000 Network RP Interface In above figure 1, the PDSN will be responsible for establishing, maintaining, and terminating the link layer to the Mobile Node. It initiates the authentication, authorization, and accounting for the Mobile Node and optionally, securely tunnels to the Home Agent. The RNN is responsible for mapping the Mobile Node identifier reference to a unique link layer identifier used to communicate with the PDSN. RNN validates the Mobile Station for access service and manages the physical layer connection to the Mobile Node. 4. Mobile IP Extensions This section describes extensions to the Mobile IP protocol for the RP interface within the third generation cdma2000 network. 4.1 Registration Request In a cdma2000 network, the mobile node initiates a connection by sending a call setup indication to the RNN across the radio network. When this indication is received by a RNN, a Registration Request will be sent from the RNN to the PDSN to setup a new RP session. A RNN MUST send a Registration Request with the GRE encapsulation and the reverse tunneling bit set. The Home Address field is set to zero. The Home Agent field will be assigned to the IP address of the PDSN and the Care-of Address field will be assigned to the IP address of RNN. When a Registration Request is received by a PDSN, the information from the Session Specific Extension (see next section) will be used to identify a RP session. When a registration is accepted, a GRE tunnel will be created for this Mobile Node. The message is sent with UDP using well-known port number 699. The fields of the Registration Request message are shown below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |S|B|D|M|G|V|T| | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Xu et al. Expires Nov. 2001 4 May 2001 | Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... +-+-+-+-+-+-+-+- Type 1 (Registration Request) G This bit MUST be set to 1 for GRE tunneling. T This bit MUST be set to 1 for reverse tunneling. Home Address The field is set to zero. Home Agent This field is assigned to the IP address of the PDSN. Care-of Address This field is assigned to the IP address of RNN. Extensions The Session Specific Extension as described in the next section MUST be included along with the ones described in RFC2002. Specifically, the MN-HA Authentication extension as described in RFC2002 MUST be included along with this extension. 4.2 Session Specific Extension This extension is defined to carry information related to the session between a Mobile Node and its serving PDSN. The detailed format of the extension is shown as follows. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | MN Connection ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Xu et al. Expires Nov. 2001 5 May 2001 | MN ID Type | MN ID Length | MN ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN ID ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 39 (not-skippable). Length This is a one octet field and it indicates the length (in bytes) of the extension, NOT including the Type and Length fields. Protocol Type This is a two octet field. It indicates the type of the protocol to be tunneled across the RP interface. It is same as the Protocol Type field in the GRE header. Key This is a four octet value assigned by the RNN and inserted in every GRE frame across the RP interface during user data tunneling. Reserved This is a two octet field. It is not used and is set to zero. MN Connection ID This is a two octet field and it is used to differentiate the multiple sessions from the same Mobile Node. It is locally unique to a Mobile Node. MN ID Type This is a two octet field and it indicates the type of the following Mobile Node ID value. Type value 1 will be reserved for International Mobile Station Identity (IMSI) encoded in ASCII format. For detailed description of the IMSI, see reference [8]. MN ID Length This is a one octet field and it indicates the length (in bytes) of the following Mobile Node ID field. For IMSI MN ID encoded in ASCII format, the length field value ranges from 10 to 15 bytes. MN ID This is the Mobile Node ID, which is globally unique. It is used to uniquely identify a Mobile Node. Xu et al. Expires Nov. 2001 6 May 2001 For Type 1 MN ID, the most significant digit of IMSI will be coded in ASCII and stored as the most significant byte of the MN ID. This extension MUST be included in the Registration Request, Registration Reply, Registration Update and Registration Acknowledge (see section 4.5) messages. It will be included before the MN-HA Authentication extension in the Registration Request and Registration Reply messages and before the Registration Update Authentication Extension in the Registration Update and Registration Acknowledge messages. The MN ID and the MN Connection ID together will uniquely identify a Mobile Session. 4.3 Registration Reply The Registration Reply will be sent by a PDSN following the procedure as described in [1]. The Home Address field will be the same value as the Home Address field from the corresponding Registration Request message received by the PDSN. The message is sent with UDP to the source port of the received Registration Request message. 4.4 Registration Update/Acknowledge Two new messages are defined to support PDSN initiated RP tunnel tear down and to speed up resource reclamation on the RNN. The Registration Update message is used for notification of the change of the registration associated with a call. It shall be sent by the PDSN to the previous RNN when a RNN to RNN handoff happens. The Registration Update message is sent with UDP using well-known port number 699. And the Registration Acknowledge message is sent with UDP to the source port from the received correspondent Registration Update message. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + Xu et al. Expires Nov. 2001 7 May 2001 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... +-+-+-+-+-+-+-+- The format of the Registration Update message is illustrated above, and contains the following fields: Type 20 Reserved Sent as 0; ignored on reception. Home Address Sent as 0; Home Agent Address The IP Address of the PDSN. Identification A 64-bit number assigned by the node sending the Registration Update message. It is used to assist in matching requests with replies, and in protecting against replay attacks. Extensions Both Registration Update Authentication Extension (see section 4.6) and Session Specific Extension (see section 4.2) SHALL be included. A Registration Update shall be sent by a PDSN to indicate the closure of a RP session. The RNN may reclaim the resource associated with that session. A Registration Acknowledge message is used to acknowledge receipt of a Registration Update message. It MUST be sent by a node receiving a Registration Update message. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Status | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Care Of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... +-+-+-+-+-+-+-+- Xu et al. Expires Nov. 2001 8 May 2001 The format of the Registration Acknowledge message is illustrated above, and contains the following fields: Type 21 Status If the Status is nonzero, this acknowledgment is negative. Reserved Sent as 0; ignored on reception. Home Address Copied from the Registration Update message being acknowledged. Care of Address The IP address of the RNN. Identification Copied from the Registration Update message being acknowledged. Extensions Both Registration Update Authentication Extension (see section 4.6) and Session Specific Extension (see section 4.2) SHALL be included. Allowable values for the Status include: 0 successful acknowledgement 128 reason unspecified 129 administratively prohibited 131 sending node failed authentication 133 identification mismatch 134 poorly formed Registration Update 4.5 Registration Update Authentication Extension The Registration Update Authentication extension is used to authenticate the Registration Update and Registration Acknowledge messages. It has the same format and default algorithm support requirements as the authentication extension defined for Mobile IP protocol [1], but with a different type (40). The authenticator value is computed from the stream of bytes including the shared secret, the UDP payload all prior extensions in their entirety, and the type and length of this extension, but not including the authenticator field itself nor the UDP header. The secret used for computing the authenticator field is shared between the RN and PDSN. This extension is required in both Registration Update and Registration Acknowledge messages. Xu et al. Expires Nov. 2001 9 May 2001 4.6 Summary The extensions to Mobile IP include enabling the GRE encapsulation and reverse tunneling during Registration. A new extension called Session Specific Extension is defined and is mandatory in the Registration Request, Registration Reply, Registration Update and Registration Acknowledge messages. The Home Address field MUST be set to zero in the Registration Request, Registration Reply, Registration Update and Registration Acknowledge messages. Two new messages (Registration Update and Registration Acknowledge) are defined to support the RP session disconnection in order to speed up resource reclamation. 5.0 GRE Encapsulation GRE encapsulation as described in [3] shall be supported during user data transmission. A new protocol type might be required to support the link layer protocol defined for the third generation cdma2000 network. The Key field shall be required and its value shall be same as the one from the Session Specific Extension as described above. The sequence number may be required, depending on the requirement of the protocol encapsulated within the GRE frame. During traffic tunneling, the sender will insert the Key value from the Registration Request message into the Key field of the GRE header. The receiver will use the Key value from the GRE header to decide where to forward the user data. 6.0 IANA Considerations The recommended message type value and extension type value have been used in 3GPP2 standard IOSv4.1. It is desirable to have the same type value assigned by IANA. The well-known UDP port number 699 used for the Registration Request and Registration Update Message was chosen from the unassigned port range. They were requested from and have been assigned by IANA and are listed at: ftp://ftp.isi.edu/in-notes/iana/assignments/port- numbers. The Registration Update and Registration Acknowledge messages defined in section 4.4 SHOULD be assigned the Type values of 20 and 21 respectively. The Session Specific Extension defined in section 4.2 SHOULD be assigned the Type value of 39, and the Registration Update Authentication Extension defined in section 4.5 SHOULD be assigned a value of 40. The Status values defined in section 4.4 are the error codes defined in RFC 2002 [1]. They correspond to the error values conventionally associated with a rejection by a home agent (i.e., Xu et al. Expires Nov. 2001 10 May 2001 the values from the range 128-255). The IANA SHOULD record the Status values as defined in section 4.4 of this document. With these assignments, the Type values assigned to the two new messages and to two new extensions, and the error values for the Status field, have been identified as not conflicting with any numbers defined for Mobile IP to date and documented at http://www.isi.edu/in-notes/iana/assignments/mobileip-numbers. 7.0 Security Considerations The protocol presented in this draft is designed for use over a protected, private network between RNN and PDSN. Pre-arranged security associations in the style of Mobile IPv4 are assumed to exist among every (RNN, PDSN) pair that will form an RP connection. Also, it is assumed that the session specific information is authenticated by means outside the scope of this draft. Several potential vulnerabilities exist if these assumptions are not met. First, if the network connecting the RNN and PDSN is accessible to an attacker, user traffic may be intercepted and/or spoofed if there are no other end-to-end security mechanisms in place. Second, the Mobile IP control messages must be authenticated, to prevent tunnel setup and tear down by unauthorized parties. Mobile IP Authentication Extensions are used to provide this additional protection for control messages. Finally, if session specific information is not authenticated, a denial-of-service attack is possible if a RNN unknowingly sends a registration request to the PDSN with a spoofed session specific extension. The PDSN would then send an explicit tunnel tear down to the previous RNN, causing user traffic to be misdirected to the new RNN. This would cause a loss of service and possibly interception of traffic, depending on what other security measures are in place. 8.0 Acknowledgments The authors of this draft would like to thank Charles E. Perkins and David B. Johnson for the ideas presented in the Route Optimization draft [7]. References [1] C. Perkins, Editor, "IP Mobility Support", RFC 2002, October 1996. [2] G. Montenegro, "Reverse Tunneling for Mobile IP", RFC2344, May 1998. Xu et al. Expires Nov. 2001 11 May 2001 [3] G. Montenegro and V. Gupta. "Sun's SKIP Firewall Traversal for Mobile IP". RFC 2356, June 1998. [4] Pat R. Calhoun and Charles E. Perkins. "Mobile IP Network Address Identifier Extension". RFC2794, March 2000. [5] Charles E. Perkins and Pat R. Calhoun. "Mobile IP Challenge/ Response Extensions". draft-ietf-mobileip-challenge-06.txt, October 1999. (work in progress). [6] Charles E. Perkins and David B. Johnson. "Route Optimization in Mobile IP". draft-ietf-mobileip-optim-08.txt, February 1999. (work in progress). [7] TIA/EIA/IS-95-B [8] J. Reynolds and J. Postel. "ASSIGNED NUMBERS". RFC1700, October 1994. [9] Farinacci, D., Li, T., Hanks, S., Meyer, D. and Traina, P., "Generic Routing Encapsulation (GRE)," RFC 2784, March 2000. [10] Gopal Dommety. "Key and Sequence Number Extensions to GRE". RFC2890, September 2000. Author's Addresses Yingchun Xu WaterCove Networks 285 Billerica Road Chelmsford, MA, USA 01824 Phone: (847) 477-9280 Email: yxu@watercove.com Rajesh Bhalla 3Com Corporation 1800 West Central Road Mount Prospect, USA 60056 Phone: (847) 797-2618 Email: rajesh_bhalla@3com.com Karl Freter 3Com Corporation 1800 W. Central Road Mount Prospect, IL 60056 Phone: (847) 222-2268 Email: karl_freter@3com.com Xu et al. Expires Nov. 2001 12 May 2001 Ed Campbell 3Com Corporation 1800 W. Central Road Mount Prospect, IL 60056 Phone:(847) 342-6769 Email: ed_campbell@3com.com Eileen McGrath Hadwen Alcatel PO Box 4442, Boulder CO 80306 Phone: 303 499 1496 Email: mcgrath.hadwen@worldnet.att.net Gopal Dommety Cisco Systems 170 West Tasman Drive San Jose, CA 95134 Phone: (408) 525-1404 Email: gdommety@cisco.com Kirit Joshi Cisco Systems 170 West Tasman Drive San Jose, CA 95134 Phone: (408) 525 7367 Email: kjoshi@cisco.com Parviz Yegani Ericson Wireless Communication Inc. 6455 Lusk Blvd. San Diego, CA 92121 Phone: (858) 332-6017 Email: p.yeqani@ericsson.com Takeo Matsumura FUJITSU Kamiodanaka Nakahara-ku, Kawasaki-City Phone: +81-44-740-8109 Email: matumura@mcs.ts.fujitsu.co.jp Atsushi Teshima HITACHI Ltd. 216 Totsuka-cho, Totsuka-ku, Yokohama Japan 244-8567 Phone:+81-45-865-7003 Email: atsushi_teshima@cm.tcd.hitachi.co.jp Lee Dong Hyun HYUNDAI Electronics Industry KOREA Kyungkido Icheonsi 435-050 Phone: 82-336-630-2756 Email: jihs@hei.co.kr Xu et al. Expires Nov. 2001 13 May 2001 Naoto Itoh IDO Corporation Gobancho YS building 12-3 Gobancho, Chiyoda-ku, Tokyo Japan 102-8361 Phone: +81-3-3263-9660 Email: nao-itoh@ido.co.jp Kimihiro Ohki KDD Corporation 3-2, Nishi-Shinjuku 2-chome, Shinjuku-ku, Tokyo 163-8003, Japan Phone: +81-3-3347-5477 Email: ki-ohki@kdd.co.jp Byung-Keun Lim, LG Information & Communications, Ltd. 533, Hogye-dong, Dongan-ku, Anyang-shi, Kyungki-do,431-080, Korea Phone: +82-343-450-7199 Email: bklim@lgic.co.kr Peter J. McCann Lucent Technologies Rm 2Z-305 263 Shuman Blvd Naperville, IL 60566 Phone: (630) 713 9359 EMail: mccap@lucent.com Thomas Towle Lucent Technologies Rm. 2D-225 263 Shuman Blvd Naperville, IL 60566 Phone: 630-979-7303 Email: ttowle@lucent.com Jay Jayapalan Motorola Inc. 1501 W Shure Drive Arlington Heights,IL 60004 Phone: (847) 642-4031 Email: jayapal@cig.mot.com Peter W. Wenzel Nortel Networks 2201 Lakeside Blvd. Richardson, TX 75082, USA Phone: (972) 684-7134 Email: wenzel@nortelnetworks.com Carey B. Becker Xu et al. Expires Nov. 2001 14 May 2001 Nortel Networks 2201 Lakeside Blvd. Richardson, TX 75082, USA Phone: (972) 685-0560 Email: becker@nortelnetworks.com James Jiang Nortel Networks 2201 Lakeside Blvd. Richardson, TX 75082, USA Phone: (972)684-5885 Email: jjiang@nortelnetworks.com Shota Shikano Oki Electric Industry Co., Ltd. Phone:+81-3-3454-2111 Email: shikano471@oki.co.jp Woojune Kim Samsung Electronics Ltd. 11th Fl, Samsung Plaza Bldg, 263, Seohyeon-dong, Pundang-gu, Sungnam-shi, Kyunggi-do, 463-050 Pundang P.O. Box 32, Korea Phone: +82-342-779-8526 Email: keg@telecom.samsung.co.kr Yong Chang Samsung Electronics Ltd. 11th Fl, Samsung Plaza Bldg, 263, Seohyeon-dong, Pundang-gu, Sungnam-shi, Kyunggi-do, 463-050 Pundang P.O. Box 32, Korea Phone: +82-342-779-6822 Email : yong@telecom.samsung.co.kr Bill Semper Samsung Telecommunications 1130 Arapaho Rd Richardson, TX 75082 Phone: 972-761-7996 Email: bsemper@telecom.samsung.com Jun Mo Koo SK Telecom Phone: 650-568-5762 Email: jmkoo@sktelecom.com Mark A. Lipford Sprint PCS 8001 College Blvd. Suite 210 KSOPKZ0101 Overland Park, KS 66210 Xu et al. Expires Nov. 2001 15 May 2001 Phone: 913-664-8335 Email: Mlipfo01@sprintspectrum.com Frederic Leroudier Sprint PCS 8001 College Blvd. Suite 210 KSOPKZ0101 Overland Park, KS 66210 Phone: 913-664-8350 Email: FLerou01@sprintspectrum.com Jim Gately USWest Advanced Technologies 4001 Discovery Drive Boulder, CO 80303 Phone: 303-541-6415 Email: jgately@uswest.com Xu et al. Expires Nov. 2001 16