WO2015031271A2

WO2015031271A2 - Methods, apparatus and systems for distributed mobility management using enhanced converged gateway

Info

Publication number: WO2015031271A2
Application number: PCT/US2014/052551
Authority: WO
Inventors: John Cartmell; Murali REDDIBOYANA; Sunil SURANNA; Chandrakanth GOWDA; Michelle Perras; MistryMegha JAYANTHILAL
Original assignee: Interdigital Patent Holdings, Inc.
Priority date: 2013-08-30
Filing date: 2014-08-25
Publication date: 2015-03-05
Also published as: WO2015031271A3

Abstract

Methods, apparatus, and systems are implemented for pre-registration, and handover of wireless transmit/receive units (WTRUs) using enhanced Converged Gateway (eCGWs). In one method, network entity discovery is performed by: sending pre-registration information to register a first network entity with a registration entity; and receiving, from the registration entity.

Description

METHODS, APPARATUS AND SYSTEMS FOR DISTRIBUTED MOBILITY MANAGEMENT USING ENHANCED CONVERGED GATEWAY

FIELD

[0001] The present invention relates to the field of wireless communications and, more particularly, to methods, apparatus and systems for distributed mobility management (DDM) using Enhanced Converged Gateway (eCGW).

SUMMARY

Representative embodiments include methods, apparatus, and systems for pre-registration, and handover of wireless transmit/receive units (WTRUs) using enhanced Converged Gateway (eCGWs). In one method, network entity discovery may be performed by: sending pre-registration information to register a first network entity with a registration entity; and receiving, from the registration entity.

BRIEF DESCRIPTION OF THE DRAWINGS

[0002] A more detailed understanding may be had from the Detailed Description below, given by way of example in conjunction with drawings appended hereto. Figures in such drawings, like the detailed description, are examples. As such, the Figures and the detailed description are not to be considered limiting, and other equally effective examples are possible and likely. Furthermore, like reference numerals in the Figures indicate like elements, and wherein:

FIG. 1 is a system diagram illustrating an example communications system in which one or more disclosed embodiments may be implemented;

FIG. 2 is a system diagram illustrating an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1 ;

FIG. 3 is a system diagram illustrating an example radio access network and another example core network that may be used within the communications system illustrated in FIG. 1 ;

FIG. 4 is a system diagram illustrating another example radio access network and another example core network that may be used within the communications system illustrated in FIG. 1 ;

FIG. 5 is a system diagram illustrating a further example radio access network and a further example core network that may be used within the communications system illustrated in FIG. 1 ;

FIG. 6 is a diagram illustrating a representative eCGW architecture;

FIG. 7 is a diagram illustrating a representative DMM flow before and after a handover procedure;

FIG. 8 is a diagram illustrating a representative DMM flow before and after user mobility among WiFi Access Points (APs);

FIG. 9 is a diagram illustrating a representative Distributed Assist Management Node (DAMN) architecture;

FIG. 10 is a diagram illustrating a representative eCGW bringup procedure;

FIG. 1 1 is a diagram illustrating a representative UE (or WTRU) Attach procedure; FIG. 12 is a diagram illustrating a representative S1 handover procedure;

FIG. 13 is a diagram illustrating a representative create session failure procedure;

FIG. 14 is a diagram illustrating a representative modify bearer failure procedure;

FIG. 15 is a diagram illustrating a representative modify bearer timeout failure procedure; FIG. 16 is a diagram illustrating a representative resource allocation failure procedure; FIG. 17 is a diagram illustrating a representative handover notify timer expiry procedure; FIG. 18 is a diagram illustrating a representative TSI RELOCOverall timer expiry procedure;

FIG. 19 is a diagram illustrating a representative TSI RELOCPrep timer expiry procedure; FIG. 20 is a diagram illustrating a representative TRRCUEAcquisition timer expiry procedure;

FIG. 21 is a diagram illustrating a representative handover cancel procedure;

FIG. 22 is a diagram illustrating a representative mobility procedure;

FIG. 23 is a diagram illustrating a representative WiFi DMM procedure;

FIG. 24 is a diagram illustrating another representative WiFi DMM procedure;

FIG. 25 is a diagram illustrating representative eCGWs with a plurality of small cell networks (SCNs);

FIG. 26 is a diagram illustrating a further representative WiFi DMM mobility procedure;

FIG. 27 is a diagram illustrating an additional representative WiFi DMM procedure;

FIG. 28 is a diagram illustrating a representative DMM flow before and after a cellular handover procedure;

FIG. 29 is a diagram illustrating another representative S1 handover procedure;

FIG. 30 is a diagram illustrating a representative eCGW user data session across SCNs;

FIG. 31 is a diagram illustrating a representative UE registration procedure;

FIG. 32 is a diagram illustrating another representative UE registration procedure;

FIG. 33 is a diagram illustrating a representative transmission procedure;

FIG. 34 is a diagram illustrating another representative transmission procedure;

FIG. 35 is a flow diagram of a representative method for registration of a first network entity with other network entities;

FIG. 36 is a flow diagram of another representative method for registration of a first network entity with other network entities;

FIG. 37 is a flow diagram of a representative method for a handover of a WTRU 1 to a network access point (AP) using a first network entity and a second network entity;

FIG. 38 is a flow diagram of a representative method for a handover of a WTRU 102-1 between a first network AP and a second network AP using a first network entity and a second network entity; FIG. 39 is a flow diagram of another representative method for a handover of a WTRU between a first network AP and a second network AP using the first network entity and a second network entity;

FIG. 40 is a flow diagram of a representative method for managing assignments of a gateway to network APs;

FIG. 41 is a flow diagram of a representative method for controlling a handover of a WTRU from a source network Access Point AP to a target network AP:

FIG. 42 is a flow diagram of a representative method for a handover of a WTRU from a WiFi AP associated with a second network entity to a WiFi AP 640-2 associated with the first network entity;

FIG. 43 is a flow diagram of a representative method for communication between or among a plurality of WTRUs; and

FIG. 44 is a flow diagram of a representative method for communication between or among at least first and second wireless transmit/receive units (WTRUs).

DETAILED DESCRIPTION

[0003] A detailed description of illustrative embodiments may now be described with reference to the figures. However, while the present invention may be described in connection with representative embodiments, it is not limited thereto and it is to be understood that other embodiments may be used or modifications and additions may be made to the described embodiments for performing the same function of the present invention without deviating therefrom.

[0004] Although the representative embodiments are generally shown hereafter using wireless network architectures, any number of different network architectures may be used including networks with wired components and/or wireless components, for example.

[0005] FIG. 1 is a diagram illustrating 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.

[0006] As shown in FIG. 1 , the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network 106/107/109, a public switched telephone network (PSTN) 108, the Internet 1 10, and other networks 1 12, 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, 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, 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. The WTRU 102a, 102b, 102c and 102d is interchangeably referred to as a UE.

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

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

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

[0010] 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 1 14a in the RAN 103/104/105 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 1 15/1 16/1 17 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 (DL) Packet Access (HSDPA) and/or High-Speed UL Packet Access (HSUPA).

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

[0012] In other embodiments, the base station 1 14a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.1 1 (i.e., Wireless Fidelity (WiFi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1 X, 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.

[0013] The base station 1 14b in FIG. 1 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 1 14b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.1 1 to establish a wireless local area network (WLAN). In another embodiment, the base station 1 14b 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 1 14b 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. 1 , the base station 1 14b may have a direct connection to the Internet 1 10. Thus, the base station 1 14b may not be required to access the Internet 1 10 via the core network 106/107/109.

[0014] 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, 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. 1 , 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, UMTS, CDMA 2000, WiMAX, or WiFi radio technology.

[0015] The core network 106/107/109 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 1 10, and/or the other networks 1 12. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 1 10 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/or the internet protocol (IP) in the TCP/IP internet protocol suite. The networks 1 12 may include wired and/or wireless communications networks owned and/or operated by other service providers. For example, the networks 1 12 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.

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

[0017] FIG. 2 is a system diagram illustrating an example WTRU 102. As shown in FIG. 2, the WTRU 102 may include a processor 1 18, 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/or other peripherals 138, among others. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0018] The processor 1 18 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 1 18 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 1 18 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While FIG. 2 depicts the processor 1 18 and the transceiver 120 as separate components, it will be appreciated that the processor 1 18 and the transceiver 120 may be integrated together in an electronic package or chip.

[0019] The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 1 14a) over the air interface 1 15/1 16/1 17. 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/or 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. [0020] Although the transmit/receive element 122 is depicted in FIG. 2 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 1 15/1 16/1 17.

[0021] 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.1 1 , for example.

[0022] The processor 1 18 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 1 18 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. In addition, the processor 1 18 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 1 18 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).

[0023] The processor 1 18 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.

[0024] The processor 1 18 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 1 15/1 16/1 17 from a base station (e.g., base stations 1 14a, 1 14b) 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.

[0025] The processor 1 18 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 and/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.

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

[0027] As shown in FIG. 3, the Node-Bs 140a, 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, 140c may communicate with the respective RNCs 142a, 142b via an lub interface. The RNCs 142a, 142b may be in communication with one another via an lur interface. Each of the RNCs 142a, 142b may be configured to control the respective Node-Bs 140a, 140b, 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.

[0028] The core network 106 shown in FIG. 3 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.

[0029] The RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an luCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices.

[0030] The RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via an luPS interface. The SGSN 148 may be connected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, 102c with access to packet- switched networks, such as the Internet 1 10, to facilitate communications between and the WTRUs 102a, 102b, 102c and IP-enabled devices. [0031] As noted above, the core network 106 may also be connected to the other networks 1 12, which may include other wired and/or wireless networks that are owned and/or operated by other service providers.

[0032] FIG. 4 is a system diagram illustrating 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, 102c over the air interface 1 16. The RAN 104 may also be in communication with the core network 107.

[0033] The RAN 104 may include eNode-Bs 160a, 160b, 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, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 1 16. In one embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and/or receive wireless signals from, the WTRU 102a.

[0034] Each of the eNode-Bs 160a, 160b, 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 UL and/or DL, and the like. As shown in FIG. 4, the eNode- Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

[0035] The core network 107 shown in FIG. 4 may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. While each of the foregoing elements are depicted as part of the core network 107, it will be appreciated that any of these elements may be owned and/or operated by an entity other than the core network operator.

[0036] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c 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, 102c, bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and/or WCDMA.

[0037] The serving gateway 164 may be connected to each of the eNode Bs 160a, 160b, 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, 102c. The serving gateway 164 may perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like. [0038] The serving gateway 164 may be connected to the PDN gateway 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 1 10, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0039] The core network 107 may facilitate communications with other networks. For example, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 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, 102c with access to the other networks 1 12, which may include other wired and/or wireless networks that are owned and/or operated by other service providers.

[0040] FIG. 5 is a system diagram illustrating 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, 102c over the air interface 1 17. As will be further discussed below, the communication links between the different functional entities of the WTRUs 102a, 102b, 102c, the RAN 105, and the core network 109 may be defined as reference points.

[0041] As shown in FIG. 5, the RAN 105 may include base stations 180a, 180b, 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, 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, 102c over the air interface 1 17. In one embodiment, the base stations 180a, 180b, 180c may implement MIMO technology. The base station 180a, for example, may use multiple antennas to transmit wireless signals to, and/or receive wireless signals from, the WTRU 102a. The base stations 180a, 180b, 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.

[0042] The air interface 1 17 between the WTRUs 102a, 102b, 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, 102c may establish a logical interface (not shown) with the core network 109. The logical interface between the WTRUs 102a, 102b, 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. [0043] The communication link between each of the base stations 180a, 180b, 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, 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, 100c.

[0044] As shown in FIG. 5, the RAN 105 may be connected to the core network 109. The communication link between the RAN 105 and the core network 109 may be 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 of these elements may be owned and/or operated by an entity other than the core network operator.

[0045] The MIP-HA 184 may be responsible for IP address management, and may enable the WTRUs 102a, 102b, 102c to roam between different ASNs and/or different core networks. The MIP-HA 184 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 1 10, to facilitate communications between the WTRUs 102a, 102b, 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, 102c with access to circuit- switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. The gateway 188 may provide the WTRUs 102a, 102b, 102c with access to the other networks 1 12, which may include other wired and/or wireless networks that are owned and/or operated by other service providers.

