WO2014008427A1

WO2014008427A1 - Systems and methods for pre-registration to enable mobility management

Info

Publication number: WO2014008427A1
Application number: PCT/US2013/049372
Authority: WO
Inventors: Michelle Perras; Carlos Jesus BERNARDOS; Juan Carlos Zuniga; Prabhakar Chitrapu; Alexander Reznik; John L. Tomici
Original assignee: Interdigital Patent Holdings, Inc.
Priority date: 2012-07-05
Filing date: 2013-07-03
Publication date: 2014-01-09
Also published as: TW201434339A

Abstract

Systems and methods for evolving a local gateway (L-GW) to distributed mobility management (DMM) (e.g. implementing a L-GW in DMM) may be provided such that mobility support may be provided between L-GWs and'or LHNs. For example, a WTRU may be able to maintain session continuity when handing over between L-GWs that may be included or may be a pari of different LHNs.

Description

SYSTEMS AND METHODS FOR PRE-REGISTRATION TO ENABLE MOBILITY

MANAGEMENT

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 61/668,129, filed on July 05, 2012, and U.S. Provisional Application No. 61/668,257, filed on July 05, 2012. The contents of which are hereby incorporated by reference in their entirety. BACKGROUND

[0002] Currently, a local gateway (L-GW) may be used to allocate an Internet Protocol (IP) address to a wireless transmit receive unit (WTRU) and/or to support LIPA Home eNodeBs (H(e)NBs) in a local home network (LHN). For example, a L-GW may allocate an IP address to a WTRU where the IP address may be associated with an IP flow. Additionally, LIPA mobility may be supported by a current L-GW within a LHN network. In such embodiments, the WTRU may maintain session continuity when handing over or during a handover to different H(e)NBs that are part of the same LHN. Unfortunately, if a UE may move out of a network coverage area of one LHN and/or may wish to move to a L-GW in a different LHN, the current IP flow or LIPA session associated with the UE may be released. As such, using current L-GWs, the UE may not be able to maintain session continuity when handing over or during a handover to L- GWs, for example, in different LHNs. SUMMARY

[0003] Systems and methods for enabling a WTRU and/or a local gateway (L-GW) to support distributed mobility management (DMM) (e.g. implementing a L-GW in DMM) may be provided such that IP flow and/or mobility support may be enabled between L-GWs and/or LHNs. For example, a WTRU may be able to maintain session continuity when handing over between L-GWs that may be included in or may be a part of different LHNs. [0004] For example, a method for providing distributed mobility management (DMM) to enable session connectivity to be maintained may be provided. In such an embodiment, at a local gateway (L-GW), a connection with a wireless transmit receive unit (WTRU) that may have relocated from a different network component associated with a different L-GW may be established. Additionally, at the local gateway (L-GW), a binding entry in a binding table for the WTRU may be created and an Internet Protocol (IP) address for the WTRU associated with the L-GW may be allocated. A tunnel with the different L-GW from which the WTRU relocated may also be created and the IP address allocated by the L-GW and at least an indication of at least one IP addresses that may be deprecating may be sent from the L-GW to the WTRU.

[0005] Additionally, a wireless transmit receive unit (WTRU) configured to provide distributed mobility management (DMM) to enable session connectivity to be maintained may be provided. the WTRU may configured to establish a connection with a network component in a local gateway (L-GW) via an IP address allocated by the L-GW, determine whether the WTRU may further be connected to another L-GW, and/or create a tunnel with the other L-GW to maintain session continuity for flows associated with an IP address allocated to the WTRU by the other L-GW.

[0006] In an additional embodiment, a method for providing distributed mobility management (DMM) to enable session connectivity to be maintained may be provided. At a local gateway (L-GW), a connection with a wireless transmit receive unit (WTRU) via a network component and a connection with a mobility management entity (MME)– serving gateway (SGW) proxy may be established. Furthermore, via the L-GW, an Internet Protocol (IP) address may be allocated for the WTRU associated with the L-GW using the MME-SGW proxy such that the core network may not be involved in the allocation. The IP address may be registered with an ANDSF server.

[0007] Additionally, a local gateway (L-GW) for providing distributed mobility management (DMM) to enable session connectivity to be maintained may be provided. The L-GW may be configured to determine whether one or more other L-GWs may be neighbors. Based on such a determination, the L-GW may be configured to pre-register a wireless transmit receive unit (WTRU) connected to the L-GW with the one or more L-GWs that are neighbors and may further be configured to create a tunnel between the L-GW and the one or more other L-GWs that are neighbors based on the pre-registration to maintain session continuity during a handover.

[0008] The Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, not is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to any limitations that solve any or all disadvantages noted in any part of this disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0010] FIG. 1A depicts a diagram of an example communications system in which one or more disclosed embodiments may be implemented.

[0011] FIG. 1B depicts a system diagram of an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A.

[0012] FIG. 1C depicts a system diagram of an example radio access network and an example core network that may be used within the communications system illustrated in FIG. 1A.

[0013] FIG. 1D depicts a system diagram of another example radio access network and an example core network that may be used within the communications system illustrated in FIG. 1A.

[0014] FIG. 1E depicts a system diagram of another example radio access network and an example core network that may be used within the communications system illustrated in FIG. 1A.

[0015] FIG. 2 illustrates an example of supporting mobility between L-GWs based on a mobility management repository (MMR).

[0016] FIG. 3 illustrates an example of mobility from a first L-GW to a second L-GW using a network-based DMM approach after a WTRU has established an IP address at the first L-GW.

[0017] FIG. 4 illustrates an example of mobility from a second L-GW to a third L-GW using a network-based DMM approach after a WTRU has established an IP address at the second L- GW and a first L-GW.

[0018] FIG. 5 illustrates an example of releasing a deprecating IP address using a network- based approach to DMM.

[0019] FIG. 6 illustrates an example of supporting mobility between L-GWs based on a client-based DMM approach.

[0020] FIG. 7 illustrates an example of mobility from a first L-GW to a second L-GW using a client-based DMM approach after a WTRU has established an IP address at the first L-GW. [0021] FIG. 8 illustrates an example of mobility from a second L-GW to a third L-GW using a client-based DMM approach after a WTRU has established an IP address at the second L-GW and a first L-GW.

[0022] FIG. 9 illustrates an example of releasing a deprecating IP address using a client- based approach to DMM.

[0023] FIG. 10 illustrates an example joint MME and SGW Proxy that may be used to provide DMM session continuity in a 3GPP network.

[0024] FIG. 11 depicts an example embodiment of an architecture for LIPA mobility.

[0025] FIG. 12 depicts an example embodiment of LIPA mobility with a stand-alone L-GW.

[0026] FIG. 13 depicts an example embodiment of LIPA mobility between LHNs that may be connected to the same PDN.

[0027] FIG. 14 depicts an example embodiment of LIPA mobility between LHNs that may be connected to different PDNs.

[0028] FIG. 15 depicts an example embodiment of a tunnel that may be created between L- GWs to enable mobility.

[0029] FIG. 16 depicts an example embodiment of mobility between L-GWs based on neighboring information (e.g. a first stage or process).

[0030] FIG. 17 depicts an example embodiment of mobility between L-GWs based on neighboring information (e.g. a second stage or process).

[0031] FIG. 18 depicts an example embodiment of mobility between L-GWs based on neighboring information (e.g. a third stage or process).

[0032] FIG. 19 depicts an example embodiment of mobility between L-GWs based on neighboring information (e.g. a UE that may go back).

[0033] FIG. 20 depicts an example embodiment of mobility between L-GWs based on neighboring information (e.g. a tunnel lifetime). DETAILED DESCRIPTION

[0034] A detailed description of illustrative embodiments will now be described with reference to the various Figures. Although this description provides a detailed example of possible implementations, it should be noted that the details are intended to be exemplary and in no way limit the scope of the application.

[0035] Systems and methods for implementing a WTRU and/or a L-GW that may support distributed mobility management (DMM) may be provided such that mobility including LIPA mobility support may be enabled between L-GWs and/or LHNs. For example, in embodiments described herein, a WTRU may be able to maintain session continuity when handing over between L-GWs that may be included or may be a part of different LHNs.

[0036] FIG. 1A depicts a diagram of an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 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.

[0037] As shown in FIG. 1A, the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, and/or 102d (which generally or collectively may be referred to as WTRU 102), a radio access network (RAN) 103/104/105, a core network 106/107/109, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, 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 102a, 102b, 102c, and/or 102d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, and/or 102d 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.

[0038] The communications systems 100 may also include a base station 114a and a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, and/or 102d to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, and/or the networks 112. By way of example, the base stations 114a and/or 114b 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 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

[0039] The base station 114a may be part of the RAN 103/104/105, 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 114a and/or the base station 114b 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 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one for each sector of the cell. In another embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.

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

[0041] More specifically, as noted above, the communications system 100 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 114a in the RAN 103/104/105 and the WTRUs 102a, 102b, and/or 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115/116/117 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).

[0042] In another embodiment, the base station 114a and the WTRUs 102a, 102b, and/or 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E- UTRA), which may establish the air interface 115/116/117 using Long Term Evolution (LTE) and/or LTE-Advanced (LTE-A).

[0043] In other embodiments, the base station 114a and the WTRUs 102a, 102b, and/or 102c may implement radio technologies such as IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA20001X, 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.

[0044] The base station 114b in FIG. 1A 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 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d 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 114b and the WTRUs 102c, 102d may utilize a cellular- based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell. As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the core network 106/107/109.

[0045] The RAN 103/104/105 may be in communication with the core network 106/107/109, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, and/or 102d. For example, the core network 106/107/109 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 FIG. 1A, it will be appreciated that the RAN 103/104/105 and/or the core network 106/107/109 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 103/104/105 or a different RAT. For example, in addition to being connected to the RAN 103/104/105, which may be utilizing an E-UTRA radio technology, the core network

106/107/109 may also be in communication with another RAN (not shown) employing a GSM radio technology.

[0046] The core network 106/107/109 may also serve as a gateway for the WTRUs 102a, 102b, 102c, and/or 102d to access the PSTN 108, the Internet 110, and/or other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 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 112 may include wired or wireless

communications networks owned and/or operated by other service providers. For example, the networks 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 103/104/105 or a different RAT.

[0047] Some or all of the WTRUs 102a, 102b, 102c, and/or 102d in the communications system 100 may include multi-mode capabilities, i.e., the WTRUs 102a, 102b, 102c, and/or 102d may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0048] FIG. 1B depicts a system diagram of an example WTRU 102. As shown in FIG. 1B, the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It will be appreciated that the WTRU 102 may include any sub- combination of the foregoing elements while remaining consistent with an embodiment. Also, embodiments contemplate that the base stations 114a and 114b, and/or the nodes that base stations 114a and 114b may represent, such as but not limited to transceiver station (BTS), a Node-B, a site controller, an access point (AP), a home node-B, an evolved home node-B (eNodeB), a home evolved node-B (HeNB), a home evolved node-B gateway, and proxy nodes, among others, may include some or all of the elements depicted in FIG. 1B and described herein.

[0049] The processor 118 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 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the

transmit/receive element 122. While FIG. 1B depicts the processor 118 and the transceiver 120 as separate components, it may be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0050] The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 115/116/117. For example, in one embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In another embodiment, the transmit/receive element 122 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 122 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals. [0051] In addition, although the transmit/receive element 122 is depicted in FIG. 1B as a single element, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115/116/117.

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

[0053] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 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 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0054] The processor 118 may receive power from the power source 134, and may be configured to distribute and/or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 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.

[0055] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 115/116/117 from a base station (e.g., base stations 114a, 114b) 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 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0056] The processor 118 may further be coupled to other peripherals 138, 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 138 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.

[0057] FIG. 1C depicts a system diagram of the RAN 103 and the core network 106 according to an embodiment. As noted above, the RAN 103 may employ a UTRA radio technology to communicate with the WTRUs 102a, 102b, and/or 102c over the air interface 115. The RAN 103 may also be in communication with the core network 106. As shown in FIG. 1C, the RAN 103 may include Node-Bs 140a, 140b, and/or 140c, which may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and/or 102c over the air interface 115. The Node-Bs 140a, 140b, and/or 140c may each be associated with a particular cell (not shown) within the RAN 103. The RAN 103 may also include RNCs 142a and/or 142b. It will be appreciated that the RAN 103 may include any number of Node-Bs and RNCs while remaining consistent with an embodiment.

