WO2014107516A2 - Distributed internet protocol mobility management support mechanisms - Google Patents

Abstract

A method for providing robustness in distributed mobility management is described. A wireless transmit/receive unit (WTRU) is attached to a first distributed gateway (D-GW) via an interface. A tunnel between the first D-GW and a second D-GW is pre-provisioned. The WTRU is attached to the second D-GW and detached from the first D-GW. The tunnel between the first D-GW and the second D-GW that was pre-provisioned is created. Data traffic between the WTRU and the first D-GW is sent via the interface on the second D-GW and using the tunnel between the first D-GW and the second D-GW, thereby providing robustness.

Description

DISTRIBUTED INTERNET PROTOCOL MOBILITY

MANAGEMENT SUPPORT MECHANISMS

CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application

No. 61/748,927, filed on January 4, 2013, the contents of which are hereby incorporated by reference as is fully set forth herein.

FIELD OF INVENTION

[0002] This application is in the field of wireless communications.

BACKGROUND

[0003] In contrast to current Mobile Internet Protocol version 6 (IPv6) and

Proxy Mobile IPv6 (PMIP) approaches that rely on centralized entities for both control and data plane operation, distributed mobility management (DMM) approaches push mobility anchors toward the edge of the network.

[0004] Figure 1 is an example of a DMM-based network architecture 100.

The architecture 100 includes a home public land mobile network (HPLMN) 102 that communicates with the Internet 104. The architecture 100 also includes several distributed gateways (D-GW) 106a-e. A D-GW is a logical entity placed at an edge of the network, close to a wireless transmit/receive unit (WTRU) 140a, 140b. Multiple D-GWs exist in a DMM domain, anchoring mobility sessions of the WTRUs attached to the domain. Each D-GW 106a-e provides network services 108a-e to a network section llOa-e.

[0005] The HPLMN 102 includes a multi-hop cellular network (MCN) 120 and one of the D-GWs (shown in Figure 1 as D-GW 106e). The MCN 120 includes several nodes 122 to communicate within the MCN, a packet data network gateway (PGW) 124, a home subscriber server (HSS) 126, an authentication, authorization, and accounting server (AAA) 128, a serving gateway (SGW) 130, and a mobility management entity (MME) 132. It is noted that the various servers and entities 126-132 are used in one implementation of the MCN 120 and that other combinations of servers and entities may also be used in the MCN 120.

SUMMARY

[0006] A method for providing robustness in distributed mobility management is described. A wireless transmit/receive unit (WTRU) is attached to a first distributed gateway (D-GW) via an interface. A tunnel between the first D-GW and a second D-GW is pre-provisioned. The WTRU is attached to the second D-GW and detached from the first D-GW. The tunnel between the first D- GW and the second D-GW that was pre-provisioned is created. Data traffic between the WTRU and the first D-GW is sent via the interface on the second D- GW and using the tunnel between the first D-GW and the second D-GW, thereby providing robustness.

[0007] A method for offloading a data traffic flow in distributed mobility management is described. A WTRU is attached to a first D-GW via a first interface. The WTRU is attached to a second D-GW via a second interface, wherein the second interface is different from the first interface. A first data traffic flow between the WTRU and the first D-GW is sent via the first interface. A second data traffic flow between the WTRU and the second D-GW is sent via the second interface. On a condition that the first D-GW decides to offload the first data traffic flow, a tunnel is created between the first D-GW and the second D-GW, and the first data traffic flow between the first D-GW and the WTRU is sent via the second D-GW using the tunnel and via the second interface, thereby offloading the first data traffic flow from the first D-GW to the second D-GW.

[0008] A method for splitting a data traffic flow in distributed mobility management is described. A WTRU is attached to a first D-GW via a first interface. The WTRU is attached to a second D-GW via a second interface, wherein the second interface is different from the first interface. A first data traffic flow between the WTRU and the first D-GW is sent via the first interface. A second data traffic flow between the WTRU and the second D-GW is sent via the second interface. On a condition that the first D-GW decides to split the first data traffic flow, a tunnel is created between the first D-GW and the second D- GW, a first percentage of the first data traffic flow between the WTRU and the first D-GW is sent via the first interface, and a second percentage of the first data traffic flow between the WTRU and the first D-GW is sent via the second interface and the second D-GW and using the tunnel to reach the first D-GW, thereby splitting the first data traffic flow between the first D-GW and the second D-GW.

BRIEF DESCRIPTION OF THE DRAWINGS

[0009] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, wherein:

[0010] Figure 1 is an example of a DMM-based network architecture;

[0011] Figure 2A is a system diagram of an example communications system in which one or more disclosed embodiments may be implemented;

[0012] Figure 2B is a system diagram of an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in Figure 2A;

[0013] Figure 2C is a system diagram of an example radio access network and an example core network that may be used within the communications system illustrated in Figure 2A;

[0014] Figure 3 is a diagram of a portion of a communication stack showing an example of a logical interface implementation on a mobile node;

[0015] Figure 4 is an example of a Proxy Mobile Internet Protocol (PMIP)- based Network-based IP Flow Mobility (NBIFOM) architecture;

[0016] Figure 5 is an example of a robustness use case;

[0017] Figures 6A-6C show an example of a network-based DMM solution to provide robustness;

[0018] Figures 7A and 7B show an example of a signaling sequence of the network-based DMM robustness solution;

[0019] Figures 8A and 8B show an example of an offloading use case;

[0020] Figures 9A and 9B is an example overview of DMM offloading;

[0021] Figure 10 is an example of a signaling sequence of the network- based DMM offloading solution; [0022] Figure 11 is an example of a split/aggregation use case;

[0023] Figures 12A and 12B show an example overview of DMM split/aggregation; and

[0024] Figure 13 is an example of a signaling sequence of the network- based DMM flow/split aggregation solution.

DETAILED DESCRIPTION

[0025] Figure 2A is a diagram of an example communications system 200 in which one or more disclosed embodiments may be implemented. The communications system 200 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 200 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 200 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), and the like.

[0026] As shown in Figure 2A, the communications system 200 may include wireless transmit/receive units (WTRUs) 202a, 202b, 202c, 202d, a radio access network (RAN) 204, a core network 206, a public switched telephone network (PSTN) 208, the Internet 210, and other networks 212, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 202a, 202b, 202c, 202d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 202a, 202b, 202c, 202d may be configured to transmit and/or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, consumer electronics, and the like. [0027] The communications systems 200 may also include a base station

214a and a base station 214b. Each of the base stations 214a, 214b may be any type of device configured to wirelessly interface with at least one of the WTRUs 202a, 202b, 202c, 202d to facilitate access to one or more communication networks, such as the core network 206, the Internet 210, and/or the networks 212. By way of example, the base stations 214a, 214b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 214a, 214b are each depicted as a single element, it will be appreciated that the base stations 214a, 214b may include any number of interconnected base stations and/or network elements.