[0046] Although not shown in FIG. 5, it will be appreciated that the RAN 105 may be connected to other ASNs, other RANS (e.g., RANs 103 and/or 104) and/or the core network 109 may be connected to other core networks (e.g., core network 106 and/or 107. The communication link between the RAN 105 and the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating the mobility of the WTRUs 102a, 102b, 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.

[0047] Although the WTRU is described in FIGS. 1-5 as a wireless terminal, it is contemplated that in certain representative embodiments that such a terminal may use (e.g., temporarily or permanently) wired communication interfaces with the communication network.

[0048] In certain representative embodiments, DMM procedures may be based on pre-registration with neighbors. [0049] In certain representative embodiments, a system for supporting DMM functionality may include a distributed eCGW environment and may use one or more cellular and/or WiFi interfaces. In the system procedures, GTP tunnels (e.g., GTP binding tables) may be used, however, other variations are possible, for example, PMIP tunnel can be established between eCGWs in lieu of or in addition to the GTP tunnels (GTP binding tables).

[0050] It is contemplated that the DMM procedures that use pre-registration with neighbors may include one or more of the following: (1 ) a direct data forwarding mechanism between HeNBs (e.g., HeNB1 and HeNB2) to forward the data (UL/DL) from the HeNB1 to the HeNB2 during S1 handover. Other data forwarding, however, may be possible. For example, an indirect data forwarding mechanism may be used between H(e)NB1 and H(e)NB2 (e.g., HeNB1 ->eCGW1 - >eCGW2 ->HeNB2) for S1 handover and/or handover prototyping.

[0051] It is contemplated that both IPv4 and IPv6 may be used for UE and Edge Server Form (ESF).

[0052] It is contemplated that the eCGW may be co-located with a Dynamic Host Configuration Protocol (DHCP) server.

[0053] It is contemplated that each eCGW may be pre-configured with its own pool of private IP addresses (IPv4/IPv6).

[0054] It is contemplated that the eCGW may not allocate the same private IP address to multiple UEs.

[0055] It is contemplated that there may be no overlap between the pools of private IP addresses allocated to the eCGWs (e.g., that are configured as neighbors).

[0056] It is contemplated that the eCGW may implement NAT functionality.

[0057] It is contemplated that the eCGW may be pre-configured with a list of its neighbor eCGWs.

[0058] It is contemplated that the eCGW may obtain the UE's unique identifier to be used with

PMIP/GTP registration/pre-registration.

[0059] It is contemplated that GTP protocol and/or PMIP protocol may be used between eCGWs.

[0060] It is contemplated that the UE may specify that DHCP may be used for the IP address allocation when establishing a cellular connection.

[0061] In certain representative embodiments, a Non-Access Stratum (NAS) Packet Data Network (PDN) CONNECTIVITY REQUEST may include Protocol Configuration Options elements in the NAS message to indicate that the UE is expecting an IP address allocation later (e.g., after a default bearer setup).

[0062] It is contemplated that the MME in the Mobile Core Network (MCN) is DMM-enabled.

[0063] It is contemplated that the MME may select an eCGW that may behave as the anchor for a created session.

[0064] It is contemplated that the MME may initiate a session creation with the selected eCGW by sending a Create Session Request message.

[0065] It is contemplated that the PGW may assign IPv4 addresses (e.g., only IPV4 addresses). [0066] It is contemplated that the eCGW may receive and/or may send IPv6 packets over the cellular network (e.g., only over the cellular network).

[0067] It is contemplated that the eCGW may receive and/or send IPv4 packets over cellular and/or WiFi.

Representative Distributed Mobility Management (DMM) Architecture

[0068] FIG. 6 is a diagram illustrating a plurality of eCGWs (e.g., eCGWs 620-1 and 620-2) in a representative eCGW architecture 600.

[0069] Referring to FIG. 6, the eCGW architecture 600 may include a small cell network (SCN) 610 and/or a public Internet 650 and an ESF 670.

[0070] The SCN 610 may include, for example, one or more eCGWs 620-1 or 620-2, one or more H(e)NBs 630-1 and 630-2 communicatively coupled to the eCGWs 620-1 or 620-2 and/or one or more WiFi APs 640-1 and 640-2 communicatively coupled to the eCGWs 620-1 or 620-2, respectively. One or more UEs 102-1 , 102-2 and 102-3 may communicate via any of the APs (e.g., the H(e)NBs 630-1 and 630-2 and/or the WiFi APs 640-1 and 640-2).

[0071] Although only two eCGWs 620-1 and 620-2 are shown, any number of eCGWs may be used in this architecture. For example as disclosed herein, a further eCGW (eCGW3) is disclosed, for example, to provide details of operation of an eCGW that is not directly involved in an operations between or among WTRUs 102-1 , 102-2 and/or 102-3.

[0072] Each eCGW 620-1 and 620-2 may include a DHCP server 622, a Domain Name System (DNS) server 624, a CE-Gateway (CE-GW) 626, and an IP Traffic Gateway 628. In certain representative embodiments, a control/data interface 629 may be provided between eCGWs (e.g., eCGW 620-1 and 620-2).

[0073] The ESF 670 may include an ESF Control and Management System (ECMS) 672 and/or a virtual edge server 674.

[0074] The public Internet 650 may include a CDN/content server 652, a Security Gateway (SeGW) 654 and/or an Evolved Packet Core (EPC) 660. The EPC 660 may include a Content Enablement Server (CES) 662, and/or a Mobility Management Entity (MME)/Serving Gateway (SGW) 664. The eCGWs 620-1 and 620-2 with added or enhanced features may be used to support Distributed Mobility Management (DMM) and local, edge based caching. UEs (e.g., UE 102-1 , 102-2 and 102-3) with added or enhanced features or functionality may also be used to support DMM. The DMM network functionality may be provided within the IP Traffic Gateway 628. The IP Flow Mobility (IFOM)/SIPTO feature in the eCGW 620-1 and 620-2 may be reused and/or augmented with DMM logic as described herein.

[0075] The DMM may maintain data sessions when a user device (e.g., UE 102-1 , 102-2 and/or 102-3) is mobile and/or transitions between the H(e)NBs (e.g., H(e)NB 630-1 and 630-2), which may be managed by different eCGWs 620-1 and 620-2, respectively. The DMM may maintain data sessions when the user device (e.g., UE 102-1 , 102-2 and/or 102-3) is mobile and/or transitions between WiFi APs (e.g., WiFi AP 640-1 and 640-2), which may be managed by the different eCGWs 620-1 and 620-2, respectively.

[0076] The UEs 102-1 , 102-2 and/or 102-3 may use IPv6 and the DHCP server 622 located within the eCGW 620-1 and/or 620-2 may support IPv6.

[0077] In certain representative embodiments, the EPC 660 may support procedures for the UE 102-1 , 102-2 and 102-3 to request an IP connection using an IPv6 deferred address assignment option. The eCGW 620-1 and 620-2, the H(e)NB 630-1 and 630-2 and/or the EPC 660 may use IPv4 for their own addresses and/or may use IPv6 addresses. For example, the GPRS Tunneling Protocol (GTP) tunnel between the eCGW 620-1 or 620-2 and the H(e)NB 630-1 or 630-2 may use IPv4. The EPC 660, the eCGW 620-1 or 620-2 and/or the H(e)NB 630-1 or 630-2 may support UEs 102-1 , 102-2 and 102-3 that use IPv6 and/or IPv4, for example.

[0078] The MME 664 may use the Access Point Name (APN) name field of the NAS PDN Connection Request to discern whether to use the SGW/PGW 664 of the EPC 660 or use the eCGW 620-1 or 620-2, as the SGW/PGW 664. The eCGW 620-1 or 620-2 may support IP Flow Mobility (IFOM) for an IPv4 UE 102-1 , 102-2 and/or 102-3 and/or an IPv6 UE 102-1 , 102-2 and/or 102-3.

[0079] The Control/Data interface 680 between the CE-GW 626 and Content Delivery Network (CDN)/Content Provider 652 may not contain actual content. The CDN server 652 may contain or include information collected by the CE-GW 626 relevant to caching that is provided to the CDN/Content Server/Content Provider 652.

[0080] FIG. 7 is a diagram 700 illustrating a representative DMM flow before and after a handover procedure.

[0081] Referring to FIG. 7, the flow of data before and after the UE 102-1 is handed over from one H(e)NB 630-1 to another H(e)NB 630-2 is illustrated. Prior to the handover, the data may travel on a first path 710 between the UE 102-1 and the CDN 652 via the H(e)NB 630-1 , and the IP Traffic Gateway 628 in the eCGW 620-1 . After the UE 102-1 has completed a handover to the H(e)NB 630-2, a Proxy Mobile IP (PMIP) tunnel or GPRS Tunneling Protocol (GTP) tunnel (e.g., via the control/data interface 629) may be created between the eCGWs 620-1 and 620-2 and data for the existing sessions between the UE 102-1 and CDN 652 may use a second path 720 (e.g., via the H(e)NB 630-2, the IP Traffic Gateway 628 in the eCGW 620-2, and IP Traffic Gateway 628 in the eCGW 620-1 ). "Existing sessions" generally refers to applications running prior to the handover. The data for any data session or application started after the handover has occurred may travel on a third path 730 between the UE 102-1 and the CDN 652 via the H(e)NB 630-2, and the IP Traffic Gateway 628 in the eCGW 620-2. The eCGW 620-2 may discern which traffic is routed into the GTP/PMIP tunnel and which is routed directly to the CDN 652 based on the source IP address used by the UE 102-1 .

[0082] FIG. 8 is a diagram 800 illustrating a representative DMM flow before and after user mobility among WiFi Access Points (APs) 640-1 and 640-2. [0083] Referring to FIG. 8, the DMM flow of data before and after the UE 102-1 moves from the coverage area of a WiFi AP 640-1 to the coverage area of the WiFi AP 640-2 is illustrated. Prior to the handover, the data may travel on a first path 810 between the UE 102-1 and the CDN 652 via WiFi AP 640-1 and IP Traffic Gateway 628 in the eCGW 620-1. After the UE 102-1 has moved from WiFi AP 640-1 coverage area to that area covered by the WiFi AP 640-2, a GTP/PMIP tunnel may be created between the eCGWs 620-1 and 620-2 (e.g., over the control/data interface 629) and data for the existing sessions between the UE 102-1 and the CDN 652 may use a second path 820 (e.g., via the WiFi AP 640-2, the IP Traffic Gateway 628 in the eCGW 620-2, and IP Traffic Gateway 628 in the eCGW 620-1. The data for any data session or application started after the handover has occurred may travel on a third path 830 between the UE 102-1 and the CDN 652 via the WiFi AP 640-2 and IP Traffic Gateway 628 in the eCGW 620-2. The eCGW 620-2 may discern which traffic is routed into the GTP/PMIP tunnel and which traffic is routed directly to the CDN 652 based on the source IP address used by the UE 102-1.

Representative Distributed Assist Management Node (DAMN)

[0084] FIG. 9 is a diagram illustrating a representative Distributed Assist Management Node (DAMN) 910.

[0085] Referring to FIG. 9, architecture 900 for the DAMN 910 is illustrated. The DAMN 910 may be used to facilitate GTP/PMIP tunnel establishment between the eCGWs 620-1 and 620-2, for example, when the eCGWs 620-1 and 620-2 are not neighbors. The DAMN 910 may reside outside of the SCNs 610-1 and 610-2. The eCGWs 620-1 and 620-2 (e.g., every eCGW) may implement pre-registration with the DAMN 910 along with its neighbor eCGWs. When the UE 102- 1 moves from the SCN 610-1 (e.g., with an attachment to WiFi AP 620-1 not shown) to the eCGW 620-2 that belongs to the SCN 610-2, the target eCGW (e.g., eCGW 620-2 may learn IP details of the UE 102-1 (e.g., assigned by the source eCGW 610-1 ) from the DAMN 910, which may enable the target eCGW 620-2 to establish one or more GTP/PMIP tunnels with the source eCGW 620-1 to have seamless download/upload of the data traffic between the source eCGW 620-1 and the target eCGW 620-2.

The interface between the eCGW 620-1 and 620-2 and the DAMN 910 may be a TR-069 interface, a RESTful interface, or any other proprietary or non-proprietary interface.

Representative System Procedures

[0086] In certain representative embodiments, system procedures may be implemented to support DMM by the eCGWs 620-1 and 620-2 and the UEs 102-1 , 102-2 and 102-3. For example, the eCGW 620-1 and/or 620-2 may pre-register with the DAMN 910 along with other eCGWs (e.g., neighbors and/or non-neighbors), when an IP address is assigned to the UE 102-1 , 102-2 and/or 102-3.

[0087] FIG. 10 is a diagram illustrating a representative eCGW bringup procedure 1000.

[0088] Referring to FIG. 10, the representative procedure 1000 may be used to bring up (e.g., initialize or start) the eCGW 620-1 and/or 620-2. The eCGWs 620-1 and 620-2 may mimic the behavior of an H(e)NB 6-30-1 and 630-2 towards the SeGW 654, a DNS Server 1002 within the Evolved Packet Core (EPC) 660 and an H(e)MS 1004. The eCGWs 620-1 and 620-2 may form a secure association using IP Sec with the SeGW 654. The eCGWs 620-1 and 620-2 may resolve the H(e)MS Fully Qualified Domain Name (FQDN) with the DNS Server 1002 within the EPC 660. The eCGWs 620-1 and 620-2 may contact the H(e)MS 1004 and a TR-069 session may be used for the eCGWs 620-1 and 620-2 to learn or detect the FQDN and/or IP address of the MME 664.

[0089] For example, at 1005, the eCGW 620-1 may power-up and, at 1010, the eCGW 620-2 may power-up. At 1015, the eCGW 620-1 may get a Local Area Network (LAN) IP address from a public DNS server 1006. At 1020, the eCGW 620-1 may send a DNS Request to the public DNS server 1006 indicating the FQDN of the SeGW 654. At 1025, the public DNS server 1006 may send a DNS Response to the eCGW 620-1 indicating the IP address of the SeGW 654. At 1030, the eCGWs 620-1 may form a secure association using IP Sec with the SeGW 654. At 1035, the eCGWs 620-1 may resolve the H(e)MS FQDN with the DNS server 1002 within the EPC 660. At 1040, the eCGWs 620-1 may contact the H(e)MS 1004 and the TR-069 session may be used for the eCGWs 620-1 to learn or detect the FQDN and/or IP address of the MME 664.

[0090] In certain representative embodiments, provisioning of the IP Traffic GW 628 in the eCGW 620-1 may be accomplished by the H(e)MS and/or the MME 644. In a first embodiment, the IP Traffic GW 628 of the eCGW 620-1 may be provisioned by the H(e)MS. In a second embodiment, the IP Traffic GW 628 of the eCGW 620-1 may be provisioned by the MME 664. The IP Traffic GW 628 may receive any of the following items including: (1 ) a list of neighbor eCGWs 620-2; (2) a list of IP addresses that the eCGW 620-1 can assign to UEs 102-1 , 102-2 and/or 102-2, which are connecting to the eCGW 620-1 ; (3) a global ID of the eCGW 620-1. For the first embodiment, at 1045, the items may be provided by the H(e)MS 1004 and in the second embodiment, at 1050 and 1055 the items may be provided by the MME 664 via a request from the eCGW 620-1 to the MME 664 and a response to the request from the MME 664 to the eCGW 620-1.

[0091] At 1060, the eCGWs 620-1 and 620-2 may discover each other (based on the provisioned neighbor list. At 1065, the eCGWs 620-1 and 620-2 may perform mutual authentication.

Representative Options 1 and 2

[0092] The first embodiment generally refer to section 5 of "TR069 API Specification for DMM", the contents of which are incorporated herein by reference, and may use a TR-069 data model to support the provisioning of information to the eCGW 620-1 by the H(e)MS 1004. The second embodiment may use additional signals to be exchanged over an S1 AP interface. The signals may be exchanged between the eCGW 620-1 and the MME 664. These signals/messages may be added to an existing S1 AP interface.

[0093] There may be one or more new signals/messages including: (1 ) a GW Configuration Request message; (2) a GW Configuration Response message; and/or (3) a GW Configuration Failure message. [0094] Although representative options 1 and 2 are illustrated, other options may exist including when the DAMN 910 is used for provisioning of information to the eCGW 620-1. For example, signaling may be exchanged between the DAMN 910 and the eCGW 620-1 over an interface to enable such provisioning.

Representative S1AP: GW Configuration Request Message

[0095] The GW Configuration Request message may be sent by the eCGW 620-1 to the MME 664 to request to download the eCGWs own IP address, the UE IP pool segment and/or the eCGWs neighbor list. Tables 1 and 2 illustrate details of a GW Configuration Request Message. Direction: eCGW -> MME

Table 1 - GW Configuration Request

Table 2 - Global eCGW ID field

Representative S1AP: GW Configuration Response Message

[0096] The GW Configuration Response message may be sent by the MME 664 to the eCGW 620-1 with the requested eCGW's IP address, the UE start and end IP addresses and the eCGWs neighbor list. Table 3 illustrates details of the GW Configuration Response Message.

Direction: MME -> eCGW

Table 3 - GW Configuration Response

Representative S1AP: GW Configuration Failure Message

[0097] This S1AP: GW Configuration Failure message may be sent by the MME 664 to the eCGW 620-1 to indicate the eCGW Configuration failure. Table 4 illustrates details of the GW Configuration Failure Message.

Direction: MME -> eCGW

Table 4 - GW Configuration Failure

9.2.1.61 : Representative Time to wait

[0098] This IE may define the minimum allowed waiting times.

Representative UE Attach (DMM)

[0099] FIG.1 1 is a diagram illustrating a representative UE (or WTRU) Attach procedure 1 100.

[0100] Referring to FIG. 1 1 , the Attach procedure 1 100 may enable the UE 102-1 to communicate via the eCGW 620-1. At 1 106, the UE 102-1 may power up. At 1 108, the UE 102-1 and the H(e)NB 630-1 may work together to establish an RRC Connection. At 1 1 10, the UE 102-1 may send a NAS Attach/PDN Connection Request message towards the MME 664 via the H(e)NB 630-1. In the NAS PDN Connection Request, the UE 102-1 may indicate the SCN 610, as the APN(DMM APN), and may indicate that the UE 102-1 may desire (e.g., or wish) to use the deferred IPv6 address allocation option (PCO indicating DHCPv6). At 1 1 12, the H(e)NB 630-1 may encapsulate the NAS signals in an S1AP: Initial UE message and may send the message to the MME 664. The MME 664 may remove the S1 encapsulation and process the NAS messages. At 1 1 14 and 1 1 16, the MME 664 may query and receive from the Home Subscriber Server (HSS) 1 102 authentication parameters for this particular user. At 1 1 18, the MME 664 may send a NAS Authentication Request to the H(e)NB 630-1 via S1 signaling.

[0101] After the S1 signaling reaches the H(e)NB 630-1 , the S1 wrapper may be removed and the NAS signaling may be sent to the UE 102-1 , at 1 120. After calculating the proper response, at 1 122, the UE 102-1 may send a NAS Authentication Response to the H(e)NB 630-1. The H(e)NB 630-1 may encapsulate the NAS Authentication Response via a S1AP UL NAS Transport and, at 1 124, may push it to the MME 664. After 1 124, the MME 664 may ensure the response is valid and if so, at 1 126, the MME 664 may update the location of the UE 102-1 with the HSS 1 102. At 1 128, the HSS 1 102 may acknowledge that the HSS received the location update. The UE's subscription information may be downloaded to the MME 664 from the HSS 1 102. At 1 130 through 1 136, the UE 102-1 and the MME 664 may exchange a NAS Security Mode Command and complete signaling using S1 signaling between the H(e)NB 630-1 and the MME 664. For example, at 1 130, the MME 644 may send a S1 downlink NAS Transfer (e.g., which may include the NAS Security Mode Command) to the H(e)NB 630-1. At 1 132, the H(e)NB 630-1 may send or forward the NAS Security Mode Command to the UE 102-1. At 1 134, the UE 102-1 may send a NAS Security Mode Complete to the H(e)NB 630-1. At 1 136, H(e)NB 630-1 may send a S1 uplink NAS Transfer e.g., which includes the NAS Security Mode Complete) to the MME 664. All of the NAS and S1 signaling may pass through the eCGW 620-1.

[0102] At 1 138 through 1 184, an interaction between the IP Traffic GW 628 of the eCGW 620-1 and the EPC elements, as the IP connection is being established for the UE 102-1 is illustrated. The GTP signals at 1 138 and at 1 150 may be used to configure the IP Traffic GW 628 of the eCGW 620-1 for the data that passes through it. At 1 138, the MME 664 may send a GTP Create Session Request message including or indicating an IMSI or any other subscriber/device identifier. At 1 140, the eCGW 620-1 may create an entry in its GTP/PMIP binding table for the particular UE 102-1 using the IMSI contained in the GTP Create Session Request message. The GTP/PMIP binding table of the eCGW 620-1 at this point may contain (e.g., may only contain) the IMSI and that the UE 102-1 is connecting through the eCGW 620-1. The UE 102-1 may have not been assigned an IP address. The other four signals, at 1 142 through 1 148 relate to the control and charging rules that are used by the eCGW 620-1.

[0103] As part of the message sequence chart (MSC), the GTP/PMIP tunnel between the H(e)NB 630-1 and the eCGW 620-1 may be established and the radio bearers may be set up between the UE 102-1 and the H(e)NB 630-1. The UE 102-1 may request an IPv6 IP address from the eCGW 620-1. The eCGW 620-1 may pre-register the UE 102-1 with its neighbors (e.g., all other neighbor eCGWs 620). The eCGW 620-1 may pre-register with the DAMN 910, if the DAMN 910 is configured in the system.

[0104] The RRC, NAS, and S1 signaling is depicted at 1162 through 1 168, as a part of initial attach and initial PDN connectivity procedures. At 1 162, the H(e)NB 630-1 may learn or determine the GTP tunnel endpoint for a particular user (in this case the eCGW 620-1 ). At 1 164, the creation of the GTP tunnel may be completed to inform the eCGW 620-1 , as to the endpoint of the GTP tunnel (which in this case is the H(e)NB 630-1 ). The eCGW 620-1 may respond at 1 166 with the appropriate GTP response (e.g., a Modify Bearer Response). The GTP tunnel, at 1 168, may be in place and may be operational.

[0105] At 1170 through 1 176, the UE 102-1 may request and may receive an IP address from the DHCP server 622 in the eCGW 620-1. For example, IP1 may be used as the assigned address. At 1 178, as the eCGW 620-1 is providing this IP address, the eCGW 620-1 may update its GTP/PMIP binding table. The eCGW 620-1 may know or determine that the IMSI 1 and the IP 1 are linked, based on the DHCP signaling from the UE 102-1 that arrived at the eCGW 620-1 via the GTP tunnel setup for the IMSI 1. At 1 180, the UE 102-1 may update its own IP address table to indicate that IP 1 is the current, in use, IP address. At 1 182, the eCGW 620-1 may pre-register with each neighbor eCGW 620-2 and indicate that it is managing IMSI 1 and IP 1. At 1 184, each neighbor eCGW (e.g., eCGW 620-2) may update its GTP/PMIP binding table, accordingly. If the UE handovers, the entry may be used to trigger the establishment of the GTP/PMIP tunnel to the eCGW 620-1 to provide data continuity.

[0106] If the DAMN 910 is configured in the system, the eCGW 620-1 may pre-register with the DAMN 920. The DAMN 910 may be contacted by non-neighbor eCGWs.

[0107] Although a GTP protocol is shown, for example, to explain the interface between the eCGW 620-1 and the eCGW 620-2, it is contemplated that the PMIP protocol may also be used for this interface or a similar interface.

With Certain Representative GTP-C messages

GTP table handling:

[0108] During an attach, when the eCGW 620-1 receives a Create Session Request message from the MME 664 for IMSI 1 , the following information may be maintained:

GTP table(eCGW 620-1 ):

IMSI UE IP eCGW

IMSI 1 _ eCGW 620-1

[0109] The IMSI, the UE IP, and the eCGW may be fields in the GTP binding table. The UE IP may be blank (null) at this point in time, as the UE IP may be assigned beyond the attach procedure. The IMSI and UE IP together may identify a unique record in the GTP binding table.

[0110] The eCGW 620-1 may check the GTP binding table entries (e.g., all of the GTP binding table entries) of the IMSI 1 , and if there is an entry that has an eCGW field value set to other than eCGW 620-1 , the eCGW 620-1 may create a GTP tunnel with the other eCGW (e.g. eCGW 620-2) and may update that eCGW's GTP binding table with the details of the eCGW 620-1 for the data forwarding over the GTP tunnel. If there are no entries where an eCGW field value is set to other than the eCGW 620-1 for the IMSI 1 , a GTP tunnel may not be created.

[0111] During the attach, when the eCGW 620-1 receives a Modify Bearer Request message (for example at 1 164) from the MME 664 for the IMSI 1 , the eCGW 620-1 may perform the following:

GTP table(eCGW 620-1 ):

IMSI UE IP eCGW

IMSI 1 eCGW 620-1 [0112] Beyond the attach, a DHCP procedure with the eCGW 620-1 may get (obtain) the UE's IP, and/or the eCGW 620-1 may pre-register with the eCGW 620-2 with (IMSI 1 , IP 1 , eCGW 620- 1 ) by sending a Create Session Request message (for example at 1 182) to the eCGW 620-2 with APN="inactive" as follows:

GTP table(eCGW 620-1 ):

IMSI UE IP eCGW

IMSI 1 IP 1 eCGW 620-1

GTP table(eCGW 620-2):

IMSI UE IP eCGW

IMSI 1 IP 1 eCGW 620-1

At this point, both UL and DL data flows of both the IPs (e.g., IP 1 , IP 2) may be handled.

With Certain New Representative GTP-C Messages

GTP binding table:

[0113] During attach, when the CGW 620-1 receives a Create Session Request message from the MME 664 (for example at 1 138) for IMSI 1 , the following information may be maintained:

GTP table(eCGW 620-1 ):

IMSI UE IP eCGW

IMSI 1 _ eCGW 620-1

[0114] The IMSI, the UE IP, and the eCGW may be fields in the GTP binding table. The UE IP may be blank at this point of time, as the UE IP may be assigned beyond the attach procedure. The IMSI and the UE IP together may identify a unique record in the GTP binding table.

[0115] The eCGW 620-1 may check all the GTP binding table entries of the IMSI 1 , and if there is an entry that has an eCGW field value set to other than eCGW 620-1 , then the eCGW 620-1 may create the GTP tunnel with that eCGW and may update that the eCGWs GTP binding table with the details of the eCGW 620-1 for the data forwarding over the GTP tunnel. If there are no entries where the eCGW field value is set to other than the eCGW 620-1 for the IMSI 1 , a GTP tunnel may not be created.

[0116] During the attach, when the eCGW 620-1 receives a Modify Bearer Request message from the MME 664 for the IMSI 1 , the eCGW 620-1 may have the following GTP binding table: GTP table(eCGW 620-1 ):

IMSI UE IP eCGW

IMSI 1 _ eCGW 620-1

[0117] Beyond the attach, a DHCP procedure with the eCGW 620-1 may get (obtain) the UE's IP, and/or the eCGW 620-1 may pre-register with the eCGW 620-2 with (IMSI 1 , IP 1 , eCGW 620- 1 ) by sending a Create Session Request message to the eCGW 620-2. The GTP binding tables may be updated as follows:

GTP table(eCGW 620-1 ):

IMSI UE IP eCGW

IMSI 1 IP 1 eCGW 620-1

GTP table(eCGW 620-2):

IMSI UE IP eCGW

IMSI 1 IP 1 eCGW 620-1

UL and DL data based on IP 1 may be handled beyond this point.

[0118] In case of a UE initiated detach, the eCGW 620-1 may receive a Delete Session Request from the MME 664. The UE 102-1 may send a DHCP Release to the DHCP server 622 on the eCGW 620-1 to release the IPs assigned by the eCGW 620-1. The eCGW 620-1 may send a Delete Inactive Session Request to the eCGW 620-2 to clean up the GTP binding table entry for IP 1 as follows:

GTP table(eCGW 620-1 ):

IMSI UE IP eCGW

GTP table(eCGW 620-2):

IMSI UE IP eCGW

Representative S1 handover within the SCN

[0119] FIG. 12 is a diagram illustrating a representative S1 handover procedure 1200.

[0120] Referring to FIGS. 7 and 12, the data may be transferred to the UE 102-1 from a data path that includes the CDN (e.g., CDN/content server 652) (or from an Edge Server). After the handover, the data path for the same applications may be changed. FIG. 12 illustrates the S1 handover procedure 1200 that may be performed when a UE 102-1 is being handed over from one H(e)NB 630-1 to another H(e)NB 630-2. As the procedures use (have signaling passing through) the eCGW entities (e.g., eCGWs 620-1 and 620-2) that are between the H(e)NBs 630-1 and 630-2 and the EPC 660), the eCGWs 620-1 and 620-2 may update their GTP/PMIP binding tables in response to certain actions/steps and/or procedures.

[0121] The UE 102-1 may be connected to the H(e)NB 630-1 , via the eCGW 620-1 . The DL data path 710 is illustrated at 1204 and the UL data path 710 is illustrated at 1206. For example, the DL data path may be from the CDN server 652 to the eCGW 620-1 (e.g., via a network address translation (NAT) server 1202-1 , an edge server 1201 -1 , the IP Traffic GW 628) of the eCGW 620- 1 ) to the H(e)NB 630-1 to the UE 102-1 . Along the DL path: (1 ) the NAT 1202-1 may send or forward the data traffic to the edge server 1201 -1 ; (2) the edge server 1201 -1 may send or forward the data traffic to the IP Traffic GW 628; (3) the IP Traffic GW 628 may send or forward the data traffic to the H(e)NB 630-1 ; and the H(e)NB may send or forward the data traffic to the UE 102-1 . The UL data path 710 may be a reversal of the DL path such that the UL data originating in the UE 102-1 may travel to the H(e)NB 630-1 , through a GTP tunnel to the eCGW 620-1 and then to the CDN server 652. For the DL path the data may traverse from the CDN server 652 to the eCGW 620-2, through the GTP tunnel in place between the eCGW 620-1 and the H(e)NB 630-1 , and then over the air to the UE 102-1 .

[0122] At 1208, the H(e)NB 630-1 may decide to handover the UE 102-1 to the H(e)NB 630-2. It is contemplated that the H(e)NB 630-1 may configure or control the UE 102-1 to perform measurements and the UE 102-1 may perform those measurements and may report them to the H(e)NB 630-1 .

[0123] It is contemplated that there may not be a direct path between the H(e)NB 630-1 and H(e)NB 630-2, which may mean that the procedure may be an S1 Handover and may not be an X2 Handover. X2 Handovers are discussed later.

[0124] As a result of a handover decision, at 1210, the H(e)NB 630-1 may issue a S1 Handover Request message towards the MME 664. This message may include both the target eNodeB Global ID and/or the Tracking Area Code. At 1212, the MME 664 may map the eNodeB Global ID and/or the Tracking Area Code to the eCGW 620-2. The MME 664 may begin preparing the eCGW 620-2 for the handover. At 1214, the MME 664 may issue a GTP Create Session Request message containing or including the IMSI of the UE 102-1 being handed over. Upon receipt of this message, the eCGW 620-2 may update its GTP/PMIP binding table with a new entry for this IMSI.

[0125] Concurrently, at 1214, the eCGW 620-2 may use the GTP signal/message as a trigger to establish a GTP/PMIP tunnel between the eCGW 620-1 and the eCGW 620-2 for the UE 102-1 . The GTP/PMIP tunnel and the GTP/PMIP binding table in both the eCGW 620-1 and the eCGW 620-2 are illustrated. The GTP/PMIP binding table in the eCGW 620-1 may reflect an entry for the UE 102-1 indicating the eCGW 620-2 and the GTP/PMIP binding table in the eCGW 620-2 may have two entries for the UE 102-1 . One of these entries indicates the eCGW 620-1 and the other indicates the eCGW 620-2. Since the UE 102-1 has not been assigned an IP address, the IP address portion of the entry may be blank. Once the GTP/PMIP tunnel is in place, any buffered UL data may be sent to the CDN 652 via the GTP/PMIP tunnel between the eCGW 620-1 and the eCGW 620-2.

[0126] The terminology "signal" and "message" are used interchangeably herein. These terms generally refer to signaling and/or messaging between two entities and may occur as part of a communication at various levels of a communication stack.

[0127] At 1216, the eCGW 620-2 may respond with a GTP Create Session Response containing or including the TEID of the eCGW 620-2. This TEID may be given to the H(e)NB 630-2 later so that the H(e)NB 630-2 may know or determine the GTP tunnel endpoint. At 1218, any DL data sent towards the UE 102-1 may reach the H(e)NB 630-1. At 1220, the H(e)NB 630-1 may buffer the received DL data. This data may continue to be buffered. After receiving the proper GTP response from the eCGW 620-2 at 1216, the MME 664 may send the S1 Handover Request message to the H(e)NB 630-2 at 1222. This S1 Handover Request message may include the GTP tunnel endpoint at the eCGW 620-2 so that the H(e)NB 630-2 may know or may determine where this tunnel terminates. At 1224, the H(e)NB 630-2 may respond with the S1 Handover Request Acknowledge message, containing or including the H(e)NB 630-2 GTP tunnel endpoint information.

[0128] At 1226, the UL data path is illustrated at this time. Any UL data sent by the UE 102-1 to the H(e)NB 630-1 may be pushed towards the eCGW 620-1 via the GTP tunnel. After reaching the eCGW 620-1 , the eCGW 620-1 may push the data towards the CDN 652. At 1228, the MME 664 may command the H(e)NB 630-1 to command the UE 102-1 to handover using a S1 Handover Command message.

[0129] Receiving this command, at 1232, the H(e)NB 630-2 may send an RRC Handover command to the UE 102-1. Simultaneously or consecutively, at 1234 and 1236, respectively, the H(e)NB 630-1 may begin forwarding the data buffered at 1220 (and any subsequent DL data) to the H(e)NB 630-2 and the H(e)NB 630-2 may buffer this DL data. Any UL data that is sent during this period, if the UL data reaches the H(e)NB 630-1 may be pushed towards the CDN 652 via the eCGW 620-1 (e.g., using an established link). At 1238, the H(e)NB 630-1 may send an S1 eNodeB Status Transfer message to the MME 664. The MME 664 may forward the information to the H(e)NB 630-2 via a S1 MME Status Transfer message, at 1240, enabling the passing of GTP sequence numbers and PDCP sequence numbers from the source (the H(e)NB 630-1 ) to the target (the H(e)NB 630-2) entities.

[0130] The representative S1 handover procedure 1200 illustrates how data may be forwarded from one H(e)NB 630-1 to another H(e)NB 630-2, as the UE 102-1 transitions from being connected from one H(e)NB 630-1 to the other H(e)NB 630-2. At 1242, the UL data path 710 is illustrated. Since the UE 102-1 has not handed over yet, UL packets may travel from the UE 102-1 to the H(e)NB 630-1 , then to the eCGW 620-1 and to the CDN server 652. At 1244, 1246, and 1248, the DL data path 720 is illustrated. [0131] At 1244, data sent by the CDN server 652 may be received at the eCGW 620-1 . At 1246, the DL data may be sent or forwarded from the eCGW 620-1 to the H(e)NB 630-1 via an existing GTP tunnel. At 1248, the H(e)NB 630-1 may route the data to the H(e)NB 630-2. At 1250, the DL data may be buffered by the H(e)NB 630-2. The DL data may remain buffered in the H(e)NB 630- 2 until the handover is complete. At 1252, the UE 102-1 may detach from the H(e)NB 630-1 and may synchronize to the H(e)NB 630-2. Any UL data sent, prior to 1252, may be sent from the UE 102-1 to the H(e)NB 630-1 , to the eCGW 620-1 and then to the CDN 652 as illustrated at 1242. At 1254, after the UE 102-1 has handed over (e.g., successfully handed over), an RRC Handover Confirmed message may be sent from the UE 102-1 to the H(e)NB 630-2. As a result of or after receiving the RRC Handover Confirmed message, at 1256, the H(e)NB 630-2 may begin sending the DL data buffered at 1250 to the UE 102-1 . Any UL data at this time (e.g., after the handover) may be sent from the UE 102-1 to the H(e)NB 630-2, and to the eCGW 620-2. The eCGW 620-2 may buffer the UL data to route the UL data to the CDN (e.g., CDN server) 652 via the eCGW 620- 1 , once the GTP/PMIP tunnel is established.

[0132] After receiving the RRC Handover Confirmed message, at 1258, the H(e)NB 630-2 may send an S1 Handover Notification to the MME 664. At 1260, The MME 664 may issue the GTP Modify Bearer Request to the eCGW 620-2. At 1262, the eCGW 620-2 may respond with the GTP Modify Bearer Response signal. At this point, the GTP tunnel may exist between the H(e)NB 630- 2 and the eCGW 620-2. Upon receipt of the GTP Modify Bearer Response signal, at 1264, the MME 664 may start a timer to release resources still configured in the H(e)NB 630-1 and the eCGW 620-1 . The timer may enable or allow forwarding of data (e.g., forwarding of all data) to be completed before the resources are freed.

[0133] After the handover is complete, the UL data may follow the UL data path 720 illustrated at 1266. The UL data may travel through the GTP tunnel between the H(e)NB 630-2 and the eCGW 620-2 and may travel through the GTP/PMIP tunnel between the eCGW 620-1 and the eCGW 620-2. After the GTP/PMIP tunnel is in place, the DL data path 720 is illustrated at 1268. It is understood that these are the data paths for those applications (e.g., only those applications) which were in operation prior to the handover. Any applications started post-handover may have a different data path.

[0134] One of skill understands that the UL path 1242, prior to UE 1 detaching from HeNB 1 and synchronizing to HeNB 2 does not go through the tunnel between the eCGWs. Once the handover has completed, the UL data path 1266 and the DL data path 1268 goes through the GTP/PMIP tunnel between the eCGWs.

[0135] Once the UE 102-1 has been handed over to the H(e)NB 630-2, the UE 102-1 may request an IP address as illustrated at 1270, 1272, 1274 and 1276. At 1270, the UE 102-1 may send a router solicitation message to the eCGW 620-2. At 1272, the eCGW 620-2 may send (e.g., respond with) a router advertisement message to the UE 102-1 . At 1274, the UE 102-1 may send a DHCPv6 Request message to the eCGW 620-2. At 1276, the eCGW 620-2 may send (e.g., response with) a DHCPv6 Response message to the UE 102-1. The UE 102-1 may get the IPv6 address from a pool allocated to the eCGW 620-2 when it was provisioned. The UE 102-1 may now have two IPv6 addresses, one from the eCGW 620-1 and the other from the eCGW 620-2. The first IP address may be considered "deprecated" and the other may be considered "in use". At 1278, the "deprecated" IP address may be used (e.g., may only be used) for applications, which were running prior to the handover and the "in use" IP Address may be used for applications which are started post-handover. At 1280, the GTP/PMIP binding table in the eCGW 620-2 is illustrated with the second entry having a newly issued IP2 address.

[0136] At 1282, the eCGW 620-2 may dispatch a Pre- registration request to the eCGW 620-1 containing or including the IMSI and IP2. At 1283, the pre-registration request may cause the eCGW 620-1 to update its GTP/PMIP binding table to have two entries as follows:

GTP table(eCGW 620-1 ):

IMSI UE IP eCGW

IMSI 1 IP 1 eCGW 620-2

IMSI 1 IP 2 eCGW 620-2

[0137] At a future time, the timer may expire in the MME 664 as illustrated at 1284. At 1286, the MME 664 may send (e.g., issue) an S1 UE Context Release Command message to the H(e)NB 630-1 to teardown (e.g., release) the endpoint of the GTP tunnel at the H(e)NB 630-1. At 1288, the H(e)NB 630-1 may send an S1 UE Context Release Complete message to the MME 664 to confirm the completion of the teardown of the end of the GTP tunnel at the H(e)NB 630-1. At 1290, the MME 664 may send (e.g., issue) a GTP Delete Session Request message to the eCGW 620-1 to teardown (e.g., release) the endpoint of the GTP tunnel at the eCGW 620-1. The eCGW 620-1 may send a GTP Delete Session Response to the MME 664 to confirm the completion of the teardown of the end of the GTP tunnel at the eCGW 620-1.

[0138] The S1 and GTP signals sent to the H(e)NB 630-1 and the eCGW 620-1 enable teardown of the GTP tunnel between the H(e)NB 630-1 and the eCGW 620-1 for the UE 102-1. At this point, the GTP tunnel between the H(e)NB 630-1 and the eCGW 620-1 has been released and/or removed/torn down.

GTP table handling:

[0139] After the UE attach has been completed, at 1214 during S1 handover, when the eCGW 620-2 receives a Create Session Request message from the MME 664 for IMSI 1 , the GTP binding tables may be as follows:

GTP table(eCGW 620-2):

IMSI UE IP eCGW

IMSI 1 IP 1 eCGW 620-1

IMSI 1 eCGW 620-2 [0140] The IMSI 1 , IP 1 , and eCGW 620-1 (IP) was received from the eCGW 620-1 as part of the pre-registration. The IMSI 1 , _, and the eCGW 620-2 are a new entry where the eCGW 620-2 assign a new IP address to the IMSI 1.

[0141] The CGW 620-2 may check all the GTP binding table entries of the IMSI 1 , and if there is an entry that has the eCGW field value other than "eCGW 620-2", then the eCGW 620-2 may create a GTP tunnel with that eCGW (e.g., the eCGW 620-1 ) and may update that eCGW's (e.g., the eCGW 620-1 ) GTP binding table with the eCGW 620-2's details for the data forwarding over the GTP tunnel.

[0142] At this point in time, there is a record (IMSI 1 , IP 1 , eCGW 620-1 ) that has the eCGW field set to other than the eCGW 620-2. The eCGW 620-2 may check if there is already a GTP connection to the eCGW 620-1 (e.g., for IP 1 ). If not, the eCGW 620-2 may establish a GTP tunnel with the eCGW 620-1 by sending a Create Session Request message with the full valid APN (APN Network Identifier and APN Operator Identifier) as defined in 3GPP TS 23.003 that was received from the MME 664 with complete bearer information

[0143] The Create Session Request/Response messages may create user plane tunnels at both ends (e.g., the eCGW 620-1 , the eCGW 620-2). The eCGW may use parameters (e.g., only certain parameters) described herein. The eCGW 620-1 's GTP binding table may be modified with the eCGW 620-2's details as described herein and illustrated in FIG. 12 at 1214 and 1216.

GTP table(eCGW 620-1 ):

IMSI UE IP eCGW

IMSI 1 IP 1 eCGW 620-2

GTP table(eCGW 620-2):

IMSI UE IP eCGW

IMSI 1 IP 1 eCGW 620-1

IMSI 1 _ eCGW 620-2

[0144] During S1 handover, when the eCGW 620-2 receives a Modify Bearer Request message from the MME 664 for the IMSI 1 , the eCGW 620-2 may perform:

GTP table(eCGW 620-2):

IMSI UE IP eCGW

IMSI 1 IP 1 eCGW 620-1

IMSI 1 eCGW 620-2 [0145] Beyond the S1 handover, a DHCP procedure with the eCGW 620-2 may get the UE's IP address and the eCGW 620-2 may pre-register with the eCGW 620-1 with (IMSI 1 , IP 2, and the eCGW 620-2(IP)). The eCGW 620-2 may pre-register (for example at 1282) for IP 2 by sending a Create Session Request to the eCGW 620-1 (pre-registration) with an APN="inactive". The GTP binding tables after the preregistration are illustrated at 1280 and 1283 as follows:

GTP table(eCGW 620-1 ):

IMSI UE IP eCGW

IMSI 1 IP 1 eCGW 620-2

IMSI 1 IP 2 eCGW 620-2

GTP table(eCGW 620-2):

IMSI UE IP eCGW

IMSI 1 IP 1 eCGW 620-1

IMSI 1 IP 2 eCGW 620-2

[0146] The UE 102-1 may implement a DHCP release when IP 1 is complete. The eCGW 620-2 may send a Delete Session Request to the eCGW 620-1 for IP 1. The eCGW 620-1 may send a Delete Session Request to the eCGW3 to deactivate inactive sessions. If the pre-registration was done at the eCGW3 by the eCGW 620-1 for IP 1 (e.g., the UE has not moved to the eCGW3 from the eCGW 620-1. Only the pre-registration was done at the eCGW3 for IP 1 ). After the DHCP release, the GTP binding tables may be as follows:

[0147]

GTP table(eCGW 620-1 ):

IMSI UE IP eCGW

IMSI 1 IP 2 eCGW 620-2

GTP table(eCGW 620-2):

IMSI UE IP eCGW

IMSI 1 IP 2 eCGW 620-2

With new GTP-C Messages:

[0148] The UE attach is completed. During the S1 handover, when the eCGW 620-2 receives a Create Session Request message from the MME 664 for the IMSI 1 and the GTP binding tables are as follows: GTP table(eCGW 620-2):

IMSI UE IP eCGW

IMSI 1 IP 1 eCGW 620-1

IMSI 1 _ eCGW 620-2

[0149] The IMSI 1 , IP 1 , and eCGW 620-1 (IP) entry was received from the eCGW 620-1 as part of the pre-registration. The IMSI 1 , _, eCGW 620-2 is the new entry where the eCGW 620-2 may assign a new IP address to the IMSI 1. The eCGW 620-2 may check the GTP binding table entries (e.g., all of the GTP binding table entries) of the IMSI 1 , and if there is an entry that has an eCGW field value other than eCGW 620-2, then the eCGW 620-2 may create a GTP tunnel with that eCGW (e.g., the eCGW 620-1 ) and may update that eCGW's (e.g., the eCGW 620-1 's) GTP binding table with the eCGW 620-2's details for the data to be forwarded over GTP tunnel. At this point in time, there is a record (IMSI 1 , IP 1 , and eCGW 620-1 ) that has the eCGW field set to other than the eCGW 620-2. The eCGW 620-2 may check if there is already a GTP connection to the eCGW 620-1 (for IP 1 ). If not, the eCGW 620-2 may establish a GTP tunnel with the eCGW 620-1 by sending a Create Session Request message.

[0150] The Create Session Request/Response messages may create user plane tunnels at both ends (e.g., the eCGW 620-1 , and the eCGW 620-2). The eCGW may explore (e.g., only explore) certain parameters that are explained herein. The eCGW 620-1 's GTP binding table may be modified with the eCGW 620-2's details as provided herein.

GTP table(eCGW 620-1 ):

IMSI UE IP eCGW

IMSI 1 IP 1 eCGW 620-2

GTP table(eCGW 620-2):

IMSI UE IP eCGW

IMSI 1 IP 1 eCGW 620-1

IMSI 1 _ eCGW 620-2

[0151] During the S1 handover, when the eCGW 620-2 receives a Modify Bearer Request message from the MME 664 for the IMSI 1 , the eCGW 620-2 may have (for example in FIG. 12 at 1280) a GTP binding table as follows:

GTP table(eCGW 620-2):

IMSI UE IP eCGW

IMSI 1 IP 1 eCGW 620-1

IMSI 1 eCGW 620-2 [0152] Beyond the S1 handover, the DHCP procedure with the eCGW 620-2 may be used to get the UE's IP. The eCGW 620-2 may pre-register with the eCGW 620-1 using (IMSI 1 , IP 2, and eCGW 620-2 (IP)). The eCGW 620-2 may do the pre-registration for IP 2 by sending a Create Inactive Session Request message to the eCGW 620-1 (e.g., for pre-registration).

GTP table(eCGW 620-1 ):

IMSI UE IP eCGW

IMSI 1 IP 1 eCGW 620-2

IMSI 1 IP 2 eCGW 620-2

GTP table(eCGW 620-2):

IMSI UE IP eCGW

IMSI 1 IP 1 eCGW 620-1

IMSI 1 IP 2 eCGW 620-2

[0153] The UE 102-1 may provide for (do) a DHCP release, when IP 1 is complete. The eCGW 620-2 may send a Delete Session Request message to the eCGW 620-1 for IP 1.

GTP table(eCGW 620-1 ):

IMSI UE IP eCGW

IMSI 1 IP 2 eCGW 620-2

GTP table(eCGW 620-2):

IMSI UE IP eCGW

IMSI 1 IP 2 eCGW 620-2

[0154] The Delete Inactive Session Request/Response messages may be used in any of the following scenario: (1 ) the UE 102-1 may attach via the eCGW 620-1 and gets IP 1 ; (2) the eCGW 620-1 may do pre-registration for IP 1 with the eCGW 620-2 and the eCGW3 by sending a Create Inactive Session Request message; (3) the UE 102-1 may move to the eCGW 620-2 and may get IP 2, and Create Session Request/Response messages may happen towards the eCGW 620-1 for IP 1 ; (4) the UE 102-1 may complete the IP 1 flow; (5) the eCGW 620-2 may send a Delete Session Request message to the eCGW 620-1 ; (6) the eCGW 620-1 may send a Delete Session Response message to the eCGW 620-2; (7) the eCGW 620-1 may send a Delete Inactive Session Request message to the eCGW3; and/or (7) the eCGW3 may send a Delete Inactive Session Response message to the eCGW 620-1 , among others. Representative S1 handover - failure scenarios

[0155] In certain representative embodiments, procedures for handover failures may be implemented, including, for example, procedures where the target H(e)NB 630-2 or the eCGW 620-1 and/or 620-2 do not respond, where they respond indicating some type of error or failure, various timeout scenarios as well as the case where a H(e)NB 630-2 may decide to cancel the handover based on updated measurements received from the UE 102-1.

Create Session Failure

[0156] FIG. 13 is a diagram illustrating a representative create session failure procedure 1300.

[0157] Referring to FIG. 13, when the MME 664 receives a Create Session Response message with a failure from the eCGW 620-2 during S1 Handover, the MME 664 may perform the following representative procedure. At 1310, the MME 664 may receive an S1AP: HANDOVER REQUIRED message from the HeNB 630-1. At 1320, as the UE 102-1 has the PDN connections as DMM- enabled, the MME 664 may send a GTP Create Session Request message to the eCGW 620-2. If the eCGW 620-2 does not respond to the GTP Create Session Request message after a period of time (e.g., there may be a timeout for failure of the eCGW 620-2 to respond), at 1330, the MME 664 may send a S1AP: HAN DOVER PREPARATION FAILURE message to the HeNB 630-1. At 1340, the eCGW 620-2 may respond to GTP Create Session Request message with a failure cause. If the eCGW 620-2 responds to GTP Create Session Request message with the failure, at 1350, the MME 664 may send a S1AP:HANDOVER PREPARATION FAILURE message to the HeNB 630-1.

Modify Bearer Failure

[0158] FIG. 14 is a diagram illustrating a representative modify bearer failure procedure 1400.

[0159] Referring to FIG. 14, at 1410, the UE 102-1 may detach from the H(e)NB 630-1 and may synch to the H(e)NB 630-2. The MME 664 may have completed a sequence of Create Session Request/Response messages with the eCGW 620-2. At 1415, the MME 664 may send a Modify bearer Request message to the eCGW 620-2 including information indicating the IP address of the H(e)NB 630-2 and the Tunnel endpoint ID (TEID) (e.g., TEID1 ) of the H(e)NB 630-2. At 1420, the MME 664 may receive a Modify bearer Response message with a failure (e.g., a failure being indicated) from the eCGW 620-2 during the S1 Handover. The MME 664 may perform the following representative procedure: At 1425, the MME 664 may send a S1AP:UE CONTEXT RELEASE COMMAND message to the HeNB 630-1. At 1430, the HeNB 630-1 may send a S1AP:UE CONTEXT RELEASE COMPLETE message to the MME 664 after cleaning up the bearer context. At 1435, the MME 664 may send a Delete Session Request message to the eCGW 620-1. At 1440, the eCGW 620-1 may send a Delete Session Response message to the MME 664 after cleaning up the bearer context. At 1445, the MME 664 may send a S1AP:DL NAS Transport (NAS:Detach Request) message to the HeNB 630-2. At 1450, the HeNB 630-2 may send a NAS:Detach Request message to the UE 102-1. At 1455, the UE 102-1 may send a NAS:Detach Accept message to the HeNB 630-2 after cleaning up bearer context. At 1460, the MME 664 may send a Delete Session Request message to the eCGW 620-2. At 1465, the eCGW 620-2 may send a Delete Session Response message to the MME 664 after cleaning up the bearer context. At 1470, the HeNB 630-22 may send a S1AP:UL NAS Transport (NAS:Detach Accept) message to the MME 664. At 1475, the MME 664 may send a S1AP:UE CONTEXT RELEASE COMMAND message to the HeNB 630-2. At 1480, the HeNB 630-2 may send a S1AP:UE CONTEXT RELEASE COMPLETE message to the MME 664 after releasing the bearer context.

Modify Bearer Timeout

[0160] FIG. 15 is a diagram illustrating a representative modify bearer timeout failure procedure 1500.

[0161] Referring to FIG. 15, at 1510, the UE 102-1 may detach from the H(e)NB 630-1 and may synch to the H(e)NB 630-2. The MME 664 may have finished the Create Session Request/Response messaging with the eCGW 620-2. At 1515, the MME 664 may send a Modify bearer Request message to the eCGW 620-2 including information indicating the IP address of the H(e)NB 630-2 and the TEID (e.g., TEID1 ) of the H(e)NB 630-2. At 1520, the MME 664 may timeout after sending the Modified Bearer Request message to the eCGW 620-2 (e.g., when the eCGW 620-2 does not send a Modify Bearer Response message to the MME 664 or does not send a Modify Bearer Response message to the MME 664 within an expiration/timeout period). At 1525, the MME 664 may send a S1AP:UE CONTEXT RELEASE COMMAND message to the HeNB 630-1. At 1530, the HeNB 630-1 may send a S1AP:UE CONTEXT RELEASE COMPLETE message to the MME 664 after cleaning up bearer context. At 1535, the MME 664 may send a Delete Session Request message to the eCGW 620-1. At 1540, the eCGW 620-1 may send a Delete Session Response message to the MME 664 after cleaning up bearer context. At 1545, the MME 664 may send a S1AP:UE CONTEXT RELEASE COMMAND message to the HeNB 630-2. At 1550, the HeNB 630-2 may send a S1AP:UE CONTEXT RELEASE COMPLETE message to the MME 664 after releasing bearer context. At 1555, the MME 664 may send a Release Access Bearer Request message to the eCGW 620-2. At 1560, the eCGW 620-2 may send a Release Access Bearer Response message to the MME 664 after moving the bearers to an INACTIVE state.

Resource Allocation Failure

[0162] FIG. 16 is a diagram illustrating a representative resource allocation failure procedure 1600.

[0163] Referring to FIG. 16, the MME 664 may perform the following representative procedure after a resource allocation failure (e.g., when the bearer resource allocation has failed towards the HeNB 630-2). At 1610, the MME 664 may send a S1AP: Handover Request message to the HeNB 630-2 and may include or indicate the eCGW 620-2 and the TEID1.

[0164] After 1610, if the HeNB 630-2 does not respond to the S1AP:Handover Request message, the procedure may include 1615 to 1640. For example, at 1615, the MME 664 may wait a timeout period. After the timeout period has expired, at 1620, the MME 664 may send a S1AP:UE CONTEXT RELEASE COMMAND message to the HeNB 630-2. At 1625, the HeNB 630-2 may send a S1AP:UE CONTEXT RELEASE COMPLETE message to the MME 664 after cleaning up bearer context. At 1630, the MME 664 may send a Delete Session Request message to the eCGW 620-2. At 1635, the eCGW 620-2 may send a Delete Session Response message to the MME 664 after cleaning up bearer context. At 1640, the MME 664 may send a S 1 AP : HAN DOVE R PREPARATION FAILURE message to the HeNB 630-1.

[0165] After 1610, if the HeNB 630-2 has responded to the S1AP:Handover Request message with a S1AP:Handover Failure, the procedure may include 1645 to 1670. At 1645, the HeNB 630- 2 may send a S1AP:Handover Failure message to the MME 664. At 1650, the MME 664 may send a S1AP:UE CONTEXT RELEASE COMMAND message to the HeNB 630-2. At 1655, the HeNB 630-2 may send a S1AP:UE CONTEXT RELEASE COMPLETE message to the MME 664 after cleaning up bearer context. At 1660, the MME 664 may send a Delete Session Request message to the eCGW 620-2. At 1665, the eCGW 620-2 may send a Delete Session Response message to the MME 664 after cleaning up bearer context. At 1670, the MME 664 may send a S 1 AP : HAN DOVE R PREPARATION FAILURE message to the HeNB 630-1.

[0166] After 1610, if the HeNB 630-2 has responded to the S1AP:Handover Request message with a S1AP:Handover Failure (e.g., when the eCGW 620-2 reports that bearers failed to setup) the procedure may include 1675 to 1697. At 1675, the HeNB 630-2 may send a S1 AP:Handover Request Acknowledge message to the MME 664 with default bearers (e.g., all default bearers) set to failed on the setup list. At 1680, the MME 664 may send a S1AP:UE CONTEXT RELEASE COMMAND message to the HeNB 630-2. At 1685, the HeNB 630-2 may send a S1AP:UE CONTEXT RELEASE COMPLETE message to the MME 664 after cleaning up bearer context. At 1690, the MME 664 may send a Delete Session Request message to the eCGW 620-2. At 1695, the eCGW 620-2 may send a Delete Session Response message to the MME 664 after cleaning up bearer context. At 1697, the MME 664 may send a S1AP:HANDOVER PREPARATION FAILURE message to the HeNB 630-1.

Handover Notify Failure

[0167] FIG. 17 is a diagram illustrating a representative handover notify timer expiry procedure 1700.

[0168] Referring to FIG. 17, the MME 664 may perform the following representative procedure 1700 after a Handover Notify Failure. At 1710, the MME 664 may determine whether a timer (e.g., a TSIAPHandoverNotify timer) has expired. At 1720, the MME 664 may send a Delete Session Request message to the eCGW 620-2. At 1730, the eCGW 620-2 may send a Delete Session Response message to the MME 664 after cleaning up bearer context. At 1740, the MME 664 may send a S1AP:UE CONTEXT RELEASE COMMAND message to the HeNB 630-2. At 1750, the HeNB 630-2 may send a S1AP:UE CONTEXT RELEASE COMPLETE message to the MME 664 after cleaning up bearer context. TS1 RELCOverallExpiry

[0169] FIG. 18 is a diagram illustrating a representative TSI RELOCOverall timer expiry procedure 1800.

[0170] Referring to FIG. 18, the MME 664 may perform the following representative procedure 1800 after TS1 RELCOverallExpiry (e.g., when TSI RELOCOverall timer is expired at the HeNB 630-1 during S1 Handover). At 1810, the HeNB 630-1 may have received a S1AP:HANDOVER COMMAND message from the MME 664. The HeNB 630-1 may start a TSI RELOCOverall timer waiting for a S1AP: UE CONTEXT RELEASE COMMAND message from the MME 664. At 1815, the TSI RELOCOverall may become expired at the HeNB 630-1. At 1820, the HeNB 630-1 may send a S1 AP:UE CONTEXT RELEASE REQUEST message to the MME 664. If the MME 664 has already received a S1AP:HANDOVER NOTIFY message from the HeNB 630-2, at 1825 handover may be executed (e.g., the S1 Handover may proceed normally as herein described) and a context release may be queued at the MME 664. If the MME 664 has not received a S1AP:HANDOVER NOTIFY message from the HeNB 630-2, 1830 to 1865 may be executed. At 1830, the MME 664 may send a S1AP:UE CONTEXT RELEASE COMMAND message to the HeNB 630-1. At 1835, the HeNB 630-1 may send a S1AP:UE CONTEXT RELEASE COMPLETE message to the MME 664 after cleaning up bearer context. At 1840, the MME 664 may send a Release Access Bearer Request message to the eCGW 620-1. At 1845, the eCGW 620-1 may send a Release Access Bearer Response message to the MME 664 after moving the bearers to the INACTIVE state. At 1850, the MME 664 may send a Delete Session Request message to the eCGW 620-2. At 1855, the eCGW 620-2 may send a Delete Session Response message to the MME 664 after cleaning up bearer context. At 1860, the MME 664 may send a S1AP:UE CONTEXT RELEASE COMMAND message to the HeNB 630-2. At 1865, the HeNB 630-2 may send a S1AP:UE CONTEXT RELEASE COMPLETE message to the MME 664 after releasing bearer context.

TSI RELOCPrep Timer Expiry

[0171] FIG. 19 is a diagram illustrating a representative TSI RELOCPrep timer expiry procedure 1900.

[0172] Referring to FIG. 19, the MME 664 may perform the following representative procedure 1900 after a TSI RELLOCPrep Timer Expiry (e.g., when the HeNB 630-1 has not received a S1AP:Handover Command message from the MME 664). At 1910, the TSI RELOCPrep timer may become expired at the HeNB 630-1 , as the H HeNB 630-1 may not have received a S1AP:Handover Command message from the MME 664. At 1920, the HeNB 630-1 may send a S1AP: Handover Cancel message to the MME 664. At 1930, the MME 664 may send a S1AP:Handover Cancel Ack message to the HeNB 630-1. At 1940, the MME 664 may send a Delete Session Request message to the eCGW 620-2. At 1950, the eCGW 620-2 may send a Delete Session Response message to the MME 664 after cleaning up bearer context. At 1960, the MME 664 may send a S1AP:UE CONTEXT RELEASE COMMAND message to the HeNB 630-2. At 1970, the HeNB 630-2 may send a S1AP:UE CONTEXT RELEASE COMPLETE message to the MME 664 after releasing the bearer context.

TRRCUEAcquisition Timer Expiry

[0173] FIG. 20 is a diagram illustrating a representative TRRCUEAcquisition timer expiry procedure 2000.

[0174] Referring to FIG. 20, the MME 664 may perform the following representative procedure after a TRRCUEAcquisition Timer Expiry (e.g., when HeNB 630-2 has not received the UE 102-1 ). At 2010, the TRRCUEAcquisition timer may become expired at the HeNB 630-2, as it has not received the UE 102-1 . At 2020, the HeNB 630-2 may send a S1AP: UE Context Release Request message to the MME 664. At 2030, the MME 664 may send a Delete Session Request message to the eCGW 620-2. At 2040, the eCGW 620-2 may send a Delete Session Response message to the MME 664 after cleaning up bearer context. At 2050, the MME 664 may send a S1AP:UE CONTEXT RELEASE COMMAND message to the HeNB 630-2. At 2060, the HeNB 630-2 may send a S1AP:UE CONTEXT RELEASE COMPLETE message to the MME 664 after releasing the bearer context.

Handover Cancel

[0175] FIG. 21 is a diagram illustrating a representative handover cancel procedure 2100.

[0176] Referring to FIG. 21 , the MME 664 may perform the following representative procedure after a Handover Cancel (e.g., when S1AP: Handover Cancel is triggered by HeNB 630-1 ). At 2105, the HeNB 630-1 may have received a RRC:Measurement Report from the UE 102-1 . At 21 10, the HeNB 630-1 may decide to perform a S1 Handover. At 21 15, the HeNB 630-1 may send a S1AP: Handover Required message to the MME 664. At 2120, the UE 102-1 may send another measurement report to the HeNB 630-1 . At 2125, the HeNB 630-1 may decide to cancel the S1 Handover (e.g., based on the latest measurement report). At 2130, the HeNB 630-1 may send a S1AP:Handover Cancel message to the MME 664. At 2135, the MME 664 may send a S1AP:Handover Cancel Ack message to the HeNB 630-1 . At 2140, the MME 664 may send a Delete Session Request message to the eCGW 620-2. At 2145, the eCGW 620-2 may send a Delete Session Response message to the MME 664 after cleaning up bearer context. At 2150, the MME 664 may send a S1AP:UE CONTEXT RELEASE COMMAND message to the HeNB 630-2. At 2155, the HeNB 630-2 may send a S1AP:UE CONTEXT RELEASE COMPLETE message to the MME 664 after releasing bearer context.

Mobility among WiFi AP coverage areas - Within SCN

[0177] FIG. 22 is a diagram illustrating a representative mobility procedure 2200.

[0178] Referring to FIG. 22, the eCGWs 620 may support a topology in which two or more WiFi APs 640-1 and 640-2 are each connected to a different eCGW 620-1 and 620-2, respectively. The two or more different eCGWs 620-1 and 620-2 may belong to the same SCN 610. The UE 102-1 may connect to one of the WiFi APs (e.g., a first WiFi AP 640-1 ) and may begin some type of data transfer. During the transfer, the UE 102-1 may move outside the coverage area of the first WiFi AP 640-1 and into the coverage area of a different WiFi AP (e.g., a second WiFi AP 640-2). The first WiFi AP 640-1 may be connected to a first eCGW 620-1 and the second WiFi AP 640-2 may be connected to a second eCGW 620-2 (different from the first eCGW 620-1 ). After a "handover", the first and second eCGWs 620-1 and 620-2 may use a GTP/PMIP tunnel 2220 between the first and second eCGWs 620-1 and 620-2 to facilitate continuing the data transfer. Representative procedures using this architecture are illustrated in FIG. 23.

[0179] FIG. 23 is a diagram illustrating a representative WiFi DMM procedure 2300.

[0180] Referring to FIG. 23, at 2304, the UE 102-1 may power up. After the UE 102-1 powers up, at 2308, the UE 102-1 may begin scanning for a WiFi AP with which to connect. Since the UE 102-1 is located in the coverage area of WiFi AP 640-1 , the UE 102-1 may detect WiFi AP 640-1. At 2312, the UE 102-1 may associate with the WiFi AP 640-1. As illustrated in 2316, 2318, 2320, and 2322, the UE 102-1 may request an IPv6 IP address from the DHCP Server 622 in the eCGW 620-1 via Router Solicitation, Router Advertisement, DHCPv6 Request, and DHCPv6 Response messages, sent between the UE 102-1 and eCGW 620-1.

[0181] In certain representative embodiments, the DHCP Server 622 may be part of the IP Traffic Gateway 628 in the MSC, although the DHCP server may be disposed, for example, in other locations in the network.

[0182] After assigning the UE 102-1 an IP address, at 2326, the IP Traffic Gateway 628 in the eCGW 620-1 may pre-register this IP address with the other IP Traffic Gateways 628 (e.g., all the other IP Traffic Gateways) in the SCN 610.

[0183] Although FIGS. 22 and 23 illustrate only one other IP Traffic Gateway 628 located in the eCGW 620-2, any number of IP Traffic Gateways are possible. The parameters of the pre- registration message may include any of: (1 ) a MAC address of the UE 102-1 ; (2) the UE assigned IP address; and/or (3) information indicating that the UE 102-1 is connected through the eCGW 620-1.

[0184] The IP Traffic Gateway 628 of the eCGW 620-1 may have a GTP/PMIP binding table and the IP Traffic Gateway 628 of the eCGW 620-2 may also have a GTP/PMIP binding table. At 2330 and 2332, the GTP/PMIP Binding tables may be created or updated with an entry for the just assigned IP address and the entity that assigned the IP address. At 2334, the UE 102-1 may have an IP address table created or updated with the just assigned IP address that may be denoted as "in use." At 2338, application data may begin to flow between the UE 102-1 and an application server 920. The data path for the data may be through the eCGW 620-1 and the WiFi AP 640-1. At 2342, the UE 102-1 may move out of the coverage area covered by WiFi AP 640-1 and into the coverage area covered by the WiFi AP 640-2.

[0185] Since the UE 102-1 has moved into an area covered by a different WiFi AP 640-2, the UE 102-1 may begin scanning at 2346. As part of this scan process, the UE 102-1 may detect the WiFi AP 640-2 and, at 2348, associate with WiFi AP 2. At 2350, 2352, 2354 and 2356, the DHCP Server 622 of the eCGW 620-2 may allocate and issue an IP address to the UE 102-1 via Router Solicitation, Router Advertisement, DHCPv6 Request, and DHCPv6 Response messages. At 2360, the UE 102-1 may update its IP address table to include the newly assigned IP address. The original IP address assigned previously may be noted or indicated, as deprecated. At 2364, the IP Traffic Gateway 628 in the eCGW 620-2 may note or may indicate that the UE 102-1 had been previously assigned an IP address by the eCGW 620-1 (e.g., found using the MAC address in the GTP/PMIP binding table). The IP Traffic Gateway 628 in the eCGW 620-2 may use this match, as a trigger, to establish a GTP/PMIP tunnel 2220 between the eCGW 620-1 and the eCGW 620-2. At 2368, the eCGW 620-2 may pre-register the newly assigned IP address with the eCGW 620-1. At 2369 and 2370, the GTP/PMIP binding tables for the eCGW 620-1 and eCGW 620-2 may be as illustrated. The UE 102-1 may have two IP addresses assigned to it (e.g., the first assigned from the eCGW 620-1 and the second assigned from the eCGW 620-2). The UE 102-1 may continue to use the IP address assigned by the eCGW 620-1 for existing, currently running, applications. The UE 102-1 may use the IP address assigned by the eCGW 620-2 for applications that start after the IP address was assigned by the eCGW 620-2. In this way, applications running prior to the mobility (e.g., prior to movement into the new coverage area of the WiFi AP 640-2) may continue to use the original IP address assigned to ensure session continuity.

[0186] The data path for applications running prior to the mobility is illustrated at 2372 for UL communications and 2376 for DL communications, while the data path for new applications started after the mobility is illustrated at 2380.

[0187] FIG. 24 is a diagram illustrating another representative WiFi DMM procedure 2400.

[0188] Referring to FIG. 24, a representative procedure 2400 is illustrated showing network behavior once the UE 102-1 has determined that IP 1 is no longer in use by an application (e.g., any applications). At 2410, the UE 102-1 may determine that IP 1 is not used by any current applications. At 2420, the UE 102-1 may perform a DHCP release for IP 1 towards the eCGW 620-2. At 2430, the eCGW 620-2 may remove the entries in the PMIP table that use IP 1. At 2435, the GTP/PMIP binding table of the eCGW 620-2 may be as illustrated. At 2440, the eCGW 620-2 may teardown the GTP/PMIP tunnel 2220 between the eCGW 620-1 and the eCGW 620-2. At 2450, the eCGW 620-1 may realize or determine that the removal of the GTP/PMIP tunnel 2220 is a trigger indicating that IP 1 is no longer used and the eCGW 620-1 may remove references to IP 1 from its GTP/PMIP binding table, as illustrated at 2460. At 2465, the GTP/PMIP binding table of the eCGW 620-1 may be as illustrated. At 2470, the eCGW 620-1 may tear down any GTP/PMIP tunnels 2220 it has with any other eCGWs 620-2 in the same SCN 610.

Mobility among WiFi AP coverage areas - Across SCNs

[0189] FIG. 25 is a diagram illustrating representative eCGWs 620-1 and 620-2 with different small cell networks (SCNs) 610-1 and 610-2.

[0190] Referring to FIG. 25, one or more eCGWs 620-1 and 620-2 may support a plurality of SCN 610-1 and 610-2. As illustrated, two WiFi APs 640-1 and 640-2 in different SCNs 610-1 and 610-2 may be connected to different eCGWs 620-1 and 620-2, respectively. For example, the eCGW 620-1 and the eCGW 620-2 may belong to different SCNs (e.g., SCN 610-1 and SCN 610- 2), respectively. The UE 102-1 may connect to one of the WiFi APs 640-1 and may begin some type of data transfer. During the transfer, the UE 102-1 may move outside the coverage area of the WiFi AP 640-1 and into the coverage area of a different WiFi AP 640-2 (e.g., also connected to an eCGW 620-2, albeit different from the eCGW 620-1 that the first WiFi AP 640-1 is connected to). After this "handover", the eCGWs 620-1 and 620-2 may use the GTP/PMIP tunnel 2220 between them to facilitate continuing the data transfer. Representative procedures using this architecture are illustrated in FIG. 26.

[0191] FIG. 26 is a diagram illustrating yet another representative WiFi DMM mobility procedure 2600.

[0192] Referring to FIG. 26, at 2604, the UE 102-1 may power up. After the UE 102-1 powers up, at 2608, the UE 102-1 may begin scanning for a WiFi AP with which to connect. Since the UE 102-1 is located in the coverage area of WiFi AP 640-1 , the UE 102-1 may detect WiFi AP 640-1 . At 2612, the UE 102-1 may associate with the WiFi AP 640-1 . As illustrated in 2616, 2618, 2620, and 2622, the UE 102-1 may request an IPv6 IP address from the DHCP Server 622 in the eCGW 620-1 via Router Solicitation, Router Advertisement, DHCPv6 Request, and DHCPv6 Response messages sent between the UE 102-1 and the eCGW 620-1 .

[0193] In certain representative embodiments, the DHCP Server 622 may be part of the IP Traffic Gateway 628 in the MSC, although the DHCP server may be disposed, for example, in other locations in the network.

[0194] After assigning the UE 102-1 an IP address, the IP Traffic Gateway 628 in the eCGW 620-1 may pre-register this IP address with the other IP Traffic Gateways 628 (e.g., all the other IP Traffic Gateways) in the SCN 610-1 . The eCGW 620-1 and the eCGW 620-2 may not be neighbors and may not directly exchange pre-registration messages. As such, there may not be any pre-registration with the eCGW 620-2. In certain representative embodiments the eCGW 620- 1 may pre-register with a Dynamic Mobility Management (DMM) Assist Management Node (DAMN) (e.g., DAMN server) 910 at 2626. The parameters of the pre-registration message may include any of the following: (1 ) the MAC address of the UE 102-1 ; (2) an assigned IP address of the UE 102-1 ; and/or (3) an indication or information that the UE 102-1 is connected through the eCGW 620-1 .

[0195] Although certain FIGs. illustrate only two IP Traffic Gateway 628 located in the eCGWs 620-1 and 620-2, any number of IP Traffic Gateways 628 are possible in any number of SCNs 610.

[0196] At 2630, the IP Traffic Gateway 628 of the eCGW 620-1 may have a GTP/PMIP binding table with an entry for the just assigned IP address and the entity that assigned the IP address and, at 2632, the DAMN may have a GTP/PMIP binding table with an entry for the assigned (e.g., just assigned) IP address and/or the entity that assigned the IP address. At 2634, the UE 102-1 may have an IP address table with the just assigned IP address that may be denoted as "in use." At 2638, application data may begin to flow between the UE 102-1 and the application server 920. The data path for the data may be through the eCGW 620-1 and the WiFi AP 640-1. At 2642, the UE 102-1 may move out of the coverage area covered by WiFi AP 640-1 and into the coverage area covered by the WiFi AP 640-2.

[0197] Although the eCGWs 620-1 and 620-2 are illustrated in conjunction with a cellular radio access technology (RAT) or a WiFi RAT, it is contemplated that other RATs are possible including, for example, IEEE 802 RATs or may be used in conjunction with a multi-RAT environment. In addition, the representative embodiments herein may apply to any frequency band and/or frequency range.

[0198] Since the UE 102-1 has moved into an area covered by a different WiFi AP 640-2, the UE 102-1 may begin scanning at 2646. As part of this scan process, the UE 102-1 may detect the WiFi AP 640-2 and, at 2646, associate with WiFi AP 2. At 2650, 2652, 2654 and 2656, the DHCP Server 622 of the eCGW 620-2 may allocate and issue an IP address to the UE 102-1 via Router Solicitation, Router Advertisement, DHCPv6 Request, and DHCPv6 Response messages. At 2660, the UE 102-1 may update its IP address table to include the newly assigned IP address. The original IP address assigned previously may be noted or indicated, as deprecated.

[0199] At 2664, the IP Traffic Gateway 628 in the eCGW 620-2 may note or may indicate that the UE 102-1 had been previously assigned an IP address by the eCGW 620-1 (e.g., found using the MAC address in the GTP/PMIP binding table of the DAMN 910). At 2669, the GTP/PMIP binding table of the eCGW 620-1 may be as illustrated. At 2670, the GTP/PMIP binding table of the eCGW 620-2 may be as illustrated. At 2670, the GTP/PMIP binding table of the DAMN 910 may be as illustrated.

[0200] The IP Traffic Gateway 628 in the eCGW 620-2 may use this match as a trigger, to establish a GTP/PMIP tunnel 2220 between the eCGW 620-1 and the eCGW 620-2. At 2668, the eCGW 620-2 may pre-register the newly assigned IP address with the DAMN 910 (e.g., as the eCGW 620-2 and the eCGW 620-1 may not be neighbors). The UE 102-1 may have two IP addresses assigned to it (e.g., the first assigned from the eCGW 620-1 and the second assigned from the eCGW 620-2).

[0201] The UE 102-1 may continue to use the IP address assigned by the eCGW 620-1 for existing, currently running, applications. The UE 102-1 may use the IP address assigned by the eCGW 620-2 for applications that start after the IP address was assigned by the eCGW 620-2. In this way, applications running prior to the mobility (e.g., prior to movement into the new coverage area of the WiFi AP 640-2) may continue to use the original IP address assigned to ensure session continuity.

[0202] The data path for applications running prior to the mobility is illustrated at 2672 for UL communications and 2676 for DL communications, while the data path for new applications started after the mobility is illustrated at 2680.

[0203] FIG. 27 is a diagram illustrating a still further representative WiFi DMM procedure 2700. [0204] Referring to FIG. 27, a representative procedure 2700 illustrates network behavior once the UE 102-1 has determined that IP 1 is no longer in use by any applications. At 2710, the UE 102-1 may determine that IP 1 is not used by any current applications. At 2720, the UE 102-1 may perform a DHCP release towards the eCGW 620-2. At 2730, the eCGW 620-2 may remove the entries in the GTP/PMIP binding table that use IP 1. At 2740, the GTP/PMIP binding table of the eCGW 620-2 may be as illustrated.

[0205] At 2750, the eCGW 620-2 may teardown the GTP/PMIP tunnel 2220 between the eCGW 620-2 and the eCGW 620-1. At 2760, the eCGW 620-1 may realize or determine that the removal of the GTP/PMIP tunnel 2220 is a trigger indicating that IP 1 is no longer used. The eCGW 620-1 may notify the DAMN to remove the references to IP1. At 2770, the GTP/PMIP binding table of the DAMN 910 may be as illustrated.

[0206] At 2780, the eCGW 620-1 may remove references to IP 1 from its GTP/PMIP binding table. At 2790, the GTP/PMIP binding table of the eCGW 620-1 may be as illustrated (e.g., may not include any entries). At 2795, the eCGW 620-1 may tear down any GTP/PMIP tunnels it has with any other eCGWs in the same SCN 610.

Representative GTP/PMIP Binding Table Handling

[0207] The eCGW 620-1 may conduct pre- registration (IP1 ) with its neighbors (e.g., all its neighbors). The eCGW 620-1 may pre-register (e.g., for the same IP1 ) with the DAMN 910. The DAMN 910 may be contacted by the eCGW 620-2 when the local GTP/PMIP binding table entries may not, do not and/or cannot lead to a GTP/PMIP tunnel creation between the eCGW 620-2 and the eCGW 620-1. If IP1 does not exist (e.g., even in the DAMN table), the eCGW 620-2 may not create a GTP/PMIP tunnel between the eCGWs 620-1 and 620-2.

Fields in DAMN Pre-Registration Table

[0208] The fields in the DAMN Pre-Registration table may include any of: DAMN table:

MAC UE IP eCGW(IP) where the MAC is the MAC address of the UE 102-1 , the UEIP is the UE's assigned IP address and the eCGW(IP) is the eCGWs IP address.

[0209] If the eCGW 620-1 and the eCGW 620-2 are not neighbors, the eCGW 620-1 may belong to the SCN 610-1 and the eCGW 620-2 may belong to the SCN 610-2. When the eCGW 620-1 assigns IP 1 to the UE 102-1 during the DHCP procedure, the eCGW 620-1 may conduct the pre- registration with the DAMN 910. The GTP binding tables for the eCGW 620-1 , the eCGW 620-2 and the DAMN 910 may be as follows:

GTP table(eCGW 620-1 ):

MAC UE IP eCGW

MAC 1 IP 1 eCGW 620-1 GTP table(eCGW 620-2):

MAC UE IP eCGW

DAMN table:

MAC UE IP eCGW

MAC 1 IP 1 eCGW 620-1

UL and DL data based on IP 1 may be handled beyond this point.

[0210] During handover, the UE (MAC 1 ) may move to the eCGW 620-2. The eCGW 620-2 may assign IP 2 to the UE 102-1. The eCGW 620-2 may conduct pre-registration with the DAMN 910 with a binding table entry (MAC 1 , IP 2, eCGW 620-2). The GTP tunnel may be created from the eCGW 620-2 towards the eCGW 620-1 for IP 1.

[0211] The eCGW 620-2 may check the GTP binding table entries (e.g., all the GTP binding table entries) of the MAC 1 to determine if there is an entry that has the eCGW field value other than "eCGW 620-2". As there is no record, the eCGW 620-2 may check the DAMN table. As there is a record in the DAMN table, the eCGW 620-2 may attempt to create a GTP tunnel with the eCGW 620-1 and may update the GTP binding table of the eCGW 620-1 with the eCGW 620-2's details for the data forwarding over the created GTP tunnel. The eCGW 620-2 may check if there is already a GTP connection to the eCGW 620-1 (for IP 1 ). If not, the eCGW 620-2 may establish a GTP tunnel with the eCGW 620-1 by sending a Create Session Request message.

[0212] The Create Session Request/Response messages may create user plane tunnels at both ends (e.g., the eCGW 620-1 and the eCGW 620-2). The eCGW may explore certain parameters (e.g., only certain parameters) in these GTP-C messages. The GTP binding table of the eCGW 620-1 may be modified with the details of the eCGW 620-2, for example, as follows.

GTP table(eCGW 620-1 ):

MAC UE IP eCGW

MAC 1 IP 1 eCGW 620-2

GTP table(eCGW 620-2):

MAC UE IP eCGW

MAC 1 IP 1 eCGW 620-1

MAC 1 IP 2 eCGW 620-2

DAMN table:

MAC UE IP eCGW

MAC 1 IP 1 eCGW 620-1

MAC 1 IP 2 eCGW 620-2 [0213] It is contemplated that the DAMN 910 may refer to the eCGW 620-1 for IP1 and the eCGW 620-2 for IP2 and the eCGW 620-2 may refer (e.g., may always refer) to the local table first for IP 1 ) since it has an entry for IP 1.