[0058] As shown in FIG. 1C, the Node-Bs 140a and/or 140b may be in communication with the RNC 142a. Additionally, the Node-B 140c may be in communication with the RNC142b. The Node-Bs 140a, 140b, and/or 140c may communicate with the respective RNCs 142a, 142b via an Iub interface. The RNCs 142a, 142b may be in communication with one another via an Iur interface. Each of the RNCs 142a, 142b may be configured to control the respective Node- Bs 140a, 140b, and/or 140c to which it is connected. In addition, each of the RNCs 142a, 142b may be configured to carry out or support other functionality, such as outer loop power control, load control, admission control, packet scheduling, handover control, macrodiversity, security functions, data encryption, and the like.

[0059] The core network 106 shown in FIG. 1C may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and/or a gateway GPRS support node (GGSN) 150. While each of the foregoing elements are depicted as part of the core network 106, 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. [0060] The RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an IuCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, and/or 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and/or 102c and traditional land-line communications devices.

[0061] The RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 may be connected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, and/or 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between and the WTRUs 102a, 102b, and/or 102c and IP-enabled devices.

[0062] As noted above, the core network 106 may also be connected to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0063] FIG. 1D depicts a system diagram of the RAN 104 and the core network 107 according to an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, and/or 102c over the air interface 116. The RAN 104 may also be in communication with the core network 107.

[0064] The RAN 104 may include eNode-Bs 160a, 160b, and/or 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, and/or 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and/or 102c over the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, and/or 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

[0065] Each of the eNode-Bs 160a, 160b, and/or 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and/or downlink, and the like. As shown in FIG. 1D, the eNode-Bs 160a, 160b, and/or 160c may communicate with one another over an X2 interface.

[0066] The core network 107 shown in FIG. 1D may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. While each of the foregoing elements are depicted as part of the core network 107, 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. [0067] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, and/or 160c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, and/or 102c, bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, and/or 102c, and the like. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

[0068] The serving gateway 164 may be connected to each of the eNode-Bs 160a, 160b, and/or 160c in the RAN 104 via the S1 interface. The serving gateway 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, and/or 102c. The serving gateway 164 may also perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, and/or 102c, managing and storing contexts of the WTRUs 102a, 102b, and/or 102c, and the like.

[0069] The serving gateway 164 may also be connected to the PDN gateway 166, which may provide the WTRUs 102a, 102b, and/or 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, and/or 102c and IP-enabled devices.

[0070] The core network 107 may facilitate communications with other networks. For example, the core network 107 may provide the WTRUs 102a, 102b, and/or 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and/or 102c and traditional land-line communications devices. For example, the core network 107 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the core network 107 and the PSTN 108. In addition, the core network 107 may provide the WTRUs 102a, 102b, and/or 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0071] FIG. 1E depicts a system diagram of the RAN 105 and the core network 109 according to an embodiment. The RAN 105 may be an access service network (ASN) that employs IEEE 802.16 radio technology to communicate with the WTRUs 102a, 102b, and/or 102c over the air interface 117. As will be further discussed below, the communication links between the different functional entities of the WTRUs 102a, 102b, and/or 102c, the RAN 105, and the core network 109 may be defined as reference points.

[0072] As shown in FIG. 1E, the RAN 105 may include base stations 180a, 180b, and/or 180c, and an ASN gateway 182, though it will be appreciated that the RAN 105 may include any number of base stations and ASN gateways while remaining consistent with an embodiment. The base stations 180a, 180b, and/or 180c may each be associated with a particular cell (not shown) in the RAN 105 and may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and/or 102c over the air interface 117. In one embodiment, the base stations 180a, 180b, and/or 180c may implement MIMO technology. Thus, the base station 180a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a. The base stations 180a, 180b, and/or 180c 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 182 may serve as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 109, and the like.

[0073] The air interface 117 between the WTRUs 102a, 102b, and/or 102c and the RAN 105 may be defined as an R1 reference point that implements the IEEE 802.16 specification. In addition, each of the WTRUs 102a, 102b, and/or 102c may establish a logical interface (not shown) with the core network 109. The logical interface between the WTRUs 102a, 102b, and/or 102c and the core network 109 may be defined as an R2 reference point, which may be used for authentication, authorization, IP host configuration management, and/or mobility management.

[0074] The communication link between each of the base stations 180a, 180b, and/or 180c 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 180a, 180b, and/or 180c and the ASN gateway 182 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 102a, 102b, and/or 102c.

[0075] As shown in FIG. 1E, the RAN 105 may be connected to the core network 109. The communication link between the RAN 105 and the core network 109 may defined as an R3 reference point that includes protocols for facilitating data transfer and mobility management capabilities, for example. The core network 109 may include a mobile IP home agent (MIP-HA) 184, an authentication, authorization, accounting (AAA) server 186, and a gateway 188. While each of the foregoing elements are depicted as part of the core network 109, 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.

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

[0077] Although not shown in FIG. 1E, it should, may, and/or will be appreciated that the RAN 105 may be connected to other ASNs and the core network 109 may be connected to other core networks. The communication link between the RAN 105 the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating the mobility of the WTRUs 102a, 102b, and/or 102c between the RAN 105 and the other ASNs. The

communication link between the core network 109 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.

[0078] Described herein are systems, methods, and/or architectures for enabling distributed mobility management (DMM). For example, mobility anchors, which may be referred to as distributed gateways (D-GWs), may be placed and/or located closer to a user and may distribute the control and data infrastructures among entities located at the edge of an access network. Additionally, to support session mobility between the D-GWs, tunnels may be created.

According to an example embodiment, a Home Subscriber Server (HSS) may be used to store and/or keep track of information used for tunnel creation. Both network-based systems, methods, and/or architectures and client-based systems, methods, and/or architectures may be provided and/or used to enable DMM (e.g., the tunnels) as described herein. Additionally, the systems, methods, and/or architectures described herein may specify when the tunnels may be to be closed.

[0079] For example, in an embodiment, local gateways (L-GWs) may include functionality to support DMM. For example, L-GWs may be configured to ensure that WTRUs are able to maintain session continuity when handing over between L-GWs that are part of different local home networks (LHNs). The network-based methods and architectures described herein may be based on a Mobility Management Repository (MMR). The client-based methods and

architectures may also be described.

[0080] According to example embodiments, the systems, methods, and/or architectures disclosed herein may enable DMM by defining evolving the L-GW capabilities, for example, to support mobility between L-GWs and/or LHNs. Additionally, the systems, methods, and/or architectures disclosed herein, although described with reference to L-GWs, may be applicable to any anchor GW involved in DMM, for example one or more of D-GWs, PDN gateways (PGWs), and/or the like.

[0081] As described herein, WTRU mobility between L-GWs may be enabled including systems, methods, and/or architectures that may provide network-based DMM support, may enhance WTRU capabilities, and/or may enhance L-GW capabilities may be disclosed. For example, to support network-based DMM, L-GW capabilities may be provided and/or extended by creating and/or adding one or more tunnels toward or to other L-GWs. The tunnels may be used to enable session continuity when a WTRU may move between different components and/or different LHNs. In such an embodiment, a tunnel lifetime may be determined for handling a termination of a tunnel. Additionally, an MMR associated with the network (e.g., core network) may be introduced such that session continuity may be enabled or maintained between L-GWs (e.g., anchor nodes) by making use of the MMR. Furthermore, local mobility anchor (LMA) and media access gateway (MAG) functionalities may be combined within a single L-GW as described herein (e.g., to support network based-DMM).

[0082] Additionally, WTRU mobility between L-GWs may be enabled. For example, methods and systems that may provide client-based DMM support are disclosed. For example, to support client-based DMM, L-GW capabilities may be provided and/or extended by adding tunnel handling between the WTRU and the L-GW to enable session continuity. In such an embodiment (e.g., in client-based DMM), WTRU capabilities may be provided and/or enhanced to handle tunnel termination. Both the network-based DMM systems and methods and/or the client-based DMM systems and methods may enhance WTRU capabilities to support deprecating IP addresses.

[0083] In further embodiments, neighbor information may be shared between L-GWs to enable mobility and maintain session continuity during, for example, a handover as described herein. For example, a L-GW may provide information associated with itself such as an identifier of a WTRU connected thereto, an IP address allocated to the WTRU by the L-GW, a state of the IP address, and/or the like. [0084] As described herein, L-GW capabilities may be provided and/or extended to support session continuity for WTRUs handing over between different eNBs (e.g., H(e)NBs), L-GWs, and/or any other component that may be part of the same LHN and/or different LHNs. For example, in an embodiment, as described herein, a local IP address (LIPA) session may be maintained if a WTRU moves out of the LHN network coverage. For example, the LIPA session may be maintained if a WTRU moves out of the LHN network coverage by enabling the creation of tunnels between L-GWs. Furthermore, LIPA mobility support between L-GWs that may be part of different LHNs and connecting to different PDNs may also be supported. In

embodiments, the use of tunnels may permit the network to maintain WTRU connectivity while handing over between L-GWs.

[0085] For example, one or more tunnels may be created and/or maintained to enable WTRU connectivity during a handover. The tunnel creation and/or maintenance may be enabled by using an enhanced network-based mobility protocol (e.g., proxy mobile IP (PMIP) or GPRS tunneling protocol (GTP)). The enhanced network-based mobility protocol may further make use of a MMR located in the network that may be accessible to the WTRU and the L-GWs. A client-based mobility protocol (e.g., dual stack mobile IP (DSMIP)) may be used to support DMM. Additionally, in the network-based methods and systems and/or the client based methods and systems described herein, deprecating IP addresses may be provided and/or used to support DMM in either the network-based or client-based embodiments described herein.

[0086] For example, in an embodiment, a WTRU source IP address may be selected. When selecting such an IP address, the“state” of the IP addresses and/or prefixes may be taken into account. A WTRU starting new IP flows may also be configured to refrain from selecting “deprecating” IP addresses. For example, the WTRU may receive a Router Advertisement (RA) from the currently connected L-GW. The RA may indicate deprecating IP addresses. The WTRU may determine whether to refrain from using for one or more (e.g., new) flow IP addresses that may be known to be deprecating. The deprecating IP addresses may be identified by a Lifetime value being set to 0. If the WTRU may use dynamic host configuration protocol (DHCP) to obtain an IP address, modifications and/or enhancements to DHCP may be configured to prevent the assignment of a deprecating IP address to a new IP flow. In additional embodiments, other methods that may be used by the WTRU to obtain an IP address may be configured to support the advertisement of deprecating IP addresses in addition to indicating the allocated and/or available IP addresses.

[0087] According to an embodiment, a WTRU may also be connected to the network using multiple IP addresses, interfaces, and/or technologies (e.g., a multi-homing WTRU). A WTRU connected to the network using multiple IP addresses, interfaces, and/or technologies may be different than“deprecating” IP addresses. A WTRU with multi-homing capabilities may use different interfaces and/or IP addresses to send data flows. In such an embodiment, a

deprecating IP address may be an IP address assigned and/or allocated to the WTRU by an anchor node where the WTRU may no longer be directly connected to the assigning anchor node. For example, after obtaining an IP address at a first anchor node, the WTRU may connect to a second anchor node (e.g., may obtain an IP address at the second anchor node). The IP address that may be received at the first anchor node may be a deprecating IP address. The first anchor node may reserve the deprecating IP address for the WTRU even if the WTRU may no longer be connected to the first anchor node. In an embodiment, the deprecating IP addresses may be provided and/or used to maintain session connectivity for the flows that may be associated therewith (e.g., that may be using such deprecating IP addresses). As described herein, new flows that may be started on the WTRU may refrain from using the deprecating IP addresses.

[0088] DHCP may be used between the WTRU and a DHCP server, for example, when the WTRU may attempt to obtain an IP address. According to an example embodiment, a L-GW may implement the DHCP server functionality. The WTRU may send a DHCP discovery message. In response, the current L-GW may send a DHCP offer message to inform the WTRU of the IP addresses that may be used by the WTRU. Typically, these IP addresses may be owned (e.g., allocated) by the L-GW.

[0089] In an example embodiment, the DHCP offer message may be modified and/or extended to enable the L-GW to indicate/include IP addresses owned by other L-GWs. For example, the other L-GWs may include IP addresses from L-GWs where the WTRU may have been previously connected, that may still be used by the WTRU, that may be neighboring the current L-GW, and the like. The IP addresses that may be owned and/or allocated by other L- GWs may be identified (e.g., in a particular manner or special way) to indicate to the WTRU that these addresses may still be valid but that the previous IP addresses should not be used for new flows. For example, the DHCP offer message may indicate that the IP addresses owned and/or allocated by other L-GWs may be deprecating IP addresses.

[0090] The DHCP offer may include a DHCP option for a lease time of the IP address. In an embodiment, such an IP address lease time may indicate that a one or more IP addresses may be deprecating IP addresses. For example, setting the lease time to 0 on the DHCP offer may indicate that the corresponding IP address may be deprecating. The WTRU may reply as usual with a DHCP request, specifying the chosen IP address from the current L-GW. The WTRU may also add, store, and/or otherwise note the IP addresses that may have been indicated as deprecating and that may still be used by the WTRU, for example, to support DMM

