Mobile Ad hoc Networks (MANET) Working Group John Z. Wang Almon Tang Internet Draft Motorola, Inc. Document: draft-wang-manet-umip-routing-00.txt July 2000 Category: Internet Draft Universal Mobile IP (UMIP) Intelligent Routing Status of this Memo This document is a submission to the Mobile Ad hoc Networks (MANET) Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the MOBILE- IP@STANDARDS.NOTELNETWORKS.COM mailing list. Distribution of this memo is unlimited. 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. 1. Abstract Global roaming is one of the design objectives for next generation 3G) cellular networks. To efficiently support real-time services for mobile users in these networks, delays in signaling and bearer traffic must be minimal. It is recognized that one of the sources causing long delays is triangle routing. Universal Mobile IP (UMIP) is proposed to minimize triangle routing in both signaling and bearer traffic. Further, UMIP is designed to enable mobile registration as well as bearer setup to be handled as close to mobile's current location as possible. When the mobile node registers with its home network from a foreign network, a location chain, consisting of a subset of the UMIP location registers, is established between the two networks. The information needed for the mobile node to access the network such as user profile, security data and billing information, may be distributed to these location registers from its home network. When Wang, Tang Internet Draft - Expires January, 2001 1 draft-wang-manet-umip-routing-00.txt July 2000 the mobile node roams into a different visiting network or returns to its home network, the nearby location registration nodes would process the registration and update mobile's location chain accordingly. When a call request is generated to set up a bearer connection with a mobile node, the unique identification of the mobile node (e.g., NAI, SIP-URL) is used to search for its present location. If the mobile node is a UMIP subscriber, the search will follow its location chain that was established during its registration. After the location of the mobile node is identified, a bearer path can then be set up between the calling parties. When the mobile roams into a different network, the nearby location registration nodes will process the handoff for the mobile when necessary and update the location chain accordingly. Procedures used by UMIP for registration and location management were documented in [1]. In this draft, the discussion will be focused on the processes used for bearer path setup and for handoff between networks. Routing examples using IPv6 are also provided. UMIP is backward compatible with Mobile IP RFC2002 [2] and its update [3]. The Regional Tunnel Management with a hierarchical Foreign Agent architecture [4] and route optimization [5] is a special case of UMIP. 2. Terminology 3Gpp Third generation partnership project for Wideband CDMA systems 3Gpp2 Third generation partnership project for CDMA 2000 systems Bluetooth Bluetooth is the codename for a technology specification for small form factor, low-cost, short range radio links between mobile PCs, mobile phones and other portable devices. The Bluetooth Special Interest Group is an industry group consisting of leaders in the telecommunications and computing industries that are driving development of the technology and bringing it to market. BRAN Broadband Radio Access Network BTS Base Transceiver Station CN Core IP-based Network CSCF Call Session Control Function Current ID The ID (NAI) of an LR to which the mobile node has successfully registered DECT Digital European Cordless Telephone DNS Domain Name Server FA Foreign Agent Foreign Domain The coverage area that is outside the Home Domain from which the mobile node subscribes network services Wang, Tang Internet Draft - Expires January, 2001 2 draft-wang-manet-umip-routing-00.txt July 2000 GSN GPRS (General Packet Radio Service) Supporting Node for 3Gpp systems HA Home Agent Home ID The ID (NAI) of the mobile node assigned by its home LR from which the MN subscribes network services. Home Network The coverage area of the home LR from which an MN subscribes network services Home Domain The entire area covered by the top layer LR that includes the home sub-tree where the mobile node subscribes network services. HSS Home Subscriber System IrDA Infrared Data Association Location Chain A sequence of location pointers at LRs forming a routing path between MN's current LR and its home LR Location Pointer IP address of an LR to which outbound packets are forwarded for a mobile user LR Location Registration or Location Register, a network entity in the IP network to handle mobility management LR(1) Layer one LR LR(2) Layer 2 LR LRd(1) LR(1) in the callee's network LRs(1) LR(1) in the caller's network LRt(1) The LR(1) that is connected to the roaming LR. It can be either LRs(1) or LRd(1). MIN Mobile Node Identification Number MN Mobile Node NAI Network Access Identifier NE Network Entity including LR, RNN. New ID The ID (NAI) of the LR which a mobile user newly discovered and to which Universal Registration Request messages are sent Node B Radio transceiver node in UMTS RAN PDSN Packet Data Service Node PLMN Public Land Mobile Network PSTN Public Switch Telephone Network RAN Radio Access Network RNN Radio Network Node for voice/data applications RNS Radio Network Subsystem TU Transmission Unit: BTS or a sector of BTS when sectional antenna is implemented TUID Transmission Unit Identifier UMIP Universal Mobile IP UMTS Universal Mobile Telecommunications System VHE Virtual Home Environment 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 [9]. Wang, Tang Internet Draft - Expires January, 2001 3 draft-wang-manet-umip-routing-00.txt July 2000 3. System architecture A simplified 3G wireless network architecture is shown in Figure 1 [6, 7]. There are two separate network segments in the architecture. The first segment is the Access Network (AN) that may include a Radio Network Controller (RNC), one or more Node B's, one or more Base Transceiver Stations (BTS's). It may also include a packet cable access system, an ISDN or a fixed wireless local loop. The second segment of the system is the Core Network (CN) which offers an integrated mobility solution among other functions to all the underlying heterogeneous ANs. Radio Access Network (RAN) --- > | < ---- Core Network (CN) MN ------------ RNN ------------ | --------- PDSN --------- | MT ------------ RNS ------------ | ----- GSN/CSCF/HSS ------ | Figure 1. 3G wireless network architecture Figure 2 shows a UMIP system architecture with four layers of Location Registers (LRs) in two diffrenet domains. The number of layers in each domain is scalable and can be different from one another. The lowest layer LR in the hierarchy, i.e., layer 1 LR which is denoted as LR(1), may be in direct contact with the mobile node (MN) and represent the functions of a radio access network. L4 LR --------------------- LR / \ / \ L3 LR LR LR LR / \ / \ / \ / \ L2 LR LR LR LR LR LR LR LR / \ / \ -------------------------------------------------- / \ M-interface / \ L1 LR LR / / - - / / MN MN Figure 2. The UMIP hierarchical system architecture Alternatively, LR(1) can be implemented in the core network as shown in Figure 3. In this case, LR(1) will be in contact with MN through the RAN. Wang, Tang Internet Draft - Expires January, 2001 4 draft-wang-manet-umip-routing-00.txt July 2000 Comparing to functions specified in the 3GPP system, LR(1) performs somewhat the combined functions of GSN, CSCF, and HSS[8]. The upper layers of LRs in UMIP are used mainly for location services and to enable quick registration and bearer setup when MN roams between different networks. There are several potential ways of mapping higher layer LRs to 3GPP network entities. One way is to map higher layer LRs to a set of Proxy/serving servers accessible to location information and potentially with user security and profile information when the home network designates them to do so. The other way is to define the Radio Access Network (RAN) --- > | < ---- Core Network (CN) MT ------------ RNS ------------ | -- LR(1) -- | -- LR(2)-- | Figure 3. UMIP wireless network architecture upper layer LRs collectively as a Location Service network with an interface toward the underlining core network entities such as SIP client/servers and proxy/redirect servers if SIP is implemented. The core network entities could also be foreign agents when Mobile IP is implemented. UMIP works with both of these mappings. In addition, the UMIP hierarchy can be constructed under individual operator, or as a shared infrastructure. Either a unique NAI (SIP-URL) or an IP address identifies the layer of the LR in the hierarchy. Different wireless systems may have their own network entities that are equivalent to the RNS. For example, the Radio Network Node (RNN) is an equivalent entity in a 3GPP2 network [6]. The RNS is responsible for all voice and/or data packets transported in the Radio Access Network (RAN). Each RNS is identified by a single location ID and is shared by multiple Base Transceiver Stations under its control. It is assumed that the RNS has a link layer connection (e.g., common control channels or the equivalent) with the Mobile Node. The RAN discussed in this dradt is responsible for all the radio access and micro mobility management issues. The core network referred MAY support multiple radio access technologies such as WCDMA, CDMA2000, GSM, IS-95, DECT, BRAN (Broadband Radio Access Network), BLUETOOTH, IrDA, and other future technologies. Also, as a by-product of UMIP, the Network-Network Interface (NNI) is pushed down to the "M" interface (see Figure 2) to maximize CN reuse and allow system integration for mobility management across multiple access technologies. The "M" interface MUST be IP based no matter what technology is implemented for the AN. This solution allows UMIP to enable new services such as for CDMA subscribers to Wang, Tang Internet Draft - Expires January, 2001 5 draft-wang-manet-umip-routing-00.txt July 2000 call GSM/UMTS subscribers by simply dialing the called party ID. In this document, all systems that support the "M" interface are defined as UMIP compatible. Otherwise, they are classified as legacy systems. For systems that do not support the M-interface between AN and CN, as shown in Figure 2, the LR(1) will have to be implemented in the core network. This is also true for systems that the mobility agents are implemented in the core network. The mobility management in UMIP is implemented in Location Registers (LRs). In addition to serving as proxy server/foreign agent and replying to registration requests for serving server/home agent, they maintain and update the mobility database. The LRs are organized in a layered architecture. The maximum layer I equals 4 is shown in Figure 2 as an example. The layer index is assigned in an increasing order from bottom to top layer. The number of layers in different sub-trees, or domains, does not need to be identical. Each LR may have zero or multiple child LRs in the next lower layer and may have zero (called root LR) or one immediate parent LR. All root LRs are assumed to be able to communicate with each other to form a location chain cross multiple domains. Each LR is associated with a logical coverage area. The total coverage area of a lower layer LR MUST be a proper sub-set of that of its parent LR. In other words, the logical boundary of a higher layer LR MUST not cross any boundary of its offspring LRs. The behavior of each LR may be different depending on the layer at which it is located. Only those LRs that have a direct (wired or wireless) interface to a MN need to advertise their presence to MNs. It should be noted that an LR at a given layer can have subtending child LRs and an interface to MNs. The root LR in a hierarchy can interface with the root nodes in other hierarchies. 4. UMIP routing process In this section, we will describe in detail the UMIP Bearer Routing process for providing real-time services. Due to certain unique nature of the cellular networks such as limited radio bandwidth, the routing process implemented by cellular network providers for real- time services may be different from those implemented for best- effort services. 4.1 Two connection phases Two phases are defined in the UMIP Bearer Routing process. The first phase is the Call Setup phase and the second is the Bearer traffic phase. A fast soft/hard handoff process, if included, is considered as part of the Bearer traffic phase. In the first phase the current location of a mobile user (callee) is identified with the help of LR pointers. Each LR in this phase functions like an HSS in 3GPP [8] or a Home Agent in Mobile IP [2] in the sense that each of the LR Wang, Tang Internet Draft - Expires January, 2001 6 draft-wang-manet-umip-routing-00.txt July 2000 forwards the received bearer setup request to the next LR (FA) as indicated by the location pointer (COA) in its database. This process continues until the message reaches the bottom layer LR where the callee is registered. In the second phase, the path for bearer traffic is set up by lowest layer LRs, bypassing higher layer LR hierarchy whenever possible to reduce latency and jitter. 4.1.1 The role of Location Registers Location Registers are involved in the bearer connection processes if at least one of the calling parties is a UMIP subscriber. To reduce delays and jitters, the layer of the LRs involved in the bearer connections should be as low as possible. There are other factors, such as global network management and security, that may require higher layer of LRs to be involved. In addition, when LR(1) is located in the access network, the Core Network may demand that all the inter LR(1) calls be connected through the LR(2). It is, thus, up to operators to configure UMIP in selecting the highest layer of LRs to be involved in call setup and that to be part of the bearer path. Without losing generality, weÆll describe henceafter in detail the solution that only requires LR(1) on the bearer path. In case one of the calling parties is within a UMIP compatible system while the other is not, an LR gateway in front of the legacy network will serve as one of the terminating points of the tunnel between the source and destination networks. In UMIP, the tunnel endpoints for the user bearer traffic can be layer one LRs in the two connecting networks. Alternatively, the bearer tunnel can be set up between LR(1) and a user device, or end to end between two user devices. The following discussion is focused on the case when the tunnel is set up between two LRs. 4.1.2 Agent advertisement If Agent Advertisement is implemented, the Mobility Agent Advertisement extension [2] is revised to include a bit indicating that the LR sending the advertisement supports UMIP. The extension will carry the IP address and NAI of the LR. A mobile user MUST not request for UMIP handoff/registration if the UMIP bit in the Agent Advertisement is not set [1]. 4.1.3 UMIP Gateways Gateways are needed for legacy networks to provide registration, call connection, and possibly handoff services for UMIP subscribers when they roam into their coverage areas. It is also possible for non-UMIP callers to utilize the UMIP capability when the callees are UMIP subscribers. The legacy systems are required to be able to exchange messages with the gateways for signaling and bearer processing. Wang, Tang Internet Draft - Expires January, 2001 7 draft-wang-manet-umip-routing-00.txt July 2000 4.2 Intra-UMIP Call setup phase The call setup process between two UMIP subscribers under different LR(1)s is discussed in this section. The discussion of intra LR(1) bearer setup is omitted since the same approach applies. The call setup process that involves legacy systems will be discussed in the later section. The LR(1) serving the caller is named source LR(1) and is denoted as LRs(1). For example, LR1111 in Figure 4 is LRs(1) when MNa initiates a call with MNb whose home LR is LR2122. The LR(1) serving the callee is named destination LR(1) (e.g., LR1121) and is denoted as LRd(1). L4 LR1 --------------------- LR2 / \ / \ L3 LR11 LR12 LR21 LR22 / \ / \ / \ / \ L2 LR111 LR112 LR121 LR122 LR211 LR212 LR221 LR222 / \ \ / \ L1 LR1111 LR1121 LR1125 LR2121 LR2122 (Hb) / \ - - / \ MNa MNb Figure 4. An example of the UMIP bearer setup process A Connection Request (e.g., an INVITE message in SIP) generated by the mobile user is first relayed to LRs(1). The Connection Request may be authenticated locally by LR server [1] or remotely by LR in Home network. If the request is positively authenticated, an NAI/IP (e.g., a SIP URL) of the LR is appended to the request message before it is relayed to other LRs in the UMIP system. This NAI/IP extension serves as the identity and care of address (or a Contact in SIP) of the source end of the tunnel (a call leg in SIP) that is between the source LR(1) and the destination LR(1). Other information, such as session setup information, security information etc., may also be included in the Connection Request message. After a Connection Request is sent, a pointer toward the location of caller (MNa) is set at LRs(1) with a "Pending" status. The details of how the Connection Request from the mobile caller to reach LRs(1) depend on the technology adopted by the access network. The location information of the called mobile user is maintained in the LR table at each LR which is on the location chain formed between the home LR and the LR where the mobile user is currently registered [1]. In the LR table, the called mobile is indexed by the NAI (e.g., SIP URL) and the address of the next hop LR serves as a Wang, Tang Internet Draft - Expires January, 2001 8 draft-wang-manet-umip-routing-00.txt July 2000 pointer toward the location of the callee. As an example, in Figure 4, there is a location chain for MNb that begins from LR2122 and ends at LR1121. Whenever an LR (e.g., LR1111) receives a call Connection Request, it will search its LR table for the called mobile user, similar to query local location server in SIP. If the entry for the called user is found at the lowest layer of UMIP hierarchy, the LR will begin the second phase of the bearer setup process. Otherwise, based on the information found in the entry, the processing LR will relay the message to other LRs that will eventually lead to the current location of the called user. If no entry is found, the LR will forward the Connection Request message along the hierarchy leading to the home network of the called user. As the example given in Figure 4, LR1111 will forward the Connection Request message to LR111 and to LR11. As the entry for the called user (MNb) is found at LR11, the Connection Request message will be relayed to the next hop LR (LR112) and then to LRd(1) (LR1121) according to the pointers in the tables. The security associations between LRs of different ownership are assumed to be established prior to the operation. LR-LR security extensions SHOULD be included as part of the Connection Request for inter-ownership signaling process. As soon as the LRd(1) receives Connection Request, it will send a Connection Request to the callee (MNb) via the protocols used by the access network. The LRd(1) then sets up a timer and waits for the reply from the callee. If LRd(1) receives a positive reply before the timer expires, it will send to LRs(1) a Connection Reply message with positive ACK, the IP address of the LRd(1) (similar to the COA in Mobile IP or Contact address in SIP), and bearer and security information. The LRd(1) also creates an entry in its bearer table with a pointer toward LRs(1) for the mobile user with the status set as "Pending". The "Pending" status ends when an "ACK" or the equivalent is received from LRs(1). If no positive ACK is received at LRd(1) from the called user before the timer expires, a NACK Connection Reply will be sent by LRd(1) to LRs(1). Similarly, LRs(1) will in turn send a NACK to the caller as an indication that the callee is not reachable if no positive ACK is received from LRd(1) before the time expires. 4.3 UMIP call setup with legacy systems This section describes two cases of the call setup process when one of the calling parties is in a legacy system. The first case is when the call is initiated from the UMIP system and the second is when the call is terminated in the UMIP system. Wang, Tang Internet Draft - Expires January, 2001 9 draft-wang-manet-umip-routing-00.txt July 2000 4.3.1 UMIP initiated connection request When a Connection Request from a UMIP compatible network to a legacy network is initiated, the message will first be relayed to the LRs(1). The LRs(1) will forward this request along the hierarchy to a UMIP gateway nearby the target network. The gateway will then serve as LRd(1) for the call. After receiving the Request message, the gateway LRd(1) relays the request via the legacy network to the mobile user and waits for the response. After the message is sent, a pointer with "Pending" status is set at LRs(1) toward LRd(1) and an associated timer is set. Subsequent actions taken by both LRs(1) and LRd(1) are similar to that specified for setting up a bearer path between two UMIP networks. 4.3.2 UMIP terminated connection request If the Connection Request is generated from a legacy network toward a UMIP network, the originating network will need to identify the gateway toward the UMIP network. The identified gateway serves as LRs(1) for the caller. Once the Connection Request reaches UMIP system, it will be processed in the same manner as a UMIP internal call. As a result, the terminating LRd(1) is identified and the request is forwarded to the called mobile user. If the connection setup fails, the gateway LRs(1) will be notified with an NACK message sent from the LRd(1). The gateway LRs(1) will in turn notify the caller via the legacy network. 4.4 Bearer traffic phase As soon as the LRs(1) (e.g. LR1111) receives a valid (error-free plus authenticated) Call Connection Reply from LRd(1) (e.g. LR1121) with positive ACK and acceptable bearer capacity, the LRs(1) also confirms the bearer path capacity toward LRd(1). After the bearer path capacity is confirmed, the LRs(1) will notify the caller (MNa) and the bearer traffic will commence over the tunnel between LRs(1) and LRd(1). LRs(1) also changes the status of associated pointers from "Pending" to "Active". If the granted bearer capacity is not acceptable, the LRs(1) will behave as specified by the selected session layer protocol for retry, renegotiation or abort. 4.4.1 Handoff mechanisms The details of the RAN handoff process without the "M" interface are specific to the RAN technologies and are not defined in this document. The intra-LR(1) handoff is hence transparent to UMIP. In the following session, we will only address the inter-LR(1) handoffs Wang, Tang Internet Draft - Expires January, 2001 10 draft-wang-manet-umip-routing-00.txt July 2000 in the UMIP system using the same example as shown in Figure 4. We now assume that the callee MNb is handing off from LR1121 to LR1125. Several issues need to be clarified before we describe the handoff process. First, there are several ways that the LRn(1) (LR1125 in Figure 4) of the target network to which the mobile user is roaming can be identified. The LRn(1) can be identified by the MN, by the system, or by combined effort of both. UMIP supports all of these methods. Secondly, there are several ways that the Handoff Request is generated. For example, the request can be generated by the CURRENT network (LRc(1), e.g., LR1121 in Figure 4 where the mobile user is registered) or by the NEW network (LRn(1), e.g., LR1125 in Figure 4 where the mobile is roaming to). UMIP supports both implementations. Furthermore, signaling between the AN and the LR(1) is required to support UMIP inter-LR(1) handoff process. The underlining access network is required to inform the associated LR(1) when a handoff support is needed from the UMIP system, or respond to a handoff request from LR(1). Information such as the target network IP addresses (e.g., IP addresses for LR1121 and LR1125) is acquired either from the access network or through exchanges between the associated LR(1)s. The interface and details of the process for the former case are access technology dependent and deserve further study. For ease of discussion, LRt(1) (LR1111 in Figure 4) is defined as LRs(1) if LRc(1) (LR1121 in Figure 4) is identical to LRd(1). Similarly, LRt(1) is defined as LRd(1) if LRc(1) is identical to LRs(1). 4.4.2 LRc(1) initiated handoff process In case the inter-LR(1) handoff process is initiated by the mobile userÆs current network, the LRc(1) (LR1121) may be informed by the current access network for the handoff request. The IP addresses of the LRc(1) and LRt(1) (LR1111), among other bearer/security information, are carried in the Handoff Request message send from LRc(1) addressed to LRn(1) (LR1125). After the Handoff Request is sent, a pointer toward LRn(1) is set at LRc(1) for the mobile user with a "Pending" status. A timer is also set at LRc(1) to specify a valid time period for that request. The LRc(1) is assumed to maintain a connection with the mobile user for ongoing signaling and bearer traffic. If the LRn(1) (LR1125) receives the Handoff Request correctly with positive authentication, it will begin a process to setup a link layer connection to the associated mobile user (MNb). After the successful setup of the link layer connection to the mobile user, the LRn(1) (LR1125) will, if it is not a LR node already involved in the communication (LRt(1)), send a Handoff Reply message with ACK and granted bearer capacity to the LRc(1) (LR1121). If the message is received correctly without bearer capacity Wang, Tang Internet Draft - Expires January, 2001 11 draft-wang-manet-umip-routing-00.txt July 2000 discrepancy and authenticated by LRc(1) before the timer expires, a tunnel is set up for that mobile user between LRc(1) and LRn(1) and LRn(1) is ready for handoff. The LRc(1) may then inform its access network with ACK for handoff. As soon as the LRn(1) is informed by its access network that it is ready for handoff, the LRn(1) will notify LRc(1) of its readiness for handoff. The ongoing bearer traffic will then be tunneled from LRc(1) to LRn(1). The status of the pending pointer at LRc(1) will be updated to "Active". Subsequently, the outbound bearer traffic will be relayed to the mobile user in the LRn(1) domain through the link layer connection that was set up in the handoff process. The existing link layer connection from the LRc(1) to the mobile user MAY be continued for a predetermined period of time to support inter-LR(1) soft handoff. If there is a bearer capacity discrepancy between LRc(1) and LRn(1), the bearer traffic will be delayed until the discrepancy is resolved. As soon as the tunnel is setup between LRc(1) and LRn(1), LRn(1) will trigger three events in the following order. 1) The bearer traffic from the access network is relayed to the LRc(1) to be forwarded to LRt(1) via existing tunnel between them. 2) A Handoff Indication message with the IP address of LRn(1) (LR1125) and granted bearer capacity is sent to the LRt(1) LR(1111) when necessary. The LRt(1) can then use the information to set up a new tunnel with LRn(1) and remove the existing tunnel with LRc(1). 3) The location registration process is initiated to update the mobile user's location chain. The details are described in [1]. 4.4.3 LRn(1) initiated handoff process In case the handoff process is initiated by the mobile user's roaming to (new) access network, the LRn(1) (LR1125) will be informed by the New access network for the handoff process. The IP address of the LRn(1), among other bearer/security information, are carried in the Handoff Request message addressed to LRc(1) (LR1121). After the Handoff Request is sent, a pointer toward LRc(1) with a "Pending" status is set at LRn(1) for the mobile user. A timer is also set at LRn(1) for that request. The LRn(1) is assumed to maintain a connection with the mobile user for further signaling. After receiving the valid (error-free plus successful user/server authentication) Handoff Request, the LRc(1) sends a handoff request to its access network to confirm the readiness for handoff, if it is necessary. After the readiness for handoff is confirmed from the access network, the LRc(1) will send a positive Handoff Reply with IP address of LRt(1) (LR1111), granted bearer capacity, and security information, etc., to LRn(1). If LRn(1) is not the LRt(1), the Wang, Tang Internet Draft - Expires January, 2001 12 draft-wang-manet-umip-routing-00.txt July 2000 bearer traffic will commence, as soon as the bearer capacity is agreed, via the tunnel between LRc(1) and LRn(1). The current link layer connection from the LRc(1) to the mobile user MAY be continued for a predetermined period of time to support soft handoff. Three events will be triggered at LRn(1) after a valid positive Handoff Reply is received from LRc(1) before timer expires: 1) The bearer traffic tunneled from the LRc(1) is relayed to the mobile user in the LRn(1) domain through the link layer connection that was set up during the handoff process. The bearer traffic from MN will be tunneled to LRc(1) in reversed direction. 2) A Handoff Indication message with the IP address of LRn(1) (LR1125) and granted bearer capacity is sent to the LRt(1) (LR1111) when necessary. The LRt(1) can then use the information to set up a new tunnel with LRn(1) and remove the existing tunnel with LRc(1). 3) The location registration process is initiated to update the mobile user's location information. The processing details are described in [1]. It should be noticed that, with the existence of gateways, handoffs in a UMIP non-compatible network are transparent to UMIP system. By the same token, handoffs within an UMIP system are also transparent to legacy systems (UMIP non-compatible networks). 4.4.4 Bearer connection optimization On receiving a valid Handoff Indication message with acceptable bearer capacity, the LRt(1) (LR1111) will update its bearer table and tunnel the ongoing bearer traffic toward LRn(1) (LR1125). The purpose is to optimize the bearer routing for efficient operation and reduced latency. If there is a bearer capacity discrepancy between LRt(1) and LRn(1), the bearer traffic will be delayed until the discrepancy is resolved. 4.4.5 Bearer table To facilitate the tunnel management and to efficiently route mobile user's packets within the LR(1) service area, a bearer table is created and maintained in the LR(1) when the user is present. The entries of the bearer table include Mobile user identity (SIP URL, NAI, IP address, etc.), forward pointers (IP addresses or MPLS labels), reverse pointers (IP addresses or MPLS labels), and associated status, lifetime, and security protection for each pointer. The forward pointers and reverse pointers are IP addresses (MPLS labels) of an entity in the access network, or the LR at the other end of the tunnel. The status can be "Pending" or "Active". The lifetime is used to specify the time in seconds before the entry Wang, Tang Internet Draft - Expires January, 2001 13 draft-wang-manet-umip-routing-00.txt July 2000 for the pointer will be expired. The security protection is used to protect the integrity of the entries. 4.4.6 Tunnel process module The tunnel process module at LR is to process all tunnel related tasks and manage the tunnel endpoint addresses for each mobile user. The tunnel information extension message should carry the information regarding the type of the tunnel and its characteristics including security and QoS. The receiving tunnel endpoint should respond with an acknowledgment of accepting/rejecting the setup, change, or tear down of the tunnel for the mobile. The outputs of the processing are stored in the bearer table and used by the LR to encapsulate and decapsulate packets. 4.4.7 QoS signaling over tunnel When reservation is required to provide various classes of services, RSVP protocol may be used to reserve the network QoS features. The tunnel management at LR becomes important in order to deliver QoS relevant control signaling and user data over the tunnel, especially for real-time services. It is in this case that the QoS tunnel managed by the network is more efficient than that by the mobile node. The performance of QoS tunnel management becomes even more critical during handoff for real-time services. To support real-time services for mobile users as described above, extensions to the IETF RSVP over the tunnel as specified in RFC2746, will be required. 5. An example for complete UMIP processes This section describes in detail the UMIP processes for location registration, for mobile to mobile connection setup and for handoff processes. Noted that the description assumes that the tunnel between the sending MN and the receiving MN is constructed between LRs(1) and LRd(1) and RSVP is implemented. A similar flow can be constructed for the case when the tunnel is constructed between MNs. 1) MN receives and responds to access network's broadcast or paging. 2) Access network performs necessary registration procedure and grants MN radio channels. 3) MN receives and responds to UMIP agent advertisement (may be integrated with access registration specified in item 1). The registration request is relayed to LRs(1). 4) Network LRs(1) performs UMIP registration which may involve MN's home LR. A location chain is setup / updated for that mobile user. An authorized LR will ACK the registration request toward the mobile user. 5) Network LRs(1) receives authenticated registration reply and user profile. Wang, Tang Internet Draft - Expires January, 2001 14 draft-wang-manet-umip-routing-00.txt July 2000 6) MN receives positive registration reply. 7) MN (MNs) sends a call connection request to initiate a call to a mobile user, MNd. The message may include QoS/capacity reservation information. The request is relayed to LRs(1) if the access network is unable to handle the request. 8) LRs(1) sends the connection request along the UMIP hierarchy towards the calleeÆs home network until a LR which is on the calleeÆs location chain is found. The request is then relayed to LRd(1) following the location chain. If no LR on the calleeÆs location chain is found, the request will reach the calleeÆs home network. 9) LRd(1) locates MNd and sends connection reply to caller's LR (LRs(1)). LRd(1) may also send along a QoS signaling message to request for resource reservation to LRs(1) and sets up the path between LRd and MNd. 10) LRs(1) replies to LRd(1) for resource reservation (RSVP) of the tunnel from LRd(1) to LRs(1). Additional message may be required for LRs(1) to send a request for resource reservation (RSVP) to LRd(1) for the tunnel from LRs(1) to LRd(1). LRs(1) also sets up the QoS path between LRs and MNs. 11) LRd(1) may reply with ACK to LRs(1) for the resource reservation of the tunnel from LRs(1) to LRd(1) . LRd also signals to MNd to begin sending bearer traffic. 12) LRs(1) signals to MNs to begin sending bearer traffic after receiving positive reply from LRd(1). The following steps will take place when MNs begins to roam into a different network. 13) MNs sends a handoff request and the request is relayed to the LRn(1) in the new visited network. 14) LRn(1) may send a handoff reply message to MNs with the status of "Pending". 15) LRn(1) will then begin the handoff process by sending a handoff request to LRc(1). LRn(1) also sets up the QoS path to the MNs. 16) LRc(1) sends a handoff request to its access network to confirm the readiness for handoff. It then sends a handoff reply to LRn(1). It also sets up the tunnel between LRc(1) and LRn(1), with the required QoS characteristics. 17) After receiving the handoff reply, LRn(1) sends positive handoff reply to MNs. 6. Service control Service control is a required function for 3G cellular network systems. The function is specified to allow mobile user's home network and visited networks to negotiate the control point for providing services to the user. Some known services are best provided at the visited network such as 911 emergency service. Others that are best provided by the home network include services not available at the visited network. Wang, Tang Internet Draft - Expires January, 2001 15 draft-wang-manet-umip-routing-00.txt July 2000 In this section, we do not intend to describe the details of the functions of the service control. Our intension is, however, to point out the similarity between the signaling required to perform service control and the signaling required for call connection set up. Both of them will require minimal tromboning in order to reduce the time delay in providing services to the MN. One of the functions of service control defined in 3GPP specification is to select the serving CSCF. The serving CSCF can either be in the mobile userÆs home network or the visiting network. To achieve minimal tromboning, the optimization of signaling routes will be required no matter where the proxy/serving CSCF is selected. To illustrate the benefits of UMIP in providing service control, the following scenarios are described for different service control implementations. 1) Centralized Home Control: The registration and call services requests are sent from the visiting CSCF to the home CSCF in the home network. In this case, the UMIP is reduced to Mobile IP with tromboning in both signaling and bearer traffic. The benefit UMIP provides is reduced number of tromboning paths through address mapping and integrated messaging. 2) Distributed Home Control: There are two approaches in this scenarios. The first one is that the registration and call services requests are sent to the home CSCF in the home network. Based on the location information contained in the received messages, the home CSCF then assigns a proxy CSCF (owned by the home network) which is nearby the visited network for the MN. The home CSCF also sends to the assigned proxy all security and user profile information of the MN. This is the degenerated UMIP case. The benefits UMIP provides are user location based distributed service control, in addition to reduced tromboning paths for initial request and localized registration, and call connection processes for subsequent requests from the same mobile user. In the second approach, the registration and call services requests are sent to the visiting CSCF. The VCSCF then forwards the messages to the nearby LR(1) of the home service provider. The LR(1) will in turn forward the messages to HCSCF in the home network if no MN information is available. The home CSCF (home LR) then can send the security and user information to this LR(1) which becomes the proxy home CSCF/Serving CSCF. This is also a degenerated UMIP case. The advantage of this system is that tromboning can be eliminated when user information is available at the local LR(1). Full UMIP Wang, Tang Internet Draft - Expires January, 2001 16 draft-wang-manet-umip-routing-00.txt July 2000 benefits could be achieved with the UMIP LR hierarchy serving as location servers for the proxy and home LRs. 3) Distributed Hierarchical Home Control: This is the system implements a hierarchy such as UMIP. The registration and call services requests are sent to the visiting CSCF. The VCSCF then forwards the messages to the nearby LR(1) of the home service provider. The nearby LR(1) then forwards the messages along the location registration tree until MN information is obtained. This LR(1) nearby the visiting network then serves as proxy home CSCF/Serving CSCF. Tromboning is further minimized in this system, in addition to all the benefits of previous systems. Full UMIP benefits are achieved by this architecture in the form that the LRs in the hierarchy acting as proxy/serving servers. 4) Visitor Control: In this case, the proxy home CSCF is assigned to VCSCF (public/private server). The registration and service control processes are forwarded in the same manner as that described in the home control systems. That is, the messages can be forwarded by VCSCF to home CSCF, to local location register or along the UMIP hierarchy toward next hop proxy/serving server. It is thus clear that the UMIP solution provides an efficient means to distribute secured information such as user location, service profiles, and service control to large coverage areas to reduce tromboning paths in both signaling and bearer path, in addition to support various scenarios of service controls that could be selected by operators. 7. UMIP routing with IPv6 UMIP is a protocol designed to provide integrated mobility (registration, service control, bearer setup, and roaming) and real- time services for users with IPv4 stack with either COA or co- located COA, or IPv6 protocol stack. In this section, examples of routing user bearer traffic using IPv6 are described. Specifically, three scenarios for routing user packets are discussed: 1) MN accessing remote ISP web site, 2) MN to MN calls, and 3) MN handoff during active session. Further, for the second and third scenarios, three cases are described. They are a) when routing path is not specified, b) when routing path is specified, and c) when routing path is specified and requiring minimum MN involvement plus location privacy. For the first scenario, only cases a) and b) are discussed. Wang, Tang Internet Draft - Expires January, 2001 17 draft-wang-manet-umip-routing-00.txt July 2000 7.1 MN accessing remote ISP web site a) Routing path not specified From MN to ISP: d = ISP | s = COA | HAD = MN | BU From ISP to MN: d = COA | s = ISP | RH = COA, MN Where d = destination IP address s = source IP address COA = Care-of-address HAD = Home address destination option BU = binding update RH = routing header option b) Routing path is specified The path between MN and ISP is specified (MN <--> Router (RTR) <- -> ISP) From MN --> RTR --> ISP: d = RTR | s = COA | RH = RTR, ISP | HAD = MN | BU From ISP --> RTR --> MN: d = RTR | s = ISP | RH = RTR, COA, MN 7.2 MN to MN call a) Routing path not specified From MN1 --> MN2: d = COA2 | s = COA1 | RH = COA2, MN2 | HAD = MN1 | BU1 where COA1 = COA of MN1 COA2 = COA of MN2 BU1 = binding update of MN1 b) Routing path is specified In this case, the routing path is specified between the MN and ISP. In addition, MN1 is assumed to be within the area of router RTR1 and MN2 within router RTR2. From MN1 --> RTR1 --> RTR2 --> MN2: d = RTR1 | s = COA1 | RH = RTR1, RTR2, COA2, MN2 | HAD = MN1 | BU1 c) Routing path is specified and requiring minimum MN involvement plus location privacy Wang, Tang Internet Draft - Expires January, 2001 18 draft-wang-manet-umip-routing-00.txt July 2000 From MN --> LR1 (RTR1): The packet is encapsulated by MN. d = LR1 | s = COA1 [d = MN2 | s = MN1] From LR1 --> LR2 (RTR2): LR1 looks up cache table {MN2, LR2} and replaces tunnel header of the packet. d = LR2 | s = LR1 [d = MN2 | s = MN1] From LR2 --> MN2: LR2 de-capsulates the packet and looks up cache table to obtain the mapping between MN2 and its Link address. d = MN2 | s = MN1 7.3 MN handoff This section describes the handoff process when MN1 roams to a new router area denoted as RTRn or LRn. a) Routing path not specified From MN1 --> MN2: @MN1 sends new binding update, BUn d = COA2 | s = COAn | RH = COA2, MN2 | HAD = MN1 | BUn where COAn = COA of MN1 from router RTRn From MN2 --> MN1: Before receiving BUn, MN2 sends packets to router RTR1 which then tunnels to MN1, after BUn from MN1 has received. d = COA1 | s = COA2 | RH = COA1, MN1 | HAD = MN2] When receiving the packet, RTR1 looks up binding cache and encapsulates the packet with new COA. d = COAn | s = RTR1 [d = COA1 | s = COA2 | RH = COA1, MN1 | HAD = MN2] After receiving BUn, the address part of the packet header sent by MN2 will become d = COAn | s = COA2 | RH = COAn, MN1 | HAD = MN2 b) Routing path is specified A direct path may be specified between MN1 and MN2 to bypass RTR1. Alternatively, the path may go through RTR1. From MN1 --> RTRn (--> RTR1) --> RTR2 --> MN2: MN1 includes in the packet sent to MN2 the new binding update, BUn. Wang, Tang Internet Draft - Expires January, 2001 19 draft-wang-manet-umip-routing-00.txt July 2000 d = RTRn | s = COAn | RH = RTRn, (RTR1), RTR2, COA2, MN2 | HAD = MN1 | BUn From MN2 --> MN1: Before receiving BUn, MN2 sends packets to RTR1 which then tunnels to RTRn. RTR1 looks up binding cache and encapsulates the packet with the destination address to RTRn. d = RTRn | s = RTR1 | RH = COAn, COA1 [d = COA1 | s = COA2 | RH = RTR2, RTR1, COA1, MN1 | HAD = MN2] After receiving BUn and the establishment of the new bearer path, the address part of the packets sent by MN2 will become d = RTR2 | s = COA2 | RH = RTR2, RTRn, COAn, MN1 | HAD = MN2 c) Routing path is specified and requiring minimum MN involvement plus location privacy Initially, the path go through the new tunnel between LRn and LR1 for fast handoff. Later, after a direct path is set up between LRn and LR2, LR1 can then be by passed. The process is symmetric for bearer traffic from MN2 (MN --> LR2 --> LR1 --> LRn --> MN1 initially and then LR1 is by passed.). From MN --> LRn: MN1 encapsulates the packet addressed to the new LR, LRn. d = LRn | s = COAn [d = MN2 | s = MN1] From LRn --> LR1: LRn decapsulates the packet and looks up the cache table to map the addresses between MN2 and LR1. d = LR1 | s = LRn [d = MN2 | s = MN1] From LR1 --> LR2: LR1 decapsulates the packet and looks up the cache table for mapping of the addresses between MN2 and LR2. d = LR2 | s = LR1 [d = MN2 | s = MN1] From LR2 --> MN2: LR2 decapsulates the packet and looks up the cache table for the mapping between MN2 and its Link address to deliver the packet to MN2. d = MN2 | s = MN1 For the reverse path from MN2 to MN1, MN2 sends packets directed to LR2. LR2 then tunnels the packets to LR1 and subsequently LR1 tunnels them to LRn, before the bearer path is optimized (bypassing LR1). MN2 sends encapsulated packet to LR2 with the header Wang, Tang Internet Draft - Expires January, 2001 20 draft-wang-manet-umip-routing-00.txt July 2000 d = LR2 | s = COA2 [d = MN1 | s = MN2] After the packet, LR2 looks up the cache table and encapsulates the packet to LR1 d = LR1 | s = LR2 [d = MN1 | s = MN2] Aftre receiving the packet, LR1 looks up cache table and encapsulates the packet to LRn. The address part of the header is d = LRn | s = LR1 [d = MN1 | s = MN2] After receiving the packet, LRn decapsulates the packet and looks up the cache table for the mapping between MN1 and its Link address to deliver the packet to MN1. The address part of the header is d = MN1 | s = MN2 8. Security Considerations The security association is to be established between all location registers. Authentication and encryption technologies are expected to be used whenever required. Details of the security considerations can be found in the previous draft defined in [1]. 9. References [1] J. Wang and A. Tang, "Universal Mobile IP (UMIP) Location Management", draft-wang-mobileip-UMIP-00.txt, March 2000. [2] Perkins, C., Editor, "IP Mobility Support", RFC 2002, October 1996. [3] C. Perkins, Editor, "IP Mobility Support for IPv4, revised", draft-ietf-mobileip-rfc2002-bis-01.txt, January 2000. [4] E. Gustafsson, A Jonsson, and C. Perkins, "Mobile IP Regional Tunnel Management", draft-ietf-mobileip-reg-tunnel-01.txt, August 1999. [5] C. Perkins and D. Johnson, "Route Optimization in Mobile-IP", draft-ietf-mobileip-optim-08.txt, February 1999. [6] T. Hiller, "Wireless IP Network Architecture based on IETF Protocols", TIA TR 45.6/TSG-P, June 1999. [7] ETSI TS 123 060 V 3.2.1, "General packet Radio Service (GPRS), Service Description", January 2000. [8] ETSI, "3GPP Technical Specification Group Services and System Aspects; Architecture Principles for Release 2000), TR 23.821 v0.2.0 (2000-03). [9] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 Wang, Tang Internet Draft - Expires January, 2001 21 draft-wang-manet-umip-routing-00.txt July 2000 10. Acknowledgments The authors would like to thank the Motorola management for their encouragement and support of this work. 11. Author's Addresses John Z. Wang Motorola, Inc 1501 west Shure Drive, Arlington Heights, IL 60004 Phone: (847)435-2710 Email: ezw001@email.mot.com D. Almon Tang Motorola, Inc 1501 west Shure Drive, Arlington Heights, IL 60004 Phone: (847)435-2715 Email: aat008@email.mot.com Wang, Tang Internet Draft - Expires January, 2001 22 draft-wang-manet-umip-routing-00.txt July 2000 Full Copyright Statement "Copyright (C) The Internet Society (date). 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 implmentation 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 document 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 developing 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 Wang, Tang Internet Draft - Expires January, 2001 23