[0214] The UE 102-1 may conduct a DHCP release (e.g., when IP 1 entry removal is complete). The eCGW 620-2 may send a Delete Session Request message to the eCGW 620-1 for IP 1. The eCGW 620-1 may remove IP 1 entry and may release IP 1. The eCGW 620-1 may notify the DAMN 910 to remove the entry of IP 1.

[0215] The GTP binding table entries may be modified, for example, from those established above as follows.

GTP table(eCGW 620-1 ):

MAC UE IP eCGW

GTP table(eCGW 620-2):

MAC UE IP eCGW

MAC 1 IP 2 eCGW 620-2

DAMN table:

MAC UE IP eCGW

MAC 1 IP 2 eCGW 620-2

DAMN 910 may remove the IP 1 entry

S1 handover across SCNs

[0216] FIG. 28 is a diagram illustrating a representative DMM flow before and after a cellular handover procedure 2800.

[0217] Referring to FIG. 28, two eCGWs are illustrated and each may belong to a different SCN. For example, the eCGW 620-1 may belong to the SCN 610-1 and the eCGW 620-2 may belong to the SCN 610-2. The eCGW 620-1 and the eCGW 620-2 may use the DAMN 910 to enable a seamless data session during S1 handover.

[0218] Although FIG. 28 illustrates two eCGWs and two SCNs, any number of the eCGWs and any number of SCNs are possible.