[0028] The base station 214a may be part of the RAN 204, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 214a and/or the base station 214b may be configured to transmit and/or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The cell may further be divided into cell sectors. For example, the cell associated with the base station 214a may be divided into three sectors. Thus, in one embodiment, the base station 214a may include three transceivers, i.e., one for each sector of the cell. In another embodiment, the base station 214a may employ multiple -input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.

[0029] The base stations 214a, 214b may communicate with one or more of the WTRUs 202a, 202b, 202c, 202d over an air interface 216, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 216 may be established using any suitable radio access technology (RAT).

[0030] More specifically, as noted above, the communications system 200 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 214a in the RAN 204 and the WTRUs 202a, 202b, 202c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 216 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) and/or High-Speed Uplink Packet Access (HSUPA).

[0031] In another embodiment, the base station 214a and the WTRUs

202a, 202b, 202c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 216 using Long Term Evolution (LTE) and/or LTE- Advanced (LTE-A).

[0032] In other embodiments, the base station 214a and the WTRUs 202a,

202b, 202c may implement radio technologies such as IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0033] The base station 214b in Figure 2A may be a wireless router, Home

Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, and the like. In one embodiment, the base station 214b and the WTRUs 202c, 202d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, the base station 214b and the WTRUs 202c, 202d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 214b and the WTRUs 202c, 202d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell. As shown in Figure 2 A, the base station 214b may have a direct connection to the Internet 210. Thus, the base station 214b may not be required to access the Internet 210 via the core network 206. [0034] The RAN 204 may be in communication with the core network 206, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (V oIP) services to one or more of the WTRUs 202a, 202b, 202c, 202d. For example, the core network 206 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication. Although not shown in Figure 2A, it will be appreciated that the RAN 204 and/or the core network 206 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 204 or a different RAT. For example, in addition to being connected to the RAN 204, which may be utilizing an E-UTRA radio technology, the core network 206 may also be in communication with another RAN (not shown) employing a GSM radio technology.

[0035] The core network 206 may also serve as a gateway for the WTRUs

202a, 202b, 202c, 202d to access the PSTN 208, the Internet 210, and/or other networks 212. The PSTN 208 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 210 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) in the TCP/IP internet protocol suite. The networks 212 may include wired or wireless communications networks owned and/or operated by other service providers. For example, the networks 212 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 204 or a different RAT.

[0036] Some or all of the WTRUs 202a, 202b, 202c, 202d in the communications system 200 may include multi-mode capabilities, i.e., the WTRUs 202a, 202b, 202c, 202d may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU 202c shown in Figure 2A may be configured to communicate with the base station 214a, which may employ a cellular-based radio technology, and with the base station 214b, which may employ an IEEE 802 radio technology. [0037] Figure 2B is a system diagram of an example WTRU 202. As shown in Figure 2B, the WTRU 202 may include a processor 218, a transceiver 220, a transmit/receive element 222, a speaker/microphone 224, a keypad 226, a display/touchpad 228, non-removable memory 230, removable memory 232, a power source 234, a global positioning system (GPS) chipset 236, and other peripherals 238. It will be appreciated that the WTRU 202 may include any subcombination of the foregoing elements while remaining consistent with an embodiment.

[0038] The processor 218 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 218 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 202 to operate in a wireless environment. The processor 218 may be coupled to the transceiver 220, which may be coupled to the transmit/receive element 222. While Figure 2B depicts the processor 218 and the transceiver 220 as separate components, it will be appreciated that the processor 218 and the transceiver 220 may be integrated together in an electronic package or chip.

[0039] The transmit/receive element 222 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 214a) over the air interface 216. For example, in one embodiment, the transmit/receive element 222 may be an antenna configured to transmit and/or receive RF signals. In another embodiment, the transmit/receive element 222 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit/receive element 222 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 222 may be configured to transmit and/or receive any combination of wireless signals. [0040] In addition, although the transmit/receive element 222 is depicted in Figure 2B as a single element, the WTRU 202 may include any number of transmit/receive elements 222. More specifically, the WTRU 202 may employ MIMO technology. Thus, in one embodiment, the WTRU 202 may include two or more transmit/receive elements 222 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 216.

[0041] The transceiver 220 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 222 and to demodulate the signals that are received by the transmit/receive element 222. As noted above, the WTRU 202 may have multi-mode capabilities. Thus, the transceiver 220 may include multiple transceivers for enabling the WTRU 202 to communicate via multiple RATs, such as UTRA and IEEE 802.11, for example.

[0042] The processor 218 of the WTRU 202 may be coupled to, and may receive user input data from, the speaker/microphone 224, the keypad 226, and/or the display/touchpad 228 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 218 may also output user data to the speaker/microphone 224, the keypad 226, and/or the display/touchpad 228. In addition, the processor 218 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 230 and/or the removable memory 232. The non-removable memory 230 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 232 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 218 may access information from, and store data in, memory that is not physically located on the WTRU 202, such as on a server or a home computer (not shown).

[0043] The processor 218 may receive power from the power source 234, and may be configured to distribute and/or control the power to the other components in the WTRU 202. The power source 234 may be any suitable device for powering the WTRU 202. For example, the power source 234 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