functionality. A WTRU that may no longer use and/or supports a given deprecating IP address may send a DHCP release message to the current L-GW (e.g., the DHCP server) specifying the IP address to be released.

[0091] The session continuity for WTRUs moving to different L-GWs may be performed and/or provided based on or assuming that particular or certain information (e.g., mobility information) may be stored or saved somewhere in the network, for example, using a network database. For example, in an embodiment, L-GWs may save and/or store certain information (e.g., an obtained IP address, an IP address of the L-GW which has allocated this IP address, WTRU unique identifier, and/or the like) in a database, and other L-GWs may obtain that information when desired (e.g., typically when a WTRU connects to the other L-GWs). The information saved in the database may be used to maintain connectivity through one or more L- GWs where the WTRU had previously established a connection. For example, a WTRU may have previously obtained an IP address from a given L-GW, and such information related to that connection may be stored, saved, and/or maintained to support DMM and/or maintain session continuity.

[0092] In an example embodiment, the WTRU may also have access to a repository that may store information related to its anchor node connections and/or IP address allocations to read and/or write such information therefrom and thereto. The information that may be saved in the repository may include one or more of a WTRU identifier, an IP address, an owner of the IP address (e.g., a L-GW), an IP address state, and/or the like. For example, for each WTRU identified in the repository, there may be a list of IP addresses associated with the WTRU, an indication of a corresponding owner (e.g., L-GW) for each IP address, and/or a corresponding IP address state for each IP address.

[0093] The repository may correspond to a database located in the network that may be accessible to the L-GWs and/or to the WTRU. For example, the repository may be stored on one or more of an enhanced Access Network Discovery and Selection Function (ANDSF) server, a visitor location register (VLR), a policy charging and rules function (PCRF), a HSS, a PGW, a serving gateway (SGW), a MME, and/or the like. Examples described herein may be described with respect to an enhanced ANDSF server, however, any suitable existing and/or new database in the network may be used to store the repository.

[0094] For example, in an embodiment, the ANDSF server may be configured to store and maintain a table (e.g., per WTRU). Each table may include one or more of the following: a L- GW IP address, an allocated IP address by this (e.g., the current) L-GW, and/or an IP address state (e.g., deprecating or in use). The ANDSF server may also create new entries as requested by the currently connected L-GW. Additionally, according to embodiments, the ANDSF server may reply to L-GW and WTRU queries about a WTRU’s IP addresses, corresponding L-GWs IP address, and/or an IP address’ state (e.g., deprecating or not). The ANDSF server may handle IP address removal, for example, based on a request to remove an IP address from the WTRU and/or may delete entries as requested by the WTRU (e.g., deprecating IP addresses that may not be used by the WTRU in the future). Furthermore, the ANDSF server may send one or more indications to a serving L-GW about an IP address for a WTRU being removed from the list. In an example embodiment, the serving L-GW may poll the ANDSF server periodically to determine deprecating and/or other IP addresses currently allocated for a WTRU.

[0095] To enable ANDSF server and/or L-GW interactions, an interface (e.g., a new interface) may be defined in the core network. For example, a dedicated interface between the ANDSF server and a L-GW may be defined. In an example embodiment, the dedicated interface may be a S14' interface, which may be similar to S14 interface between the WTRU and the ANDSF server.

[0096] In an embodiment, the S14' interface may be a reference point between a L-GW and Home-ANDSF (H ANDSF) and/or between a L-GW and a visiting ANDSF (V ANDSF). The S14' interface may be used for direct queries via pull and/or may enable dynamic provision of information to the L-GW. For example, a L-GW may use the S14' interface to obtain or receive information related to current connections (e.g., attached L-GWs) for a WTRU and/or to obtain or receive network topology information. In embodiments, the dynamic provision via the S14' interface may be supported with Pull (e.g., L-GW-initiated session) and/or with Push (e.g., ANDSF-initiated session). Additionally, communication over or via the S14' interface may be secured (e.g., a WTRU and an ANDSF server may establish a security association to protect the messages of Access Network Info Request and Access Network Info Response). The S14' interface may be realized over an IP level such that an IP packet may be exchanged between the ANDSF server and WTRU and/or L-GW.

[0097] As described herein, according to embodiments, L-GW functionality may be provided and/or extended to enable the L-GW to act as an anchor node (e.g., LMA) when, for example, a WTRU may be directly connected to the L-GW. For example, the L-GW may allocate an IP address to the WTRU when the WTRU connects to the L-GW. In such an embodiment, this IP address may be advertised to the WTRU using one or more of the following: a PDP context activation message, a Router Advertisement (e.g., with prefix for IPv6) message, a DHCP message, and/or the like. The L-GW may also create a binding entry (e.g., locally). Additionally, in an example embodiment, the L-GW may update the MMR to include an entry for the newly created IP address. The entry may include one or more of a unique WTRU identifier, the allocated IP address information (e.g., HoA), and/or its own (e.g., L-GW IP) address.

[0098] Additionally, a L-GW may act as an access GW (e.g., a MAG) if or when, for example, the WTRU may have one or more IP flows anchored at other L-GWs. In such embodiments, a L-GW to which the WTRU is currently connected (e.g., a L-GWc where c may refer one or more nodes to which a WTRU may be currently connected) may interrogate the MMR to determine if another L-GW (e.g., a L-GWp where p may refer to one or more notes to which a WTRU may have been previously connected) may be in use and/or which IP address may have been allocated to the WTRU by the L-GWp. The L-GWc may update the MMR to indicate that it (e.g., L-GWc) may be the L-GW in use. By doing so, the state of entry in the MMR for the L-GWp may be set to deprecating. The L-GWc may also create a tunnel toward the L-GWp, which may be registered in the MMR. If a WTRU may have previously been connected to multiple L-GW_Ps, the L-GWc may create multiple tunnels to the plurality of L- GWps. In such an embodiment, one or more IP flows that may use the IP address allocated by a L-GWp may be redirected through the created tunnel. For example, IP flows for which a L- GWp may be the anchor node may be routed using the tunnel from the L-GWc. As such, in an embodiment, the L-GWc may act as the MAG for flows to be sent to one or more L-GW_Ps via a created tunnel. Additionally, new IP flows may use the newly allocated IP address from the L- GWc such that the IP flows using the IP address associated with the L-GWc may be directly forwarded to the WTRU (e.g., there may be no tunneling).

[0099] According to an example embodiment, a L-GW to which a WTRU may be directly connected (e.g., a L-GWc) may simultaneously act as an anchor node and as an access gateway (e.g., a LMA and MAG). In such an embodiment, a binding entry may be created even when a L-GW may be acting as both an anchor node and an access gateway (e.g., a LMA and MAG). Additionally, in an embodiment, encapsulation (e.g., tunneling) between the anchor node and the access node may not be used, because the anchor node and access node may be internal to the same gateway. For example, if PMIP may be used, the binding entry may include a CoA set to NULL (e.g., no value).

[0100] Additionally, in one embodiment, if a L-GW may behave as an access gateway (e.g., a MAG), a serving L-GW (e.g., a current L-GW or L-GWc) may tunnel packets to a previous L- GW (e.g., L-GWp). For example, the previous L-GW may act as an anchor node. According to an embodiment, a regular binding entry may be created at the current L-GW to tunnel packets to a previous L-GW. For example, a HoA for an entry corresponding to the previous L-GW may be a deprecating IP address allocated by the previous L-GW to the WTRU. The CoA in the binding table may be the allocated IP address from the current L-GW.

[0101] As described herein, WTRU capabilities may be provided, enhanced, and/or modified in to support handover between L-GWs, for example while simultaneously maintaining connectivity of existing IP flows. For example, in an embodiment, the WTRU may receive an IP address such as a new IP address from the currently connected L-GW (e.g., L-GWc) and/or may receive an indication about one or more previously allocated IP addresses and/or prefixes, for example, setting their state to deprecating. In such an embodiment, the indication may be a Router Advertisement with the deprecating IP addresses and/or prefixes identified with their Lifetime value set to 0 (zero).

[0102] Additionally, if DHCP may be used by the WTRU for IP address allocation, modifications, changes, enhancements, and the like in DHCP may be provided and/or defined for the WTRU and/or the L-GWs (e.g., a DHCP server). For example, the WTRU may receive a DHCP offer that may indicate available IP addresses from the connected L-GW. The DHCP offer may include or indicate one or more IP addresses already allocated to the WTRU by other DHCP servers such as other L-GWs. According to an example embodiment, the current L-GW may learn of the other IP addresses using the MMR. Additionally, these previously allocated IP addresses may be considered as deprecating by the WTRU and, as such, the WTRU may be configured to refrain from selecting these deprecating IP addresses for new flows. For such new flows, in an embodiment, the WTRU may select an IP address from the IP addresses that were indicated as available by the current L-GW. The WTRU may also maintain the other IP addresses (e.g., deprecating) already in use. Additionally, the WTRU may send a DHCP request specifying the selected IP address from the currently connected L-GW and/or also specifying the deprecating IP addresses to be maintained.

[0103] In an example embodiment, the WTRU may query the MMR (e.g., rather than or in addition to receiving an RA indication about the previously allocated IP addresses/prefixes and/or using DHCP) to obtain the states (e.g., deprecating, available, and the like) associated with the IP addresses and/or prefixes. As described herein, the IP addresses and/or prefixes allocated by previous L-GWs (e.g., L-GWs not currently connected with the WTRU) may be set to deprecating in the MMR. A WTRU starting an IP flow (e.g., new IP flows) may perform a source IP address selection. During such a source IP address selection, the WTRU may select IP addresses and/or prefixes that may not be set to deprecating, for example, for such flows. [0104] According to one embodiment, the MMR may be maintained and/or modified (e.g., cleaned up) by the WTRU when the WTRU may terminate an IP flow. For example, if an associated deprecating IP address and/or prefix may be associated with IP flow that may no longer be used and/or there may be no other IP flows using the deprecated IP address, the WTRU may be configured to release the deprecating IP address. The WTRU may also send a message modifying the MMR such that the message and modified MMR may release the deprecated IP address. Additionally or alternatively, in an example embodiment, if the WTRU may not have a direct interface to the MMR, the WTRU may send the information (e.g., a WTRU unique identifier, an IP address to be released, an IP address of owner L-GW, and/or the like) to the MMR via another trusted node in the network, which may relay the information to the MMR. Additionally, the WTRU may inform the current L-GW that a deprecating IP address may no longer be used. For example, the WTRU may send a DHCP release to the L-GW and/or a RS. The message may include the IP addresses that may be still in-use, but may omit IP addresses that may no longer be used by the WTRU.

[0105] When a WTRU may connect to an L-GW, the L-GW may assign an IP address and/or prefix such as a new IP address and/or prefix to the WTRU. The L-GW may then update the MMR, for example, with one or more of the following: the IP address and/or prefix allocated, the unique identifier for the WTRU, and/or the IP address of the L-GW. Based on such an update, the MMR may provide or return (e.g., to one or more L-GWs and/or WTRU) a list of deprecating IP addresses with an indication of the corresponding L-GW’s IP address (e.g., an anchor for the IP address). In an example embodiment, the L-GW may query the MMR to determine one or more deprecating IP addresses for a WTRU. These deprecating IP addresses may represent the IP addresses assigned to the WTRU by other L-GWs (e.g., L-GWs not directly connected with WTRU anymore). The deprecating IP addresses may still be used by the WTRU and may be anchored to one or more previous L-GWs.

[0106] According to an embodiment, the current L-GW may behave as a MAG for the deprecating IP addresses. For example, the current L-GW may initiate an establishment of a tunnel between itself (e.g., a MAG) and the L-GW that may have assigned the deprecating IP addresses (e.g., an anchor node such as an LMA). As described herein, in embodiments, there may be multiple previous L-GWs such that multiple tunnels may be created. The current L-GW may act as a MAG for each of the created tunnels associated with those previous L-GWs.

[0107] According to an example embodiment, the current L-GW may advertise the newly allocated IP addresses and/or prefixes to the WTRU. The deprecating IP addresses and/or prefixes (e.g., the other IP addresses from other L-GWs that may be determined via the MMR) may be advertised to the WTRU as well. Such deprecating IP addresses may include a lifetime and/or lease time set to 0 to indicate that they may be associated with a deprecating state.

[0108] The L-GW to which the WTRU may be currently connected may receive IP packets from WTRU. In an embodiment, if the source IP address of a packet may be associated with another L-GW, the currently connected L-GW may encapsulate the packet and send it to the other anchoring L-GW (e.g., that may be acting as a LMA) via tunneling. If the source IP address of a packet may be associated with the currently connected L-GW, the L-GW may send the packet to the destination address directly (e.g., implementing MAG + LMA functionality in this embodiment).