[0219] FIG. 29 is a diagram illustrating yet another representative S1 handover procedure 2900, for example, using the system of FIG. 28.

[0220] Referring to FIG. 29, the S1 handover procedure 2900 may be performed when the UE 102-1 is handover from one H(e)NB 630-1 to another H(e)NB 630-2. An attach procedure may be performed as herein described except for the pre-registration from the eCGW 620-1 to the eCGW 620-2. At 2902, downlink (DL) data may be transferred to the UE 102-1 from the CDN 652 (or from the Edge Server). At 2904, uplink (UL) data may be transferred from the UE 102-1 , for example, to the CDN 652. For applications running before the handover, 2902 and 2904 illustrate the UL and DL data paths, respectively. After the handover, the UL and/or DL data path for these same applications may be changed. The UL and/or DL data paths may pass through the eCGW entities (e.g., eCGW 620-1 and eCGW 620-2) that are between the H(e)NBs 630-1 and 630-2 and the EPC 660 and the eCGWs 620-1 and 620-2 may update their GTP/PMIP binding tables in response to processes/actions/steps in the handover procedure.

[0221] Initially, the UE 102-1 may be connected to the H(e)NB 630-1 , via the eCGW 620-1 . The DL data path is illustrated at 2902. The DL data may traverse from the CDN 652 towards the eCGW 620-1 , through the GTP tunnel in place between the eCGW 620-1 and the H(e)NB 630-1 , and then over the air to the UE 102-1 . The UL data path is illustrated at 2904. Data originating in the UE 102-1 may travel to the H(e)NB 630-1 , through a GTP tunnel to the eCGW 620-1 and then towards the CDN 652. At 2906, the H(e)NB 630-1 may decide to handover the UE 102-1 to the H(e)NB 630-2.