[0044] The processor 218 may also be coupled to the GPS chipset 236, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 202. In addition to, or in lieu of, the information from the GPS chipset 236, the WTRU 202 may receive location information over the air interface 216 from a base station (e.g., base stations 214a, 214b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 202 may acquire location information by way of any suitable location- determination method while remaining consistent with an embodiment.

[0045] The processor 218 may further be coupled to other peripherals 238, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 238 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

[0046] Figure 2C is a system diagram of the RAN 204 and the core network 206 according to an embodiment. The RAN 204 may be an access service network (ASN) that employs IEEE 802.16 radio technology to communicate with the WTRUs 202a, 202b, 202c over the air interface 216. As will be further discussed below, the communication links between the different functional entities of the WTRUs 202a, 202b, 202c, the RAN 204, and the core network 206 may be defined as reference points.

[0047] As shown in Figure 2C, the RAN 204 may include base stations

240a, 240b, 240c, and an ASN gateway 242, though it will be appreciated that the RAN 204 may include any number of base stations and ASN gateways while remaining consistent with an embodiment. The base stations 240a, 240b, 240c may each be associated with a particular cell (not shown) in the RAN 204 and may each include one or more transceivers for communicating with the WTRUs 202a, 202b, 202c over the air interface 216. In one embodiment, the base stations 240a, 240b, 240c may implement MIMO technology. Thus, the base station 240a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 202a. The base stations 240a, 240b, 240c may also provide mobility management functions, such as handoff triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, and the like. The ASN gateway 242 may serve as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 206, and the like.

[0048] The air interface 216 between the WTRUs 202a, 202b, 202c and the

RAN 204 may be defined as an Rl reference point that implements the IEEE 802.16 specification. In addition, each of the WTRUs 202a, 202b, 202c may establish a logical interface (not shown) with the core network 206. The logical interface between the WTRUs 202a, 202b, 202c and the core network 206 may be defined as an R2 reference point, which may be used for authentication, authorization, IP host configuration management, and/or mobility management.

[0049] The communication link between each of the base stations 240a,

240b, 240c may be defined as an R8 reference point that includes protocols for facilitating WTRU handovers and the transfer of data between base stations. The communication link between the base stations 240a, 240b, 240c and the ASN gateway 242 may be defined as an R6 reference point. The R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each of the WTRUs 202a, 202b, 202c.

[0050] As shown in Figure 2C, the RAN 204 may be connected to the core network 206. The communication link between the RAN 204 and the core network 206 may defined as an R3 reference point that includes protocols for facilitating data transfer and mobility management capabilities, for example. The core network 206 may include a mobile IP home agent (MIP-HA) 244, an authentication, authorization, accounting (AAA) server 246, and a gateway 248. While each of the foregoing elements are depicted as part of the core network 206, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0051] The MIP-HA may be responsible for IP address management, and may enable the WTRUs 202a, 202b, 202c to roam between different ASNs and/or different core networks. The MIP-HA 244 may provide the WTRUs 202a, 202b, 202c with access to packet- switched networks, such as the Internet 210, to facilitate communications between the WTRUs 202a, 202b, 202c and IP-enabled devices. The AAA server 246 may be responsible for user authentication and for supporting user services. The gateway 248 may facilitate interworking with other networks. For example, the gateway 248 may provide the WTRUs 202a, 202b, 202c with access to circuit- switched networks, such as the PSTN 208, to facilitate communications between the WTRUs 202a, 202b, 202c and traditional land-line communications devices. In addition, the gateway 248 may provide the WTRUs 202a, 202b, 202c with access to the networks 212, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0052] Although not shown in Figure 2C, it will be appreciated that the

RAN 204 may be connected to other ASNs and the core network 206 may be connected to other core networks. The communication link between the RAN 204 the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating the mobility of the WTRUs 202a, 202b, 202c between the RAN 204 and the other ASNs. The communication link between the core network 206 and the other core networks may be defined as an R5 reference, which may include protocols for facilitating interworking between home core networks and visited core networks.

[0053] Other network 212 may further be connected to an IEEE 802.11 based wireless local area network (WLAN) 260. The WLAN 260 may include an access router 265. The access router may contain gateway functionality. The access router 265 may be in communication with a plurality of access points (APs) 270a, 270b. The communication between access router 265 and APs 270a, 270b may be via wired Ethernet (IEEE 802.3 standards), or any type of wireless communication protocol. AP 270a is in wireless communication over an air interface with WTRU 202d.

[0054] A Logical Interface (LIF) is a construct internal to the operating system or connection manager. It is an approach where the link layer implementations hide the physical interfaces from the IP stack and from the network nodes. Figure 3 is a diagram of a portion of a communication stack 300 showing an example of a logical interface implementation on a mobile node. Both proxy mobile IP (PMIP) and general packet radio service (GPRS) tunneling protocol (GTP) network-based IP flow mobility solutions in general may require the existence of a LIF at the mobile node (MN) or wireless transmit/receive unit (WTRU). It is desirable to use distributed IP mobility management to provide robustness, offload a data traffic flow, split a data traffic flow, and/or aggregate multiple data traffic flows, as described below in connection with one or more embodiments.

[0055] The communication stack 300 includes a transmission control protocol (TCP)/user datagram protocol (UDP) layer 302, an IP layer 304, a LIF layer 306, several Layer 2 (L2) instances 308a-n, and several Layer 1 (LI) instances 310a-n. A session to IP address binding 320 is established between the TCP/UDP layer 302 and the IP layer 304. An IP address binding 322 is established between the IP layer 304 and the LIF layer 306. A logical to physical interface binding 324 is established between the LIF layer 306 and the L2 instances 308a-n.

[0056] Figure 4 is an example of a PMIP-based network-based IP flow mobility (NBIFOM) architecture 400. The NBIFOM architecture 400 includes a PMIPv6 domain 402 that communicates with the Internet 404, which permits a node 406 to access the PMIPv6 domain 402. The PMIPv6 domain 402 includes a local mobility anchor (LMA) 410, two mobility access gateways (MAG) 412a and 412b, and a multi-interfaced mobile node 414 configured to connect to both MAGs 412a and 412b. It is noted that a GTP-based solution may present similar functionalities to the architecture 400.

[0057] Relevant use cases where a mobile node attached to an IP-based

DMM-enabled mobile network might benefit from enhanced support are described below. These use cases include a robustness use case, an offloading use case, and a flow split/aggregation use case. Operation of single and multi- interfaced mobile nodes in IP-based mobile networks may be enhanced using a network-based DMM solution by introducing pre-provisioning signaling and packet buffering for the robustness use case, offloading concepts and mechanisms, and mechanisms to perform flow split/aggregation.

[0058] Figure 5 is an example of a robustness use case, described in terms of a system 500. The system 500 includes a MCN 502, several D-GWs 504a-c, and a WTRU 506. The MCN 502 includes a PGW 510 and a HSS 512 and communicates with the D-GWs 504a-c via a D-GW local interconnection 514. The D-GWs 504a-c provide network services 516a-c and communicate with the WTRU 506 via connections 518a-c using a locally anchored prefix (PrefA::/64, PrefB::/64, PrefC::/64).

[0059] In the robustness use case, the WTRU 506 may have several D-GWs

504a-c in radio range over one or multiple interfaces. The D-GWs 504a-c may be used by the WTRU 506 to transmit/receive traffic via multiple interfaces sequentially, but not simultaneously. This arrangement may provide robustness, as the WTRU 506 does not depend on one D-GW 504a-c, but may select a D-GW from among several.

[0060] In a regular non-optimized scenario, when the WTRU 506 moves from one D-GW 504a-c to another, this may be considered a handover. With a handover, there are signaling procedures designed to prepare the network so the traffic reaches the WTRU 506 at its new location. Although optimized, these operations may require some time and may not be feasible to hand off traffic on a per packet basis, which is what the robustness use case requires. Accordingly, the handover operations may not be directly used to provide robustness as imposed by this use case.

[0061] Different extensions/operation considerations may be used to enable a DMM solution meet the requirements of the robustness use case. Enhancements to the current DMM behavior may enable a faster tunnel setup between the previously connected D-GWs where the WTRU may be anchored and the current D-GW where the WTRU may have recently connected. The enhancements may be based on a pre-registration mechanism with neighbor D- GWs.