[0109] Additionally, IP packets destined for the WTRU may be directly received by the current L-GW (e.g., without tunnels). Such IP packets may then be forwarded to the WTRU. Other IP packets that may be destined to the WTRU may be received by the current L-GW via the established tunnels with other L-GWs. In this embodiment, the IP packets may also be forwarded to the WTRU, for example, after having removed the tunnel encapsulation.

[0110] The serving L-GW (e.g., the current L-GW to which the WTRU may be connected) may periodically query the MMR to learn about the IP addresses that may not be in use anymore by the WTRU. In an example embodiment, the L-GW may receive information (e.g., IP addresses that may not be used anymore by the WTRU) regarding the status of allocated IP addresses directly from the WTRU. Additionally, a tunnel using a deprecating IP address that may not be used anymore may subsequently be closed by the L-GW.

[0111] A previous L-GW (e.g., a L-GW where the WTRU may not be directly connected anymore) that may have a tunnel established with the current L-GW may maintain the allocation of the IP address to the WTRU (e.g., the previous L-GW may determine not to allocate a deprecating IP address to another WTRU). The associated lifetime or lease for such an IP address may be set to deprecating (e.g., zero or -1). Additionally, a previous L-GW that may receive a request to close a tunnel may assume that the WTRU may not be using the associated IP address anymore and/or may then make the IP address available to other WTRUs. A previous L-GW (e.g., a L-GW where the WTRU may not be connected anymore) that learns that the IP address allocated to a WTRU is not used anymore (e.g., by receiving a DHCP Release request or some other IP address release indication) may further initiate the closing of the tunnel with the serving L-GW (e.g., the MAG or current L-GW).

[0112] As described herein, embodiments may be provided (e.g., in FIG. 2-5) that may illustrate a L-GW and/or WTRU behavior when the WTRU may move from L-GWa to L-GWb to L-GWc while keeping its current flows anchored at the original L-GW (e.g., may maintain session continuity while moving between different L-GWs, for example, in different LHNs). For example, a network-based DMM approach may be provided as described herein that may use a MMR. In embodiments, the MMR functionality may be included in an ANDSF server.

Additionally, new flows may be anchored at the current L-GW where the flow may have been initiated. The handling of a terminated flow may also be performed as shown.

[0113] FIG. 2 illustrates an example embodiment of mobility between L-GWs based on a mobility management repository (MMR). For example, at 1, a WTRU such as a WTRU 205 may connect to an eNB such as HeNBa2210a that may be part of a network such as a local home network 215a. As shown, the eNB such as a HeNBa2210a may be in communication with a L-GW such as L-GWa 220a that may also be part of the network. According to an

embodiment, the L-GWa 220a may act as an anchor node (e.g., a LMA) for the WTRU 205 when connected to the HeNBa2210a. The L-GWa 220a may also be in communication with other eNBs such as HeNBa1 211a that may be part of the network and that may be connected to the L-GWa 220a and/or the WTRU 205 (not shown).

[0114] At 2, the L-GWa 220a may create a binding entry in a binding table for the WTRU 205. The binding entry in the binding table created, at 2, may include a CoA of null (e.g., no COA or an indication there may be no tunnel). At 2, the L-GWa 220a may then allocate an IP address to the WTRU 205 (e.g., HoAa) that may further be included in the binding entry of the binding table as shown in FIG. 2. In an example embodiment, as described herein, the IP address may be allocated via DCHP or any other suitable technique.

[0115] After allocating the IP address, the L-GWa 220a, at 3, may register such an IP address (e.g., HoAa) and an identifier of the WTRU 205 such as a WTRU-ID with an MMR such as an MMR 225 via an interface, for example, the Internet. In response thereto, the MMR 225 may reply with (e.g., send) an indication of one or more other IP address that may be allocated to the WTRU 205 by other L-GWs (e.g., L-GWb 220b and/or L-GWc 220c should IP addresses be allocated thereby where such L-GWs may be in in different networks such as LHN 215b and/or LHN 215c). In the example embodiment shown in FIG. 2, the WTRU 205 may not have any other allocated IP addresses that may be registered with other L-GWs such as the L-GWb 220b and/or the L-GWc 220c. According to an embodiment, at 3, the L-GWa 220a may query the MMR 225 to learn the deprecating IP addresses and/or one or more IP addresses associated with the other L-GWs such as the L-GWb 220b and/or the L-GWc 220c (e.g., via a polling mechanism or technique).

[0116] At 4, the L-GWa 220a may provide, send, broadcast, and/or advertise the newly allocated IP address (e.g., the HoAa) to the WTRU 205. For example, the L-GWa 220a may provide and/or advertise the IP address allocated thereby (e.g., the HoAa) to the HeNBa2210a, which in turn may provide, send, broadcast, and/or advertise such an address to the WTRU 205 as shown in FIG. 2. In an embodiment, the IP address allocation provided, sent, broadcast, and/or advertised to the WTRU 205 (e.g., via the HeNBa2214) may be indicated via a RA, DHCP, and/or the like.

[0117] FIG. 3 illustrates an example of mobility (e.g., a handover or change in L-GWs and/or LHNs) from a L-GW such as the L-GWa 220a to another L-GW such as the L-GWb 220b, for example, after a WTRU such as a WTRU 205 may have obtained an IP address at the original L- GW (e.g., L-GWa. 320a). For example, at 5, the WTRU 205 may relocate and may connect to a different eNB such as HeNBb2210b, for example, in a different L-GW such as the L-GWb 220b (e.g., that may be part of a different LHN such as LHN 215b). The L-GWb 220b may also be in communication with other eNBs such as HeNBb1 211b that may be part of the network and that may be connected to the L-GWa 220a and/or the WTRU 205 (not shown).

[0118] In an embodiment, the L-GWb 220b may act as an anchor node (e.g., a LMA) for the WTRU 205 when connected to HeNBb2210b. For example, at 6, the L-GWb 220b may create a binding entry in a binding table for the WTRU 205. The binding entry in the binding table may include a CoA of null (e.g., no COA or an indication there may be no tunnel). The L-GWb 220b may further allocate an IP address to the WTRU 205 (e.g., HoAb) at, for example, 6.

[0119] At 7, the L-GWb 210b may register this IP address (e.g., HoAb) and the identifier of the WTRU 205 such as the WTRU-ID with the MMR 225. via an interface, for example, the Internet. The MMR 225 may update its table and may change the state of the previous WTRU IP address (e.g., the HoAa) to deprecating. The MMR 225 may then return one or more other IP addresses allocated to the WTRU 205 by other L-GWs such as the L-GWa 220a and/or the L- GWc 220c (e.g., the HoAa) that may be part of other networks such as the LHN 215a and/or the LHN 215c, one or more IP addresses associated with the other L-GWs such as the L-GWa 220a and/or L-GWc 220c (e.g., the IP address of the L-GWa 220a and/or the L-GWc 220c), the identifier of the WTRU 205, and/or any other suitable information associated with the L-GWs and/or WTRU.

[0120] According to an embodiment, at 8, the L-GWb 220b may update its binding table with the information received from the MMR 225. Additionally, the L-GWb 220b may create a tunnel with the L-GWa 220a, for example, based on the information such as the received from the MMR. In an example embodiment, the L-GWb 220b may query the MMR 225 to determine information regarding the deprecating IP addresses and/or one or more associated L-GW IP addresses. [0121] At 9, L-GWb 220b may advertise, send, broadcast, and/or provide the newly allocated IP address (e.g., the HoAb) to the WTRU 205. The L-GWb 220b may also indicate the deprecating IP address (e.g., HoAa) to the WTRU 205. In an example embodiment, as shown in FIG. 3, at 10, the WTRU 205 may query the MMR 225 to obtain HoA states (e.g., deprecating, in-use, and/or the like). The WTRU 205 may also be configured to refrain from using deprecating HoAa for new flows according to one embodiment.