[0222] It is contemplated that the H(e)NB 630-1 may configure the UE 102-1 to perform measurements and the UE 102-1 may perform those measurements and may report the measurements to the H(e)NB 630-1 , but these processes are omitted from FIG. 29 for brevity. It is also contemplated that there is not a direct path between the H(e)NB 630-1 and the H(e)NB 2, causing an S1 Handover (e.g., not an X2 Handover).

[0223] As a result of the handover decision, at 2908, the H(e)NB 630-1 may issue a S1 Handover Request (and/or S1 Handover Required) message towards the MME 664. This message may include any of: (1 ) a target eNB Global ID and/or (2) a Tracking Area Code. At 2910, the MME 664 may map the eNB Global ID and/or Tracking Area Code to the eCGW 620-2. The MME 664 may begin preparing the eCGW 620-2 for the handover. At 2912, the MME 664 may issue a GTP Create Session Request message containing or including the IMSI of the UE 102-1 being handed over. Upon receipt of the GTP Create Session Request message, the eCGW 620-2 may update its GTP/PMIP binding table with a new entry for the IMSI.

[0224] Concurrently or sequentially, at 2912, the eCGW 620-2 may use the GTP signal/message as a trigger, to establish a GTP/PMIP tunnel 2220 between the eCGW 620-1 and the eCGW 620-2 for the UE 102-1 . The GTP/PMIP tunnel 2220 is illustrated at 2914 and the GTP/PMIP binding table in both the eCGW 620-1 and the eCGW 620-2 are also illustrated at 2916 and 2918, respectively. The GTP/PMIP binding table in the eCGW 620-1 reflects an entry for the UE 102-1 , indicating IP1 and eCGW 620-2 while the GTP/PMIP binding table in the eCGW 620-2 has two entries for the UE 102-1 . One of these entries indicates IP1 and eCGW 620-1 and the other indicates a blank for IP address and eCGW 620-2. Since the UE 102-1 has not been assigned an IP address for the eCGW 620-2, the IP address portion of the entry is blank (e.g., a null value). Once the GTP/PMIP tunnel 2220 is in place, any buffered UL data may be sent to the CDN 652 via the GTP/PMIP tunnel 2220 between the eCGW 620-1 and the eCGW 620-2. [0225] At 2920, the eCGW 620-2 may respond with a GTP Create Session Response message containing or including the eCGW TEID. The eCGW TEID may be given or provided to the H(e)NB 630-2 (e.g. later) so that the H(e)NB 630-2 may know or may determine the GTP tunnel endpoint. After 2920, any DL data sent towards the UE 102-1 may reach the H(e)NB 630-1 and may be buffered there as illustrated at 2922 and 2924. The DL data may continue to be buffered. After receiving a proper GTP response from the eCGW 620-2, the MME 664 may send the S1 Handover Request message to the H(e)NB 630-2, at 2926. The S1 Handover Request message may include the GTP tunnel endpoint information at the eCGW 620-2 so that the H(e)NB 630-2 may know where the GTP tunnel terminates. In this instance, the tunnel endpoint provided to the eCGW 620-2 is the identity of the eCGW 620-1 . At 2928, the H(e)NB 2 may respond with the S1 Handover Request Acknowledge message, containing or including the H(e)NB 630-2 GTP tunnel endpoint information.

[0226] The current UL data path is illustrated at 2930 Any UL data sent by the UE 102-1 to the H(e)NB 630-1 may be pushed towards the eCGW 620-1 via the GTP tunnel. After reaching the eCGW 620-1 , the eCGW 620-1 may push the data towards the CDN 652. At 2932, the MME 664 may command the H(e)NB 630-1 to command the UE 102-2 to handover using the S1 Handover Command message. Receiving the S1 Handover Command message, the H(e)NB 630-1 may send an RRC Handover Command message to the UE 102-1 , at 2934.

[0227] Simultaneously or sequentially, as illustrated at 2936 and 2938, respectively, the H(e)NB 630-1 may begin forwarding the DL data buffered at 2924 (and any subsequent DL data) to the H(e)NB 630-2 and the H(e)NB 630-2 may buffer this DL data. Any UL data that is sent during this period, if the data reaches the H(e)NB 630-1 , may be pushed towards the CDN 652 via the eCGW 620-1 (e.g., using any existing or new link).

[0228] At 2940, the H(e)NB 630-1 may send an S1 eNB Status Transfer message to the MME 664. The MME 664 may forward the information (e.g., from the message or the message itself) to the H(e)NB 630-2, at 2942. The GTP sequence numbers and PDCP sequence numbers to be passed from the source (the H(e)NB 630-1 ) to the target (the H(e)NB 2) entities may be enabled at 2940 and 2942.

[0229] Data may be forwarded from the H(e)NB 630-1 to the H(e)NB 630-2, as the UE 102-1 transitions from being connected from the H(e)NB 630-1 to the H(e)NB 630-2. At 1944, the UL data path is illustrated. Since the UE 102-1 has not handed over yet, UL packets may travel from the UE 102-1 to the H(e)NB 630-1 , to the eCGW 620-1 and then onto the CDN 652. The DL data path is illustrated at 2946, 2948, and 2950. Data sent by the CDN 652 may be received at the eCGW 620-1 and may be forwarded to the H(e)NB 630-1 via the existing GTP tunnel. The H(e)NB 630-1 may route the DL data to the H(e)NB 630-2 where the DL data may be buffered, at 2950. The data may remain buffered in the H(e)NB 630-2 until the handover is complete. At 2952, the UE 102-1 may detach from the H(e)NB 630-1 and may synchronize to the H(e)NB 630-2. Any UL data prior to 2952 may be sent from the UE 102-1 to the H(e)NB 630-1 , to the eCGW 620-1 and then onto the CDN 652 as illustrated at 2944. Once the UE 102-1 has handed over successfully, the UE 102-1 , as illustrated at 2954, may send a RRC Handover Confirmed message to the H(e)NB 630-2. As a result of receiving the RRC Handover Confirmed message (e.g., the signal), the H(e)NB 630-2, at 2956, may begin sending the DL data buffered at 2950 to the UE 102-1 .

[0230] Any UL data at this time may be sent from the UE 102-1 to the H(e)NB 630-2, and to the eCGW 620-2. The eCGW 620-2 may buffer this UL data to route the UL data to the CDN 652 via the eCGW 620-1 , once the PMIP tunnel 2220 is established. After receiving the RRC Handover Confirmed message, at 2954, the H(e)NB 2 may send an S1 Handover Notification message to the MME 664, at 2958. The MME 664 may issue the GTP Modify Bearer Request message to the eCGW 620-2, at 2960. At 2962, the eCGW 620-2 may respond with the GTP Modify Bearer Response message (e.g., or signal). At this point, the GTP tunnel, as illustrated at 2964, may exist between the H(e)NB 630-2 and the eCGW 620-2. Upon receipt of the GTP message or signal from eCGW 620-2, the MME 664 may start a timer to release the resources still configured in the H(e)NB 630-1 and the eCGW 620-1 . At 2966, the timer may allow forwarding (e.g., all forwarding) of data to complete before the resources are freed.

[0231] The UL data path followed after the handover is complete is illustrated at 2968. The UL data may travel through the GTP tunnel 2964 between the H(e)NB 630-2 and the eCGW 620-2 and may travel through the GTP/PMIP tunnel 2220 between the eCGW 620-1 and the eCGW 2. The DL data path after the GTP/PMIP tunnel 2220is in place is illustrated at 2970. It is understood that these are the data paths for those applications (e.g., only those applications) which were in operation prior to the handover. Any applications started post-handover may have a different data path as described herein.

[0232] Once the UE 102-1 has been handed over to the H(e)NB 630-2, the UE 102-1 may request an IP address, as illustrated at 2972, 2974, 2976 and 2978. The UE 102-1 may get this IPv6 address from the pool allocated to the eCGW 620-2, when it was provisioned.

[0233] The UE 102-1 may now have two IPv6 addresses including one assigned from the eCGW 620-1 and the other assigned from the eCGW 620-2. The first IP address assigned by the eCGW 620-1 may be considered "deprecated" and the other IP address assigned by the eCGW 620-2 may be considered "in use". The "deprecated" IP address may be used (e.g., only be used) for applications which were running prior to the handover. The "in use" IP Address may be used for applications that are started post-handover, as illustrated at 2980 The GTP/PMIP binding table in the eCGW 620-2 is illustrated at 2982 and the second entry has the newly issued IP2 address. The GTP/PMIP binding table in the DAMN 910 is illustrated at 2986.

[0234] It is contemplated that prior to handover and post-handover intervals may be based on a handover start time, a handover completion time and/or a delay period associated with one of these start or completion times.

[0235] The eCGW 620-2 may dispatch a Pre-registration request message to the eCGW 620-1 containing or including the IMSI and/or IP2, which may cause the eCGW 620-1 to update its GTP/PMIP binding table. The GTP/PMIP binding table in the eCGW 620-1 is illustrated at 2984. When the timer expires in the MME 664, as illustrated at 2988, the MME 664 may issue S1 and GTP messages/signals to the H(e)NB 630-1 and the eCGW 620-1 , respectively, to teardown the GTP tunnel between the H(e)NB 630-1 and the eCGW 620-1 for the UE 102-1. The S1 messages/signals are illustrated at 2990 and 2992 and the GTP messages/signals are illustrated at 2994 and 2996. At this point, the GTP tunnel between the H(e)NB 630-1 and the eCGW 620-1 may be removed.

Representative User interaction across SCNs (without mobility)

[0236] FIG. 30 is a diagram illustrating a representative eCGW user data session 3000 across SCNs 610-1 and 610-2.

[0237] Referring to FIG. 30, the eCGWs may support any number of WiFi APs, each connected to a corresponding eCGW. For example, two WiFi APs (e.g., the WiFi APs 640-1 and 640-2) may be respectively connected to a different eCGW (e.g., eCGWs 620-1 and 620-2). The eCGW 620-1 may belong to the SCN 610-1 and the eCGW 620-2 may belong to the SCN 610-2. The UE 102-1 may belong to the SCN 610-1 and the UE 102-2 and 102-3 may belong to the SCN 610-2. The UE 102-1 and UE 102-2 may have an established data session. The UEs (e.g., UE 102-1 and UE 102-2) may remain in their respective SCNs (e.g., SCN 610-1 and SCN 610-2). In the SCN 610-1 and/or 610-2 or outside the SCNs 610-1 and 610-2 may be located an application server (for example 920) In the Public Internet 650 may be the DAMN 910. Each SCN 610-1 and 610-2 may include a local gateway to extend the WiFi connectivity across SCNs.

[0238] FIG. 31 is a diagram illustrating a representative UE registration procedure 3100.

[0239] Referring to FIG. 31 , at 3120, the UE 102-1 may power up. After the UE 102-1 powers up, at 3125, the UE 102-1 may begin scanning for a WiFi AP (e.g., WiFi AP 640-1 and/or WiFi AP 640-2) with which to connect. Since the UE 102-1 may be located in the coverage area of WiFi AP 640-1 , it may detect the WiFi AP 640-1. At 3130, the UE 102-1 may associate with the WiFi AP 640-1. The UE 102-1 may request an IP address as illustrated at 3135, 3140, 3145 and 3150. At 3135, the UE 102-1 may send a router solicitation message to the eCGW 620-1. At 3140, the eCGW 620-1 may send (e.g., respond with) a router advertisement message to UE 102-1. At 3145, the UE 102-1 may send a DHCPv6 Request message to the eCGW 620-1 . At 3150, the eCGW 620-1 may send (e.g., response with) a DHCPv6 Response message to UE 102-1. The UE 102-1 may get the IPv6 address from a pool allocated to the eCGW 620-1 when it was provisioned. After assigning the UE 102-1 an IP address, at 3155, the IP Traffic Gateway 628 in the eCGW 620-1 may be used to pre-register the assigned IP address with the other (e.g., all the other) IP Traffic Gateways 628 in the SCNs (e.g., SCN 610-1 and 610-2). If the eCGW 620-1 and the eCGW 620-2 are not neighbors, there may not be any pre-registration directly with the eCGW 620-2. The eCGW 620-1 may pre-register with the DAMN 910. The parameters of the pre- registration message may include any of: (1 ) a MAC address of the UE 102-1 ; (2) the assigned IP address of the UE 102-1 ; and/or (3) an indication or information of through which eCGW (e.g., the eCGW 620-1 ) the UE 102-1 is connected. After 3155, both the IP Traffic Gateway 628 of the eCGW 620-1 and the DAMN 910 may have a GTP/PMIP binding table with an entry for the just assigned IP address and who assigned the IP address. The UE 102-1 may have an IP address table with the just assigned IP address indicated as "in use". The IP address table for the UE 102-

1 is illustrated at 3160. The GTP/PMIP binding table for the eCGW 620-1 is illustrated at 3165 and the GTP/PMIP binding table for the DAMN 910 is illustrated at 3170. At 3175, the application data may begin to flow between the UE 102-1 and the application server 920. The data path of the data may be through the eCGW 620-1 and the WiFi AP 640-1.

[0240] FIG. 32 is a diagram illustrating another representative UE registration procedure 3200.

[0241] Referring to FIG. 32, at 3220, the UE 102-2 may power up. After the UE 102-2 powers up, at 3225, the UE 102-2 may begin scanning for a WiFi AP (e.g., WiFi AP 640-1 and/or WiFi AP 640-2) with which to connect. Since the UE 102-2 may be located in the coverage area of WiFi AP 640-2, it may detect the WiFi AP 640-2. At 3230, the UE 102-2 may associate with the WiFi AP 640-2. The UE 102-2 may request an IP address as illustrated at 3235, 3240, 3245 and 3250. At 3235, the UE 102-2 may send a router solicitation message to the eCGW 620-2. At 3240, the eCGW 620-2 may send (e.g., respond with) a router advertisement message to UE 102-2. At 3245, the UE 102-2 may send a DHCPv6 Request message to the eCGW 620-2. At 3250, the eCGW 620-2 may send (e.g., response with) a DHCPv6 Response message to UE 102-2. The UE 102-2 may get the IPv6 address from a pool allocated to the eCGW 620-2 when it was provisioned. After assigning the UE 102-2 an IP address, at 3255, the IP Traffic Gateway 628 in the eCGW 620-2 may be used to pre-register the assigned IP address with the other (e.g., all the other) IP Traffic Gateways 628 in the SCNs (e.g., SCNs 610-1 and 610-2). If the eCGW 620-1 and the eCGW 620-2 are not neighbors, there may not be any pre-registration directly with the eCGW 620-1. The eCGW 620-2 may pre-register with the DAMN 910. The parameters of the pre- registration message may include any of: (1 ) a MAC address of the UE 102-2; (2) the assigned IP address of the UE 102-2; and/or (3) an indication or information of through which eCGW (e.g., the eCGW 620-2) the UE 102-2 is connected. After 3255, both the IP Traffic Gateway 628 of the eCGW 620-2 and the DAMN 910 may have a GTP/PMIP binding table with an entry for the just assigned IP address and who assigned the IP address. The UE 102-2 may have an IP address table with the just assigned IP address indicated as "in use". The IP address table for the UE 102-

2 is illustrated at 3260. The GTP/PMIP binding table for the eCGW 620-2 is illustrated at 3265 and the GTP/PMIP binding table for the DAMN 910 is illustrated at 3270. At 3275, the application data may begin to flow between the UE 102-2 and the application server 920. The data path of the data may be through the eCGW 620-2 and the WiFi AP 640-2.

[0242] FIG. 33 is a diagram illustrating a representative communication procedure 3300. FIG. 34 is a continuation after the registration procedures of FIG. 31 and/or FIG. 32.

[0243] Referring to FIG. 33, after the UE 102-1 and UE 102-2 are registered, at 3310, UE 102-1 may send data to UE 102-2. At 3320, IP 1 may still be managed by the eCGW 620-1. The destination IP address (IP 2) may be extracted and checked in the local GTP/PMIP binding table (e.g., of the eCGW 620-1 ). If there is no entry in the local GTP/PMIP binding table, the eCGW 620-1 may check the DAMN 910 for IP 2. At 3330, if IP 2 is found in the local binding table and/or the binding table of the DAMN 910, the eCGW 620-1 may establish a GTP/PMIP tunnel 2220 between the eCGW 620-1 and the eCGW 620-2. At 3340, the eCGW 620-1 may forward a packet to the eCGW 620-2 on the newly created GTP/PMIP tunnel 2220. At 3350, the eCGW 620-2 may check if there is any valid GTP TEID to reach the destination IP address (IP 2). If there is a valid GTP TEID, the eCGW 620-2 may forward the packet to the UE 102-2. If the TEID is not found, the eCGW 620-2 may contact the ESF 670.

[0244] FIG. 34 is a diagram illustrating another representative communication procedure 3400. FIG. 34 is a continuation after the registration procedures of FIG. 31 and/or FIG. 32.

[0245] Referring to FIG. 34, after the UE 102-1 and UE 102-2 are registered, at 3410, UE 102-2 may send data to UE 102-1. At 3420, IP 2 may still be managed by the eCGW 620-2. The destination IP address (IP 1 ) may be extracted and checked in the local GTP/PMIP binding table (e.g., of the eCGW 620-2). If there is no entry in the local GTP/PMIP binding table, the eCGW 620-2 may check the DAMN 910 for IP 1. At 3430, if IP 1 is found in the local binding table and/or in the binding table of the DAMN 910, the eCGW 620-2 may establish a GTP/PMIP tunnel 2220 between the eCGW 620-1 and the eCGW 620-2. At 3440, the eCGW 620-2 may forward a packet to the eCGW 620-1 on the newly created GTP/PMIP tunnel 2220. At 3450, the eCGW 620-1 may check if there is any valid GTP TEID to reach the destination IP address (IP 1 ). If there is a valid GTP TEID, the eCGW 620-1 may forward the packet to the UE 102-1. If the TEID is not found, the eCGW 620-1 may contact the ESF 670.

Representative GTP Binding Table Handling

[0246] The eCGW 620-1 and the eCGW 620-2 may belong to different SCNs (SCN 610-1 and SCN 610-2). The UE 102-1 may be attached on the eCGW 620-1 and the UE 102-2 may be attached on the eCGW 620-2. Pre-registration may be performed with the DAMN 910 from the eCGW 620-1 for IP 1 and from the eCGW 620-2 for IP 2. The eCGW 620-1 and the eCGW 620-2 may not be neighbors. The GTP binding table entries and the DAMN entries may be as follows:

GTP table(eCGW 620-1 ):

MAC UE IP eCGW

MAC 1 IP 1 eCGW 620-1

GTP table(eCGW 620-2):

MAC UE IP eCGW

MAC 2 IP 2 eCGW 620-2 DAMN table:

MAC UE IP eCGW

MAC 1 IP 1 eCGW 620-1

MAC 2 IP 2 eCGW 620-2

[0247] The UE 102-1 may send data to the UE 102-2. When the data comes from the UE 102- 1 (MAC 1 ) to the UE 102-2(MAC 2) on the eCGW 620-1 , the eCGW 620-1 may check the GTP binding table(eCGW 620-1 ) for the Source IP address (IP 1 ) and IP 1 may still be handled by the eCGW 620-1. The eCGW 620-1 may check the GTP binding table(eCGW 620-1 ) for destination IP address (IP 2), and no entry may be found for IP 1.

[0248] The eCGW 620-1 may contact (e.g., make a request of) the DAMN 910 to check the DAMN table. There may be an entry in the DAMN table for IP 2. A GTP tunnel 2220 from the eCGW 620-1 to the eCGW 620-2 may be created for IP 2, and the data may be forwarded to the eCGW 620-2 for further processing. If there was no entry in the DAMN table for IP 2, a regular CDN flow may be used and the eCGW 620-1 may contact ESF 670/CDN 652 or public Internet 650. After creating the GTP tunnel 2220 between the eCGW 620-1 and the eCGW 620-2 for IP 2, the GTP binding tables and the DAMN table may be as follows:

GTP table(eCGW 620-1 ):

MAC UE IP eCGW

MAC 1 IP 1 eCGW 620-1

MAC 2 IP 2 eCGW 620-2

GTP table(eCGW 620-2):

MAC UE IP eCGW

MAC 2 IP 2 eCGW 620-2

DAMN table:

MAC UE IP eCGW

MAC 1 IP 1 eCGW 620-1

MAC 2 IP 2 eCGW 620-2

[0249] The eCGW 620-2 may receive the data and may extract the destination IP address(IP 2). The eCGW 620-2 may check if there is any suitable GTP TEID to reach IP 2. In this case, there is a TEID to reach IP 2(UE 102-2). If there is no GTP TEID to reach IP 2, the eCGW 620-2 may contact the ESF 670/CDN 652. The eCGW 620-2 may or may not check GTP binding/DAMN table for IP 2 in this case, as the packet is received on an inter-eCGW interface. [0250] The UE 102-2 may send data to the UE 102-1 , when the data comes from UE 102- 2(MAC 2) to UE 102-1 (MAC 1 ) on the eCGW 620-2.

[0251] The eCGW 620-2 may check the GTP binding table (eCGW 620-2) for the Source IP address (IP 2) and IP 2 may still be handled by the eCGW 620-2. The eCGW 620-2 may check the GTP binding table (eCGW 620-2) for destination IP address (IP 1 ) and no entry may be found for IP 1. The eCGW 620-2 may contact (e.g., make a request of) the DAMN 910 to check the DAMN table.