[0062] Figures 6A-6C show an example of a network-based DMM solution to provide robustness, described in terms of a system 600. The system 600 includes a MCN 602, several D-GWs 604a-c, and a WTRU 606. The MCN 602 includes a PGW 610 and a HSS 612 and communicates with the D-GWs 604a-c via a D-GW local interconnection 614. The D-GWs 604a-c communicate with the WTRU 606 via connections 616a-c.

[0063] Upon initial attachment of the WTRU 606 to D-GWl 604a, D-GWl

604a configures a distributed logical interface (ueldgwl) 620, delegates a locally anchored prefix (PrefA::/64), and advertises the prefix to the WTRU 606. The WTRU 606 configures (for normal operation) an IPv6 address (PrefA::UEl/64) out of a prefix locally anchored by D-GWl 604a (PrefA::/64). To allow the WTRU 606 to transmit and receive packets via other neighboring D-GWs, the D-GWs may transmit a pre-provisioning signaling message to neighboring D-GW2 604b and D-GW3 604c. For example, the signaling message may be a modified Proxy Binding Update (PBU) when using PMIPv6, or a modified Create Session Request when using GTP. If the solution uses the distributed logical interface concept, the signaling message may include the information required to set up the logical interface ueldgwl 620, a tunnel 630 (from D-GWl 604a to D-GW2 604b) and a tunnel 632 (from D-GWl 604A to D-GW3 604C) to redirect traffic if needed, as well as the prefix anchored at D-GWl 604a. The signaling message may be replied to with a Proxy Binding Acknowledgement/Create Session Response.

[0064] D-GWl 604a may determine the neighboring D-GWs by different means, such as consulting a database (such as the HSS 612 or a centralized local mobility anchor (LMA)), asking the WTRU 606 itself, using an Access Network Discovery and Selection Function (ANDSF), locally configuring the neighboring D-GWs, and the like. In this way, the required network elements may be pre- provisioned with the information required to forward traffic to the WTRU 606 using the prefix anchored at D-GWl 604a. If the WTRU 606 decides to fast attach with D-GW2 604b and begins transmitting traffic through D-GW2 604b, the time required to create the tunnel 630 to D-GW1 604a may be minimized, because the information to create the tunnel 630 is already known at D-GW2 604b. D-GW2 604b may not have to fetch the information from the network, for example, from the HSS 612.

[0065] In this example, the tunnel 630 may be created only after the handover (HO) is performed. An alternative is to create the tunnel 630 at pre- provisioning time but flag the tunnel 630 as "inactive" so that it may not be used before the HO is performed. Using this alternative, the tunnel 630 may need to be set as "active" once the HO is completed. In this case, the pre-provisioning signaling may be used to provide the information about the locally anchored prefix and associated distributed logical interface (DLIF) to the receiver of the PBU (or Create Session Request in case of GTP), instead of the other way around. Alternatively, flow mobility initiate (FMI)/flow mobility acknowledgement (FMA) signaling may be used.

[0066] If the WTRU 606 decides to attach to D-GW2 604b (as shown in

Figure 6B), D-GW2 604b may already be provisioned with the information to perform the operations (for example, logical interface creation, tunnel and routing set-up) to route traffic from the WTRU 606 using the PrefA::UEl/64 address. It may be necessary to create a tunnel 634 (from D-GW2 604b to D-GW1 604a) and a tunnel 636 (from D-GW2 604b to D-GW3 604c) or alternatively set the tunnels 634, 636 to "active" and let the D-GW2 604b neighbors know that the WTRU 606 is now attached to D-GW2 604b. This may be achieved by the signaling that D-GW2 604b transmits to the neighboring D-GWs (as D-GW1 604a did for the initial attachment of the WTRU 606). In this way, all the neighboring D-GWs may have the information to guarantee connectivity to the WTRU 606 if it later attaches to any of the neighboring D-GWs. In this process, D-GW2 604b may also advertise the locally anchored prefix (PrefB::/64) to the WTRU 606. Upon attachment of the WTRU 606 to D-GW2 604b, D-GW2 604b configures a distributed logical interface (ueldgw2) 622.

[0067] Similarly, if the WTRU 606 decides to attach to D-GW3 604c (as shown in Figure 6C), the process is analogous. D-GW3 604c allocates a prefix (PrefC::/64) to the WTRU, creates a tunnel 638 (from D-GW3 604c to D-GW1 604a) and a tunnel 640 (from D-GW3 604c to D-GW2 604b) where the WTRU 606 was attached, and informs the neighboring D-GWs of the new attachment. Upon attachment of the WTRU 606 to D-GW3 604c, D-GW3 604c configures a distributed logical interface (ueldgw3) 624.

[0068] Figures 7A and 7B show an example of a signaling sequence 700 of the network-based DMM robustness solution. The signaling sequence 700 is implemented between a WTRU 702, a first D-GW (D-GWl) 704, a second D-GW (D-GW2) 706, and a third D-GW (D-GW3) 708. The WTRU 702 completes its attachment to D-GWl 704 (step 710) and D-GWl 704 sets up a logical interface ueldgwl (step 712). D-GWl 704 sends a router advertisement with the address prefix PrefA::/64 to the WTRU 702 (step 714). The WTRU 702 then configures the address PrefA::UEl/64 and sets a default route via D-GWl 704 (step 716).

[0069] D-GWl 704 sends a pre-provisioning signaling message (for example, a modified Proxy Binding Update or a modified Create Session Request) to D-GW2 706 (step 718). D-GW2 replies to the pre-provisioning signaling message with a pre-provisioning signaling ACK (e.g., a Proxy Binding ACK or a Create Session Response; step 720). The logical interface ueldgwl is thereby created at D-GW2 706.

[0070] D-GWl 704 also sends a pre-provisioning signaling message to D-

GW3 708 (step 722). D-GW3 replies to the pre-provisioning signaling message with a pre-provisioning signaling ACK (e.g., a Proxy Binding ACK or a Create Session Response; step 724). The logical interface ueldgwl is thereby created at D-GW3 708. After receiving the replies from D-GW2 706 and D-GW3 708, the pre-provisioning signaling is complete (step 726) and data traffic begins flowing between the WTRU 702 and D-GWl 704 (step 728).

[0071] The WTRU 702 then switches to D-GW2 706 (step 730). Because the pre-provisioning signaling has already been completed, the handover from D- GW1 704 to D-GW2 706 (the WTRU 702 attaching to the D-GW2 706) is quickly completed (step 732). A tunnel between D-GWl 704 and D-GW2 706 is created using the pre-provisioning information (steps 734, 736). D-GW2 706 sends a pre- provisioning signaling message to D-GW3 708 to inform D-GW3 that the WTRU 702 is now attached to D-GW2 706 (step 738). Data traffic between the WTRU 702 and D-GW2 706 using the PrefA::UEl/64 address begins (step 740) and utilizes the tunnel between D-GW2 706 and D-GW1 704 (steps 742, 744).