[0122] FIG. 4 illustrates an example of mobility (e.g., a handover or change in L-GWs and/or LHNs) from the L-GWb 220b to the L-GWc 220c after the WTRU 205 may have established an IP address at the L-GWa 220a and an IP address at the L-GWb 220b. For example, at 11, the WTRU 205 may relocate and may connect to a different eNB such as HeNBc1 211c, for example, in a different L-GW such as the L-GWc 220c (e.g., that may be part of a different LHN such as LHN 215c. The L-GWb 220b may also be in communication with other eNBs such as HeNBc2210c that may be part of the network and that may be connected to the L-GWa 220c and/or the WTRU 205 (not shown).

[0123] According to an embodiment, the L-GWc 220c may act as an anchor node (e.g., LMA) for the WTRU when connected to the HeNBc1 211c. For example, at 12, the L-GWc 220c may create a binding entry in a binding table for the WTRU 205. The binding entry in the binding table may include a CoA of null (e.g., no COA or an indication there may be no tunnel. The L-GWc 220c may further allocate an IP address to the WTRU 205 (e.g., HoAc).

[0124] At 13, the L-GWc 220c may register this IP address (e.g., HoAc) and the WTRU-ID with the MMR 225. The MMR 225 may update its table and may change the state of a previously active WTRU IP address (e.g., HoAb) to deprecating. In an example embodiment, the MMR 225 may ensure that the state of each of the IP addresses associated with L-GWs such as L-GWa 220a and/or L-GWb 220b that may not be the current L-GW (e.g., that are not associated with L-GWc 220c) to be set as deprecating. The MMR 225 may then return one or more other IP addresses allocated to the WTRU 205 by other L-GWs such as the L-GWa 220a and/or L-GWb 220b (e.g., HoAa and HoAb) and/or the IP address(es) associated with the other L-GWs (e.g., the IP address of the L-GWa 220a and/or the IP address of the L-GWb 220b in this embodiment).

[0125] At 14, the L-GWc 220c may update its binding table with the information received from the MMR 225. As shown, in an example embodiment, at 14, the L-GWc 220c may further create a tunnel with L-GWa 220a and L-GWb 220b, for example, based on the information received from the MMR 225. Additionally, according to an embodiment, the L-GWc 220c may query the MMR 225 to determine information regarding one or more deprecating IP addresses and/or associated L-GW IP addresses.

[0126] At 15, the L-GWc 220c may advertise the newly allocated IP address (e.g., HoAc) to the WTRU 205. In an embodiment, the L-GWc 220c may also indicate the deprecating IP addresses (e.g., HoAa and HoAb) to the WTRU 205.

[0127] As shown, at 16, the WTRU 206 may query the MMR 225 to obtain the HoA states (e.g., deprecating, in-use, and/or the like). In such embodiments, the WTRU 205 may further be configured to refrain from using deprecating HoAa and deprecating HoAb for new flows.

[0128] FIG. 5 illustrates an example of releasing a deprecating IP address using a network- based approach to DMM, for example, if it may no longer be in use by the WTRU 205. For example, the WTRU 205 may be connected to the L-GWc 220c and may have previously assigned IP addresses from L-GWc 220c, L-GWb 220b, and/or L-GWa 220a (e.g., the end of the sequence illustrated in FIG. 4). Additionally, in the example shown in FIG. 5, the WTRU 205 may be associated with three flows such as FLOW_A, FLOW_B, and/or FLOW_C. According to an example embodiment, the FLOW_A may use HoAa, FLOW_B may use HoAb, and/or FLOW_C may use HoAc.

[0129] At 17, the FLOW_B may be terminated, for example, by the WTRU and/or a peer. In this example embodiment, the HoAb may no longer be used by the WTRU 205. As such, the WTRU 205 may indicate to the MMR 225 that HoAb will no longer be used.

[0130] Additionally, at 18, the MMR 225 may update its table (e.g., registration table) for the WTRU 205 to remove the HoAb entry. The MMR 225 may send an indication to the current L- GW (e.g., L-GWc 220c) with the list of deprecating IP addresses (e.g., HoAs) and/or the L-GW may learn about that deprecating IP address removal by polling the MMR 225. In an example embodiment, the L-GW (e.g., L-GWc 220) may learn that one or more deprecating IP addresses may no longer be used directly from the WTRU 205 (e.g., using a router solicitation (RS) message and/or a DHCP release message).

[0131] At 19 (e.g., in response thereto), the L-GWc 220c may close the tunnel with L-GWb 220b and/or may update its binding table to remove the entry associated with HoAb. By doing so, the tunnel between L-GWc 220c and L-GWb 220b may be terminated.

[0132] According to an embodiment, at 20, the L-GWc 220c may send, provide, advertise, and/or broadcast the valid HoA(s) (e.g., HoAc and HoAa) to the WTRU 205 (e.g., by sending a RA) and/or may indicate the status of the HoAs (e.g., in use, deprecating, and/or the like). The L-GWc 220c may also indicate that HoAb may no longer be in use. [0133] As described herein, client-based (e.g., WTRU based) methods and systems may also be provided and/or used for a WTRU to provide DMM. Although the client-based approach may be described and illustrated using the DSMIP protocol as described herein in embodiments, the client-based approach may also be applicable to other client-based mobile protocols.

[0134] In an example embodiment, a WTRU may connect to an L-GW (e.g., L-GW1 and/or the current L-GW), and the WTRU may obtain an IP address. The WTRU may store and/or maintain this new IP address in a local binding table. The local binding table may include one or more of the IP address that was allocated, the IP address of the L-GW that allocated the address, and/or the number of IP flows using this IP address. In an embodiment, a tunnel may not yet be created even if the binding table may have been updated. Instead, normal IP routing may be used to forward IP packets.

[0135] When the WTRU may move to another L-GW (e.g., L-GW2), another IP address may be obtained (e.g., from L-GW2). The previous IP address obtained from the prior L-GW (e.g., L-GW1) may be kept by the WTRU and the IP flows using this IP address may be maintained (e.g., session continuity). To achieve the session continuity, the WTRU may create a tunnel with the prior L-GW (e.g., the L-GW1). For example, the WTRU may set the state of the previous IP address from the prior L-GW (e.g., L-GW1) to deprecating so the WTRU may know that this IP address should not be selected during the IP address selection, for example, during the initiation of a new flow. The WTRU may also store and/or maintain the number of IP flows using each IP address.

[0136] If no IP flows and/or no further IP flows may be using a deprecating IP address, the tunnel to the associated L-GW may be closed and the corresponding entry in the binding table may be deleted. The deprecating IP address may be deleted from the IP addresses maintained by the WTRU, and the L-GW that may have allocated this IP address may release such IP addresses (e.g., make it available to another WTRU). Table 1, below, illustrates an example binding table that may be maintained by the WTRU using the example embodiments described herein.

[0137] As described herein, embodiments may be provided (e.g., in FIG. 6-9) that may illustrate L-GW and/or WTRU behavior when the WTRU may move from L-GWa to L-GWb to L-GWc while keeping its current flows anchored at the original L-GW (e.g., may maintain session continuity while moving between different L-GWs, for example, in different LHNs). In such embodiments, new flows may be anchored at the current L-GW where the flow may have been initiated. The handling of a terminated flow may also be provided and/or used as shown and described herein.

[0138] FIG. 6 illustrates an example of mobility between L-GWs based on client-based mobility management. For example, at 21, a WTRU 305 may connect to an eNB such as HeNBa2310a that may be part of a network such as a local home network 315a. As shown, the eNB such as a HeNBa2210a may be in communication with a L-GW such as L-GWa 320a that may also be part of the network. The L-GWa 320a may act as a normal router for the WTRU 305 when connected to HeNBa2310a. The L-GWa 320a may also be in communication with other eNBs such as HeNBa1 311a that may be part of the network and that may be connected to the L-GWa 320a and/or the WTRU 305 (not shown).

[0139] For example, at 22, the L-GWa 320a may allocate an IP address to the WTRU 305 (e.g., HoAa). In an example embodiment, as described herein, the IP address may be allocated via DCHP or any other suitable technique. At 23, the WTRU 305 may then update a binding table to create an entry for HoAa. The binding entry in the binding table created, at 23, may also include a CoA of null (e.g., no CoA or an indication there may be no tunnel). Additionally, in the example shown in FIG. 6, the WTRU may have two IP flows that are associated with HoAa as indicated in the binding table.

[0140] FIG. 7 illustrates an example of mobility from the L-GWa 320a to a L-GWb 320b after the WTRU 305 may have established an IP address at L-GWa 320a (e.g., HoAa). For example, at 24, the WTRU 305 may relocate and may connect to a different eNB such as a HeNBb2210b that may be part of another network such as a local home network 315b. As shown, the eNB such as a HeNBb2310b may be in communication with a L-GW such as L- GWb 320b that may also be part of the network. The L-GWb 320b may act as a normal router for the WTRU 305 when connected to HeNBb2310b. The L-GWb 320b may also be in communication with other eNBs such as HeNBb1 311b that may be part of the network and that may be connected to the L-GWb 320b and/or the WTRU 305 (not shown).

[0141] At 25, the L-GWb 320b may allocate an IP address to the WTRU (e.g., HoAb) as described herein. At 26, the WTRU 305 may then determine or know whether it may be connected to another L-GW such as L-GWa 320a and/or L-GW 320c. In response to determining that it may be connected to another L-GW such as L-GWa 320 as shown in FIG. 7, the WTRU 305 may create a tunnel, at 26, with L-GWa 320a to maintain session continuity for flows using HoAa. Additionally, a binding entry for the WTRU 305 may be created in the binding table of L-GWa 320a.

[0142] At 27, the WTRU 305 may update its binding table to create an entry for HoAb and/or to update the entry for HoAa. In such an embodiment, the state for HoAa may be set to deprecating and the WTRU 305 may be configured to ensure that HoAa may not be selected for the initiation of new flows. In the example shown in FIG. 7, the WTRU 305 may have 2 IP flows that may be associated with HoAa and 1 IP flow that may be associated with HoAb.

[0143] FIG. 8 illustrates an example of mobility from the L-GWb 320b to L-GWc 320c after the WTRU 305 may have established an IP address at the L-GWa 320a (e.g., HoAa) and an IP address at the L-GWb 320b (e.g., HoAb). For example, at 28, the WTRU 305 may relocate and may connect to a different eNB such as a HeNBc1 that may be part of another network such as a local home network 315c. As shown, the eNB such as a HeNBc1 311c may be in

communication with a L-GW such as L-GWc 320c that may also be part of the network. The L- GWc 320c may act as a normal router for the WTRU 305 when connected to HeNBc1 311c. The L-GWc 320c may also be in communication with other eNBs such as HeNBc2310c that may be part of the network and that may be connected to the L-GWc 320c and/or the WTRU 305 (not shown). At 28, the L-GWc 320c may allocate an IP address to the WTRU 305 (e.g., HoAc).

[0144] In an embodiment, at 29, the WTRU 305 may determine or know whether it may be connected to another L-GW such as L-GWa 320a and/or L-GWb 320b. In response to determining that it may be connected to another L-GW such as L-GWa 320 and L-GWb 320b as shown in FIG. 8, the WTRU 305 may create a tunnel, at 29, with L-GWb 320b and/or update its tunnel with L-GWa 320a to maintain session continuity for flows using HoAa and/or HoAb. Additionally, the binding entry for the WTRU in the binding table of L-GWa may be updated to reflect a new CoA for the WTRU (e.g., HoAc). Additionally, a binding entry for the WTRU may be created in the binding table for L-GWb.

[0145] At 30, the WTRU 305 may update its binding table to create an entry for HoAc and/or to update the entries for HoAa and/or HoAb. For example, the state for HoAa and/or HoAb may be set to deprecating and the WTRU 305 may be configured to ensure that HoAa and/or HoAb may not be selected for the initiation of new flows. In the example shown in FIG. 8, the WTRU 305 may have 2 IP flows that may be associated with HoAa, 1 IP flow that may be associated with HoAb, and 1 IP flow that may be associated with HoAc.

[0146] FIG. 9 illustrates an example of releasing a deprecating IP address using a client- based approach to DMM, for example, if it may no longer be in use by the WTRU 305. For example, the WTRU 305 may be connected to L-GWc 320c and may have previously assigned IP addresses from L-GWc 320c, L-GWb 320b, and L-GWa 320a (e.g., the end of the sequence illustrated in FIG. 8). In the example shown in FIG. 9, the WTRU 305 may be associated with at least three flows such as FLOW_A, FLOW_B, and/or FLOW_C. According to an embodiment, FLOW_A may use HoAa, FLOW_B may use HoAb, and FLOW_C may use HoAc.

[0147] At 31, FLOW_B may be terminated, for example, by the WTRU 305 and/or a peer. In this example, the HoAb may no longer be used by the WTRU 305. The WTRU 305 may terminate the tunnel with L-GWb 320b and may remove the entry associated with HoAb from the binding table of the WTRU 305. Additionally, after FLOW_B may have been terminated there may be 2 IP flows using HoAa and 1 IP flow using HoAc. In an embodiment, there may also have been a single IP flow that may have been using HoAb (e.g., FLOW_B), and the single IP flow using HoAb may have been terminated.

[0148] As shown, at 32, L-GWb 320b may update its binding table to remove the entry associated with HoAb, for example in response to receiving a binding update message from the WTRU 320. By doing so, the tunnel between L-GWc 320c and L-GWb 320b may be terminated. The L-GWb 320b may then release HoAb and may assign the HoAb to a different WTRU.

[0149] In embodiments, one or more of the methods and/or systems described herein may be realized and/or implemented in a 3GPP Network. To implement such systems and/or methods, one or more changes may be made to the current 3GPP Network architecture and/or 3GPP interfaces in. Example changes may be described herein with respect to FIG. 4, although as may be appreciated, any of the systems and methods described herein may be applicable to a 3GPP architecture.

[0150] For example, in 12 of FIG. 4 (e.g., where L-GWc 220c may create a binding entry for the WTRU that may include no CoA or a CoA of null (e.g., no tunnel may be established) and the L-GWc 220c may allocate an IP address to the WTRU 205 (e.g., HoAc)), the assignment of an IP address to the WTRU 205 may occur as follows in a 3GPP network. The WTRU 205 may communicate with an eNB, and the eNB may communicate with the Mobility Management Entity (MME). The MME may in turn communicate with the SGW. The SGW may select a particular PDN-Gateway, which in the example of FIG. 4 may be L-GWc 220c in the local network LHN 215c. The SGW may request an IP-address for the WTRU 205 as well as other network parameters. The PDN-Gateway may assign an IP-address to the WTRU 205, which may be communicated to the SGW, MME, eNB, and ultimately the WTRU 205. Such a standard allocation of 3GPP IP addresses may be modified for application to the DMM methods and systems described herein, for example, such as the methods and systems depicted in FIG. 4. [0151] In an embodiment, a joint MME and SGW Proxy may be used, for example, as illustrated in FIG. 10. As shown, a HeNB such as a HeNBa1 411 and/or a HeNBa2410 in a LHN such as LHN 415 may be logically connected to a node such as a MME-SGW Proxy function 450 using an S1-type interface, for example an S1-type interface suitably modified for local application (e.g., shown as S1' in FIG. 10). In an example embodiment, the MME-SGW Proxy function 450 may be logically connected to the L-GW 420 using an S5-type interface, for example suitably modified (e.g., shown as S5' in FIG. 10). Using such a configuration, IP- addresses may be allocated to the WTRU 405 directly within the local network, for example without involving the Core Network that includes the MME and/or SGW functionalities.

[0152] For example, at 3 of FIG. 4 (e.g., where L-GWc 220c may register this IP address (e.g., HoAc) and the WTRU-ID with the MMR 225), in FIG. 10, the L-GW 420 may register the IP address (e.g., HoAc in FIG. 4) and the WTRU-ID with an ANDSF server 455. ). As such, to realize such functionality described herein with respect to, for example, FIG. 4 and also the other figures and corresponding description therefor disclosed herein, the methods and/or architecture of the 3GPP network may be modified. For example, a new interface may be created between the L-GW 420 and the ANDSF Server 455 using an IP-level connection. The logical interface may be based on a S14 interface, modified as desired (e.g., shown as S14' in FIG. 10). As such, the L-GW 320 may be modified to support the S14' interface to provide the functionality of the methods or embodiments described herein, for example.

[0153] In an example embodiment, the local joint MME and SGW functionality (e.g., the MME-SGW proxy 450) may be logically connected to one or more of the MME, SGW, and/or the PGW functionality 460 of the Core Network. Such an interface may be illustrated as a generic interface called Sxx' in FIG. 10. For example, an interface, S8, may be suitably modified and may be used to logically connect the local SGW Proxy functionality 450 to the PGW 460 of the Core Network. Such a logical interface may be similar to a roaming scenario. Thus, in an example, the Sxx' interface may be referred to as an S8' interface. The PGW 460 of the Core Network may then communicate this information (e.g., the registration of an IP address for a WTRU from an L-GW) to the ANDSF Server 455 using an appropriate interface. The appropriate interface may be an S14 interface, for example, an S14 interface that may suitably modified shown as S14'' in FIG. 10. Such an interface may be entirely within the Core Network and may not involve the local network.

[0154] As such, in embodiments, to implement the methods and/or systems described herein, for example, in a 3GPP network as shown in FIG. 10, a local IP address may be generated and/or allocated, for example, using a L-GW and a proxy without going to the Core Network using an S5’ interface. Additionally, an interface may be provided between the L-GW and an ANDSF server where such an interface may include a S14’ interface. Additionally or alternative to the S14’ interface, a combination of an S5’ interface, an Sxx’ interface, and a S14’’ interface (from L-GW to ANDSF server via MME-SGW proxy and Core Network) may be provided and/or used. In an embodiment, a proxy may also be used to forward an ANDSF modification to Core Network such that the Core Network may handle or manage an interface to the ANDSF server (e.g., and the reverse, i.e. a response from ANDSF server to the Core Network to the proxy to the L-GW).

[0155] Additionally, in embodiments, LIPA and SIPTO traffic offload (e.g., that may be used in Release 10) may be provided and/or used herein. For example, the support of Local IP Access (LIPA) and Selected IP Traffic Offload (SIPTO) may be provided and/or used. In such an embodiment, one or more of the following may be provided and/or used: the L-GW and the H(e)NB may be co-located; there may be no mobility support; LIPA P-GW functions (e.g., included in L-GW/HNB) may be provided including per : 758 policy based packet filtering and rate policing and/or shaping, UE IP address assignment, and/or direct tunneling between L-GW and RAN in a connected mode, and/RU the like.

[0156] LIPA mobility and SIPTO at a local network (e.g., that may be used in Release 11) may further be provided and/or used herein. For example, the support of mobility for LIPA between the H(e)NBs located in a local IP network may be provided and/or used. In an embodiment, session continuity of IP data sessions (i.e., IP address preservation) for LIPA considering mobility between H(e)NBs within a single residential or Enterprise network may be supported. Additionally, session continuity for LIPA with mobility between H(e)NBs of the same Local H(e)NB Network may be supported with, for example, an L-GW acting as an anchor, a standardized interface between the L-GW and the H(e)NB, and handover procedures from the source H(e)NB to the target H(e)NB.

[0157] FIG. 11 illustrates an example embodiment of an architecture for LIPA mobility. For example, when a WTRU may request a LIPA bearer, a PDN connection may be established and may terminate in a L-GW such as L-GW 520a and/or 520b that may be part of different LHNs such as LHN 515a and/or LHN 515b where it may be assigned an IP address (e.g., belonging to the local IP network). As the WTRU may move around between the H(e)NBs such as LHNs 510a-510c and 511a-511b in the local network, it may maintain its connectivity to the L-GW 520 to keep its IP address and the ongoing services. The L-GW such as L-GW520a and/or 520b may be, thus, the anchor point of the LIPA connectivity to the local IP network. The L-GW such as L-GWs 520a and/or 520b may further be connected to one or more PDNs such as PDN 560a and/or 560b.

[0158] FIG. 12 illustrates an example embodiment of LIPA mobility with a stand-alone L- GW such as L-GW 620. According to an embodiment, LIPA mobility may be supported within an LHN such as LHN 615. In such an embodiment, a WTRU 605 may maintain session continuity when handing over between different H(e)NBs 610a-d that may be part of the same LHN 615.

[0159] Additionally, WTRU source IP address selection may be provided and/or used. For example, a WTRU source IP address selection algorithm may be provided that may take into account a“state” of the IP addresses and/or prefixes. The WTRU starting new IP flows may not select“deprecating” IP addresses.

[0160] In an embodiment, as described herein, the WTRU may receive IP addresses advertisements and/or assignments from a currently connected L-GW. The IP addresses which may not be used with new flows may be“deprecating.” In embodiment disclosed herein, the WTRU may support“deprecating” IP addresses in its source IP address selection algorithm. Moreover, the WTRU may be informed of the IP addresses state regardless of the IP version used (e.g., IPv4 or IPv6).

[0161] For an L-GW to evolve, a WTRU may be able to maintain session continuity when handing over between L-GWs that may be part of different LHNs. Unfortunately, as described herein, this may not be achievable with the current definition of L-GWs where LIPA mobility may be supported within an LHN network such that a WTRU may maintain session continuity when handing over between different H(e)NBs that may be part of the same LHN and LIPA mobility may not be supported between LHN networks such that if a WTRU may move out of the LHN network coverage, the LIPA session may be released.

[0162] As described herein, systems and methods for evolving a L-GW to distributed mobility management (DMM) may be provided such that mobility support may be provided between L-GWs and/or LHNs. For example, an L-GW architecture that may be defined for LIPA in a system (e.g. in 3GPP systems) may be evolved by enabling support of mobility between L-GWs within different LHN connecting to the same PDN or different PDNs and/or by enabling operation in LIPA-only network (e.g., where the PDN-GW may no longer be present) while still supporting operation with a PDN-GW. Additionally, L-GW capabilities may be extended by adding tunnel handling toward other L-GWs enabling session continuity. A neighbor concept (e.g., knowledge about network topology and/or neighbors), a pre-registration concept, and/or a mechanism to manage a tunnel lifetime at an anchor node may also be provided or used. A PMIPv6 protocol may further be enhanced by adding support for“pre- registration” and“inactive binding entries” and/or by adding a“state” to the binding entries (e.g., inactive or in-use).

[0163] As such, in an embodiment, an evolved L-GW architecture may be disclosed herein. In an embodiment, the L-GW architecture may be evolved to provide a DMM D-GW

architecture. PMIPv6 may be used herein, for example, to illustrate a network-based mobile network solution however,other network-based mobility protocol such as GTP may also be used. In such an example architecture, as described herein, each L-GW may be an anchor node (e.g., a LMA) and may be an access GW (e.g., MAG). As such, in embodiments, the combined LMA- MAG functionalities within a single L-GW may be supported.

[0164] Using the evolved architecture and/or systems or methods disclosed herein, LIPA mobility may be supported between LHNs connecting to the same PDN (i.e., the WTRU may be able to maintain session continuity when handing over between L-GWs that may be part of different LHNs and that may be connecting to the same PDNs). FIG. 13 illustrates an example embodiment of LIPA mobility between LHNs connecting to the same PDN. As shown in FIG. 13, a L-GW 720a in LHN 715a and another L-GW 720b in LHN 715b may connect to the same PDN 760.

[0165] LIPA mobility support between L-GWs that may be part of different LHNs and connecting to different PDNs may also be supported as described herein. In an embodiment, the L-GWs may be configured with desired security information. FIG. 14 illustrates an example embodiment of LIPA mobility between LHNs connecting to different PDNs. As shown in FIG. 14, a L-GW 820a in a LHN 815a may connect to one PDN 860a and another L-GW 820b in LHN 815b may connect to another PDN 860b.

[0166] In a network-based mobile network, tunnels may be created between“previously connected L-GWs” (e.g., L-GWa) and“currently connected L-GW” (e.g., L-GWb). The connected L-GW may behave as an access GW for existing IP flows and as an anchor node for new IP flows. L-GWs where the WTRU may have been previously connected may behave as anchor nodes. FIG. 15 illustrates an example embodiment of tunnel creation between L-GWs to enable mobility. As shown in FIG. 15, a tunnel 965 may be created between a L-GW 920a in a LHN 915a and/or a L-GW 920b in a LHN 915b where such L-GWs may be connected to PDNs 960a and/or 960b.

[0167] Local to macro mobility support may also be provided and/or used. For example, embodiments disclosed herein, although focused on L-GW architecture, may apply to various PDN entry points and/or architectures. For example, the tunnel (e.g., tunnel 965) that may be created between the L-GWs (e.g., L-GWs 960a and/or 960b) may be extended between an L-GW and a D-GW or PGW. In an embodiment, extending the current embodiments to other entry points may provide an additional support of local to macro mobility. The various entry points may be, for example, PGW, SGW, D-GW, L-GW, and/or the like. The SGW, which may not usually be an entry point, may become one in roaming scenarios, for example.

[0168] Extended L-GW capabilities may also be provided and/or used. For example, L-GW capabilities may be extended to support session continuity for UEs handing over between different H(e)NBs that may be part of the same LHN. Using the embodiments disclosed herein, the LIPA session may be maintained if a WTRU may move out of the LHN network coverage. This may be achieved by enabling the creation of tunnels between L-GWs that may enable WTRU connectivity to be maintained while handing over between L-GWs. Additionally, the tunnel creation and/or maintenance may be enabled by using an enhanced network-based mobility protocol (e.g., PMIP or GTP) that may enable pre-registrations (e.g., doing pre- registrations) with the envisioned target GWs (e.g., as described herein below).

[0169] Pre-Registration and/or a neighbor technique may be provided and/or used. For example, pre-registration may be provided and/or used based on an enhanced network-based mobile protocol. In such an embodiment, PMIP may used to illustrate the solution however, as described above, other network-based mobile protocols like GTP, and/or the like may be used. In such embodiments, a neighbor L-GW technique may be provided and/or used. Additionally, a pre-registration may be done with the neighbor L-GWs where new PMIP signaling (e.g., between LMA & MAG) such as CBI/CBA/DBI/DBA (e.g., Create/Delete Binding Inactive & corresponding Ack), and/or the like may be provided and/or used. In an example embodiment, a pre-registration may create inactive binding entries on neighbor L-GWs where an“inactive” state may be added to the binding entry. One or more benefits of introducing the pre-registration may be that the HoA allocated to the WTRU may be already registered with the neighbor L-GWs (e.g., in case the WTRU hands over there) as well as the current L-GW (e.g., acting as LMA) IP address (e.g., for possible tunnel creation later on). As such, in embodiments, a neighbor configuration or discovery mechanism or technique may be provided and/or used.

[0170] In embodiments, the neighbor techniques may be based on pre-registration with the identified neighbor GWs and, using L-GW evolution, may apply to various architectures and features. Such an embodiment may enable pre-registering information on a potential target GW or L-GW that may use that information later on to establish direct communication (e.g. a tunnel) between the current and previous GWs or L-GWs such that session continuity may be enabled. In an embodiment, its application and/or usage may be broader than the L-GW evolution context. For exam ple, it may apply to s mall cells n etworks, m acro netwo rks, macro to local mo bility support, DMM sup port, device -to-device, and the lik e. In such a concept, e ach L-GW may know its neigh bor L-GW s. Addition ally, L-GW neighbors may be de fined as L-G Ws where the WTRU may directl y handover (HO). A d irect HO m ay be defin ed by one o r more of t he followin g: the next L-GW whe re a WTRU may HO and/or a nex t H(e)NB w here the W TRU may HO (e.g ., that may be connecte d to anothe r L-GW).

[0171] Depend ing on the d efinition, a n inactive b inding entr y may be c reated on th e neighbo r L-GWs u nder differe nt conditio ns. This ma y be illustr ated in the f ollowing ta bles (e.g. Table 2 and Table 3 ). These ta bles illustra te an embo diment wh ere three L- GWs may b e used (e.g. as shown in th e figures il lustrating th e embodim ents descri bed below) .

[0172] Neighbo r configura tion and/or discovery techniques and/or mec hanisms (e .g., methods ) may be p rovided and /or used. T he neighbo r L-GWs d iscovery m ay be done in differen t ways. So me example embodime nts may be given belo w. For exa mple, in on e embodim ent, the L -GWs may be pre-conf igured with the netwo rk topology so each L- GW may know its neighbors and how to reach them . Addition ally, a more dynamic s olution or embodim ent may b e to have th e L-GWs q uery an Ac cess Netwo rk Discove ry and Sele ction Function (ANDSF) server (or another database) that may already have knowledge about the network topology. The L-GWs may do this query periodically to make sure they may be up-to- date. The ANDSF server may also push the network topology information to the L-GWs.

According to another example embodiment, H(e)NBs may be pre-configured with neighbors (e.g., instead of L-GWs being configured with neighbors) and may provide neighboring information to the connected L-GW. L-GWs may advertise their position in the PDN and may deduce or determine a topology associated therewith dynamically from the received

advertisements from other L-GWs. Additionally, WTRUs may obtain neighboring information and may send this information to the connected L-GW.

[0173] According to an embodiment, the WTRU may be associated with an L-GW when it may first connect to a H(e)NB. The WTRU’s IP address (e.g. Home Address (HoA)) may be then allocated by the L-GW as described herein. The L-GW may create a local binding entry for the UE with the a Care-of-Address (CoA) empty (e.g. null), for example, no tunnel may be created since the L-GW may behave as the LMA and the media access gateway (MAG) for this UE and/or HoA.

[0174] After creating such an entry, the current L-GW may send a Create Binding Inactive (CBI) message to its neighbor L-GWs (e.g., L-GWs close to the H(e)NB where a WTRU may be connected) specifying the WTRU’s HoA that may have been recently allocated, the WTRU unique identifier and the IP address of the L-GW which may own the HoA. The CBI message may be a newly introduced Proxy MIP (PMIP) message.

[0175] A neighbor L-GW that may receive a CBI message may create an“inactive” binding entry with the HoA specified by L-GW or local mobility anchor (LMA) in the CBI message. A CoA may be assigned by the neighbor L-GW receiving the CBI message and associated with the inactive binding entry (alternatively, the CoA may be set to NULL since no tunnel may be created at this point). As such, in an embodiment, the binding entry state may be set to “inactive,” for example, the WTRU may not be connected to this neighbor L-GW yet so the tunnel may not be used at this point. A new field in the binding table may be created for the binding state (e.g., inactive/active) or alternatively, a CoA equal to NULL may be used to represent an inactive entry. A Create Binding Ack (CBA) message may be sent to the current L- GW as a reply to the CBI message.

[0176] When the WTRU may move and connect to a neighbor L-GW (e.g., which already may have an inactive binding created), this neighbor L-GW may assigns a new IP address to the WTRU such that the WTRU may possibly end-up with multiple IP addresses assigned to the same interface. This L-GW may advertise the new IP address to the WTRU. The IP addresses that may be already in use by the WTRU and may be obtained via pre-registration (e.g., via CBI) may also be advertised to maintain connectivity for flows using those IP addresses and may be identified as“deprecating.” The IP addresses that may be already in use by the WTRU may be kept since the connectivity of the flows using these IP addresses may be maintained.

[0177] Additionally, a current L-GW may behave as a combined LMA-MAG for the newly allocated IP address, for example, without using a tunnel (e.g., binding entry without a CoA may be created). The current L-GW may also behave as a MAG for the IP addresses that may be already registered by other L-GWs. The current L-GW may send PBU messages to the pre- registered L-GWs (e.g. owners of“inactive” bindings) such that tunnels may be created with previous L-GWs. The local binding state may be changed from“inactive” to“active” once the tunnel may be created. The current L-GW may also send CBI messages to its own neighbor L- GWs to pre-register the HoA assigned and/or other IP addresses that may be used with created PMIP tunnels in case the WTRU handovers to one of these neighbor L-GWs.

[0178] As described herein, RA (e.g., router advertisement) and/or Dynamic Host

Configuration Protocol (DHCP), for example, may be used by the L-GW to advertise the IP addresses and/or prefix to the UE. The newly allocated IP address and the previous IP addresses in use by the WTRU may be specified. The previously allocated IP addresses may be advertised with a Lifetime and/or lease time set to zero, indicating“deprecating” IP addresses. As described herein, the WTRU may continue to use the deprecating IP addresses with the existing flows, but may not use them when starting a new flow.

[0179] A L-GW that may receive a proxy binding update (PBU) for a WTRU that may have been previously registered (e.g., a binding entry with no tunnel) may update the binding entry with the received CoA and may create a tunnel toward the new L-GW. Such a L-GW (e.g. receiving the PBU) may have been acting as a combined LMA and MAG and may be now acting as an LMA. The new L-GW may be acting as a MAG. In such an embodiment, the L-GW or LMA may delete the inactive binding created on neighbor L-GWs except for the L-GW that may have been effectively handed over by the UE (e.g. L-GW(MAG)). The new PMIP message Delete Binding Inactive (DBI) may be used to delete inactive entries on neighbor L-GWs. An ACK (DBA) message may also be returned.

[0180] In an embodiment, a L-GW or LMA that may have a tunnel for a WTRU and/or IP address and that may receive a PBU with lifetime=0 (e.g., close tunnel) may release the IP address allocated to the WTRU and may make it available for another WTRU.

[0181] According to example embodiments, a WTRU may go back to a previous L-GW as described herein. For example, when a WTRU may have obtained two IP addresses, for example, a HoAa from L-GWa and HoAb from L-GWb, the WTRU may have first connected to L-GWa and may then move to L-GWb. The L-GWa may be acting as the LMA for HoAa while L-GWb may be acting as a MAG for HoAa (e.g., an active tunnel may exist between the 2 L- GWs). In such an embodiment, the L-GWb may be acting as both LMA and MAG for the HoAb. As such, in embodiments, each of the neighbors may be pre-configured with information associated with the HoAs (e.g., HoA information).

[0182] Additionally, after some time, the WTRU may move back to L-GWa. The L-GWa may detect that the WTRU may be now directly connected to one of its HeNB and/or may delete the tunnel with the remote L-GWb that may be acting as a MAG for HoAa. In such an embodiment, the L-GWa may be now acting as LMA and MAG for HoAa. Additionally, to handle packets using HoAb, the L-GWa may create a tunnel with L-GWb (e.g., a previous MAG). For this HoAb, the current L-GWa may behave as a MAG and the previous MAG (e.g. L-GWb) may become the LMA.

[0183] When the WTRU may not be connected anymore to L-GWb, the L-GWb may send DBI messages to its neighbor L-GWs to delete the WTRU pre-registrations created earlier (e.g. when the UE connected to L-GWb). In an embodiment, L-GWa may advertise HoAa to the WTRU as“in use” and HoAb may be advertised as“deprecating.”

[0184] A tunnel lifetime when RA may be provided and/or used may be disclosed herein. To make sure that tunnels may not be maintained as active if not used anymore, a L-GW in which the WTRU may be connected and which may have tunnels created toward other L-GWs may count the number of IP packets that may be sent over the tunnels during a certain period of time (or may raise a flag).

[0185] At the expiration of this period (e.g., that may correspond to the lifetime of the tunnel), if IP packets may have been sent through the tunnel during the last period, the L-GW may extend the tunnel lifetime, for example, by sending another PBU. The counter of IP packets may be reset (e.g., set to zero). Additionally, for example, at the expiration of this period, if no IP packets may have been sent through the tunnel (e.g., in either direction) during the last period (e.g., the number of IP packets may be equal to 0), the tunnel may be closed where, for example, either no PBU may be sent to the LMA to extend the lifetime or a PBU with lifetime may be equal to 0 may be sent and the corresponding“inactive” binding entries on the neighbor L-GWs may be deleted using DBI message. To make sure that tunnels may not be prematurely closed (e.g., when still active but without data transmission and/or reception for a while), the tunnel lifetime may be set to a value that may be greater than the TCP lifetime that may guarantee transmission of“keepalive” IP packets to maintain the session alive. The binding entry corresponding to the closed tunnel on the currently connected L-GW may be deleted and the next RA sent to the WTRU may not include the HoA corresponding to that binding entry. The WTRU may stop using the removed IP address and/or prefix.

[0186] For UDP, since it may be a connectionless protocol, it may not have“keepalive” capability. Usually, a UDP socket may be“unconnected” such that connectivity may not have to be maintained. The source IP address that may be used to send UDP packets may be provided each time a packet may be sent. With L-GW evolution support, the selected source IP address may be a non-deprecating IP address and, as such, the UDP packet may not be sent through tunnels, but directly from the serving L-GW to the internet. For“connected” UDP sockets, the source IP address may be bound to the socket so packets sent through that socket may be sent using the same source IP address. On the receiving side, packets that may be received on the corresponding socket may use this IP address. In such an embodiment,“keepalive” IP packets may be sent over the socket to maintain connectivity. The WTRU or an application running on the WTRU may have to generate packets to maintain the UDP sessions opened (e.g., using the keepalive script). This may be provided on the UDP applications to support session continuity.

[0187] A tunnel lifetime when DHCP may be used may be disclosed herein. For example, when DHCP may be used to manage the allocated IP addresses, the WTRU may send a DHCP release message to the current L-GW or DHCP server when a“deprecating” IP address may not be used anymore. The L-GW that may receive this message may identify the L-GW which owns this IP address and may close the corresponding tunnel toward this L-GW.

[0188] In embodiments, an enhanced PMIPv6 protocol may also be provided and/or used. For example, new PMIP messages (e.g., four new PMIP messages) may be added to handle pre- registration of a WTRU on neighbor L-GWs. Such pre-registration may enable the creation of a PMIP tunnel between L-GWs such as two L-GWs (e.g. by providing the desired information to create the PMIP tunnel) when the WTRU may move to a neighbor L-GW.

[0189] In an embodiment, a new PMIP message associated with Create Binding Inactive (CBI) may be provided and/or used. Such a message may be a request to create an inactive binding entry on a neighbor L-GW. An inactivity timer may be associated with the inactive binding entry (e.g., as for a regular binding entry). In an embodiment, the CBI may be sent periodically to maintain the binding entry on the neighbor L-GW. An inactive binding entry that may time-out may be deleted. Additionally, both a sender and receiver of the CBI may maintain an inactivity timer per an inactive binding entry. An IP address (e.g., HoA) may be specified as well as the IP address of the L-GW that may own that IP address. A WTRU unique identifier may also be specified. [0190] According to an example embodiment, a new PMIP message associated with Create Binding Inactive Acknowledgement (CBA) may be provided and/or used. Such a message may be an acknowledgement to the CBI message. It may be returned to ACK the reception of the CBI.

[0191] A new PMIP message associated with Delete Binding Inactive (DBI) may be provided and/or used. Such a message may be sent to request the deletion of an inactive binding entry on a neighbor L-GW. The DBI may be sent by the L-GW that may have previously sent a CBI message. In an example embodiment, the DBI may be sent when the L-GW may notice, determine, or know that the WTRU may not be connected anymore (e.g., a HO to another L- GW). The DBI may also be sent when an L-GW may receive a PBU for this WTRU from another L-GW (e.g., the WTRU may have a HO and may not be directly connected anymore to the L-GW).

[0192] A new PMIP message associated with Delete Binding Inactive Acknowledgement (DBA) may be provided and/or used. Such DBA message may be sent to ACK the reception of the DBI message.

[0193] An alternative to introducing new messages in PMIP (e.g., for the

CBI/CBA/DBI/DBA) may be to modify Proxy Binding Update (PBU) and/or Proxy Binding Acknowledgement (PBA) messages. For example, the handoff indicator field may be set to, for example, five or another value indicating that this may be a pre-registration for a specified WTRU. An inactive PMIP tunnel may be created at that moment. When the WTRU may effectively perform a HO to this L-GW, information about the WTRU’s HoAs (or network prefix) may be already known (e.g., via pre-registration).

[0194] Another alternative may include modifying a flow mobility initiate (FMI) and/or a flow mobility acknowledge (FMA) message. For example, a FMI message may be sent instead of the CBI message to pre-register the WTRU. The FMI message may be modified to include the sending L-GW’s IP address and the IP addresses used by the WTRU and/or their associated state (e.g., in-use or deprecating). Additionally, other information that may be used for pre- registration may be included in the FMI message. Additionally, the FMI message may be used to remove the pre-registration, instead of a DBI message. In such an embodiment, the lifetime value may be set to 0. Additionally, the FMA may be used to acknowledge the pre-registration or removal of pre-registration.

[0195] Other network-based mobile protocols may be used to obtain session continuity based on the pre-registration method described herein. Additionally, features, embodiments, and/or enhancements similar to those described herein may be applied to these network-based mobile protocols.

[0196] Example embodiments (e.g., as shown in FIGs 16-20) may be described herein to illustrate, for example, the handling of a WTRU moving between L-GWs. Router Advertisement (RA) may be used to illustrate the IP address advertisement to the WTRU. In embodiment, the same logic may apply independently of the IP address allocation method that may be used.

[0197] For example, in one embodiment (e.g., a first embodiment), a WTRU may be moving. Such an embodiment may illustrate L-GW neighbors as shown in Table 3. The WTRU may be first attaching to L-GWa and may be moving to L-GWb and then to L-GWc.

[0198] FIG. 16 illustrates an example embodiment of mobility between L-GWs based on neighboring information (e.g. a first stage thereof). As shown in FIG. 16, at 51, L-GWs may be configured with neighbor information. For example, a L-GWa 1020a in a LHN 315a may be configured with information of its neighbor L-GWb 1020b in LHN 315b, L-GWb 1020b in LHN 1015b may be configured with information of its neighbors L-GWa 1020a in LHN 1015a and L- GWc 1020c in LHN 1015c, and L-GWc 1020c in LHN 1015c may be configured with information of its neighbor L-GWb 1020b in LHN 1015b.

[0199] As shown, at 52, a WTRU 1005 may connect to HeNBa2 such as HeNBa21010a. The HeNBa21010a may further be connected to the L-GWa 1020a. The L-GWa 1020a may allocate an IP address (e.g., HoAa) to the WTRU 1005.

[0200] At 53, L-GWa may act as LMA and may create a binding entry with no CoA or a CoA of null (e.g., indicating no tunnel being established). For example, the L-GWa 1020a may include a binding table and may create a binding entry with the CoA and/or an identifier of the WTRU 1005 (e.g., WTRU-ID) and/or the IP address thereof (e.g., HoAa).

[0201] At 54, the L-GWa 1020a may determine that L-GWb 1020b may be a neighbor. Based on such a determination, the L-GWa 1020a may pre-register the WTRU 1005 on L-GWb 1020b by sending, for example, a CBI.

[0202] In response to receiving the CBI, at 55, the L-GWb 1020b may be made aware that WTRU may be connected to L-GWa 1020a. For example, an inactive binding entry with the information for the L-GWa 1020a and WTRU 1005 may be created by the L-GWb 1020b in its binding table. The L-GWb 1020b may be ready to service the WTRU if it may connect to HeNBa1 1011a and/or HeNBa21010a.

[0203] At 56, the L-GWa 1020a may advertise the HoAa to the WTRU 1005 using RA. Data from and/or to WTRU 1005 may be going through the L-GWa 1020a (e.g., with no tunnel). [0204] FIG. 17 illustrates an example embodiment of mobility between L-GWs based on neighboring information (e.g. a second stage thereof). As shown in FIG. 17, at 57, a WTRU 1005 may handover to an eNB such as HeNBb1 211b that may be part of another network such as LHN 1015b, for example, from L-GWa 1020a in the network such as LHN 1015a. The HeNBb1 1011b may be in communication with or connected the L-GWb 1020b. In

embodiments, L-GWb 1020b may be in communication with or connected to other eNBs in the network such as HeNBb21010b as well.

[0205] During or after the handover, at 58, the L-GWb 1011b may be now serving the WTRU 1005. Since the WTRU 1005 may be pre-registered (e.g., after performing 54 and 55 of FIG. 16), the L-GWb 1020b may know that HoAa may be used by the WTRU 1005 and that may have been assigned by L-GWa 1020a. A tunnel may be created toward L-GWa 1020a such that the HoAa may still be used by the WTRU 1005 (e.g., to maintain connectivity during the handover). A new HoAb may be allocated to the WTRU 1005 from L-GWb 1020b and a binding entry with no tunnel may be created on L-GWb 1020b in its binding table.

[0206] At 59, the L-GWb 1020b may send a CBI to its neighbor L-GWc 1020, pre- registering the WTRU 1050 with its HoA (e.g., HoAa, HoAb). In such an embodiment, a binding entry may be created on the L-GWc 1020c in its binding table with an“inactive” state associated to HoAa. The binding table may include the CoA and/or an identifier of the WTRU 1005 (e.g., WTRU-ID) along with the IP addresses and state information. In response to the CBI, the L- GWc 1020c may reply with a CBA as described herein. The L-GWb 1020b may also pre-register HoAb with its neighbor L-GWa 1020a, for example, if the WTRU goes back to L-GWa 1020a (e.g., which is not shown in FIG. 17, but described herein).

[0207] At 60, the L-GWb 1020b may send a RA to the WTRU 1005 with HoAb and HoAa. The WTRU 1005 may keep these IP addresses with their state (e.g., HoAb“in use” and HoAa “deprecating”).

[0208] FIG. 18 illustrates an example embodiment of mobility between L-GWs based on neighboring information (e.g. a third stage thereof). As shown in FIG. 18, at 61, a WTRU 1005 may handover to another eNB in yet another network such HeNBc1 1011c in LHN 1015c. The HeNBc1 1011c may be connected to or in communication with L-GWc 1015c, which may further be connected to or in communication with other eNBs such as HeNBc21010c. The L- GWc 1015c may allocate an IP address (e.g., HoAc) to the WTRU 1005.

[0209] In response to such a handover, at 62, L-GWc 1020c may discover and/or determine that the WTRU 1005 may be pre-registered (e.g., may determine that inactive entries may exist in its binding table for this WTRU 1005). Based on such a determination, the entries may be activated. For example, a PBU may be sent to the creator of each entry such as L-GWb 1020b and L-GWa 1020a to create tunnels (e.g., as shown) that may be used to maintain connectivity. Additionally, the L-GWc 1020c may pre-register HoAc and/or HoAa with its neighbor L-GWb 1020b using CBI (e.g., which may not be not shown in FIG. 18)

[0210] At 63, the L-GWc 1020c may advertise the local IP address (e.g., HoAc) to the WTRU 1005. Additionally, at 63, the L-GWc 1020 may advertise the IP address associated with the tunnels (e.g., HoAa and/or HoAb) along with other information such as their states. In an embodiment, the WTRU 1005 may save these IP addresses with their corresponding states.

[0211] Furthermore, in an embodiment, a WTRU 1005 may be going back to a L-GW that it may have been previously connected to. Such an embodiment may be started when the WTRU 1005 may be connected to L-GWb 1020b (e.g., to a previous L-GW such as L-GWa 1020a when the WTRU 1005 may be connected to another L-GW such as L-GWb 1020b).

[0212] FIG. 19 illustrates an example embodiment of mobility between L-GWs based on neighboring information, for example, with the WTRU 1005 going back to the L-GWa 1020a. As shown in FIG. 19, at 64, a WTRU 1005 may handover back to HeNBa21010a.

[0213] In response to such a handover, at 65, the L-GWb 1020b may notice, determine, or detect that the WTRU 1005 may not be connected to it anymore and it may close the tunnel for HoAa with L-GWa 1020a. Alternatively or additionally, the L-GWa 1020a may detect that the WTRU 1005 may be connected and may terminate the tunnel with L-GWb 1020b. The L-GWa 1020a may then establish a tunnel for HoAb with L-GWb where with L-GWa being the MAG and L-GWb being the LMA.The L-GWc 1020c may pre-register HoAc and/or HoAa with its neighbor L-GWb 1020b using CBI (e.g., which may not be shown in FIG. 19)

[0214] At 66, the L-GWb 1020b may delete the WTRU pre-registration that it may have done with its neighbor L-GWc 1020c. For example, the L-GWb 1020b may send a DBI message that may be used to delete the information pre-registered on the L-GWc 1020c as described here. In response to such a message, the L-GWc 1020 may send a DBA message indicating such a pre- registration was deleted.

[0215] In an embodiment, at 67, the L-GWa 1020a may then send the IP addresses to the WTRU 1005 with new states (e.g. HoAa may now be the IP address“in use”), for example, using a RA message. The WTRU 1005 may then store such information as described herein.

[0216] According to an example embodiment, a tunnel lifetime may be shown. Such an embodiment may be started when a UE may be connected to L-GWb 1020b (e.g., after the WTRU 1005 may handover to the L-GWb 1020b from the the L-GWa 1020a as shown in FIG. 17). In such an embodiment, the UE may terminate flows that may have been using HoAa. L- GWb may notice , determine, or know that HoAa may not be used anymore and may delete the associated tunnel with the L-GW owner of HoAa and also may delete the pre-registrations with the neighbor L-GW for that IP address (e.g. HoAa).

[0217] FIG. 20 illustrates an example embodiment of mobility between L-GWs based on neighboring information showing a tunnel lifetime. As shown in FIG. 20, at 68, a WTRU 1005 may be connected to L-GWb 1020b. The L-GWb 1020b may count the number of packets sent through the tunnels to detect unused tunnels. For such a purpose, the L-GWb 1020b may maintain a tunnel lifetime table.

[0218] At 69, L-GWb 1020b may determine and/or detect that the tunnel toward, for example, one of the neighboring L-GWs may not be in use anymore. For example, the L-GWb 1020b may determine or detect that the tunnel toward L-GWa 1020a may not be used anymore. As such, in an embodiment, the L-GWb 1020b may close the tunnel.

[0219] At 70, the L-GWb 1020b may consider the L-GWa 1020a as a neighbor that the WTRU 1005 handover to. A WTRU pre-registration may be done on L-GWa 1020a (e.g., by sending a CBI as described herein) for HoAb as well as on the L-GWc 1020c (e.g., which may not be shown in FIG. 20).

[0220] At 71, L-GWb 1020b may delete the WTRU pre-registration for HoAa on neighbor L-GWc (e.g. using DBI as described herein) and, at 72, a new RA including only HoAb may be sent to the WTRU 1005 and/or information for the state thereof such that the WTRU 1005 may store such information.

[0221] Although the terms UE or WTRU may be used herein, it may and should be understood that the use of such terms may be used interchangeably and, as such, may not be distinguishable.

[0222] Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can 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 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 computer- readable storage media. Examples of 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.

Claims

What is claimed: 1. A method for providing distributed mobility management (DMM) to enable session connectivity to be maintained, the method comprising:

establishing, at a local gateway (L-GW), a connection with a wireless transmit receive unit (WTRU) that has relocated from a different network component associated with a different L-GW;

creating, at a local gateway (L-GW), a binding entry in a binding table for the WTRU; allocating, at the L-GW, an Internet Protocol (IP) address for the WTRU associated with the L-GW;

creating, at the L-GW, a tunnel with the different L-GW from which the WTRU relocated; and

sending, from the L-GW to the WTRU, the IP address allocated by the L-GW and at least an indication of at least one IP addresses that is deprecating.

2. The method of claim 1, further comprising:

registering , via the L-GW, the IP address with a mobility management repository (MMR).

3. The method of claim 2, further comprising:

receiving, at the L-GW from the MMR, at least one IP address allocated to the WTRU by at least the different L-GW and information associated therewith; and

updating, at the L-GW, the binding table to include the IP address allocated to the WTRU by at least the different L-GW and the information associated therewith.

4. The method of claim 3, further comprising:

querying, at the L-GW, the MMR to determine information associated with the IP address that is deprecating.

5. The method of claim 1, wherein the IP address that is deprecating incudes an IP address allocated by the different L-GW to the WTRU.

6. The method of claim 1, wherein the L-GW is in a different local home network than the different L-GW.

7. A wireless transmit receive unit (WTRU) configured to provide distributed mobility management (DMM) to enable session connectivity to be maintained, the WTRU configured to: establish a connection with a network component in a local gateway (L-GW) via an IP address allocated by the L-GW;

determine whether the WTRU is further connected to another L-GW; and

create a tunnel with the other L-GW to maintain session continuity for flows associated with an IP address allocated to the WTRU by the other L-GW.

8. The WTRU of claim 7, wherein the WTRU is further configured to:

update a binding table to create an entry for the IP address allocated by the L-GW.

9. The WTRU of claim 7, wherein the WTRU is further configured to:

update an entry for the IP address allocated by the other L-GW.

10. The WTRU of claim 7, wherein the L-GW is in a local home network and the different L- GW is in a different home network.

11. A method for providing distributed mobility management (DMM) to enable session connectivity to be maintained, the method comprising:

establishing, at a local gateway (L-GW), a connection with a wireless transmit receive unit (WTRU) via a network component and a connection with a mobility management entity (MME)– serving gateway (SGW) proxy;

allocating, via the L-GW, an Internet Protocol (IP) address for the WTRU associated with the L-GW using the MME-SGW proxy such that the core network is not involved in the allocation; and

registering , from the L-GW, the IP address with an ANDSF server.

12. The method of claim 11, wherein the IP address is registered with the ANDSF server directly from the L-GW via an interface therebetween.

13. The method of claim 11, wherein the IP address is registered with the ANDSF server using a component in the core network in communication with the MME-SGW proxy.

14. A local gateway (L-GW) for providing distributed mobility management (DMM) to enable session connectivity to be maintained, the L-GW configured to:

determine whether one or more other L-GWs are neighbors;

pre-register a wireless transmit receive unit (WTRU) connected to the L-GW with the one or more L-GWs that are neighbors; and

create a tunnel between the L-GW and the one or more other L-GWs that are neighbors based on the pre-registration to maintain session continuity during a handover.

15. The L-GW of claim 14, wherein the one or more L-GWs that are neighbors are configured to pre-register the WTRU connected to the L-GW by updating a binding entry in a binding table with an IP address allocated by the L-GW to the WTRU, a state of the IP address, and an identifier of the WTRU.

16. The L-GW of claim 14, wherein the WTRU connected to the L-GW is pre-registered via a create binding inactive (CBI) message.

17. The L-GW of claim 15, further configured to:

receive a create binding acknowledgement (CBA) message to acknowledge the pre- registration of the WTRU connected to the L-GW at the one or more other L-GWs.

18. The L-GW of claim 14, wherein the L-GW is further configured to send a router advertisement (RA) to the WTRU with the IP address and state thereof allocated to the WTRU by the L-GW and an IP address and state thereof allocated to the WTRU by the one or more L- GWs that are neighbors.

19. The L-GW of claim 14, wherein the L-GW is further configured to:

maintain the tunnel until at least one of the following: the other L-GWs are no longer neighboring or an IP address allocated to the WTRU by the L-GW is not used anymore.

20. The L-GW of claim 14, wherein the L-GW is in a local home network and the one or more other L-GWs are connected to one or more different local home networks.