[0252] There may be an entry in the DAMN table for IP 1. A GTP tunnel 2220 from the eCGW 620-2 to the eCGW 620-1 may be created for IP 1 , and the data may be forwarded to the eCGW 620-1 for further processing. If there was no entry in the DAMN table for IP 1 , a regular CDN flow may be used and the eCGW 620-2 may contact ESF 670/CDN 562 or public Internet 650. After creating the GTP tunnel 2220 between the eCGW 620-2 and the eCGW 620-1 for IP 1 , the GTP binding tables and the DAMN table may be as follows:

GTP table(eCGW 620-1 ):

MAC UE IP eCGW

MAC 1 IP 1 eCGW 620-1

MAC 2 IP 2 eCGW 620-2

GTP table(eCGW 620-2):

MAC UE IP eCGW

MAC 2 IP 2 eCGW 620-2

MAC 1 IP 1 eCGW 620-1

DAMN table:

MAC UE IP eCGW

MAC 1 IP 1 eCGW 620-1

MAC 2 IP 2 eCGW 620-2

[0253] The eCGW 620-1 may receive the data and may extract the destination IP address (IP 1 ). The eCGW 620-1 may check if there is any suitable GTP TEID to reach IP 1. In this case, there is a TEID to reach IP 1 (UE 102-1 ). If there is no GTP TEID to reach IP 1 , the eCGW 620-1 may contact the ESF 670/CDN 652. The eCGW 620-1 may or may not check GTP binding/DAMN table for IP 1 in this case, as the packet is received on the inter-eCGW interface.

[0254] When a DHCP Release is received by the eCGW 620-1 (for IP 1 ), the eCGW 620-1 may notify the DAMN 910 to remove the entry in its DAMN table and the eCGW 620-1 may release IP 1. The GTP binding tables and the DAMN table after the release may be as follows: GTP table(eCGW 620-1 ):

MAC UE IP eCGW

MAC 2 IP 2 eCGW 620-2

GTP table(eCGW 620-2):

MAC UE IP eCGW

MAC 2 IP 2 eCGW 620-2

MAC 1 IP 1 eCGW 620-1

DAMN table:

MAC UE IP eCGW

MAC 2 IP 2 eCGW 620-2

[0255] When a DHCP Release is received by the eCGW 620-2 (for IP 2), the eCGW 620-2 may notify the DAMN 910 to remove the entry IP 2 from its GTP binding table. The eCGW 620-2 may release IP 2. The GTP binding tables and the DAMN table after the release may be as follows:

GTP table(eCGW 620-1 ):

MAC UE IP eCGW

MAC 2 IP 2 eCGW 620-2

GTP table(eCGW 620-2):

MAC UE IP eCGW

MAC 1 IP 1 eCGW 620-1

DAMN table:

MAC UE IP eCGW

Representative TR069 API for DMM

[0256] In certain representative embodiments, a TR069 API may be implemented for interfacing between the IP Traffic GW 628 and a H(e)MS/ACS (not shown) in the EPC or on the public Internet. For the communication between the IP Traffic GW 628 and the H(e)MS/ACS, the CPE WAN management protocol in TR069 may be implemented, which is a bidirectional SOAP/HTTP- based protocol used to configure the IP Traffic GW 628. The TR069 interface may be used for the initial provisioning of the IP Traffic GW 628. The TR069 interface may be used to update the IP Traffic GW 628, whenever the new neighbor eCGW is added or an already existing neighbor eCGW is deleted. [0257] The initial provisioning of the IP Traffic GW 628 is performed to configure the following at the eCGW 620 based on the Global ID received from the eCGW 620: (1 ) the FQDN of the eCGW 620; (2) a pool of IP addresses for assigning to the UEs 102 including, for example, an IP Address Pool Start Address, an IP Address Pool End Address and/or an IP Address Network Mask; and/or (3) a list of neighbor eCGWs 620 with each neighbor eCGW 620 comprising a Global ID and/or a FQDN, among others.

[0258] The list of neighbor eCGWs 620 at the IP Traffic GW 628 may be updated when the new neighbor eCGW 620 is added. The list of neighbor eCGWs 620 at the IP Traffic GW 628 may be updated when an already existing neighbor eCGW 620 is deleted.

Representative RPC Methods

[0259] The following Table 5 lists the various RPC methods supported to enable the communication between the IP Traffic GW 628 and the H(e)MS/ACS.

Table 5: TR069 RPC Methods

Representative Data Model

[0260] A list of Data Model Parameters for the TR069 interface is listed below in Table 6.

Table 6: TR069 Data Model

Name Type Write Description

InternetGatewayDevice.Dev Object - The Device Object containing the icelnfo. device parameters

>GloballD string(32) The Global Identifier for the eCGW. It may be combination of VendorlD and SerialNumber of the device

>FQDN string(32) W Self Fully Qualified Domain Name

>DeviceState unsigned The Device Status

Int (Initialization/Established)

>IPAddressPoolStart string(32) w The Starting IP Address of the IP

Address Pool

>IPAddressPoolEnd string(32) w The Ending IP Address of the IP

Address Pool

>IPAddressNetworkMask string(32) w The Network Mask for the IP Address

Pool

>lnternetGatewayDevice. Object - The Device Object containing the

Devicelnfo. details of the neighbor eCGWs eCGWneighborlist.{i}.

»GloballD string(32) W The Global Identifier for the neighbor eCGW

»FQDN string(32) W Fully Qualified Domain Name of

neighbor eCGW

Representative Interface Services

[0261] The following Table 7 lists the supported TR069 interface services.

Table 7: TR069 Interface Services

Initial Provisioning of eCGW

Add neighbor eCGW

Delete neighbor eCGW

Representative Initial provisioning of the eCGW

[0262] The TR069 API may provide for the ability for the H(e)MS/ACS to configure the IP Traffic GW 628. The operation of the TR069 API allows the H(e)MS/ACS to perform initial provisioning of the eCGW 620. Representative Request and Response Arguments are as follows.

Representative Request Arguments

Name Opt I Description

> Global ID - I The global identifier for eCGW.

I NOTE: The Global ID is a unique identifier for eCGW.

> FQDN I Self Fully Qualified Domain Name of the eCGW

> IPAddressPoolStart I The Starting IP Address of the ΪΡ Address Pool

> IPAddressPoolEnd I The Ending ΪΡ Address of t e IP Address Pool

>IPAddressNetworkMa I Trie Network Mask for the IP Address Pool

sk

>List of neighbor Y I It provides a list of neighbor eCGWs [Global ID,

eCGWs I FQDN].

» Global ID I The global identifier for neighbor eCGW.

I NOTE: The Global ID is a unique identifier for eCGW.

» FQDN I Fully Qualified Domain Name of the neig bor eCGW.

Representative Response Arguments

Name Opt Description

Result Success / failure indication.

Authentication

[0263] HTTP Basic Authentication may be performed between the TR069 Client at the IP Traffic GW and the TR069 Server at the H(e)MS/ACS.

Representative Procedures/Methods

[0264] Representative transaction procedures/methods for initial provisioning of an eCGW 620 may include the initial provisioning and any subsequent re-provisioning of the eCGW 620, which may be accessed via the TR069 API to configure the eCGW 620. The following procedures/methods are available including: (1 ) an inform RPC procedure/method, which may be used to inform the Global ID and the device state of the eCGW 620 (the IP Traffic GW 628 may send the Inform Request procedure/method towards the H(e)MS/ACS and the H(e)MS/ACS may respond with the Inform Response); (2) a SetParameterValues RPC procedure/method may be used to configure the eCGW FQDN and/or IP Address Pool information (the H(e)MS/ACS may send the SetParameterValues Request procedure/method towards the IP Traffic GW 628 and the IP Traffic GW 628 may respond with the SetParameterValues Response); (3) the AddObject may be used to add neighbor eCGW information (the H(e)MS/ACS may send the AddObject Request procedure/method towards the IP Traffic GW 628 and the IP Traffic GW 628 may respond with the AddObject Response); and/or (4) a SetParameterValues may be used to populate the contents of the neighbor eCGW data object added (the H(e)MS/ACS may send the SetParameterValues Request procedure/method towards the IP Traffic GW 628 and the IP Traffic GW 628 may respond with the SetParameterValues Response).

Inform Request Example

[0265] The following is an example of an Inform Request.

<soap:Body>

<cwmp:lnform>

<Parameterl_ist soap-enc:arrayType="cwmp:ParameterValueStruct[6]">

<Name> InternetGatewayDevice.Devicelnfo. GloballD </Name>

<Value xsi:type="xsd:string">VendorlD_SerialNumber <A alue>

</ParameterValueStruct>

<Name> InternetGatewayDevice.Devicelnfo. DeviceState</Name>

</ParameterValueStruct>

</Parameterl_ist>

</cwmp:lnform>

</soap:Body>

[0266] It is contemplated that the MaxEnvelopes may indicate to the H(e)MS/ACS the maximum number of SOAP envelopes that may be contained in a single HTTP Response message. The Device State can take the values O(INITIALIZATION), 1 (ESTABLISHED). Inform Response Example

[0267] The following is an example of an Inform Response:

<soapenv:Envelopexmlns:soap="http://schemas. xmlsoap.org/soap/encoding/"

xmlns:xsd="http://www. w3.org/2001/XMLSchema" xmlns:cwmp="urn:dslforum-org:cwmp-1 -0" xmlns:soapenv="http://schemas. xmlsoap.org/soap/envelope/"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<soapenv:Header>

<cwmp:ID soapenv:mustUnderstand="1 ">1 </cwmp:ID>

</soapenv:Header>

<soapenv:Body>

<cwmp:lnformResponse>

</cwmp:lnformResponse>

</soapenv:Body>

</soapenv:Envelope>

[0268] It is contemplated that cwmp:ID may be a unique session identifier for each of the SOAP transaction sessions. MaxEnvelopes may indicate to the IP Traffic GW the maximum number of SOAP envelopes that may be contained in a single HTTP Post message.

SetParameterValues Request Example

[0269] The following is an example of a SetParameterValues Request.

<soap:Body>

<cwmp:SetParameterValues>

<Parameterl_ist soap-enc:arrayType="cwmp:ParameterValueStruct[1 ]">

<Name> InternetGatewayDevice.Devicelnfo. GloballD </Name>

<Value xsi:type="xsd:string">VendorlD_SerialNumber <A alue>

</ParameterValueStruct>

<Name> InternetGatewayDevice.Devicelnfo. FQDN </Name>

<Value xsi:type="xsd:string">www.VendorlD_SerialNumber.com <A alue>

</ParameterValueStruct>

<Name> InternetGatewayDevice.Devicelnfo. IPAddressPoolStart </Name>

<Name> InternetGatewayDevice.Devicelnfo. IPAddressPoolEnd</Name>

</ParameterValueStruct>

<Name> InternetGatewayDevice.Devicelnfo. IPAddressNetworkMask</Name>

</ParameterValueStruct>

</ParameterList>

</cwmp:SetParameterValues>

</soap:Body>

SetParameterValues Response Example

[0270] The following is an example of a SetParameterValues Response.

<soap:Body>

<cwmp:SetParameterValuesResponse>

</cwmp:SetParameterValuesResponse>

[0271] It is contemplated that status can take values O(Success), 1 (Failure- Internal Server Error), 2(Failure-lnvalid).

AddObject Request Example

[0272] The following is an example of a AddObject Request.

<soapenv:Body>

<cwmp:AddObject>

<ObjectName> lnternetGatewayDevice.Devicelnfo.eCGWneighborlist</ObjectName>

</cwmp:AddObject>

</soapenv:Body>

AddObject Response Example

[0273] The following is an example of a AddObject Response.

<SOAP-ENV:Body SOAP-ENV:encodingStyle="http://schemas. xmlsoap.org/soap/encoding/"> <cwmp:AddObjectResponse>

</cwmp:AddObjectResponse>

</SOAP-ENV:Body>

[0274] It is contemplated that the Instance Number returned as part of AddObject Response may be used to uniquely identify the neighbor eCGW for the later TR069 transactions.

SetParameterValues Request Example

[0275] The following is an example of a SetParameterValues Request.

<soap:Body>

<cwmp:SetParameterValues>

<Parameterl_ist soap-enc:arrayType="cwmp:ParameterValueStruct[1 ]">

<Name> InternetGatewayDevice.Devicelnfo.eCGWneighborlist . 1 .GIoballD</Name> <Value xsi:type="xsd:string"> VendorlD_SerialNumber <A alue>

<Name> InternetGatewayDevice.Devicelnfo.eCGWneighborlist . 1 .FQDN</Name>

<Value xsi:type="xsd:string">www. VendorlD_SerialNumber .com<A alue>

</ParameterValueStruct>

</ParameterList>

</cwmp:SetParameterValuesResponse>

</soap:Body>

SetParameterValues Response Example

[0276] The following is an example of a SetParameterValues Response.

<soap:Body>

<cwmp:SetParameterValuesResponse>

</cwmp:SetParameterValuesResponse>

</soap:Body>

[0277] It is contemplated that status can take values O(Success), 1 (Failure- Internal Server Error), 2(Failure-lnvalid). Add neighbor eCGW

[0278] The TR069 API may provide the ability for the H(e)MS/ACS to add one or more new neighbors in the IP Traffic GW 628. The operation of the TR069 API may allow the H(e)MS/ACS to add one or more new neighbors in the IP Traffic GW 628. Representative Request and Response Arguments are as follows.

Representative Request Arguments

Representative Response Arguments

Authentication

[0279] HTTP Basic Authentication may be performed between the TR069 Client at the IP Traffic GW 628 and the TR069 Server at the H(e)MS/ACS.

Representative Procedures/Methods

[0280] Representative transactional procedures for adding a neighbor eCGW 620 may be accessed via the TR069 API to add one or more new neighbors in the IP Traffic GW 628. The connection request may be initiated from the H(e)MS/ACS towards the IP Traffic GW 628 to initiate the connection. The following procedures/methods may be available including: (1 ) an inform RPC procedure/method may be used to inform the Global ID and/or the device state of the eCGW 620 (the IP Traffic GW 628 may send the Inform Request method towards the H(e)MS/ACS and the H(e)MS/ACS may respond with the Inform Response); (2) an AddObject may be used to add neighbor eCGW information (the H(e)MS/ACS may send the AddObject Request procedure/method towards the IP Traffic GW 628 and the IP Traffic GW 628 may respond with the AddObject Response); and/or (3) a SetParameterValues may be used to populate the contents of the neighbor eCGW data object added (the H(e)MS/ACS may send the SetParameterValues Request procedure/method towards the IP Traffic GW 628 and the IP Traffic GW 628 may respond with the SetParameterValues Response), among others.

Inform Request Example

[0281] The following is an example of an Inform Request.

<soap:Body>

<cwmp:lnform> <MaxEnvelopes>1 </MaxEnvelopes>

<Parameterl_ist soap-enc:arrayType="cwmp:ParameterValueStruct[6]">

<Name> InternetGatewayDevice.Devicelnfo. GloballD </Name>

<Value xsi:type="xsd:string">VendorlD_SerialNumber <A alue>

</ParameterValueStruct>

<Name> InternetGatewayDevice.Devicelnfo. DeviceState</Name>

</ParameterValueStruct>

</ParameterList>

</cwmp:lnform>

</soap:Body>

[0282] It is contemplated that MaxEnvelopes may indicate to the H(e)MS/ACS the maximum number of SOAP envelopes that may be contained in a single HTTP Response message. The Device State can take the values O(INITIALIZATION), 1 (ESTABLISHED).

Inform Response Example

[0283] The following is an example of an Inform Response.

<soapenv:Envelope xmlns:soap="http://schemas. xmlsoap.org/soap/encoding/"

xmlns:xsd="http://www. w3.org/2001/XMLSchema" xmlns:cwmp="urn:dslforum-org:cwmp-1-0" xmlns:soapenv="http://schemas. xmlsoap.org/soap/envelope/"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<soapenv:Header>

<cwmp:ID soapenv:mustUnderstand="1">1 </cwmp:ID>

</soapenv:Header>

<soapenv:Body>

<cwmp:lnformResponse>

</cwmp:lnformResponse>

</soapenv:Body>

</soapenv:Envelope>

[0284] It is contemplated that cwmp:ID may be a unique session identifier for each of the SOAP transaction sessions. MaxEnvelopes may indicate to the IP Traffic GW the maximum number of SOAP envelopes that may be contained in a single HTTP Post message. AddObject Request Example

[0285] The following is an example of a AddObject Request.

<soapenv:Body>

<cwmp:AddObject>

<ObjectName> lnternetGatewayDevice.Devicelnfo.eCGWneighborlist</ObjectName>

</cwmp:AddObject>

</soapenv:Body>

AddObject Response Example

[0286] The following is an example of a AddObject Response.

<SOAP-ENV:Body SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<cwmp:AddObjectResponse>

</cwmp:AddObjectResponse>

</SOAP-ENV:Body>

[0287] It is contemplated that the Instance Number returned as part of AddObject Response may be used to uniquely identify the neighbor eCGW for the later TR069 transactions.

SetParameterValues Request Example

[0288] The following is an example of a SetParameterValues Request.

<soap:Body>

<cwmp:SetParameterValues>

<Parameterl_ist soap-enc:arrayType="cwmp:ParameterValueStruct[1]">

<Name> InternetGatewayDevice.Devicelnfo.eCGWneighborlist . 5.GloballD</Name> <Value xsi:type="xsd:string"> VendorlD_SerialNumber <A alue>

</ParameterValueStruct>

<Name> InternetGatewayDevice.Devicelnfo.eCGWneighborlist . 5.FQDN</Name>

<Value xsi:type="xsd:string"> www.VendorlD_SerialNumber.com <A alue>

</ParameterValueStruct> </Parameterl_ist>

</cwmp:SetParameterValues>

</soap:Body>

SetParameterValues Response Example

[0289] The following is an example of a SetParameterValues Response.

<soap:Body>

<cwmp:SetParameterValuesResponse>

</cwmp:SetParameterValuesResponse>

</soap:Body>

[0290] It is contemplated that status can take values O(Success), 1 (Failure- Internal Server Error), 2(Failure-lnvalid).

Delete Neighbor eCGW

[0291] The TR069 API may provide the ability for the H(e)MS/ACS to delete one or more existing neighbors in the IP Traffic GW 628. The operation of the TR069 API may allow the H(e)MS/ACS to delete one or more existing neighbors in the IP Traffic GW 628. Representative Request and Response Arguments are as follows.

Representative Request Arguments

Representative Response Arguments

Authentication

[0292] HTTP Basic Authentication may be performed between the TR069 Client at the IP Traffic GW 628 and the TR069 Server at the H(e)MS/ACS.

Representative Procedures/Methods

[0293] Representative transactional procedures for deleting a neighbor eCGW 620 may be accessed via the TR069 API to delete one or more existing neighbors in the IP Traffic GW 628. The connection request may be initiated from the H(e)MS/ACS towards the IP Traffic GW 628 to initiate the connection. The following procedures/methods may be available including: (1 ) an inform RPC procedure/method may be used to inform the Global ID and/or the device state of the eCGW (the IP Traffic GW 628 may send the Inform Request procedure/method towards the H(e)MS/ACS and the H(e)MS/ACS may respond with the Inform Response); and/or (2) a DeleteObject may be used to delete neighbor eCGW information (the H(e)MS/ACS may send the DeleteObject Request procedure/method towards the IP Traffic GW 628 and the IP Traffic GW 628 may respond with the DeleteObject Response), among others.

Inform Request Example

[0294] The following is an example of an Inform Request.

<soap:Body>

<cwmp:lnform>

<Parameterl_ist soap-enc:arrayType="cwmp:ParameterValueStruct[6]">

<Name> InternetGatewayDevice.Devicelnfo. GloballD </Name>

<Value xsi:type="xsd:string">VendorlD_SerialNumber <A alue>

</ParameterValueStruct>

<Name> InternetGatewayDevice.Devicelnfo. DeviceState</Name>

</ParameterValueStruct>

</Parameterl_ist>

</cwmp:lnform>

</soap:Body>

[0295] It is contemplated that MaxEnvelopes may indicate to the H(e)MS/ACS the maximum number of SOAP envelopes that may be contained in a single HTTP Response message. The Device State can take the values O(INITIALIZATION), 1 (ESTABLISHED).

Inform Response Example

[0296] The following is an example of an Inform Response.

<soapenv:Envelopexmlns:soap="http://schemas. xmlsoap.org/soap/encoding/"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<soapenv:Header> <cwmp: ID soapenv:mustUnderstand=" 1 ">1 </cwmp: ID>

</soapenv:Header>

<soapenv:Body>

<cwmp: lnformResponse>

</cwmp: lnformResponse>

</soapenv: Body>

</soapenv:Envelope>

[0297] It is contemplated that cwmp: ID may be a unique session identifier for each of the SOAP transaction sessions. MaxEnvelopes may indicate to the IP Traffic GW 628 the maximum number of SOAP envelopes that may be contained in a single HTTP Post message.

DeleteObject Request Example

[0298] The following is an example of a DeleteObject Request.

<soapenv:Body>

<cwmp:DeleteObject>

<ObjectName> InternetGatewayDevice.Devicelnfo.eCGWneighborlist . 5</ObjectName>

</cwmp:DeleteObject>

</soapenv: Body>

DeleteObject Response Example

[0299] The following is an example of a DeleteObject Response.

<cwmp:DeleteObjectResponse>

</cwmp:DeleteObjectResponse>

</SOAP-ENV:Body>

[0300] It is contemplated that status may take values O(Success), 1 (Failure- Internal Server Error), 2(Failure-lnvalid).

Representative messages for GTP-C

[0301 ] New messages for GTP-C to enable creation and deletion of inactive sessions may include: (1 ) Create Inactive Session Request messages; (2) Create Inactive Session Response messages; (3) Delete Inactive Session Request messages; and/or (4) Delete Inactive Session Response messages.

[0302] The Create Inactive Session Request/Response messages may be used to create an inactive session. The Create Inactive Session Request message may not create user plane TEIDs at source and destination nodes. The Create Inactive Session Request message may pass IMSI (or other subscriber/device identifier), IP, and eCGW ID(IP) to the destination as part of the pre- registration procedure.

Representative Information Elements in a Create Inactive Session Request message

Information Elements in a Create Inactive Session Response message

[0303] The Delete Inactive Session Request/Response messages may be used to delete inactive sessions at neighbors. For example, when an IP address is released, the eCGW 620 may notify the neighbors to remove inactive sessions.

Information Elements in a Delete Inactive Session Request message

Information Elements in a Delete Inactive Session Response message

Representative messages for PMIP

[0304] New messages for PMIP may include, for example: (1 ) PMIP: Create Binding Inactive (CBI) messages; (2) PMIP: Create Binding Ack (CBA) messages; (3) PMIP: Delete Binding Inactive (DBI) messages and/or (4) PMIP: Delete Binding Inactive Ack (DBA) messages, among others.

Representative signals for S1AP

[0305] New signals (e.g., signal types) may be exchanged between the eCGW 620 and the MME 664 and may be signals/messages added to the existing S1 AP interface, (See 3GPP TS 36.413, Release 10, the contents of which are incorporated by reference herein). Three new messages/signals may include: (1 ) GW Configuration Request message; (2) GW Configuration Response message; and/or (3) GW Configuration Failure message, among others.

S1AP: GW Configuration Request message

[0306] The S1AP: GW Configuration Request message may be sent by the eCGW 620 to the MME 664 to request the download of the eCGWs own IP, UE IP pool segment and/or the eCGW's neighbor list. Tables 8 and 9 include details of the GW Configuration Request message.

Direction: eCGW -> MME Table 8 - GW Configuration Request message

a.b.c.d: Global eCGW ID

Table 9 - Global eCGW ID field

S1AP: GW Configuration Response message