[0072] Figures 7A and 7B show only the details of the pre-provisioning to ensure robustness of the sessions using the IPv6 address anchored at D-GW1 704. When the WTRU 702 moves, the DMM signaling used to provide IPv6 addresses anchored at the serving D-GWs may also be in place.

[0073] To minimize packet loss during the signaling sequence 700, the following actions may be performed. When a D-GW receives a binding signaling message (for example, a Proxy Binding Update/Create Session Request) from the currently serving D-GW, it may pre-allocate a prefix and logical interface configuration when there is no active session with the WTRU 702. The pre- provisioning may minimize the time required to create the session upon attachment of the WTRU. Some of the operations may involve contacting a centralized entity, such as the HSS, so performing operations proactively may help reduce the time required. When a D-GW detects that a WTRU has detached (using cross-layer interactions), it may begin buffering packets during a pre- configured period of time. If the WTRU attaches to a neighboring D-GW, the buffered packets may be transmitted immediately via the appropriate tunnel.

[0074] Figures 8A and 8B show an example of an offloading use case, described in terms of a system 800. The system 800 includes a MCN 802, several D-GWs 804a-c, and a multi-interfaced WTRU 806. The MCN 802 includes a PGW 810 and a HSS 812. The D-GWs 804a-c provide network services 814a-c, 816a-c and communicate with the WTRU 806 via connections 818a-c using a locally anchored prefix (PrefA::/64, PrefB::/64). Two different traffic flows 820a, 820b are shown. Traffic flow 820a flows through network service 814a, D-GW 804a, network service 816a, and connection 818a to WTRU 806. Similarly, traffic flow 820b flows through network service 814b, D-GW 804b, network service 816b, and connection 818b to WTRU 806.

[0075] In the offloading use case, the WTRU 806 may simultaneously attach to multiple D-GWs 804a, 804b. Figure 8A shows an example of normal operation, in which the WTRU 806 is attached to D-GW1 804a via one access technology (for example, LTE) and to D-GW2 804b via a different technology (for example, WLAN). Using a DMM solution, the WTRU 806 is provided with two different IPv6 prefixes (PrefA::/64 and PrefB::/64), each anchored at a different D-GW 804a, 804b.

[0076] This arrangement may be used to offload traffic from a loaded access network or to improve aggregated bandwidth by using several technologies simultaneously but by the same flow. Figure 8B shows that flow 820a (using PrefA::/64) is forwarded by D-GWl 804a via a tunnel 822 with D- GW2 804b so it is received by the WTRU 806 via the WLAN connection 818b instead of via the LTE connection 818a.

[0077] The different extensions to a network-based DMM solution may include the capability to offload some traffic from one potentially congested interface/path to another interface/path. This may be achieved by re-using the tunneling capability between D-GWs in the network. With these extensions, tunnels may be created between D-GWs with which the WTRU is directly connected, enabling IP flow mobility-type features.

[0078] Figures 9A and 9B show an example overview of DMM offloading, described in terms of a system 900. The system 900 includes a MCN 902, several D-GWs 904a-c, and a multi-interfaced WTRU 906. The MCN 902 includes a PGW 910 and a HSS 912 and communicates with the D-GWs 904a-c via a D-GW local interconnection 914. The D-GWs 904a-b communicate with the WTRU 906 via connections 916a-b. Two different traffic flows 920a, 920b are shown. Traffic flow 920a flows through D-GW 904a, a logical interface (ueldgwl) 922a, and connection 916a to the WTRU 906. Similarly, traffic flow 920b flows through D- GW 904b, a logical interface (ueldgw2) 922b, and connection 916b to the WTRU 906.

[0079] The WTRU 906, equipped with the logical interface capability, may attach to two different D-GWs (D-GWl 904a and D-GW2 904b), configuring two IPv6 addresses (PrefA::UEl/64 and PrefB::UEl/64), each locally anchored at the respective D-GW. This may be the normal operation of a network-based DMM solution. If one D-GW, for example, D-GWl 904a, detects congestion on its access link, it may want to offload some traffic to another access interface available on the WTRU 906. To do so, D-GWl 904a may first need to know that the WTRU 906 is simultaneously attached to D-GW2 904b, and then may need to negotiate with D-GW2 904b about the offloading.

[0080] D-GW1 904a may learn about other attachments of the WTRU 906 by consulting the HSS 912. D-GW1 904a may negotiate with D-GW2 904b by transmitting an extended Proxy Binding Update or an extended Create Session Request message, which may include information about the flow 920a that is requested to be offloaded. This may include only the IP flow information or may also include quality of service (QoS) parameters, so that the receiving D-GW may estimate the resources required by that flow. If D-GW2 904b accepts the flow offload, it replies to D-GW1 904a with a positive Proxy Binding Acknowledgement or a Create Session Response. If the solution uses the distributed logical interface concept, D-GW1 904a may trigger the set-up of the logical interface at D-GW2 904b (ueldgwl 922a), and a tunnel 924 between D- GW1 904a and D-GW2 904b, as well as the required routing state. After that, D- GW1 904a may begin forwarding packets of the offloaded flow 920a via the tunnel 924 between D-GW1 904a and D-GW2 904b.

[0081] On the WTRU side, the IP flow movement may be noticed and the uplink packets may be transmitted using the same interface as for the downlink packets. The explicit offloading request from D-GW1 904a may be required because in a DMM scenario, there is no centralized controlling data plane as in the non-DMM case, in which a central node (for example, a LMA/PGW) plays that role.

[0082] Figure 10 is an example of a signaling sequence 1000 of the network-based DMM offloading solution. The signaling sequence 1000 is implemented between a WTRU 1002, a first D-GW (D-GW1) 1004, a second D- GW (D-GW2) 1006, and a HSS 1008. The WTRU 1002 completes its attachment to D-GW1 1004 (step 1010) and D-GW1 1004 sets up a logical interface ueldgwl (step 1012). D-GW1 1004 sends a router advertisement with the address prefix PrefA::/64 to the WTRU 1002 (step 1014). The WTRU 1002 then configures the address PrefA::UEl/64 and sets a default route via D-GW1 1004 (step 1016).

[0083] When the WTRU 1002 attaches to D-GW2 1006 via a different interface (step 1018), D-GW2 1006 sets up a ueldgw2 logical interface (step 1020). D-GW2 1006 sends a router advertisement with the address prefix PrefB::/64 to the WTRU 1002 (step 1022). The WTRU 1002 then configures the address PrefB::UEl/64 and sets another default route via D-GW2 1006 (step 1024).

[0084] Data traffic may then begin between the WTRU 1002 and D-GWl

1004 via the ueldgwl logical interface (step 1026) and between the WTRU 1002 and D-GW2 1006 via the ueldgw2 logical interface (step 1028). If D-GWl 1004 detects congestion on the access network over the link with the WTRU 1002 (step 1030) or otherwise decides to offload this data traffic flow, then D-GWl 1004 checks with the HSS 1008 whether the WTRU 1002 is attached to another D-GW within the same network (step 1032). The HSS 1008 responds to D-GWl 1004 that the WTRU 1002 is also attached to D-GW2 1006 (step 1034). D-GWl 1004 sends an offloading signaling request message (for example, a modified Proxy Binding Update or a modified Create Session Request) to D-GW2 1006 (step 1036). D-GW2 1006 acknowledges the request message to D-GWl 1004 (step 1038) and sets up the ueldgwl logical interface at D-GW2 1006 (step 1040). Offloading of data traffic using the PrefA::UEl/64 address may begin (step 1042) between the WTRU 1002 and D-GW2 1006 and utilizes the tunnel between D- GW2 1006 and D-GWl 1004 in the network (steps 1044, 1046).

[0085] Figure 11 is an example of a split/aggregation use case, described in terms of a system 1100. The system 1100 includes a MCN 1102, several D-GWs 1104a-c, and a multi- interfaced WTRU 1106. The MCN 1102 includes a PGW 1110 and a HSS 1112. The D-GWs 1104a-c provide network services 1114a-c, 1116a-c and communicate with the WTRU 1106 via connections 1118a-c using a locally anchored prefix (PrefA::/64, PrefB::/64). A tunnel 1122 may be established between D-GWl 1104a and D-GW2 1104b. Two different traffic flows 1120a, 1120b are shown. Traffic flow 1120a flows through network service 1114a, D-GW 1104a, network service 1116a, and connection 1118a to WTRU 1106. Similarly, traffic flow 1120b flows through network service 1114b, D-GW 1104b, network service 1116b, and connection 1118b to WTRU 1106.

[0086] In the split/aggregation use case, the WTRU 1106 may simultaneously attach to multiple D-GWs 1104a, 1104b and may split flow 1120a over these different attachments, increasing the effective bandwidth. The WTRU 1106 is attached to D-GW1 1104a via one access technology (for example, LTE) and to D-GW2 1104b via a different technology (for example, WLAN). Using a DMM solution, the WTRU 1106 is provided with two different IPv6 prefixes (PrefA::/64 and PrefB::/64), each anchored at a different D-GW 1104a, 1104b. If flow 1120a requires a higher bandwidth than the one provided by any of the individual access technologies (i.e., LTE or WLAN) used by the WTRU 1106, the flow 1120a may be split over several attachment points and then aggregated in the network (at the D-GW anchoring the prefix used by the flow). Flow 1120a (using PrefA::/64) is split, so that part of flow 1120a is directly forwarded by D- GW1 1104a (the anchoring D-GW) over the LTE connection 1118a, and part of flow 1120a is forwarded via the tunnel 1122 to D-GW2 1104b, which then delivers the flow 1120a to the WTRU 1106 over the WLAN connection 1118b.

[0087] The different extensions to enable a network-based DMM solution may enable the WTRU to use multiple interfaces simultaneously. This may increase the available bandwidth to reach the WTRU, for example, between the D-GW and the WTRU. A D-GW which detects congestion on the interface to the WTRU may determine to redirect some IP packets to another D-GW where the WTRU is currently connected using another interface to offload the congested interface. The redirection may be done on a packet per packet basis (i.e., not per flow) and may be defined as aggregation. The possibility to create tunnels between the D-GWs, as described above, may be extended to permit this tunnel creation between currently connected D-GWs.

[0088] Figures 12A and 12B show an example overview of DMM split/aggregation, described in terms of a system 1200. The system 1200 includes a MCN 1202, several D-GWs 1204a-c, and a multi- interfaced WTRU 1206. The MCN 1202 includes a PGW 1210 and a HSS 1212 and communicates with the D- GWs 1204a-c via a D-GW local interconnection 1214. The D-GWs 1204a-b communicate with the WTRU 1206 via connections 1216a-b. Two different traffic flows 1220a, 1220b are shown. Traffic flow 1220a flows through D-GW 1204a, a logical interface (ueldgwl) 1222a, and connection 1216a to the WTRU 1206. Similarly, traffic flow 1220b flows through D-GW 1204b, a logical interface (ueldgw2) 1222b, and connection 1216b to the WTRU 1206.

[0089] The logical interface ueldgwl 1222a (which may hide the use of different physical interfaces from the IP layer) enables the WTRU 1206 to transmit/receive packets belonging to the same flow over different accesses. The D-GW that anchors the flow 1220a that is to be split (D-GWl 1204a) may have to signal the D-GW(s) that may also participate in forwarding the packets belonging to flow 1220a, for example, D-GW2 1204b.

[0090] If D-GWl 1204a detects congestion on its access link, it may want to split some of the traffic from flow 1220a to another access interface available on the WTRU 1206. If the solution uses the distributed logical interface concept, D- GW1 1204a may trigger the set-up of the logical interface ueldgwl 1222a at D- GW2 1204b , and a tunnel 1224 between D-GWl 1204a and D-GW2 1204b, as well as the required routing state. After that, D-GWl 1204a may begin forwarding packets of the split flow 1220a via the tunnel 1224 between D-GWl 1204a and D-GW2 1204b.

[0091] Once the network state has been set-up, the anchoring D-GWl

1204a and the WTRU 1206 need to be coordinated. Both D-GWl 1204a and the WTRU 1206 may use a consistent forwarding policy for uplink and downlink packets, in terms of which packets are transmitted via which D-GW. For downlink packets, the anchoring D-GW may forward the packets toward the appropriate D-GW (or locally sending them), while for uplink packets, the WTRU may forward the packets toward the appropriate D-GW. The decision of how to split traffic may impact overall network performance. For example, TCP traffic may be negatively impacted if the split is not done properly, due to the differences in network delay, packet re-ordering, and the like. Any approaches considered for a non-DMM case may apply here without changes.

[0092] Figure 13 is an example of a signaling sequence 1300 of the network-based DMM flow/split aggregation solution. The signaling sequence 1300 is implemented between a WTRU 1302, a first D-GW (D-GWl) 1304, a second D-GW (D-GW2) 1306, and a HSS 1308. The WTRU 1302 completes its attachment to D-GWl 1304 (step 1310) and D-GWl 1304 sets up a logical interface ueldgwl (step 1312). D-GWl 1304 sends a router advertisement with the address prefix PrefA::/64 to the WTRU 1302 (step 1314). The WTRU 1302 then configures the address PrefA::UEl/64 and sets a default route via D-GWl 1304 (step 1316).