[0307] The S1AP: GW Configuration Response message may be sent by the MME 664 to the eCGW 620 with the requested eCGWs IP address, the UE start and end IP addresses and the eCGW neighbor list. Table 10 includes details of the GW Configuration Response message. Direction: MME -> eCGW

Table 10 - GW Configuration Response

Range bound Explanation

maxnoofeCGWIds Maximum no. of neighbor eCGWs. Value is 10.

S1AP: GW Configuration Failure message

[0308] The S1AP: GW Configuration Failure message may be sent by the MME 664 to the eCGW 620 to indicate eCGW Configuration failure. Table 1 1 includes details of the GW Configuration Failure message.

Direction: MME -> eCGW

Table 11 - GW Configuration Failure

Time to wait

This IE defines the minimum allowed waiting times.

[0309] FIG. 35 is a flow diagram of a representative method 3500 for registration of a first network entity 620-2 with other network entities 620. The first network entity 620-2 may control flow and/or session routing between or among a communication network 610-2 and one or more network access points. 630-2 and 640-2.

[0310] Referring to FIG. 35, the representative method 3500 may include, at block 3510, the first network entity 620-2 performing network entity discovery. For example, the first network entity 620-2 may send pre-registration information to register the first network entity 620-2 with a registration entity 910 and may receive from the registration entity 910 pre-registration information of other network entities 620.

[0311] In certain representative embodiments, the pre-registration information may include any of: (1 ) a list of neighboring network entities 620-1 ; (2) a unique identifier of a terminal device 102-1 ; (3) information indicating the unique identifier of the terminal device 102-1 and/or that the first network entity 620-1 is managing an IP address of the terminal device 102-1 , among others.

[0312] FIG. 36 is a flow diagram of another representative method 3600 for registration of a first network entity 620-2 with other network entities 620-1. The first network entity 620-2 may control flow and/or session routing between or among a communication network 610 and one or more network access points. 630-2 and 640-2.

[0313] Referring to FIG. 36, the representative method 3600 may include, at block 3610, the first network entity 620-2 performing network entity discovery. For example, the first network entity 620-2 may send pre-registration information to register the first network entity 620-2 with one or more of the other network entities 620 that control flow or session routing and may receive from a respective one or respective ones of the one or more other network entities 620-1 pre-registration information of the respective one or respective ones of the network entities 620-1.

[0314] In certain representative embodiments, the pre-registration information may include any of: (1 ) a list of neighboring network entities 620-1 ; (2) a unique identifier of a terminal device 102-1 ; (3) information indicating the unique identifier of the terminal device 102-1 and/or that the other network entity 620-1 is managing an IP address of the terminal device 102-1 , among others.

[0315] FIG. 37 is a flow diagram of a representative method 3700 for a handover of a WTRU 102-1 to a network access point (AP) 640-2 using a first network entity 620-2 and a second network entity 620-1.

[0316] Referring to FIG. 37, the representative method 3700 may include, at block 3710, the first network entity 620-2 performing network entity discovery of the second network entity 620-1 using pre-registration information. At block 3720, the first network entity 620-2 may establish a tunnel 2220 between the first network entity 620-2 and the second network entity 620-1 based on the pre- registration information. At block 3730, the first network entity 620-2 may send and/or may receive data packets associated with an application executing on the WTRU 102-1 and started prior to handover, via the second network entity 620-1 and via the established tunnel 2220.

[0317] In certain representative embodiments, the first network entity 620-2 may, tear down the established tunnel 2220 responsive to each application executing on the WTRU 102-1 prior to the handover terminating.

[0318] In certain representative embodiments, the tunnel 2220 may be based on GPRS Tunneling Protocol (GTP) or Proxy Mobile IP (PMIP).

[0319] FIG. 38 is a flow diagram of a representative method 3800 for a handover of a WTRU 102-1 between a first network access point (AP) 640-2 and a second network AP 640-1 using the first network entity 620-2 and a second network entity 620-1.

[0320] Referring to FIG. 38, the representative method 3800 may include, at block 3810, the first network entity 620-2 performing network entity discovery of the second network entity 620-1 using pre-registration information. [0321] At block 3820, the first network entity 620-2 may establish a tunnel 2220 between the first network entity 620-2 and the second network entity 620-1 based on the pre-registration information. At block 3830, after the handover: the first network entity 620-2 may receive data packets associated with an application executing on the WTRU 102-1 and started prior to handover, via the first network AP 640-2, and may send the received data packets via the established tunnel 2220 to the second network entity 620-1.

[0322] In certain representative embodiments, the first and second network entities 620-1 and 620-2 may buffer the data packets prior to handover, during the establishing of the tunnel 2220.

[0323] In certain representative embodiments, the first and second network entities 620-1 and 620-2 may send the buffered data packets responsive to completion of the tunnel 2220.

[0324] FIG. 39 is a flow diagram of another representative method 3900 for a handover of a WTRU 102-1 between a first network access point (AP) 640-2 and a second network AP 640-1 using the first network entity 620-2 and a second network entity 620-1.

[0325] Referring to FIG. 39, the representative method 3900 may include, at block 3910, the first network entity 620-2 performing network entity discovery of the second network entity 620-1 using pre-registration information. At block 3920, the first network entity 620-2 may establish a tunnel 2220 between the first network entity 620-2 and the second network entity 620-1 based on the pre- registration information. At block 3930, after the handover: the first network entity 620-2 may receive data packets associated with an application executing on the WTRU 102-1 and started prior to handover, via the established tunnel 2220 from the second network entity 620-1 , and may send the received data packets via the first network AP 640-2.

[0326] FIG. 40 is a flow diagram of a representative method 4000 for managing assignments of a gateway 620-2 to network Access Points (APs) 630-2.

[0327] Referring to FIG. 40, the representative method 4000 may include, at block 4010, the network entity 664 receiving a request including an identifier of a first network AP 630-2 for handover of a WTRU 102-1 to the first network AP 630-2 and a tracking area code that identifies a tracking area. At block 4020, the network entity 664 may map the identifier of the first network AP 630-2 and the tracking area code to the gateway 620-2.

[0328] FIG. 41 is a flow diagram of a representative method 4100 for controlling a handover of a WTRU 102-1 from a source network Access Point (AP) 630-1 to a target network AP 630-2:

[0329] Referring to FIG. 41 , the representative method 4100 may include, at block 41 10, the network entity 664 receiving from the source network AP 630-1 a handover request including an identifier of the target network AP 630-2. At block 4120, the network entity 664 may map the identifier of the target network AP 630-2 to a target gateway 620-2. At block 4130, the network entity 664 may send to the target gateway 620-2, a request to generate a tunnel 2220 between the target gateway 620-2 and a source gateway 620-1 serving the WTRU 102-1. The handover request may include an identifier of the WTRU 102-1. At block 4140, the network entity 664 may send to the target network AP 630-2, a request including a tunnel endpoint of the tunnel 2220 at the target gateway 620-2.

[0330] In certain representative embodiments, the network entity 664 may control tearing down of the generated tunnel 2220 responsive to each application executing on the WTRU 102-1 prior to the handover terminating.

[0331] In certain representative embodiments, the network entity 664 (or a Serving GPRS Support Node (SGSN) as the network entity) may send a handover command to the source network AP 630-1.

[0332] In certain representative embodiments, the network entity 664 may control communications over a first data path traversing via the source gateway 620-1 , the target gateway 620-2 and the target AP 630-2 for one or more applications which are executing on the WTRU 102-1 after the handover and that had been started prior to the handover.

[0333] In certain representative embodiments, the first data path may be based on a first IP address.

[0334] In certain representative embodiments, the network entity 664 may control tearing down of the generated tunnel 2220 responsive to all applications executing on the WTRU 102-1 using a second IP address, different from the first IP address.

[0335] In certain representative embodiments, the network entity 664 may control communications over the second data path, different from the first data path, which may traverse via the target gateway 620-2 and the target AP 630-2, exclusive of the source gateway 620-1 , for one or more applications which started executing after the handover.

[0336] In certain representative embodiments, the second data path may be based on a second IP address.

[0337] FIG. 42 is a flow diagram of a representative method 4200 for a handover of a WTRU 102-1 from a WiFi AP 640-1 associated with a second network entity 620-1 to a WiFi AP 640-2 associated with the first network entity 620-2. The WTRU 102-1 may communicate via the WiFi AP 640-1 of the second network entity 620-1 prior to the handover.

[0338] Referring to FIG. 42, the representative method 4200 may include, at block 4210, a first network entity 620-2 establishing a tunnel 2220 between the first and second network entities 620- 1 and 620-2. At block 4220, a first network entity 620-2 may send a message to handover the WTRU 102-1 from the second network entity 620-1 to the first network entity 620-2 such that: (1 ) for one or more applications executing prior to the handover, a data path after the handover is via the WiFi AP 640-2 associated with the first network entity 620-2 and the tunnel 2220 between the first and second network entities 620-1 and 620-2, and (2) for an application not executing prior to the handover, a data path after the handover is via the WiFi AP 640-2 associated with the first network entity 620-2 and not via the tunnel 2220 between the first and second network entities 620-1 and 620-2. [0339] In certain representative embodiments, the first network entity 620-2 may buffer uplink data while the WTRU 102-1 is being handed over.

[0340] In certain representative embodiments, the first network entity 620-2 may send the uplink data after the WTRU 102-1 is handed over.

[0341] In certain representative embodiments, the first network entity 620-2 may discover the second network entity 620-1 ; may communicate with the discovered second network entity 620-1 or a further network entity 910 to receive tunnel configuration information and may modify one or more binding table entries to establish the tunnel 2220 based on the received tunnel configuration information.

[0342] In certain representative embodiments, the first network entity 620-2 may: (1 ) broadcast one or more messages to enable discovery of the second network entity 620-1 ; and/or (2) send one or more messages to a further network entity 910 which pre-registers the first and second network entities 620-1 and 620-2.

[0343] In certain representative embodiments, the first network entity 620-2 may send control information to setup the tunnel 2220 via an interface 629 between the first and second network entities 620-1 and 620-2.

[0344] FIG. 43 is a flow diagram of a representative method 4300 for communication between or among a plurality of WTRUs 102-1 and 102-2 using at least first and second network entities 620-1 and 620-2 of a plurality of network entities 620 that control flow and/or session routing between or among one or more communication networks 610-1 and 610-2 and one or more network access points 640-1 and 640-2. A second WTRU 102-2 of the plurality of WTRUs 102-1 and 102-2 may be registered with the second network entity 620-2 and a tunnel 2220 between the first and second network entities 620-1 and 620-2 may be established using pre-registration information.

[0345] Referring to FIG. 43, the representative method 4300 may include, at block 4310, the first WTRU 102-1 registering with the first network entity 620-1. At block 4320, the first WTRU 102-1 may send information to establish a data path via the established tunnel 2220 to the registered, second WTRU 102-2. At block 4330, the first WTRU 102-1 may communicate with the registered, second WTRU 102-2 via the established data path that includes the established tunnel 2220.

[0346] FIG. 44 is a flow diagram of a representative method 4400 for communication between or among at least first and second WTRUs 102-1 and 102-2 of a plurality of WTRUs using at least the first network entity 620-1 and a second network entity 620-2 of a plurality of network entities that control flow and/or session routing between or among one or more communication networks 610-1 and 610-2 and one or more network access points 640-1 and 640-2. The second WTRU 1-2-2 may be registered with the second network entity 620-2.

[0347] Referring to FIG. 44, the representative method 4400 may include, at block 4410, the first network entity 620-1 receiving registration information from the first WTRU 102-1. At block 4420, the first network entity 620-1 may discover the second network entity 620-2. [0348] At block 4430, the first network entity 620-1 may establish a tunnel 2220 to the second network entity 620-2. At block 4440, the first network entity 620-1 may send a communication from the first WTRU 102-1 towards the second WTRU 102-2 via the established tunnel 2220. In certain representative embodiments, the first network entity 620-2 may send a communication from the second WTRU 102-2 towards the first WTRU 102-1.

Certain Representative Embodiments

[0349] In a first representative embodiment, a method, implemented by a first network entity (NE), for registration of the first NE with other NEs may comprise: performing NE discovery by: sending pre-registration information, by the first NE, to register the first NE with a registration entity; and/or receiving, by the first NE from the registration entity, pre-registration information of other NEs, wherein the first NE may control flow and/or session routing between or among a communication network and one or more network APs.

[0350] In a second representative embodiment, a method, implemented by a first NE, for registration of the first NE with other NEs may comprise performing NE discovery by: sending pre- registration information, by the first NE, to register the first NE with one or more of the other NEs that control flow or session routing; and/or receiving, by the first NE from a respective one or respective ones of the one or more other NEs, pre-registration information of the respective one or respective ones of the NEs, wherein the first NE may control flow and/or session routing between or among a communication network and one or more network APs.

[0351] In a third representative embodiment, a method, implemented by a first NE, for a handover of a WTRU to a network AP using the first NE and a second NE may comprise performing, by the first NE, NE discovery of the second NE using pre-registration information; establishing, by the first NE, a tunnel between the first NE and the second NE based on the pre- registration information; and/or sending or receiving, by the first NE, data packets associated with an application executing on the WTRU and started prior to handover, via the second NE and via the established tunnel.

[0352] In a fourth representative embodiment, a method, implemented by a first NE, for a handover of a WTRU between a first network AP and a second network AP using the first NE and a second NE may comprise: performing, by the first NE, NE discovery of the second NE using pre- registration information; establishing, by the first NE, a tunnel between the first NE and the second NE based on the pre-registration information; and/or after the handover, receiving, by the first NE, data packets associated with an application executing on the WTRU and started prior to handover, via the first network AP, and sending, by the first NE, the received data packets via the established tunnel to the second NE.

[0353] In a fifth representative embodiment, a method implemented by a first NE for handover of a WTRU between a first network AP and a second network AP using the first NE and a second NE, may comprise: performing, by the first NE, NE discovery of the second NE using pre- registration information; establishing, by the first NE, a tunnel between the first NE and the second NE based on the pre-registration information; and/or after the handover: receiving, by the first NE, data packets associated with an application executing on the WTRU and started prior to handover via the established tunnel from the second NE, and sending, by the first NE, the received data packets via the first network AP.

[0354] In a sixth representative embodiment, a method implemented by a NE for managing assignments of a gateway to network APs may comprise: receiving, by the NE, a request including an identifier of a first network AP for handover of a WTRU to the first network AP and a tracking area code that identifies a tracking area; and/or mapping, by the NE, the identifier of the first network AP and the tracking area code to the gateway.

[0355] In a seventh representative embodiment, a method, implemented by a NE, for controlling a handover of a WTRU from a source network AP to a target network AP may comprise: receiving, by the NE, from the source network AP, a handover request including an identifier of the target network AP; mapping, by the NE, the identifier of the target network AP to a target gateway; sending, by the NE to the target gateway, a request to generate a tunnel between the target gateway and a source gateway serving the WTRU, the request including an identifier of the WTRU; and/or sending, by the NE to the target network AP, a request including a tunnel endpoint of the tunnel at the target gateway.

[0356] In an eighth representative embodiment, a method implemented by a first NE for a handover of a WTRU from a WiFi AP associated with a second NE to a WiFi AP associated with the first NE, may comprise: establishing, by the first NE, a tunnel between the first and second NEs; and/or sending a message to handover the WTRU from the second NE to the first NE such that: (1 ) for one or more applications executing prior to the handover, a data path after the handover is via the WiFi AP associated with the first NE and the tunnel between the first and second NEs, and (2) for an application not executing prior to the handover, a data path after the handover is via the WiFi AP associated with the first NE and not via the tunnel between the first and second NEs, wherein the WTRU may communicate via the WiFi AP of the second NE prior to the handover.

[0357] In a ninth representative embodiment, a method, implemented by a first WTRU, for communication between or among a plurality of WTRUs using at least first and second NEs of a plurality of NEs that control flow and/or session routing between or among one or more communication networks and one or more network APs may comprise: registering, by the first WTRU, the first WTRU with the first NE; sending information to establish a data path via the established tunnel to the registered, second WTRU; and/or communicating, by the first WTRU, with the registered, second WTRU via the established data path that includes the established tunnel, wherein the second WTRU of the plurality of WTRUs may have been registered with the second NE and a tunnel between the first and second NEs may have been established using pre- registration information. [0358] In a tenth representative embodiment, a method implemented by a first NE for communication between or among at least first and second WTRUs of a plurality of WTRUs using at least the first NE and a second NE of a plurality of NEs that control flow and/or session routing between or among one or more communication networks and one or more network APs may comprise: receiving, by the first NE, registration information from the first WTRU; discovering, by the first NE, the second NE; establishing, by the first NE, a tunnel to the second NE; and/or sending, by the first NE, a communication from the first WTRU towards the second WTRU via the established tunnel, wherein the second WTRU may have been registered with the second NE.

[0359] The method of any of the first through tenth embodiments, wherein the pre-registration information may include a list of neighboring NEs.

[0360] The method of any of the first through tenth embodiments, wherein the pre-registration information may include a unique terminal device identifier.

[0361] The method of any of the first through tenth embodiments, wherein the pre-registration information may include information indicating a unique identifier of a terminal device and that the NE is managing the IP address of the terminal device.

[0362] The method of any of the first through tenth embodiments, which may further comprise tearing down the established tunnel, responsive to each application executing on the WTRU prior to the handover terminating.

[0363] The method of any of the first through tenth embodiments, wherein the tunnel may be based on GPRS Tunneling Protocol (GTP) or Proxy Mobile IP (PMIP).

[0364] The method of any of the first through tenth embodiments, which may further comprise buffering, by the first NE, the data packets prior to handover, during the establishing of the tunnel, wherein the sending of the buffered data packets may be responsive to completion of the tunnel.

[0365] The method of any of the first through tenth embodiments, which may further comprise sending, by a Mobility Management Entity (MME) or a Serving GPRS Support Node (SGSN), as the NE, a handover command to the source network AP.

[0366] The method of any of the first through tenth embodiments, which may further comprise controlling communications over a first data path traversing via the source gateway, the target gateway and the target AP for one or more applications which are executing on the WTRU after the handover and that had been started prior to the handover.

[0367] The method of any of the first through tenth embodiments, wherein the first data path may be based on a first IP address.

[0368] The method of any of the first through tenth embodiments, which may further comprise tearing down the established tunnel, responsive to all applications executing on the WTRU using a second IP address, different from the first IP address.

[0369] The method of any of the first through tenth embodiments, which may further comprise controlling communications over a second data path, different from the first data path, traversing via the target gateway and the target AP, exclusive of the source gateway, for one or more applications which started executing after the handover.

[0370] The method of any of the first through tenth embodiments, wherein the second data path may be based on a second IP address.

[0371] The method of any of the first through tenth embodiments, which may further comprise buffering uplink data, by the first NE while the WTRU is being handed over; and sending the uplink data after the WTRU is handed over.

[0372] The method of any of the first through tenth embodiments, wherein the establishing of the tunnel between the first NE and the second NE may include: discovering, by the first NE, the second NE; communicating, by the first NE, with the discovered second NE or a further NE to receive tunnel configuration information, and/or modifying, by the first NE, one or more binding table entries to establish the tunnel based on the received tunnel configuration information.

[0373] The method of any of the first through tenth embodiments, wherein the discovering of the second NE may include any of: (1 ) broadcasting one or more messages to enable discovery of the second NE; or (2) sending one or more messages to the further NE which pre-registers the first and second NEs.

[0374] The method of any of the first through tenth embodiments, wherein the establishing of the tunnel between the first NE and a second NE may include sending control information to setup the tunnel via an interface between the first and second NEs.

[0375] The method of any of the first through tenth embodiments, which may further comprise sending a communication from the second WTRU towards the first WTRU.

[0376] In an eleventh embodiment, a NE configured to register with other NEs, may comprise a transmit/receive unit configured to perform NE discovery, wherein: the transmit/receive unit may send pre-registration information to register the NE with a registration entity and may receive from the registration entity pre-registration information of other NEs, and the NE may control flow and/or session routing between or among a communication network and one or more network AP.

[0377] In a twelfth embodiment, a NE configured to register with other NEs, may comprise: a transmit/receive unit configured to perform NE discovery, wherein the transmit/receive unit may send pre-registration information to register the NE with one or more of other NEs that control flow or session routing; and may receive from a respective one or respective ones of the one or more other NEs, pre-registration information of the respective one or respective ones of the NEs; and the NE may control flow and/or session routing between or among a communication network and one or more network APs.

[0378] In a thirteenth embodiment, a NE configured to facilitate a handover of a WTRU to a network AP using a further NE may comprise: a processor configured to: perform NE discovery of the further NE using pre-registration information, and establish a tunnel between the NE and the further NE based on the pre-registration information; and/or a transmit/receive unit configured to send or receive data packets associated with an application executing on the WTRU and started prior to handover, via the further NE and via the established tunnel therebetween.

[0379] In a fourteenth embodiment, a NE configured to facilitate a handover of a WTRU between a first network AP and a second network AP using the NE and a further NE, may comprise: a processor configured to: perform NE discovery of the further NE using pre-registration information, and establish a tunnel between the NE and the further NE based on the pre-registration information; and/or a transmit/receive unit configured to, after the handover: receive data packets associated with an application executing on the WTRU and that had been started prior to the handover, via the first network AP, and send the received data packets via the established tunnel to the further NE.

[0380] In a fifteenth embodiment, a NE configured to facilitate a handover of a WTRU between a first network AP and a second network AP using a further NE may comprise: a processor is configured to: perform NE discovery of the further NE using pre-registration information, and establish a tunnel between the NE and the further NE based on the pre-registration information; and/or a transmit/receive unit configured to, after the handover: receive data packets associated with an application executing on the WTRU and started prior to handover via the established tunnel from the further NE, and send the data packets via the first network AP.

[0381] In a sixteenth embodiment, a NE configured to manage assignments of a gateway to network APs may comprise: a transmit/receive unit configured to receive a request including an identifier of a first network AP for handover of a WTRU to the first network AP and a tracking area code that identifies a tracking area; and/or a processor configured to map the identifier of the first network AP and the tracking area code to the gateway.

[0382] In a seventeenth embodiment, a NE configured to control a handover of a WTRU from a source network AP to a target network AP may comprise: a transmit/receive unit configured to receive from the source network AP, a handover request including an identifier of the target network AP; and/or a processor configured to map the identifier of the target network AP to a target gateway, wherein the transmit/receive unit may be configured to: send to the target gateway a request to generate a tunnel between the target gateway and a source gateway serving the WTRU, the request including an identifier of the WTRU, and send to the target network AP a request including a tunnel endpoint of the tunnel at the target gateway.

[0383] In an eighteenth embodiment, a NE configured to facilitate a handover of a WTRU from a WiFi AP associated with a further NE to a WiFi AP associated with the NE, may comprise a processor and a transmit/receive unit configured to: establish a tunnel between the NE and the second NE; and/or send a message to handover the WTRU from the further NE to the NE such that: (1 ) for one or more applications executing prior to the handover, a data path after the handover is via the WiFi AP of the NE and the tunnel between the further NE and the NE, and (2) for an application not executing prior to the handover, a data path after the handover is via the WiFi AP of the NE and not via the tunnel between the further NE and the NE, wherein the WTRU may communicate via the WiFi AP of the further NE prior to the handover.

[0384] In a nineteenth embodiment, a WTRU configured to communicate between or among a plurality of WTRUs using at least a NE (NE) and a further NE of a plurality of NEs that control flow and/or session routing between or among one or more communication networks and one or more network APs, may comprise: a processor configured to register the WTRU with the NE; and/or a transmit/receive unit configured to: send information to establish a data path to the registered, further WTRU, and communicate with the registered, further WTRU via the established data path that includes the established tunnel, wherein the further WTRU of the plurality of WTRUs may have been registered with the further NE, and a tunnel between the NE and the further NE may have been established using pre-registration information.