[0093] When the WTRU 1302 attaches to D-GW2 1306 via a different interface (step 1318), D-GW2 1306 sets up a ueldgw2 logical interface (step 1320). D-GW2 1306 sends a router advertisement with the address prefix PrefB::/64 to the WTRU 1302 (step 1322). The WTRU 1302 then configures the address PrefB::UEl/64 and sets another default route via D-GW2 1306 (step 1324).

[0094] Data traffic may then begin between the WTRU 1302 and D-GWl

1304 via the ueldgwl logical interface (step 1326) and between the WTRU 1302 and D-GW2 1306 via the ueldgw2 logical interface (step 1328). If D-GWl 1304 decides to split a flow, for example, due to congestion on the access network over the link with the WTRU 1302 (step 1330), D-GWl 1304 checks with the HSS 1308 whether the WTRU 1302 is attached to another D-GW within the same network (step 1332). The HSS 1308 responds to D-GWl 1304 that the WTRU 1302 is also attached to D-GW2 1306 (step 1334). D-GWl 1304 sends a flow split signaling request message (for example, a modified Proxy Binding Update or a modified Create Session Request) to D-GW2 1306 (step 1336). D-GW2 1306 acknowledges the request message to D-GWl 1304 (step 1338) and sets up the ueldgwl logical interface at D-GW2 1306 (step 1340). A portion of the data traffic of the split flow (X%) is kept between the WTRU 1302 and D-GWl 1304 (step 1342). The remaining portion of the data traffic of the split flow (100-X%) using the PrefA::UEl/64 address begins (step 1344) between the WTRU 1302 and D-GW2 1306 and utilizes the tunnel between D-GW2 1306 and D-GWl 1304 (steps 1346, 1348).

[0095] Regarding the anchoring coordination between the D-GW(s) and the

WTRU, two main approaches may be followed. For WTRU-controlled aggregation, the WTRU may determine to initiate aggregation and control how the packets are split. The WTRU may convey the information to one serving D- GW using Layer 2- specific signaling or by extending IPv6 signaling (for example, neighbor discovery). The serving D-GW receiving this information may forward it to the anchoring D-GW. For anchoring D-GW controlled aggregation, the network may control the aggregation conveys the information to the WTRU. This may be done via a serving D-GW, using Layer 2-specific signaling or by extending IPv6 signaling.

[0096] Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element may be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a non-transitory computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and non-transitory computer-readable storage media. Examples of non-transitory computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

EMBODIMENTS

[0097] 1. A method for providing robustness in distributed mobility management includes attaching a wireless transmit/receive unit (WTRU) to a first distributed gateway (D-GW) via an interface.

[0098] 2. The method of embodiment 1, further including pre- provisioning a tunnel between the first D-GW and a second D-GW.

[0099] 3. The method of embodiments 1 or 2, further including attaching the WTRU to the second D-GW and detaching the WTRU from the first D-GW. [0100] 4. The method of any one of embodiments 1-3, further including creating the tunnel between the first D-GW and the second D-GW that was pre- provisioned.

[0101] 5. The method of any one of embodiments 1-4, further including sending data traffic between the WTRU and the first D-GW via the interface on the second D-GW and using the tunnel between the first D-GW and the second D-GW.

[0102] 6. The method of any one of embodiments 1-5, wherein the interface is a logical interface.

[0103] 7. The method of any one of embodiments 1-6, wherein the pre- provisioning includes sending a first signaling message from the first D-GW to the second D-GW.

[0104] 8. The method of embodiment 7, wherein the pre-provisioning further includes receiving a second signaling message at the first D-GW from the second D-GW in response to the signaling message.

[0105] 9. The method of embodiments 7 or 8, wherein on a condition that proxy mobile Internet protocol is being used, the first signaling message includes a modified proxy binding update message.

[0106] 10. The method of embodiment 9, wherein the second signaling message includes a proxy binding acknowledgement.

[0107] 11. The method of embodiments 7 or 8, wherein on a condition that general packet radio service tunneling protocol is being used, the first signaling message includes a modified create session request message.

[0108] 12. The method of embodiment 11, wherein the second signaling message includes a create session response message.

[0109] 13. A method for offloading a data traffic flow in distributed mobility management includes attaching a wireless transmit/receive unit (WTRU) to a first distributed gateway (D-GW) via a first interface.

[0110] 14. The method of embodiment 13, further including attaching the WTRU to a second D-GW via a second interface, wherein the second interface is different from the first interface. [0111] 15. The method of embodiments 13 or 14, further including sending a first data traffic flow between the WTRU and the first D-GW via the first interface.

[0112] 16. The method of any one of embodiments 13-15, further including sending a second data traffic flow between the WTRU and the second D-GW via the second interface.

[0113] 17. The method of any one of embodiments 13-16, wherein on a condition that the first D-GW decides to offload the first data traffic flow, the method further includes creating a tunnel between the first D-GW and the second D-GW.

[0114] 18. The method of embodiment 17, further including sending the first data traffic flow between the first D-GW and the WTRU via the second D- GW using the tunnel and via the second interface.

[0115] 19. The method of any one of embodiments 13-18, wherein the first interface and the second interface are logical interfaces.

[0116] 20. The method of any one of embodiments 13-19, wherein the creating includes the first D-GW checking with a home subscriber server (HSS) to determine whether the WTRU is attached to another D-GW.

[0117] 21. The method of embodiment 20, wherein the creating further includes receiving a response at the first D-GW from the HSS that the WTRU is attached to the second D-GW.

[0118] 22. The method of embodiment 21, wherein the creating further includes sending an offloading signaling request message from the first D-GW to the second D-GW.

[0119] 23. The method of embodiment 22, wherein the creating further includes receiving an offloading signaling response message at the first D-GW from the second D-GW in response to the offloading signaling request message.

[0120] 24. The method of embodiments 22 or 23, wherein on a condition that proxy mobile Internet protocol is being used, the offloading signaling request message includes a modified proxy binding update message.

[0121] 25. The method of embodiment 24, wherein the offloading signaling response message includes a proxy binding acknowledgement. [0122] 26. The method of embodiments 22 or 23, wherein on a condition that general packet radio service tunneling protocol is being used, the offloading signaling request message includes a modified create session request message.

[0123] 27. The method of embodiment 26, wherein the offloading signaling response message includes a create session response message.

[0124] 28. A method for splitting a data traffic flow in distributed mobility management includes attaching a wireless transmit/receive unit (WTRU) to a first distributed gateway (D-GW) via a first interface.