[0385] In a twentieth embodiment, a NE configured to facilitate communications between or among at least first and second WTRUs of a plurality of WTRUs using at least the NE and a further NE of a plurality of NEs that control flow and/or session routing between or among one or more communication networks and one or more network APs may comprise a transmit/receive unit configured to receive registration information from the first WTRU; and/or a processor configured to: discover the further NE, and establish a tunnel to the further NE, wherein the second WTRU may have been registered with the further NE, and the transmit/receive unit may be configured to send a communication from the first WTRU towards the second WTRU.

[0386] The NE of any of the eleventh through eighteenth and twentieth embodiments, wherein the NE may include any of: (1 ) an enhanced Converged Gateway (eCGW), (2) a Converged Gateway (CGW), (3) a Local Gateway (LGW) and/or (4) a Small Cell Network (SCN) Controller.

[0387] The NE of any of the eleventh through eighteenth and twentieth embodiments, wherein the transmit/receive unit may be configured to send the pre-registration information that includes any of: (1 ) a list of neighboring NEs; (2) a unique identifier of a terminal device; or (3) information indicating the unique identifier of the terminal device and that the NE is managing an IP address of the terminal device.

[0388] The NE of any of the eleventh through eighteenth and twentieth embodiments, wherein the processor may be configured to tear down the established tunnel, responsive to each application executing on the WTRU prior to the handover terminating.

[0389] The NE of any of the eleventh through eighteenth and twentieth embodiments, wherein the processor may be configure to establish the tunnel based on GPRS Tunneling Protocol (GTP) or Proxy Mobile IP (PMIP).

[0390] The NE of any of the eleventh through eighteenth and twentieth embodiments, wherein: the processor may be configured to buffer the data packets prior to handover, during the establishing of the tunnel; and/or the transmit/receive unit may be configured to send the buffered data packets responsive to completion of the tunnel. [0391] The NE of any of the eleventh through eighteenth and twentieth embodiments, wherein the NE may include a Mobility Management Entity (MME) or Serving GPRS Support Node (SGSN) and the gateway may include an enhanced Converged Gateway (eCGW), a Converged Gateway (CGW), a Local Gateway (LGW) or a Small Cell Network (SCN) Controller.

[0392] The NE of any of the eleventh through eighteenth and twentieth embodiments, wherein the processor may be configured to control communications over a first data path traversing via the source gateway, the target gateway and the target AP for one or more applications which are executing on the WTRU after the handover and that had been started prior to the handover.

[0393] The NE of any of the eleventh through eighteenth and twentieth embodiments, wherein: the first data path may be based on a first IP address; and the processor may be configured to tearing down the established tunnel, responsive to all applications executing on the WTRU using a second IP address, different from the first IP address.

[0394] The NE of any of the eleventh through eighteenth and twentieth embodiments, wherein the processor may be configured to buffer data while the WTRU is being handed over from the further NE to the NE, wherein the NE may further comprise a transmit/receive unit configured to send the data after the WTRU is handed over from the further NE to the NE.

[0395] The NE of any of the eleventh through eighteenth and twentieth embodiments, which may further comprise a transmit/receive unit, wherein: the processor may be configured to discover the further NE, the transmit/receive unit may be configured to: communicate with the discovered further NE and receive tunnel configuration information, and/or the processor may be configured to modify one or more binding table entries to establish the tunnel based on the tunnel configuration information.

[0396] The NE of any of the eleventh through eighteenth and twentieth embodiments, wherein the transmit/receive unit may be configured to any of: (1 ) broadcast one or more messages to enable discovery of the further NE; or (2) send one or more messages to a registration NE which pre-registers the NE and the further NE.

[0397] The NE of any of the eleventh through eighteenth and twentieth embodiments, wherein the transmit/receive unit may be configured to send control information to setup the tunnel via an interface between the NE and the further NE.

[0398] The NE of any of the eleventh through eighteenth and twentieth embodiments, wherein the transmit/receive unit may be configured to send a communication from the second WTRU towards the first WTRU.

[0399] 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 non-transitory computer-readable storage media include, but are not limited to, a read only memory (ROM), 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 102, UE, terminal, base station, RNC, or any host computer.

[0400] Moreover, in the embodiments described above, processing platforms, computing systems, controllers, and other devices containing processors are noted. These devices may contain at least one Central Processing Unit ("CPU") and memory. In accordance with the practices of persons skilled in the art of computer programming, reference to acts and symbolic representations of operations or instructions may be performed by the various CPUs and memories. Such acts and instructions may be referred to as being "executed," "computer executed" or "CPU executed."

[0401] One of ordinary skill in the art will appreciate that the acts and symbolically represented operations or instructions include the manipulation of electrical signals by the CPU. An electrical system represents data bits that can cause a resulting transformation or reduction of the electrical signals and the maintenance of data bits at memory locations in a memory system to thereby reconfigure or otherwise alter the CPU's operation, as well as other processing of signals. The memory locations where data bits are maintained are physical locations that have particular electrical, magnetic, optical, or organic properties corresponding to or representative of the data bits.

[0402] The data bits may also be maintained on a computer readable medium including magnetic disks, optical disks, and any other volatile (e.g., Random Access Memory ("RAM")) or non-volatile ("e.g., Read-Only Memory ("ROM")) mass storage system readable by the CPU. The computer readable medium may include cooperating or interconnected computer readable medium, which exist exclusively on the processing system or are distributed among multiple interconnected processing systems that may be local or remote to the processing system. It is understood that the representative embodiments are not limited to the above-mentioned memories and that other platforms and memories may support the described methods.

[0403] Moreover, the claims should not be read as limited to the described order or elements unless stated to that effect. In addition, use of the term "means" in any claim is intended to invoke 35 U.S.C. §1 12, If 6, and any claim without the word "means" is not so intended.

[0404] Suitable processors include, by way of example, 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), Application Specific Standard Products (ASSPs); Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (IC), and/or a state machine. [0405] A processor in association with software may be used to implement a radio frequency transceiver for use in a wireless transmit receive unit (WTRU), user equipment (UE), terminal, base station, MME or EPC, or any host computer. The WTRU may be used m conjunction with modules, implemented in hardware and/or software including a Software Defined Radio (SDR), and other components such as a camera, a video camera module, a videophone, a speakerphone, a vibration device, a speaker, a microphone, a television transceiver, a hands free headset, a keyboard, a Bluetooth® module, a frequency modulated (FM) radio unit, a Near Field Communication (NFC) Module, a liquid crystal display (LCD) display unit, an organic light-emitting diode (OLED) display unit, a digital music player, a media player, a video game player module, an Internet browser, and/or any Wireless Local Area Network (WLAN) or Ultra Wide Band (UWB) module.

[0406] Although the invention has been described in terms of communication systems, it is contemplated that the systems may be implemented in software on microprocessors/general purpose computers (not shown). In certain embodiments, one or more of the functions of the various components may be implemented in software that controls a general-purpose computer.

[0407] In addition, although the invention is illustrated and described herein with reference to specific embodiments, the invention is not intended to be limited to the details shown. Rather, various modifications may be made in the details within the scope and range of equivalents of the claims and without departing from the invention.

Claims

What is claimed is:

1. A method, implemented by a first network entity, for registration of the first network entity with other network entities, the first network entity controlling flow and/or session routing between or among a communication network and one or more network access points, the method comprising:

performing network entity discovery by:

sending pre-registration information, by the first network entity, to register the first network entity with a registration entity; and

receiving, by the first network entity from the registration entity, pre-registration information of other network entities.

2. The method of claim 1 , wherein the pre-registration information includes a list of neighboring network entities.

3. The method of claim 1 , wherein the pre-registration information includes a unique terminal device identifier.

4. The method of claim 1 , wherein the pre-registration information includes information indicating a unique identifier of a terminal device and that the network entity is managing the IP address of the terminal device.

5. A method, implemented by a first network entity, for registration of the first network entity with other network entities, the first network entity controlling flow and/or session routing between or among a communication network and one or more network access points, the method comprising:

performing network entity discovery by:

sending pre-registration information, by the first network entity, to register the first network entity with one or more of the other network entities that control flow or session routing; and

receiving, by the first network entity from a respective one or respective ones of the one or more other network entities, pre-registration information of the respective one or respective ones of the network entities.

6. The method of claim 5, wherein the pre-registration information includes a list of neighboring network entities.

7. The method of claim 5, wherein the pre-registration information includes a unique terminal device identifier.

8. The method of claim 5, wherein the pre-registration information includes information indicating a unique identifier of a terminal device and that the network entity is managing the IP address of the terminal device.

9. A method, implemented by a first network entity, for a handover of a Wireless Transmit/Receive Unit (WTRU) to a network access point (AP) using the first network entity and a second network entity, the method comprising:

performing, by the first network entity, network entity discovery of the second network entity using pre-registration information;

establishing, by the first network entity, a tunnel between the first network entity and the second network entity based on the pre-registration information; and

sending or receiving, by the first network entity, data packets associated with an application executing on the WTRU and started prior to handover, via the second network entity and via the established tunnel.

10. The method of claim 9, further comprising:

tearing down the established tunnel, responsive to each application executing on the WTRU prior to the handover terminating.

1 1 . The method of claim 9, wherein the tunnel is based on GPRS Tunneling Protocol (GTP) or Proxy Mobile IP (PMIP).

12. A method, implemented by a first network entity, for a handover of a Wireless Transmit/Receive Unit (WTRU) between a first network access point (AP) and a second network AP using the first network entity and a second network entity, the method comprising:

after the handover,

receiving, by the first network entity, data packets associated with an application executing on the WTRU and started prior to handover, via the first network AP, and

sending, by the first network entity, the received data packets via the established tunnel to the second network entity.

13. The method of claim 12, further comprising:

buffering, by the first network entity, the data packets prior to handover, during the establishing of the tunnel,

wherein the sending of the buffered data packets is responsive to completion of the tunnel.

14. The method of claim 12, further comprising:

15. The method of claim 14, wherein the tunnel is based on GPRS Tunneling Protocol (GTP) or Proxy Mobile IP (PMIP).

16. A method implemented by a first network entity for handover of a Wireless Transmit/Receive Unit (WTRU) between a first network access point (AP) and a second network AP using the first network entity and a second network entity, the method comprising:

after the handover,

receiving, by the first network entity, data packets associated with an application executing on the WTRU and started prior to handover via the established tunnel from the second network entity, and

sending, by the first network entity, the received data packets via the first network

AP.

17. The method of claim 16, further comprising:

18. A method implemented by a network entity for managing assignments of a gateway to network Access Points (APs), the method comprising:

receiving, by the network entity, a request including an identifier of a first network AP for handover of a Wireless Transmit/Receive Unit (WTRU) to the first network AP and a tracking area code that identifies a tracking area; and

mapping, by the network entity, the identifier of the first network AP and the tracking area code to the gateway.

19. A method, implemented by a network entity, for controlling a handover of a Wireless Transmit/Receive Unit (WTRU) from a source network Access Point (AP) to a target network AP; the method comprising:

receiving, by the network entity, from the source network AP, a handover request including an identifier of the target network AP;

mapping, by the network entity, the identifier of the target network AP to a target gateway; sending, by the network entity to the target gateway, a request to generate a tunnel between the target gateway and a source gateway serving the WTRU, the request including an identifier of the WTRU; and

sending, by the network entity to the target network AP, a request including a tunnel endpoint of the tunnel at the target gateway.

20. The method of claim 19, further comprising:

tearing down the generated tunnel, responsive to each application executing on the WTRU prior to the handover terminating.

21. The method of claim 19, further comprising sending, by a Mobility Management Entity (MME) or a Serving GPRS Support Node (SGSN), as the network entity, a handover command to the source network AP.

22. The method of claim 19, further comprising controlling communications over a first data path traversing via the source gateway, the target gateway and the target AP for one or more applications which are executing on the WTRU after the handover and that had been started prior to the handover.

23. The method of claim 22, wherein the first data path is based on a first IP address.

24. The method of claim 23, further comprising:

tearing down the established tunnel, responsive to all applications executing on the WTRU using a second IP address, different from the first IP address.

25. The method of claim 22, further comprising controlling communications over a second data path, different from the first data path, traversing via the target gateway and the target AP, exclusive of the source gateway, for one or more applications which started executing after the handover.

26. The method of claim 25, wherein the second data path is based on a second IP address.

27. The method of claim 19, wherein the tunnel is based on GPRS Tunneling Protocol (GTP) or Proxy Mobile IP (PMIP).

28. A method implemented by a first network entity for a handover of a wireless transmit/receive unit (WTRU) from a WiFi AP associated with a second network entity to a WiFi AP associated with the first network entity, the WTRU communicating via the WiFi AP of the second network entity prior to the handover, the method comprising:

establishing, by the first network entity, a tunnel between the first and second network entities; and

sending a message to handover the WTRU from the second network entity to the first network entity such that: (1 ) for one or more applications executing prior to the handover, a data path after the handover is via the WiFi AP associated with the first network entity and the tunnel between the first and second network entities, and (2) for an application not executing prior to the handover, a data path after the handover is via the WiFi AP associated with the first network entity and not via the tunnel between the first and second network entities.

29. The method of claim 28, further comprising:

buffering uplink data, by the first network entity while the WTRU is being handed over; and sending the uplink data after the WTRU is handed over.

30. The method of claim 28, wherein the establishing of the tunnel between the first network entity and the second network entity includes:

discovering, by the first network entity, the second network entity; communicating, by the first network entity, with the discovered second network entity or a further network entity to receive tunnel configuration information, and

modifying, by the first network entity, one or more binding table entries to establish the tunnel based on the received tunnel configuration information.

31. The method of claim 30, wherein the discovering of the second network entity includes any of: (1 ) broadcasting one or more messages to enable discovery of the second network entity; or (2) sending one or more messages to the further network entity which pre-registers the first and second network entities.

32. The method of claim 28, wherein the establishing of tunnel between the first network entity and a second network entity includes sending control information to setup the tunnel via an interface between the first and second network entities.

33. A method, implemented by a first wireless transmit/receive units (WTRU), for communication between or among a plurality of WTRUs using at least first and second network entities of a plurality of network entities that control flow and/or session routing between or among one or more communication networks and one or more network access points, a second WTRU of the plurality of WTRUs having been registered with the second network entity and a tunnel between the first and second network entities having been established using pre-registration information, the method comprising:

registering, by the first WTRU, the first WTRU with the first network entity; and

sending information to establish a data path via the established tunnel to the registered, second WTRU; and

communicating, by the first WTRU, with the registered, second WTRU via the established data path that includes the established tunnel.

34. A method implemented by a first network entity for communication between or among at least first and second wireless transmit/receive units (WTRUs) of a plurality of WTRUs using at least the first network entity and a second network entity of a plurality of network entities that control flow and/or session routing between or among one or more communication networks and one or more network access points, the second WTRU having been registered with the second network entity, the method comprising:

receiving, by the first network entity, registration information from the first WTRU;

discovering, by the first network entity, the second network entity;

establishing, by the first network entity, a tunnel to the second network entity; and sending, by the first network entity, a communication from the first WTRU towards the second WTRU via the established tunnel.

35. The method of claim 34, further comprising sending a communication from the second WTRU towards the first WTRU.

36. A network entity (NE) configured to register with other NEs, the NE controlling flow and/or session routing between or among a communication network and one or more network access points, comprising:

a transmit/receive unit configured to perform network entity discovery, wherein the transmit/receive unit sends pre-registration information to register the NE with a registration entity and receives from the registration entity pre-registration information of other NEs.

37. The NE of claim 36, wherein the NE includes any of: (1 ) an enhanced Converged Gateway (eCGW), (2) a Converged Gateway (CGW), (3) a Local Gateway (LGW) and/or (4) a Small Cell Network (SCN) Controller.

38. The NE of claim 36, wherein the transmit/receive unit is configured to send the pre- registration information that includes any of: (1 ) a list of neighboring NEs; (2) a unique identifier of a terminal device; or (3) information indicating the unique identifier of the terminal device and that the NE is managing an IP address of the terminal device.

39. A network entity (NE) configured to register with other NEs, the NE controlling flow and/or session routing between or among a communication network and one or more network access points, comprising:

a transmit/receive unit configured to perform network entity discovery, wherein the transmit/receive unit sends pre-registration information to register the NE with one or more of other NEs that control flow or session routing; and receives from a respective one or respective ones of the one or more other NEs, pre-registration information of the respective one or respective ones of the NEs.

40. The NE of claim 39, wherein the NE includes any of: (1 ) an enhanced Converged Gateway (eCGW), (2) a Converged Gateway (CGW), (3) a Local Gateway (LGW) and/or (4) a Small Cell Network (SCN) Controller.

41. The NE of claim 39, wherein the transmit/receive unit is configured to send and/or receive the pre-registration information including any of: (1 ) a list of neighboring NEs; (2) a unique identifier of a terminal device; or (3) information indicating the unique identifier of the terminal device and that the NE is managing the IP address of the terminal device.

42. A network entity (NE) configured to facilitate a handover of a Wireless Transmit/Receive Unit (WTRU) to a network access point (AP) using a further NE, comprising: a processor configured to:

perform network entity discovery of the further NE using pre-registration information, and

establish a tunnel between the NE and the further NE based on the pre-registration information; and

a transmit/receive unit configured to send or receive data packets associated with an application executing on the WTRU and started prior to handover, via the further NE and via the established tunnel therebetween.

43. The NE of claim 42, wherein the processor is configured to tear down the established tunnel, responsive to each application executing on the WTRU prior to the handover terminating.

44. The NE of claim 42, wherein the processor is configure to establish the tunnel based on GPRS Tunneling Protocol (GTP) or Proxy Mobile IP (PMIP).

45. A network entity (NE) configured to facilitate a handover of a Wireless Transmit/Receive Unit (WTRU) between a first network access point (AP) and a second network AP using the NE and a further NE, comprising:

a processor configured to:

a transmit/receive unit configured to, after the handover:

receive data packets associated with an application executing on the WTRU and that had been started prior to the handover, via the first network AP, and

send the received data packets via the established tunnel to the further NE.

46. The NE of claim 45, wherein:

the processor is configured to buffer the data packets prior to handover, during the establishing of the tunnel; and

the transmit/receive unit is configured to send the buffered data packets responsive to completion of the tunnel.

47. The NE of claim 45, wherein the processor is configured to tear down the established tunnel, responsive to each application executing on the WTRU prior to the handover terminating.

48. The NE of claim 45, wherein the processor is configured to establish the tunnel using GPRS Tunneling Protocol (GTP) or Proxy Mobile IP (PMIP).

49. A network entity (NE) configured to facilitate a handover of a Wireless Transmit/Receive Unit (WTRU) between a first network access point (AP) and a second network AP using a further NE, comprising:

a processor is configured to:

a transmit/receive unit configured to, after the handover:

receive data packets associated with an application executing on the WTRU and started prior to handover via the established tunnel from the further NE, and

send the data packets via the first network AP.

50. The NE of claim 49, wherein: the processor is configured to buffer the data packets prior to the handover, during the establishing of the tunnel; and

51. A network entity (NE) configured to manage assignments of a gateway to network Access Points (APs), comprising:

a transmit/receive unit configured to receive a request including an identifier of a first network AP for handover of a Wireless Transmit/Receive Unit (WTRU) to the first network AP and a tracking area code that identifies a tracking area; and

a processor is configured to map the identifier of the first network AP and the tracking area code to the gateway.

52. The NE of claim 51 , wherein the NE includes a Mobility Management Entity (MME) or Serving GPRS Support Node (SGSN) and the gateway includes an enhanced Converged Gateway (eCGW), a Converged Gateway (CGW), a Local Gateway (LGW) or a Small Cell Network (SCN) Controller.

53. A network entity (NE) configured to control a handover of a Wireless Transmit/Receive Unit (WTRU) from a source network Access Point (AP) to a target network AP; comprising:

a transmit/receive unit configured to receive from the source network AP, a handover request including an identifier of the target network AP; and

a processor configured to map the identifier of the target network AP to a target gateway, wherein the transmit/receive unit is configured to:

send to the target gateway a request to generate a tunnel between the target gateway and a source gateway serving the WTRU, the request including an identifier of the WTRU, and

send to the target network AP a request including a tunnel endpoint of the tunnel at the target gateway.

54. The NE of claim 53, wherein the processor is configured to tear down the generated tunnel responsive to each application executing on the WTRU prior to the handover terminating.

55. The NE of claim 54, wherein the NE includes a Mobility Management Entity (MME) or Serving GPRS Support Node (SGSN) and the gateway includes an enhanced Converged Gateway (eCGW), a Converged Gateway (CGW), a Local Gateway (LGW) or a Small Cell Network (SCN) Controller.

56. The NE of claim 53, wherein the processor is configured to control communications over a first data path traversing via the source gateway, the target gateway and the target AP for one or more applications which are executing on the WTRU after the handover and that had been started prior to the handover.

57. The NE of claim 56, wherein:

the first data path is based on a first IP address; and the processor is configured to tearing down the established tunnel, responsive to all applications executing on the WTRU using a second IP address, different from the first IP address.

58. The NE of claim 53, wherein the processor is configured to control communications over a second data path, different from the first data path, that traverses via the target gateway and the target AP, exclusive of the source gateway, for one or more applications which started executing after the handover.

59. A network entity (NE) configured to facilitate a handover of a wireless transmit/receive unit (WTRU) from a WiFi AP associated with a further NE to a WiFi AP associated with the NE, the WTRU communicating via the WiFi AP of the further NE prior to the handover, the NE comprising: a processor and a transmit/receive unit configured to:

establish a tunnel between the NE and the second NE; and

send a message to handover the WTRU from the further NE to the NE such that: (1 ) for one or more applications executing prior to the handover, a data path after the handover is via the WiFi AP of the NE and the tunnel between the further NE and the NE, and (2) for an application not executing prior to the handover, a data path after the handover is via the WiFi AP of the NE and not via the tunnel between the further NE and the NE.

60. The NE of claim 59, wherein the processor is configured to buffer data while the WTRU is being handed over from the further NE to the NE,

wherein the NE further comprises a transmit/receive unit configured to send the data after the WTRU is handed over from the further NE to the NE.

61. The NE of claim 59, further comprising a transmit/receive unit, wherein:

the processor is configured to discover the further NE,

the transmit/receive unit is configured to communicate with the discovered further NE and receive tunnel configuration information, and

the processor is configured to modify one or more binding table entries to establish the tunnel based on the tunnel configuration information.

62. The NE of claim 59, wherein the transmit/receive unit configured to any of: (1 ) broadcast one or more messages to enable discovery of the further NE; or (2) send one or more messages to a registration NE which pre-registers the NE and the further NE.

63. The NE of claim 59, wherein the transmit/receive unit is configured to send control information to setup the tunnel via an interface between the NE and further NE.

64. A wireless transmit/receive Unit (WTRU) configured to communicate between or among a plurality of WTRUs using at least a network entity (NE) and a further NE of a plurality of NEs that control flow and/or session routing between or among one or more communication networks and one or more network access points, a further WTRU of the plurality of WTRUs having been registered with the further NE, and a tunnel between the NE and the further NE having been established using pre-registration information, the WTRU comprising:

a processor configured to register the WTRU with the NE; and a transmit/receive unit configured to:

send information to establish a data path to the registered, further WTRU, and communicate with the registered, further WTRU via the established data path that includes the established tunnel.

65. A network entity (NE) configured to facilitate communications between or among at least first and second wireless transmit/receive units (WTRUs) of a plurality of WTRUs using at least the NE and a further NE of a plurality of NEs that control flow and/or session routing between or among one or more communication networks and one or more network access points, the second WTRU having been registered with the further NE, the NE comprising:

a transmit/receive unit configured to receive registration information from the first WTRU; and

a processor configured to discover the further NE, and establish a tunnel to the further NE, wherein the transmit/receive unit is configured to send a communication from the first WTRU towards the second WTRU.

66. The NE of claim 65, wherein the transmit/receive unit is configured to send a communication from the second WTRU towards the first WTRU.