[0125] 29. The method of embodiment 28, further including attaching the WTRU to a second D-GW via a second interface, wherein the second interface is different from the first interface.

[0126] 30. The method of embodiments 28 or 29, further including sending a first data traffic flow between the WTRU and the first D-GW via the first interface.

[0127] 31. The method of any one of embodiments 28-30, further including sending a second data traffic flow between the WTRU and the second D-GW via the second interface.

[0128] 32. The method of any one of embodiments 28-31, wherein on a condition that the first D-GW decides to split the first data traffic flow, the method further includes creating a tunnel between the first D-GW and the second D-GW.

[0129] 33. The method of embodiment 32, further including sending a first percentage of the first data traffic flow between the WTRU and the first D- GW via the first interface.

[0130] 34. The method of embodiment 33, further including sending a second percentage of the first data traffic flow between the WTRU and the first D-GW via the second interface and the second D-GW and using the tunnel to reach the first D-GW.

[0131] 35. The method of any one of embodiments 28-34, wherein the first interface and the second interface are logical interfaces. [0132] 36. The method of any one of embodiments 28-35, wherein the creating includes the first D-GW checking with a home subscriber server (HSS) to determine whether the WTRU is attached to another D-GW.

[0133] 37. The method of embodiment 36, wherein the creating further includes receiving a response at the first D-GW from the HSS that the WTRU is attached to the second D-GW.

[0134] 38. The method of embodiment 37, wherein the creating further includes sending a flow split signaling request message from the first D-GW to the second D-GW.

[0135] 39. The method of embodiment 38, wherein the creating further includes receiving a flow split signaling response message at the first D-GW from the second D-GW in response to the flow split signaling request message.

[0136] 40. The method of embodiments 38 or 39, wherein on a condition that proxy mobile Internet protocol is being used, the flow split signaling request message includes a modified proxy binding update message.

[0137] 41. The method of embodiment 40, wherein the flow split signaling response message includes a proxy binding acknowledgement.

[0138] 42. The method of embodiments 38 or 39, wherein on a condition that general packet radio service tunneling protocol is being used, the flow split signaling request message includes a modified create session request message.

[0139] 43. The method of embodiment 42, wherein the flow split signaling response message includes a create session response message.

Claims

CLAIMS What is claimed is:

1. A method for providing robustness in distributed mobility management, comprising:

attaching a wireless transmit/receive unit (WTRU) to a first distributed gateway (D-GW) via an interface;

pre-provisioning a tunnel between the first D-GW and a second D-GW; attaching the WTRU to the second D-GW and detaching the WTRU from the first D-GW;

creating the tunnel between the first D-GW and the second D-GW that was pre-provisioned; and

sending data traffic between the WTRU and the first D-GW via the interface on the second D-GW and using the tunnel between the first D-GW and the second D-GW, thereby providing robustness.

2. The method according to claim 1, wherein the interface is a logical interface.

3. The method according to claim 1, wherein the pre-provisioning includes:

sending a first signaling message from the first D-GW to the second D- GW; and

receiving a second signaling message at the first D-GW from the second D- GW in response to the signaling message.

4. The method according to claim 3, wherein on a condition that proxy mobile Internet protocol is being used,

the first signaling message includes a modified proxy binding update message; and

the second signaling message includes a proxy binding acknowledgement.

5. The method according to claim 3, wherein on a condition that general packet radio service tunneling protocol is being used,

the first signaling message includes a modified create session request message; and

the second signaling message includes a create session response message.

6. A method for offloading a data traffic flow in distributed mobility management, comprising:

attaching a wireless transmit/receive unit (WTRU) to a first distributed gateway (D-GW) via a first interface;

attaching the WTRU to a second D-GW via a second interface, wherein the second interface is different from the first interface;

sending a first data traffic flow between the WTRU and the first D-GW via the first interface;

sending a second data traffic flow between the WTRU and the second D- GW via the second interface;

on a condition that the first D-GW decides to offload the first data traffic flow,

creating a tunnel between the first D-GW and the second D-GW; and

sending the first data traffic flow between the first D-GW and the WTRU via the second D-GW using the tunnel and via the second interface, thereby offloading the first data traffic flow from the first D-GW to the second D- GW.

7. The method according to claim 6, wherein the first interface and the second interface are logical interfaces.

8. The method according to claim 6, wherein the creating includes: the first D-GW checking with a home subscriber server (HSS) to determine whether the WTRU is attached to another D-GW; receiving a response at the first D-GW from the HSS that the WTRU is attached to the second D-GW;

sending an offloading signaling request message from the first D-GW to the second D-GW; and

receiving an offloading signaling response message at the first D-GW from the second D-GW in response to the offloading signaling request message.

9. The method according to claim 8, wherein on a condition that proxy mobile Internet protocol is being used,

the offloading signaling request message includes a modified proxy binding update message; and

the offloading signaling response message includes a proxy binding acknowledgement.

10. The method according to claim 8, wherein on a condition that general packet radio service tunneling protocol is being used,

the offloading signaling request message includes a modified create session request message; and

the offloading signaling response message includes a create session response message.

11. A method for splitting a data traffic flow in distributed mobility management, comprising:

attaching a wireless transmit/receive unit (WTRU) to a first distributed gateway (D-GW) via a first interface;

attaching the WTRU to a second D-GW via a second interface, wherein the second interface is different from the first interface;

sending a first data traffic flow between the WTRU and the first D-GW via the first interface;

sending a second data traffic flow between the WTRU and the second D- GW via the second interface; on a condition that the first D-GW decides to split the first data traffic flow,

creating a tunnel between the first D-GW and the second D-GW; sending a first percentage of the first data traffic flow between the WTRU and the first D-GW via the first interface; and

sending a second percentage of the first data traffic flow between the WTRU and the first D-GW via the second interface and the second D-GW and using the tunnel to reach the first D-GW, thereby splitting the first data traffic flow between the first D-GW and the second D-GW.

12. The method according to claim 11, wherein the first interface and the second interface are logical interfaces.

13. The method according to claim 11, wherein the creating includes: the first D-GW checking with a home subscriber server (HSS) to determine whether the WTRU is attached to another D-GW;

receiving a response at the first D-GW from the HSS that the WTRU is attached to the second D-GW;

sending a flow split signaling request message from the first D-GW to the second D-GW; and

receiving a flow split signaling response message at the first D-GW from the second D-GW in response to the flow split signaling request message.

14. The method according to claim 13, wherein on a condition that proxy mobile Internet protocol is being used,

the flow split signaling request message includes a modified proxy binding update message; and

the flow split signaling response message includes a proxy binding acknowledgement.

15. The method according to claim 13, wherein on a condition that general packet radio service tunneling protocol is being used, the flow split signaling request message includes a modified create session request message; and

the flow split signaling response message includes a create session response message.