TW201320698A - Methods, apparatus and systems for managing IP flow mobility - Google Patents

Abstract

Systems and methods are described for IP mobility based on feedback received fromeNodeBs and/or Home eNodeBs ((H)eNBs). The feedback may include, for example, levels of interference and load levels. In some embodiments a converged gateway may configure the (H)eNBs to measure a performance parameter. The (H)eNB may then provide the measurement to the converged gateway. Based on the measurement, the converged gateway may determine to offload one or more IP flows from a first radio access technology (cellular, for example) to a second radio access technology (non- cellular, for example).

Description

Management IP flow mobility method, device and system

A User Equipment (UE) may include a dual mode device that enables two different Radio Access Technologies (RATs) to connect to a wireless communication network. Recently, these RATs have been used for message separation, in which the message is divided into two packet streams, which for example can be assigned to the UE's increased throughput.

In one embodiment, a method includes configuring one of an eNodeB and a home eNodeB hosting an IP flow to measure performance parameters, receive feedback data, wherein the feedback data includes measurements of performance parameters, and The offloading of the IP flow is determined based on the feedback data.
In one embodiment, a method includes receiving feedback data from one of a home eNodeB and an eNodeB of a escrow IP flow via an X2 interface, wherein the feedback data includes measurements of performance parameters, and based on the feedback data To determine the uninstallation of the IP stream.
In one embodiment, a method includes receiving an interference measurement from an eNodeB via an interface, wherein an IP flow is traversing the eNodeB, and moving the IP flow from the eNodeB to the non-interference when the interference measurement exceeds an interference threshold The cellular radio access technology, and when the interference measurement does not exceed the interference threshold, determines that the load on the eNodeB exceeds the load threshold and moves the IP flow from the eNodeB to the non-homed radio access technology.
In one embodiment, a method includes receiving interference measurements from a home eNodeB via an interface, wherein an IP flow is traversing the home eNodeB, and when the interference measurement exceeds an interference threshold, the IP flow is from the home eNode B moves to non-homed radio access technology, determines that the load on the home eNodeB exceeds the load threshold when the interference measurement does not exceed the interference threshold, and moves the IP flow from the home eNodeB to the non-homed Radio access technology.
In one embodiment, a method includes requesting performance parameter measurements from a home eNodeB management system, receiving performance parameter measurements from the home eNodeB management system, and determining offloading of IP flows based on the performance parameter measurements.

While the detailed description is to be considered as illustrative and illustrative, the embodiments Instead, various modifications may be made in the details without departing from the scope of the invention.
A femto access point (eg, Home Node B or Evolved Home Node B) may be capable of using a cellular network wireless air interface (eg, UMTS Terrestrial Radio Access (UTRAN), Long Term Evolution (LTE), and code division A multiple access (CDMA) wireless transmit/receive unit (WTRU) is connected to a customer premises equipment (CPE) of a cellular operator network that uses broadband IP backhaul. Wired options for broadband IP backhaul for subscribers may include two-wire xDSL (eg ADSL, ADSL2, VDSL, VDSL2), coaxial cable (eg via DOCSIS 1.1, 2.0 and 3.0), fiber to home/home (FTTH/FTTP) and / or broadband (BPL) via wires.
Some of the basic aspects and features of the CGW concept, as well as various embodiments of the CGW, are disclosed in various publications, including US Patent Application Publication No. 2011/0228750 and 2012/0071168, which are hereby incorporated by reference in its entirety.
In certain example embodiments, a general architecture for a hybrid network based on "Converged Gateway" (CGW) for home, neighbor, and enterprise environments is disclosed. The hybrid network architecture can be based, for example, on an evolved 3GPP Home Node B platform to address wireless communications between local devices or devices via a CGW in conjunction with value added services provided by a wide area network operator.
The gateway system can provide various features such as access to femtocells to the local network, the public internet, and the private service provider network, ie via 3GPP Home Node B (HNB); including 3GPP UMTS and IEEE 802.11 Offloading, streaming and bandwidth or converged management (BWM or CGM) between multiple radio access technologies (RATs) (or wired technologies such as Ethernet); machine-to-machine (M2M) network connections, Includes assistance for 802.1S.4-based ad hoc networks (SON); and M2M gateway functionality for hierarchical network elements.
There are many ways to combine CGW devices in a network such as a cellular network. For example, the CGW can be placed between the Mobile Core Network (MCN) and the HNB, acting as an HNB for the MCN device and as an MCN device for the HNB.
The CGW can be used to determine how to separate the data for transmission (eg, determining which data packets are sent to the terminal device between each of the multiple RATs or other wired technologies). For example, the sequence number can be associated with a data packet sent via a particular RAT. The CGW device can track the sequence number of the separately transmitted data packets in order to maintain an appropriate sequence between the transmitting and receiving devices (e.g., between a Serving GPRS Support Node (SGSN) and the WTRU, etc.).
The methods and apparatus described herein can be used on all wired networks, wireless networks, and hybrid wired wireless networks, collectively referred to as communication systems. FIG. 1A is a diagram of an example communication system 100 in which one or more of the disclosed embodiments can be implemented. Communication system 100 may be a multiple access system that provides content to multiple wireless users, such as voice, data, video, messaging, and broadcast. Communication system 100 enables multiple wireless users to access such content via sharing system resources including wireless bandwidth. For example, communication system 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). And/or single carrier FDMA (SC-FDMA) and the like.
As shown in FIG. 1A, communication system 100 can include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, radio access network (RAN) 104, core network 106, public switched telephone network (PSTN). 108, the Internet 110 and other networks 112.
Although a particular number of WTRUs, base stations, and network elements are shown, any number of such WTRUs, base stations, and/or network elements are contemplated.
While the WTRU is shown as an exemplary terminal device, other devices are contemplated as possible. For example, a mixture of wired and wireless terminal devices connected via HNB, WIFI, and an Ethernet access point via the CGW.
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), mobile stations, fixed or mobile subscriber units, pagers, cellular phones, individuals Digital assistants (PDAs), smart phones, laptops, mini-notebooks, personal computers, wireless sensors, and/or consumer electronics.
The UE may be used herein for illustrative purposes, but any WTRU may be readily applied to the examples herein.
The communication system 100 can also include a base station 114a and a base station 114b. Each of the base stations 114a, 114b can be configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to, for example, the core network 106, the Internet 110, and/or other networks. 112 Any type of device of one or more communication networks. For example, the base stations 114a, 114b may be a base transceiver station (BTS), a node-B, an e-Node B, a home node B, a home e-Node B, a site controller, an access point (AP), and/or a wireless router, etc. .
While base stations 114a, 114b are each illustrated as a single component or device, it is contemplated that base stations 114a, 114b can include any number of interconnected base stations and/or network elements.
In some example embodiments, base station 114a may be part of RAN 104, and RAN 104 may also include other base stations and/or network elements (not shown), such as base station controller (BSC), radio network control (RNC) and/or relay nodes. Base station 114a and/or base station 114b may be configured to transmit and/or receive wireless signals within a particular geographic area (which may be referred to as a cell (not shown). The cell can be further divided into cell sectors. For example, a cell associated with base station 114a can be divided into three cell sectors.
In some example embodiments, base station 114a may include three transceivers, such as one for each cell sector. In other example embodiments, base station 114a may employ multiple input multiple output (MIMO) technology and may use multiple transceivers for each sector of a cell.
The base stations 114a, 114b can communicate with one or more of the WTRUs 102a, 102b, 102c, 102d via the air interface 116, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV) and/or visible light, etc.). The air interface 116 can be established using any suitable radio access technology (RAT).
Communication system 100 can be a multiple access system and can employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, and/or SC-FDMA. For example, base station 114a and WTRUs 102a, 102b, and 102c in RAN 104 may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wide Frequency CDMA (WCDMA) to establish an air interface 116. WCDMA may include communication protocols such as High Speed Packet Access (HSPA) and/or Evolution HSPA (HSPA+). HSPA may include High Speed Downlink Packet Access (HSDPA) and/or High Speed Uplink Packet Access (HSUPA).
In some example embodiments, base station 114a and WTRUs 102a, 102b, and 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may use Long Term Evolution (LTE) and/or LTE-Advanced ( LTE-A) to establish air interface 116.
In some example embodiments, base station 114a and WTRUs 102a, 102b, and 102c may implement, for example, IEEE 802.16 (ie, Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Temporary Standard 2000 (IS- 2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate GSM Evolution (EDGE) and/or GSM EDGE (GERAN) Radio technology.
The base station 114b in Figure 1A may be, for example, a wireless router, a home Node B, a home eNodeB or an access point, and any suitable RAT may be used to facilitate localization of, for example, a business location, home, vehicle, and/or campus. Wireless connectivity in the area.
In some example embodiments, base station 114b and WTRUs 102c and 102d may: (1) implement a radio technology such as (i) IEEE 802.11 to establish a wireless local area network (WLAN); and/or (ii) IEEE 802.15 Such radio technology to establish a wireless personal area network (WPAN); and/or (2) cellular-based RATs (eg, WCDMA, CDMA2000, GSM, LTE, and/or LTE-A, etc.) can be used to establish picocells (picocell) or femtocell.
As shown in FIG. 1A, the base station 114b can be directly connected to the Internet 110, and the base station 114b can access (or not access) the Internet 110 via the core network 106.
The RAN 104 can communicate with a core network 106, which can be configured to provide voice, data, applications, and/or voice over the Internet Protocol to one or more of the WTRUs 102a, 102b, 102c, and 102d ( VoIP) Any type of network that serves. For example, core network 106 may provide call control, billing services, mobile location based services, prepaid calling, internet connection and/or video distribution, etc., and/or perform high level security functions such as user authentication. The RAN 104 and/or the core network 106 can communicate directly or indirectly with other RANs (not shown) that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to (e.g., communicating with) the RAN 104, which may employ an E-UTRA radio technology, the core network 106 may also be in communication with another RAN employing a GSM radio technology.
The core network 106 can also serve as a gateway for the WTRUs 102a, 102b, 102c, and 102d to access the PSTN 108, the Internet 110, and/or other networks 112. The PSTN 108 may include a circuit switched telephone network that provides traditional legacy telephone service (POTS). Internet 110 may include a global system of interconnected computer networks and devices that use public communication protocols, such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and the Internet in the TCP/IP Internet Protocol Series. Road Agreement (IP). Network 112 may include a wired or wireless communication network that is owned and/or operated by other service providers. For example, network 112 may include another core network that is connected to one or more RANs that may employ the same RAT as RAN 104 or a different RAT.
The WTRUs in communication system 100 (e.g., some or all of WTRUs 102a, 102b, 102c, and/or 102d) may include multi-mode capabilities (e.g., WTRUs 102a, 102b, 102c, and/or 102d may be included for use via different wireless chains) Multiple transceivers that communicate with different wireless networks). For example, the WTRU 102c may be configured to communicate with a base station 114a that may employ a cellular-based radio technology and a base station 114b that may employ an IEEE 802 radio technology.
FIG. 1B is a system diagram of an example WTRU 102. As shown in FIG. 1B, the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keyboard 126, a display/touchpad 128, a non-removable memory 130, and a removable Memory 132, power source 134, Global Positioning System (GPS) chip set 136 and/or other peripheral devices 138, and the like.
The processor 118 can 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 associated with the DSP core, a controller, a micro control , dedicated integrated circuit (ASIC), field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC) and/or state machine. The processor 118 may perform signal encoding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 can be coupled to a transceiver 120 that can be coupled to the transmit/receive element 122. Although FIG. 1B illustrates processor 118 and transceiver 120 as separate components, it is contemplated that processor 118 and transceiver 120 can be integrated together in an electronic package or wafer.
Transmission/reception components (e.g., units, devices, modules, or devices) 122 can be configured to use air interface 116 to transmit signals to, for example, a base station (e.g., base station 114a) or to receive signals from a base station (e.g., base station 114a). For example, in some example embodiments, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals.
In some example embodiments, the transmit/receive element 122 may be, for example, an illuminant/detector configured to transmit and/or receive IR, UV, or visible light signals. In various example embodiments, transmit/receive element 122 may be configured to transmit and receive both RF and optical signals. It is contemplated that the transmit/receive element 122 can be configured to transmit and/or receive any combination of wireless signals.
Although the transmit/receive element 122 is shown as a single element, the WTRU 102 may include any number of transmit/receive elements 122. For example, the WTRU 102 may employ MIMO technology such that the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals (e.g., via the air interface 116).
The transceiver 120 can be configured to modulate a signal to be transmitted by the transmission/reception element 122 and demodulate the signal received by the transmission/reception element 122. Since the WTRU 102 may have multi-mode capabilities, the transceiver 120 may include, for example, multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs such as UTRA, WIFI, and/or IEEE 802.11.
The processor 118 of the WTRU 102 can be coupled to and can be coupled to a speaker/microphone 124, a keyboard 126, and/or a display/touchpad 128, such as a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit. It receives user input data. The processor 118 can also output user profiles to the speaker/microphone 124, the keyboard 126, and/or the display/touchpad 128. The processor 118 can access information from any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132, and store the data therein. The non-removable memory 130 may include random access memory (RAM), read only memory (ROM), a hard disk, or any other type of memory device. The removable memory 132 can include a Subscriber Identity Module (SIM) card, a memory stick, and/or a secure digital (SO) memory card, and the like.
In some example embodiments, processor 118 may access information from, and store data in, memory that is not physically located on WTRU 102 (e.g., on a server or a home computer (not shown)).
The processor 118 can receive (supply) power from the power source 134 and can be configured to allocate and/or control power to other elements in the WTRU 102. Power source 134 may be any suitable device for powering WTRU 102. For example, the power source 134 can include one or more dry cells (eg, nickel cadmium (NiCd), nickel zinc (NiZn), nickel metal hydride (NiMH), lithium ion (Li-ion), etc.), solar cells, and/or fuel cells. Wait.
The processor 118 may also be coupled to a set of GPS chips 136 that may be configured to provide location information (e.g., longitude and latitude) with respect to the current location of the WTRU 102. In addition to or in lieu of information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base station 114a and/or 114b) via air interface 116, and/or based on two or more nearby The timing of the signal received (local or adjacent) by the base station to determine its position. It is contemplated that the WTRU 102 may obtain location information using any suitable location determination method.
The processor 118 can be coupled to other peripheral devices 138, which can include one or more software and/or hardware modules that provide additional features, functionality, and/or wired or wireless connections. For example, peripheral device 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photo and/or video), a universal serial bus (USB) port, a vibrating device, a television transceiver, a hands-free headset, Bluetooth R module, FM radio unit, digital music player, media player, video game player module and/or internet browser.
1C is a system diagram of RAN 104 and core network 106, in accordance with an embodiment. As noted above, the RAN 104 may employ E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c via the air interface 116. The RAN 104 also communicates with the core network 106.
The RAN 104 may include eNodeBs 140a, 140b, 140c, but it will be understood that the RAN 104 may include any number of eNodeBs consistent with embodiments. Each of the eNodeBs 140a, 140b, 140c may include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c via the air interface 116. In one embodiment, eNodeBs 140a, 140b, 140c may implement MIMO technology. Thus, eNodeB 140a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, WTRU 102a.
Each of the eNodeBs 140a, 140b, 140c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling in the uplink and/or downlink Users and so on. As shown in FIG. 1C, the eNodeBs 140a, 140b, 140c can communicate with each other via the X2 interface.
The core network 106 shown in FIG. 1C may include a mobility management gateway (MME) 142, a service gateway 144, and a packet data network (PDN) gateway 146. While the above elements are described as being part of the core network 106, it will be understood that any of these elements can be owned and/or operated by entities other than the core network operator.
The MME 142 may be connected to each of the eNodeBs 140a, 140b, 140c in the RAN 104 via the S1 interface and may serve as a control node. For example, the MME 142 may be responsible for authenticating user authentication for the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular service gateway during initial connection of the WTRUs 102a, 102b, 102c, and the like. The MME 142 may also provide control plane functionality for switching between the RAN 104 and other RANs (not shown) employing other radio technologies such as GSM or WCDMA.
Service gateway 144 may be coupled to each eNodeB of eNodeBs 140a, 140b, 140c in RAN 104 via an S1 interface. The service gateway 144 can typically route and forward user data packets to/from the WTRUs 102a, 102b, 102c. The service gateway 144 may also perform other functions, such as anchoring the user plane during handover between eNodeBs, triggering paging when the downlink information is available to the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, etc. .
The service gateway 144 can also be coupled to a PDN gateway 146 that can provide the WTRUs 102a, 102b, 102c with access to a packet switched network, such as the Internet 110, to facilitate the WTRUs 102a, 102b, 102c. Communication with an enabled IP device.
The core network 106 facilitates communication with other networks. For example, core network 106 may provide WTRUs 102a, 102b, 102c with access to a circuit-switched network, such as PSTN 108, to facilitate communications between WTRUs 102a, 102b, 102c and conventional landline communication devices. For example, core network 106 may include or be in communication with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that interfaces between core network 106 and PSTN 108. In addition, core network 106 can provide WTRUs 102a, 102b, 102c with access to network 112, which can include other wired or wireless networks that are owned and/or operated by other service providers.
While some of the figures show LTE components, other mobile telecommunications technologies such as UMTS, CDMA, and/or LTE-A may be expected to be applied, for example, for UMTS, the RAN 104 may include, for example, Node-B and RNC.
Home Node B (HNB) and Home eNodeB (HeNB), which may be referred to as H(e)NB, are 3GPP terminology and are not limited to use only for homes, but also for enterprise and metro deployments. The term "Femto Access Point" (FAP) can be considered synonymous with H(e)NB.
The H(e)NB can be connected to the cellular operator's network via a UMTS Terrestrial Radio Access Network (UTRAN) or Long Term Evolution (LTE) wireless air interface using broadband IP backhaul.
By providing additional intelligence in the evolved HNB platform and providing new value-added services via broadband IP back-up, there may be additional opportunities for integration or interaction via the HNB platform and other digital home/neighbor/enterprise components. Value-added services can include lower cost communication and entertainment options (such as "quadruple play"), simplified home network management (including remote access), extended applications for personal devices (including audio) / Videoconferencing transition and / or universal remote control capabilities), "local" services that enable IP multimedia conversations (IMS), improved personal/home security, and/or network security support for operator support. New capabilities may include wireless broadband backhaul options (including 3G technology and/or higher bandwidth 4G technologies such as WiMAX, LTE and/or LTE-A).
New capabilities may include HNB support for a large number of machine-to-machine (M2M) devices and/or M2M gateways, cooperative multi-RAT delivery of multimedia data (including simultaneous multi-RAT connections), and interconnections with neighboring HNBs to form neighbor regions Or corporate local area network, which facilitates local P2P communication including access to local cached content.
New capabilities may also include an interface between the HNB and wireless access in a vehicle environment (WAVE) enabled vehicle. Such an interface can help the continuity of user conversations in the vehicle and the delivery of vehicle data to the network when the user reaches or leaves home.
The following are examples of service requirements that can be supported by the CGW hybrid network architecture: (1) simplified deployment and operation, including automatic configuration; and (2) WTRU services (such as all WTRU services) provided by the cellular network operator, including Movement to/from macrocells, support for IMS and/or M2M gateways, etc.; (3) local device communication using messaging and data via CGW; (4) use of messaging via CGW and via local devices Local device communication of peer-to-peer (P2P) connected data; (5) local IP access from the WTRU to the home network; (6) remote access from the WTRU to the home network; (7) public alert system to Expansion of the home network; and/or (8) expansion of cellular Internet TV services (eg, multimedia broadcast multicast services including bandwidth management for home networks).
Examples of access requirements that may be supported by the CGW hybrid network architecture may include support for: (1) IP-based broadband backhaul for the cellular core network of the cellular operator; (2) blocking of access to the cellular and WLAN, Open and hybrid subscriber groups; (3) UMTS air interface, including support for legacy terminals; (4) LTE/LTE-A air interface; (5) 802.1I-based WLAN air interface, including legacy terminals and 802.11 Support for p WAVE devices; (6) use of hive/WLAN interface/gateway and/or M2M directly via optional M2M interface such as ZigBee and/or Bluetooth; (7) inter-RAT and/or inter-HNB access /service delivery; (8) multi-RAT access/service; and/or (9) local admission control and/or local resource control.
The CGW may provide the following features: (1) CGW components including 3GPP HNB, local GW, IEEE 802.11 AP, IEEE 802.15.4 WPAN, RF sensing module and/or M2M GW, and CGW application including Dynamic Spectrum Management (DSM) (2) registration of CGW elements to one or more external operator networks and/or one or more service providers, including support for IMS and non-IMS services and/or external M2M servers; 3) Local IP access (LIPA) between the WTRU and the residential/enterprise network via the CGW; (4) selected IP traffic offload via the CGW (SIPTO); (5) enhanced CGW via bandwidth management to Access to local and mobile core operator (MCN) services; (6) idle and/or active mobility from HNB to HNB, HNB to macrocells and macrocells to HNB; (7) assisted self-organizing Network (SON) forward view interference management (pIM); and / or (8) M2M gateway function.
Active HNB mobility can support combined hard handoffs and Service Radio Network Subsystem (SRNS) redirection procedures including support for lossless handoff. The bandwidth management in the CGW may include a bandwidth management (BWM) server that provides IP packet data between the cellular (eg, UMTS) and 802.11 air interfaces for devices with multimode capable BWM clients. RAT distribution. In some example embodiments, the BWM server may be integrated into a CGW that includes BWM server function integration in the HNB, or the BWM server may be a separate entity between the standard HNB and the MCN.
In some example embodiments, the BWM server may be integrated with multiple HNBs, which may be useful in an enterprise arrangement.
The home or business network can be configured to have a cable modem or digital subscriber line (DSL) connection to the public internet. The network may have HNB and BWM servers that can be interconnected in the same Home Area Network (HAN) or Enterprise Area (EAN), and HNB and BWM servers with IP addresses on the HAN or EAN.
Figures 2A and 2B (collectively including a system distributed over two pages, where the data machine 207 displayed on both pages shows where the two figures overlap/meet) is an example infrastructure for a CGW hybrid network . Entity implementations may vary depending on the particular function of interest. The description of the main components is outlined here.
In the architecture shown in Figure 2, a special interface (referred to as a logical interface) can be implemented by more than one physical interface. For example, a terminal device such as a cellular telephone 202 can have both a Wi-Fi interface 206 and a cellular interface 204. In this example, the logical interface can be a physical multi-radio access technology (multi-RAT). This may facilitate multiple transmissions to increase data rate or provide link robustness (eg, multi-RAT diversity), or provide flexibility to select each RAT in an adaptive manner depending on the RAT's applicability to the data to be transmitted. .
The CGW infrastructure may consist of a family "core network" component that includes any hardwired facility (eg, Category 5 cable, coaxial cable, telephone line, wire and/or fiber optics, etc.).
In FIG. 2, certain functions of the CGW platform 201 are shown in the block labeled CGW function 210. These functions may exist logically in the CGW platform, but may be implemented in a centralized form, such as in an HNB or in a distributed form, between multiple nodes.
The higher order components of the CGW infrastructure network can be separate entities or modules. However, commercial implementations of general architectures can incorporate various components to improve performance and reduce size/cost/energy consumption. For example, the HNB 203 can be physically integrated with a home gateway, WLAN access point 208, and/or TV STB 211 to provide a single box multi-technology "fusion gateway." To support such a structure, HNB 203, HeNB 205, broadband modem 207, and/or STB 211 may share a common application layer protocol for remote management based on TR-069 or other standards of the Broadband Forum. In some example embodiments, the femtocell base station may be integrated with a home gateway and a Wi-Fi router.
In some example embodiments, HNB 203 may include the ability to provide a WTRU-enabled device with a Home Based Network or "Local IP Access" (LIPA) to an external Internet. HNBs can support logical and/or physical connections to other networks, and/or integrate with other networks via gateways such as WLAN APs.
The HNB 203 can be connected to the customer's home gateway via an Ethernet network, which can provide access to the cellular operator's core network 208 via, for example, broadband, cable, fiber optic or DSL. Fixed wireless broadband access can also be an option, such as WiMAX or LTE cellular technology. Non-operator WLAN APs can be used in home networks. The CGW may also use an 802.11n-based AP managed by a cellular operator.
The systems and methods described herein generally relate to bandwidth management techniques, IP flow mobility, and seamless WLAN offload (IFOM). In some embodiments, the controlling entity may be a CGW, BWM server 224, or an action core network itself that makes a packet to the WTRU, such as a user device. As described in more detail below, the systems and methods described herein can use feedback as input to an IFOM decision engine. For example, the feedback may come from a home eNodeB and/or an eNodeB (hereinafter collectively referred to as a (H)eNB). The systems and methods described herein are not solely directed to an eNodeB embodiment or a home eNodeB embodiment. Rather, the systems and methods described herein are applicable to architectures having either or both of an eNodeB or a home eNodeB. Thus, any embodiment for eNodeB can also be implemented using a home eNodeB, and vice versa, unless otherwise explicitly stated.
This feedback may include, for example, congestion and/or load measured at the (H)eNB, or other measurements of performance parameters. This feedback, such as interference measured at the eNodeB, can be provided to the IFOM decision engine using any of a variety of suitable techniques (or combinations). In one embodiment, for example, the feedback is provided via an X2 interface. In another embodiment, the feedback is received directly from the (H)eNB that has been configured to report various performance measurements. In yet another embodiment, the feedback is received from a Home eNodeB Management System (HeMS).
In some embodiments, upon receiving this feedback information, routing decisions can be made based on the following logic. If the (H)eNB reports interference and/or overload conditions via any of the interfaces listed above, and the WTRU using this overloaded or interfering (H) eNB has both 3GPP and non-3GPP transmissions, and originates from/sinks (sink) To) the IP flow of the user equipment allows the IP flow to be offloaded to non-3GPP transmissions, then some or all of the WTRU's IP flows are moved from 3GPP radio access technologies (eg, hives) to non-3GPP radio access technologies (eg, Wi -Fi).
CGW-based IFOM using eSON
In some embodiments, a CGW-based IFOM evolved ad hoc network (eSON) system and method can be used. The IFOM Decision Engine functionality currently in the CGW can be used by employing the Home eNodeB requirement in 3GPP TS 32.581 v9.1.0, incorporated herein by reference:
REQ-OAMP_CM-FUN-016 The HeNB should be able to inform the HeMS of changes in the radio environment and the required radio bandwidth.
It should be noted that although the illustrated embodiment is illustrated using a CGW located in a building that controls several home eNodeBs, this disclosure is not so limited. Rather, some systems and methods may use CGWs located in the mobile core network and control several small cell eNodeBs or macro eNodeBs without departing from the scope of the present disclosure.
In a CGW-based IFOM, the CGW may have a decision engine that decides how to move IP flows between two RATs, such as a cellular and Wi-Fi, based on several input functions, for example. Inputs may include, but are not limited to, the number of IP flows, the amount of traffic consumed by each IP flow, the routing policy per IP flow, and Received Signal Strength Indication (RSSI) measurements made at the WTRU. In some embodiments, additional input to this decision process may include feedback information from the (H)eNB. The feedback information may include interference measured by the (H)eNB, level or resource load at the (H)eNB, or other performance parameters.
In order to receive this feedback information, in some embodiments, the CGW can configure the (H) eNB to make measurements and report it to the CGW. Once one or more measurements are received, the CGW can then process the measurements and decide to remove the IP stream from the hive transmission based on the measured interference. Therefore, (H) inter-eNB interference can be reduced.
Figure 3 - Figure 8 illustrates a non-limiting embodiment of the CGW based IFOM-eSON architecture at various operational stages. Referring first to Figure 3, in the illustrated embodiment, there are a number of home eNodeBs 303a, 303b in the building 301, and a number of user devices 305a, 305b, 305c, 305d, some (e.g., devices 305a and 305d). At the same time, it is connected to one of the home eNodeBs 303a or 303b and one of the Wi-Fi APs 311a or 311b. Other user devices, such as user devices 305b and 305c, are only connected via Wi-Fi. As will be appreciated, for any particular building, there may be n home eNode Bs and m Wi-Fi APs, where n is any positive integer and m is any positive integer. Additionally, for purposes of explanation, let us assume that each user device 305a-305d actively participates in data transfer, as indicated by line 320. In the illustrated embodiment, there is a single CGW 310 in the building that manages the home eNodeB.
Referring to FIG. 4, although each of the user devices 305a-305d connected to the home eNodeB 303a or 303b actively participates in the material conversation, the home eNodeB may begin to interfere with each other, as indicated by arrow 402 in FIG. That way. The eSON server 315 in the CGW 310 can configure each of the home eNodeBs 303a, 303b to collect measurements of its environment.
Referring next to Figure 5, after collecting these measurements, each home eNodeB can send these measurements to CGW 310, as indicated by arrow 502 shown in Figure 5. How often each home eNodeB sends a measurement report can be based on how it is configured by the CGW. Referring now to Figure 6, after receiving these measurements, the eSON server 315 in the CGW 310 can pass this performance data to the IFOM decision engine 317, as indicated by arrow 602 in Figure 6.
After analyzing the performance data, the IFOM decision engine 317 can determine that there is an unacceptable level of interference 402 between the home eNodeBs 303a and 303b. Referring to Figure 7, to mitigate this interference, the IFOM decision engine 317 can then attempt to use the IFOM function to move the IP stream away from the cellular transmission and move to a non-homed transmission (e.g., Wi-Fi), as shown in Figure 7. As indicated by IP flow 702. After one or more of the IP flows have moved from the cellular transmission to the non-homing transmission, the inter-eNode inter-B interference can be effectively reduced to no longer adversely affect performance, as shown in FIG.
Figure 9 shows a non-protocol-specific high-order message sequence diagram showing the interaction between CGW 901 and eNodeB 903 in accordance with a non-limiting embodiment. A similar message sequence diagram can be applied to a home eNodeB. Via message 902, CGW 901 can configure eNodeB 903 for environmental measurements. Via message 904, eNodeB 903 can acknowledge the configuration message. At 906, the eNodeB 903 can begin to obtain data (ie, interference measurements, congestion measurements, resource loads, or other performance metrics) for provision to the CGW 901. Via message 908, the eNodeB can send a measurement report. At 910, the CGW 901 can analyze the feedback material provided by the eNodeB 903.
The flow shown in dashed box 914 occurs if the CGW determines that interference (or at least an unacceptable level of interference) exists. In particular, CGW 901 moves IP flows from cellular radio access technology to non-homed radio access technology (ie, Wi-Fi) as shown at 916. By comparison, if CGW 901 determines that interference does not exist (or at least an acceptable level of interference exists), the flow shown in dashed box 917 occurs. In particular, CGW 901 does not move IP flows from cellular radio access technology to non-homed radio access technologies, as shown at 918.
In one embodiment, the messaging interface between the CGW 901 and the home eNodeB 903 can use the CPE WAN Management Protocol (refer to TR-069). Other embodiments may use different protocols that perform similar functions without departing from the scope of the disclosure. Using the CPE WAN Management Agreement may require a TR-069 client in the Home eNodeB. However, the eNodeB already has a TR-069 client that is used for initial provision by the HeMS, as described in 3GPP TS 32.581 v9.1.0:
REQ-OAMP_CM-FUN-001 HeNB configuration should be managed by HeMS using the TR-069 CWMP protocol.
The configuration of the home eNodeB that made the measurements according to one non-limiting embodiment and the transmission of these measurements to the CGW using the TR-069 protocol are shown in Figures 10A and 10B. At 1001, the CGW can open a TR-069 connection with the home eNodeB. At 1002, the CGW and the home eNodeB can establish a secure connection. At 1003, the CGW can establish a conversation with the home eNodeB by sending a connection request message.
Multiple events can trigger the CGW to establish a conversation. For example, in some embodiments, the provision of a home eNodeB by HeMS can be used as a trigger. In some embodiments, logic can be used to determine that interference is possible based on the number of home eNodeBs operating in one location. In any event, at 1004, the home eNodeB can send a notification request to the CGW to identify itself. This notification request may include parameters that uniquely identify the home eNodeB. In some embodiments, the notification request can be similar to step 2.1 of 3GPP TS 32.593 v9.1.0 part 5.1.2.2. At 1005, the CGW can send a notification response to the home eNodeB. In some embodiments, the notification response can be similar to step 2.1 of 3GPP TS 32.593 v9.1.0 part 5.1.2.2. At 1006, the CGW can send a set parameter value request message that can include various parameters. In some embodiments, these parameters may include, for example, a list of measured frequencies, what are measured in those frequencies, and how often these measurements are performed. These parameters may include, for example, the EUTRA ARFCN minimum, the EUTRA ARFCN maximum, and a list of measurements (eg, RSSI, RSRP, etc.). The set parameter value request message can also indicate a period, such as "once" or once every "x" seconds. It may also include an execution measurement flag when it is set to indicate that the home eNodeB should begin performing measurements.
At 1007, the home eNodeB can send a set parameter value response message to the CGW. At 1008, the TR-069 session between the CGW and the home eNodeB ends. It should be noted that although the illustrated embodiment shows that the TR-069 session ends at 1008, the disclosure is not so limited. In fact, in some embodiments, the conversation between the CGW and the home eNodeB may remain open while the eNodeB is performing measurements. In some embodiments, the CGW can determine whether to keep the conversation open based on the messaging needs. For example, if the CGW and the home eNodeB have a relatively active relationship, keeping the conversation open is beneficial to reduce overall messaging because several signals are required to establish a TR-069 conversation. On the other hand, if the CGW only needs information from the CGW relatively infrequently, it may be beneficial to end the conversation and re-initiate it later (as shown in Figures 10A and 10B).
Once configured, the home eNodeB performs the indicated measurements at 1009. After the measurement is taken, at 1010 the home eNodeB opens a TR-069 connection with the CGW. At 1011, the CGW and the home eNodeB can establish a secure connection. At 1012, the home eNodeB can establish a TR-069 session by sending a notification request to the CGW. Note that if the measurement is configured to "once" then the message 1009-1016 will only occur once. If the measurements are configured to occur periodically or at least re-occur, then appropriate measurements can occur after each cycle of measurement. At 1013, the CGW sends a notification response to the home eNodeB. The notification request and subsequent notification responses may be similar to step 2.1 of 3GPP TS 32.593 v9.1.0 part 5.1.2.2. At 1014, the CGW may send a Get Parameter Value Request message to query the measurements that the Home eNodeB has made. At 1015, the home eNodeB can return these values in the Get Parameter Response message. At 1016, the TR-069 session between the CGW and the home eNodeB ends.
Once the measurement information is received, at 1017, the CGW can act on these measurements to determine if the IP flow needs to be moved from the hive to Wi-Fi (or other non-homed network) to avoid interference. If the IP flows can be moved (based on user device capabilities and routing rules), the CGW will transfer these IP flows to Wi-Fi.
Referring now to FIG. 10B, if the CGW determines that it no longer needs the home eNodeB to perform measurements, it will command the home eNodeB to stop performing measurements. To stop the home eNodeB from making any additional measurements, the CGW can open a TR-069 connection with the home eNodeB, as shown at 1018. At 1019, the CGW and the home eNodeB can establish a secure connection. At 1020, the CGW can contact the home eNodeB to request it to establish a TR-069 session via a connection request message. At 1021, the home eNodeB can send a notification request to the CGW to identify itself. This notification request may include parameters that uniquely identify the home eNodeB. In some embodiments, the notification request can be similar to step 2.1 of 3GPP TS 32.593 v9.1.0 part 5.1.2.2. At 1022, the CGW can send a notification response to the home eNodeB that can be similar to step 2.1 of 3GPP TS 32.593 v9.1.0 part 5.1.2.2. At 1023, the CGW may send a set parameter value request message including an execution measurement flag that is reset to indicate that the home eNodeB should stop performing measurements. At 1024, the home eNodeB can send a set parameter value response message to the CGW. At 1025, the TR-069 conversation between the CGW and the home eNodeB can end.
The home eNodeB in Figures 10A and 10B may include structures (i.e., memory) to which the CGW may write to configure measurements and read actual measurements therefrom.
After the measurements have been taken and received from the (H) eNB, the CGW will know the radio environment in which each eNodeB operates. The CGW can then analyze the results and decide whether to attempt to offload the IP flow from the cellular transmission to one or more non-homed transmissions. In some embodiments, the decision may be based on the principle that if all (H)eNBs measure low interference, nothing is done; if there is no non-homing AP, nothing is done; and if the (H)eNB does measure high Interference, devices attached to it may suffer from unfavorable throughput/performance. If any of those connected devices are IFOM capable, one or more IP flows can be moved (ie, those IP flows with routing rules that do not require "honeycomb only" can be moved to non-homed transmissions (eg Wi-Fi transmission)).
In various embodiments, the CGW may configure (H) the eNB to measure the frequency around the transmission frequency allocated to each (H) eNB. When the measurement is received from one (H) eNB (or several (H) eNBs), this logic may receive a reported received signal strength indication (RSSI) and reference signal reception at frequencies near the transmission frequency of the (H) eNB. The power (RSRP) level is compared to the threshold RSSI and RSRP levels stored in the CGW. If the measured value is below the critical value, no IP flow is attempted. If the measured value is above the threshold, the CGW may attempt to move the stream. If the CGW determines that the IP flow should be moved, it can traverse the list of existing IP flows routed via the reported interfered (H) eNB. For each of these IP flows, the CGW may determine if the WTRU (ie, the destination) also has an active linked non-homed connection and will determine if the IP flow routing rule allows IP flow movement from the cellular to the non-homed transmission. After discovering all IP flows that can be moved from the hive to the non-homed, the CGW will perform the movement of these IP flows.
Figure 11 illustrates a process flow 1100 for measurement-based home e-Node B interference based on a non-limiting embodiment. As will be appreciated, a similar process flow can be used to measure inter-E-B interference. This process flow 1100 can be performed for each home eNodeB that has measured interference. At 1102, it is determined whether the home eNodeB has been reported to have detected interference on a frequency near its transmission frequency. If no interference is measured, the process ends. However, if interference has been measured, the process flow continues to 1104 where the IP flows through the CGW and the home eNodeB that are experiencing interference are identified. In those IP flows, it is determined which arrives at the WTRU with an existing Wi-Fi connection that is linked to the 3GPP PDP context via this home eNodeB. It is also determined whether the IP flow has a routing policy that is not "honeycomb only" or otherwise can restrict offloading. At 1106, one or more IP flows identified at 1104 are offloaded to Wi-Fi transmissions (or other non-homed transmissions). In some embodiments, all IP flows identified at 1104 can be moved to non-homed transmissions. In other embodiments, a single IP stream may be sequentially unloaded via an interference level re-evaluation performed after each unload.
The systems and methods described herein may be WTRU device agnostic. Instead, from a WTRU's perspective, for some embodiments, all of the systems and methods required to perform the systems described herein are IFOM capable WTRU devices. Also, the systems and methods described herein can be implemented to perform self-optimization and self-recovery via mitigation of interference.
CGW-based IFOM using the X2 interface
The LTE X2 interface is designed for (H) inter-eNB communication. 3GPP TS 36.420 v10.1.0 has additional details regarding the X2 interface and is incorporated herein by reference. There are several defined procedures based on traversing the X2 interface for execution in the (H)eNB. The main scope of these procedures is found in 3GPP TS 36.423 v10.2.0, which is incorporated herein by reference. These programs include interface management, measurement, and switching collaboration. Additional details regarding the X2 Application Protocol (AP) for the X2 interface can also be found in 3GPP TS 36.423 v10.2.0.
According to various embodiments, the IFOM decision engine function already present in the CGW may be used in conjunction with the X2 interface defined between the (H) eNB and the (H)eNB supporting the definition of the result of the X2 interface. While the various embodiments described herein are explained in the context of a CGW located in a building that controls several home eNodeBs, the system and method are not so limited. Rather, the system and method are applicable to embodiments having a CGW located in the MCN and controlling a number of small cell eNodeBs or macro eNodeBs. Also, in other embodiments, the systems and methods described herein can be extended to existing PDN gateway based IFOMs.
According to one embodiment of the CGW-based IFOM, the CGW may have a decision engine that determines how to move IP flows between the cellular access network and the non-homed access network (eg, Wi-Fi) based on one or more input functions. These inputs are for example but not limited to: the number of IP flows, the amount of traffic consumed by each IP flow, the routing policy per IP flow, and the RSSI measurements made at the UE. Also, the CGW may also use an input indicating interference measured by one or more (H)eNBs, an overload of (H) eNB resources, and/or other performance related metrics.
In general, the (H)eNB may transmit a message including interference measured by the (H)eNB and a load of the (H)eNB resource to another (H) eNB. In accordance with the systems and methods described herein, a (H)eNB can be configured to operate as if the CGW is another (H) eNB. In order to cause the eNodeB to operate like this, the CGW can emulate the (H)eNB and establish an X2 connection with the (H) eNB. Thus, in some embodiments, the CGW has functionality associated with creating an X2 proxy in the CGW. One or more associated (H)eNBs will perform as they are communicating with another (H)eNB. Via this X2 connection, the CGW knows that the cell is within the (H)eNB range. It can then configure the (H)eNB to perform the already defined measurements to support the X2 interface. The (H)eNB can then perform (or collect from the cells it manages) the required measurements and send these measurements to the CGW. The CGW can then use these as input to the IFOM decision engine. If the (H) eNB (and its cells) are tied (eg, from an interference or resource load perspective), the CGW can decide to move the IP flow away from the cellular transmission based on the measured interference or resource load. By offloading IP flows from the cellular access network, (H) inter-eNB interference can be reduced and resource overloading can be mitigated.
Figures 12 - 17 illustrate a CGW-based IFOM using the X2 interface in accordance with one non-limiting embodiment. Although the illustrated embodiment shows two home eNodeBs 1203a, 1203b and two Wi-Fi APs 1211a, 1211b, the disclosure is not so limited. Instead, any suitable number of home eNodeBs and/or eNodeBs 1211a, 1211b and an appropriate number of non-homed APs can be used. For example, in some embodiments, a building may include 3 eNodeBs, 7 Wi-Fi APs, and a Bluetooth access point. Additionally, for purposes of illustration, several user devices 1205a, 1205b, 1205c, 1205d are shown, some of which (1205b and 1205c) are connected to one of the home eNodeBs 1203a, 1203b and Wi-Fi APs 1211a, 1211b And other devices (1205a, 1205d) connected only via Wi-Fi. In addition, for the purpose of explanation, let us assume that each user actively participates in data transmission. Moreover, for purposes of explanation, assume that a single CGW 1210 is managing a home eNodeB in this building 1201. Figure 12 illustrates the CGW-based IFOM-X2 architecture.
Referring now to Figure 13, although each user device connected to the home eNodeB actively participates in the data session, the home eNodeBs may begin to interfere with each other, as indicated by arrow 1302 in Figure 13. Also, in some embodiments, the home eNodeB may be overloaded even if there is no interference (ie, the smallest idle resource is available). Also, in some embodiments, the home eNodeB may additionally suffer from degraded performance. As shown in FIG. 14, the X2 agent 1216 in the CGW 1210 can configure each home eNodeB 1203a, 1203b via the X2 interface 1404 to collect measurements of its environment. This configuration can occur at the appropriate time, including before there is interference. After collecting these measurements, each home eNodeB can send measurements to the CGW via the X2 interface 1404. In some embodiments, how often each home eNodeB sends a measurement report can be based on how it is configured by the CGW. For example, measurement reports can be sent periodically.
As shown in FIG. 15, after receiving these measurements, the X2 agent in the CGW can pass this data to the IFOM decision engine 1217 as indicated by arrow 1502. After analyzing the interference and/or load profile, the IFOM decision engine 1217 can determine that one or more of the home eNodeBs 1203a, 1203b are experiencing interference. In some cases, it may be determined that one or more home eNodeBs may be experiencing an overload condition and/or other potentially harmful operational conditions that have been reported by the X2 interface 1404. In any event, to alleviate the interference, overload or performance related issues experienced by the home eNodeB, the IFOM decision engine 1217 may attempt to use the IFOM function to move the IP stream 1220 from the cellular transmission to the Wi-Fi transmission, as shown in FIG. Shown. As shown in Fig. 16, the IP stream 1220 to the user device is moved from the home eNodeB 1203a to the Wi-Fi AP 1211a.
After one or more of the IP flows have been moved from the cellular transmission to the Wi-Fi transmission, the interference, overload and/or other harmful conditions measured by the home eNodeB can be effectively reduced to no longer adversely affect performance. . This repaired operating environment is shown in Figure 17.
Referring now to Figure 18, there is shown a non-contracted specific high-order message sequence diagram showing the interaction between CGW 1801 and (H)eNB 1803 in accordance with one non-limiting embodiment. Via message 1802, CGW 1801 configures (H) the eNB for environmental measurements. The message (1), (H)eNB 1803 acknowledges the configuration message. At 1806, the (H)eNB 1803 performs the measurement. Via message 1808, (H)eNB 1803 sends a measurement report to CGW 1801. At 1810, the CGW 1801 analyzes these measurements. Dashed box 1812 shows the sequence of messages if CGW 1801 determines that interference occurred in 1810. In particular, as shown at 1818, CGW 1801 moves one or more IP flows from the hive to Wi-Fi. In another aspect, dashed box 1814 illustrates the message flow if it is determined that (H) eNB 1803 is overloaded. In particular, as shown at 1820, CGW 1801 moves the IP stream from the hive to Wi-Fi. Finally, dashed box 1816 illustrates the presence of a message at the (H) eNB if there is no interference, overload, or other harmful condition as determined by CGW 1801. In particular, as shown at 1822, the IP stream is not moved.
In some embodiments, the communication interface between the CGW and the (H) eNB will reuse the LTE X2 interface designed for (H) inter-eNB communication (refer to 3GPP TS 36.420 v10.1.0). In other words, in some embodiments, the CGW can generally mimic the actions of the (H) eNB by performing (H)eNB configuration under the control of the CGW to perform and report measurements defined in 3GPP TS 36.423.
While some embodiments use the X2 interface, other embodiments may use different protocols that perform similar functions. If the existing X2 interface is used, no changes need to be made to the (H)eNB. The X2 interface can communicate between the (H) eNBs using the X2 Application Protocol (refer to 3GPP TS 36.423 v10.2.0) and SCTP/IP. Existing defined procedures via the X2 interface can be reused to cause the (H)eNB to perform measurements and report measurements to the CGW. The CGW can use these results to decide whether to move certain IP flows from the cellular transmission (traversing the reported (H) eNBs) to non-homing transmissions (also under the control of the CGW).
Figure 19 illustrates a communication diagram for configuring (H) eNB 1903 to perform measurements using the X2 interface and pass those measurements to CGW 1901, according to one non-limiting embodiment. At 1902, CGW 1901 sends an X2 Setup message to (H)eNB 1903. The setup message can be as defined in 3GPP TS 36.423 v10.2.0 part 9.1.2.3. The triggering of the CGW 1901 to perform this step can be a variety of suitable triggers. For example, it may be the result of a home eNodeB provided by HeMS. Alternatively, it may be intuitive knowledge established in a CGW with several home eNode Bs in one location and possibly interference. In any event, the X2 Setup message 1902 requires the sending entity to have a (H)eNB ID. Thus, in some embodiments, CGW 1901 will have to be assigned (H) eNB ID (even if it is not (H) eNB). The X2 Setup message 1902 may also have a list of cells within the scope of the entity that sent the message. The receiving entity uses this information to determine which entities to send interference messages to. If two (H) eNBs use the same frequency, once they have an X2 conversation, each can send interference information to the other. In order for the CGW 1901 to force the (H)eNB 1903 to transmit interference information, the CGW will have to include cell information including the (H)eNB transmitting interference information. These will be done by setting the EUARFCN to the frequency used by the (H)eNB. In some embodiments, the CGW may eavesdrop on the home eNodeB-HeMS interaction to learn the EUARFCN when the home eNodeB is provided, or the CGW may be pre-configured with this information.
At 1904, the (H)eNB 1903 can send an X2 response message to the CGW 1901 as defined in section 9.2.1.4 of 3GPP TS 36.423 V10.2.0. Based on this message, the CGW 1901 can learn about the messages of all cells served by the responding (H)eNB 1903. At 1906, the CGW can send a resource status request message to the (H) eNB as defined in section 9.2.1.11 of 3GPP TS 36.423 V10.2.0. The CGW 1901 can set this message to configure the following measurements for each cell reported by the (H)eNB in 1904: PRB period, TNL load indicator period, HW load indicator period, and composite available capacity period. The CGW can set the period so that the (H)eNB will periodically report these measurements. The CGW may set a "partial success indicator" to allow the (H)eNB to report those measurements it supports if it does not support all of the above measurements. The CGW may set a "registration request" to begin causing the (H)eNB to perform and send measurements.
At 1908, the (H)eNB may send a resource status response message to the CGW, for example, as defined in section 9.2.1.12 of 3GPP TS 36.423 V10.2.0. At 1910, once configured, the (H)eNB 1903 can perform the indicated measurements. At 1912, the (H)eNB may periodically send a resource status update message to the CGW as defined in section 9.2.1.14 of 3GPP TS 36.423 V10.2.0. At 1914, the (H)eNB may send the load information message to the CGW asynchronously as defined in section 9.1.2.1 of 3GPP TS 36.423 V10.2.0.
At 1916, the CGW can act on the measurements received at 1912 and 1914 to determine if IP flows need to be moved from the homing to Wi-Fi (or other radio access technology) to avoid interference, reduce on the (H) eNB. Load or improve operational performance. If the (H)eNB is experiencing interference or is in an overload condition, and if the IP flow can be moved (based on user equipment capabilities and routing rules), the CGW can transfer one or more IP flows to Wi-Fi.
If the CGW determines that it no longer needs the (H)eNB to perform the measurement, it may send a resource status request message with the "registration request" set to stop to the (H) eNB to inform the (H)eNB to stop performing the measurement, As shown at 1918. Then, as shown at 1920, although the (H)eNB may suspend transmitting the resource status update message to the CGW, it may continue to send the load information message to the CGW.
In some embodiments, the (H)eNB may provide the load experienced by the (H)eNB (via a resource status update message) and/or the interference measured by the (H) eNB (via a load information message). Since both of these indicate (H) whether the eNB is in a bond (although for different reasons), the interference decision algorithm can consider both cases. However, regardless of why the (H)eNB is in a binding situation, the resulting actions may be the same, in particular, attempting to move the IP stream from the cellular transmission to the non-homing transmission.
A process flow considering interference measurement and overload according to a non-limiting embodiment is shown in FIG.
In step 2001, the CGW determines if the home eNodeB has measured interference (load information message) on the uplink or downlink frequency that the home eNodeB is using. If not, the flow continues to step 2003 where the CGW determines if the home eNodeB is overloaded (radio status update message). If not, there is no need to do anything to transfer IP traffic, and thus the process ends.
On the other hand, if it is determined in step 2001 that the home eNodeB has measured interference on the uplink or downlink frequency that the home eNodeB is using or that the home eNodeB is overloaded in step 2003, the flow Continue to step 2005. In step 2005, the CGW determines all IP flows that meet the following criteria: (1) through this CGW and the home eNodeB that is experiencing interference; (2) arrives to have an existing link to the 3GPP PDP context via this home eNodeB Wi-Fi connected user devices; and (3) have routing policies that are not "honeycomb only". Then, at step 2007, the CGW moves one or more (in this example all) IP flows that satisfy the above criteria to the Wi-Fi transmission, and the process ends.
In some embodiments, some principles of the mobile algorithm may include the following: if the (H)eNB measures low interference and is not overloaded, nothing is done. If you don't have a Wi-Fi AP, don't do anything. If the (H) eNB measures high interference or overload, the device connected to it may suffer from unfavorable throughput/performance. If any of those devices are IFOM capable, one or more IP flows that can be moved (such as those with routing rules that do not require "honeycomb only") will be moved to Wi-Fi transmission.
When the CGW receives the load information message from the (H) eNB, it can decode the following information elements (IEs) from the message: the uplink interference overload indication and the associated narrowband transmission power (RNTP). Each of these IEs reports its own information per physical resource block (PRB). The uplink interference overload indication reports the uplink interference level measured by the (H) eNB cell and reports the interference of each PRB as an enumerated value (high, medium or low). The RNTP reports whether the downlink power delivered by the eNodeB cell in each PRB is greater than the RNTP threshold provided in the same IE.
In some embodiments, the CGW can analyze the reported values and determine if there is an unacceptable amount of up- or down-chain interference. To determine if there is uplink interference, the CGW can calculate the percentage of PRBs that are experiencing high interference. For example, if this percentage exceeds a threshold stored in the CGW, the CGW may attempt to move at least one IP stream from the cellular transmission to the Wi-Fi transmission (or other non-homed transmission). In order to determine if there is downlink interference, the CGW may use the RNTP per PRB received from the (H) eNB. If the (H)eNB plans to "many" PRBs exceed the downlink power threshold, the (H)eNB may operate well in a heavy interference environment. Similar to the up-chain interference calculation, the CGW can calculate the percentage of PRBs that are projected to exceed the lower-chain power threshold. For example, if this percentage exceeds a threshold stored in the CGW, the CGW may attempt to move at least one IP stream from the cellular transmission to the Wi-Fi transmission (or other non-homed transmission). Thus, according to some embodiments, if the eNodeB cell is experiencing uplink and/or downlink interference, the CGW may attempt to move the IP flow from the cellular transmission to the non-homed transmission.
When the CGW receives the resource status update message from the (H) eNB, it can decode the following IE from the message: hardware load indicator; S1 transport network layer (TNL) load indicator; radio resource indicator and composite Available capacity group. The hardware load indicator IE consists of a hard-chain hardware load indicator and a downlink hardware load indicator. Each of these can be reported as an enumeration parameter (low load, medium load, high load, and overload). Similarly, the S1 TNL load indicator IE consists of an uplink S1 TNL load indicator and a downlink S1 TNL load indicator. Each of these can also be reported as an enumeration parameter (low load, medium load, high load, and overload). The Radio Resource Indicator IE consists of several parameters including the percentage of the total PRB of the uplink and downlink that are currently in use. The percentage of each includes a value of 0 to 100%. The composite available capacity group IE consists of two items, a composite available capacity uplink and a composite available capacity downlink. Each of these items can be split into several components, including capacity values. The capacity value is a percentage of the available eNodeB capacity. For example, 0 means that there is no remaining capacity, and 100 means that all capacity of the (H) eNB remains.
The CGW can analyze the reported values and determine if (H) the eNB is overloaded. If the parameter indicates an overloaded (H) eNB (eg, exceeding a threshold stored in the CGW), the CGW may attempt to move at least one IP flow from the cellular transmission to the Wi-Fi transmission.
In various embodiments, various parameters can be used to determine when an overload condition exists. In one embodiment, the following eight parameters can be used to determine a metric for evaluating the load condition:
Winding hardware load indicator (UHLI)
Downlink hardware load indicator (DHLI)
Winding S1 TNL load indicator (USTLI)
Downlink S1 TNL load indicator (DSTLI)
Upstream total PRB (UTPU) currently in use
Downlink total PRB (DTPU) currently in use
Composite Available Capacity Winding - Capacity Value (UCV)
Composite Available Capacity Downlink - Capacity Value (DCV)
The individual weights for each of these parameters can be stored in the CGW. Since the following algorithms calculate these parameters proportionally based on weights, in some embodiments, the only restriction on weights is that they are non-negative.
One process for determining (H) eNB status (overloaded or not overloaded) is as follows. First, sum the weights stored in the CGW (total weight):

Next, set the sum (sum) of the 8 parameters to 0:

Sum=0

If UHLI = "overload" then:

Sum=sum+w _UHLI

If UHLI = "high load" then:

If UHLI = "Medium Load" or "Low Load", do nothing if DHLI = "Overload":

If DHLI = "high load" then:

If DHLI = "Medium Load" or "Low Load", do nothing if USTLI = "overload":

If USTLI = "high load" then:

If USTLI = "Medium Load" or "Low Load", do nothing if DSTLI = "Overload":

If DSTLI = "High Load" then:

If DSTLI = "Medium Load" or "Low Load", nothing is done:
For UTPU:

For DTPU:

For UCV:

For DCV:

The following equation can then be used to calculate the weighted % of load:

In some embodiments, the (H)eNB may be considered overloaded if the weighted load % is greater than the limit stored in the CGW. Otherwise, the (H) eNB is not considered overloaded. In some embodiments, the "level" that can further quantify the overload can be further quantified. For example, if the weighted load % falls within the upper limit, the (H) eNB is considered to be heavily overloaded. If the weighted load % falls within the medium range, the (H) eNB is considered to be moderately overloaded. If the weighted load % falls within the lower limit range, then the (H) eNB is considered not to be overloaded. The actions taken by the CGW may vary depending on whether the (H) eNB is heavily or moderately overloaded. For example, if heavily overloaded, the CGW can offload all IP flows that are considered to be offloadable. However, if the (H) eNB is moderately overloaded, the CGW can offload several IP flows that are less than the total number of IP flows that are considered to be offloadable.
As will be appreciated, other factors can be used to weight various parameters. For example, a parameter rated as a "medium" load level may be given a weight of 1/4. In some embodiments, a parameter having a "high" load level, for example, may be given a weight of 2/3. The disclosure is not limited to any particular weighting scheme.
In some embodiments, the system and method for using the X2 interface for a CGW based IFOM may be WTRU device and (H)eNB independent. Additionally, the systems and methods described herein typically perform self-optimization and self-recovery by mitigating interference and/or other conditions that impede performance.
Figure 21 illustrates an alternative embodiment disclosed in connection with Figures 12-17, but also using the X2 interface. This embodiment may use (H) existing X2 conversations between eNBs and route these X2 conversations via the CGW, as shown in FIG. In particular, independent of any CGW, existing X2 interfaces may exist between (H) eNBs, such as the X2 interface 2105 between (H) eNBs 2101 and 2103. Such an X2 interface uses X2 application protocols as defined in 3GPP TS 36.423 to carry information between (H) eNBs. It allows one (H)eNB to inform another (H)eNB about the load conditions that the (H)eNB is experiencing, and allows one (H)eNB to configure another (H)eNB to report its observed interference. In this embodiment, the existing X2 session 2105 between the (H) eNBs 2101 and 2103 will be routed via the CGW 2107, as shown in FIG. Routing the existing X2 interface 2105 via the CGW 2107 allows the CGW to access the load information and interference information traversing the existing X2 connection 2105 without the CGW having to create its own X2 session to the (H)eNB. As an initial condition for this embodiment, the (H)eNB must be configured such that it establishes an X2 connection and configures each other to report interference and load information.
This embodiment may use substantially the same concepts, mechanisms, and processes described above in connection with Figures 12-20.
Macro based IFOM
In some embodiments, the eSON functionality described above can be placed in any core network element in the mobile core network, such as in a PDN Gateway (PGW). In such an embodiment, it assists the IFOM engine in directing the IP flow through the interfering (H) eNB to a different transmission, such as Wi-Fi. A macro-based IFOM eSON architecture in accordance with one embodiment is shown in Figures 22-27. The illustrated embodiment includes several example home eNodeBs 2203a, 2203b and several example user devices 2205a, 2205b, 2205c, 2205d in building 2201. Some of the user devices (e.g., user device 2205d) may be coupled to one of the home eNodeBs (e.g., HeNB 2203b) and the Wi-Fi AP 2211. Other user devices, such as user devices 2205a, 2205b, 2205c, are only connected to the network via the home eNodeB (2203a). Other (not shown) may be connected only via the Wi-Fi AP. For any particular building, there may be n home eNode Bs and m Wi-Fi APs, where n is any positive integer and m is any positive integer. Additionally, for purposes of explanation, assume that each user device actively participates in data transfer. The cellular portion of the network includes a serving gateway 2223 with which the MME 2221 and (H)eNB can communicate. The service gateway 2223 is in communication with a PND gateway 2225 that includes an eSON server 2227 and an IFOM decision engine 2229. Wi-Fi AP 2211 is directly coupled to PDN gateway 2225 as indicated by S2a link 2233, or coupled thereto via evolved packet data gateway 2231 as indicated by SW link 2235 and S2b link 2237.
Referring to Figure 23, as described above, the (H) eNBs 2203a, 2203b can be configured to perform and report measurements in their respective environments, as illustrated by the bidirectional link 2302 in Figure 23. Figure 23 shows the interaction between (H) eNBs 2203a, 2203b and PDN gateway 2225 in the presence of (H) inter-eNB interference (indicated by arrow 2304).
Once the eSON server 2227 receives the measurements, the data will be analyzed and the input can be sent to the IFOM decision engine 2209 for the IP flow for the user device 2305d to be moved from the cellular transmission to the Wi-Fi transmission. Figure 24 illustrates the data flow after the IFOM decision engine 2229 has moved the IP stream 2239a from the hive (as shown in Figure 23) to Wi-Fi (as shown at 2239b in Figure 24).
In still other embodiments, such as shown in Figures 25-27, the X2 proxy function as described above in connection with Figures 12-21 may be incorporated into a PDN Gateway (PGW) 2525. The X2 proxy function can function in a similar manner in a macro environment so that it generally assists the IFOM engine in directing IP flows through interfering home eNodeBs to different transmissions (e.g., Wi-Fi). As shown, the X2 interface 2502 is formed between the PGW 2525 and the eNodeBs 2203a, 2203b. Although not shown, it should be understood that a similar architecture may be used with the (H)eNB without departing from the scope of the present disclosure.
With the X2 proxy 2527 in the PGW 2525 and the X2 proxy (not shown) in the (H)eNB 2503a, 2503b, the (H)eNB can be configured in its respective environment via the X2 interface 2502 from the PGW 2525. The measurements are performed and reported as indicated by arrow 2602 in Figure 26. Figure 26 also shows the presence of (H) inter-eNB interference, as indicated by arrow 2604.
Once the X2 agent 2527 receives the measurement, the data can be analyzed and the input can be sent to the IP flow for the user device 2205d should be moved from the cellular transmission (2608a shown in Figure 26) to Wi-Fi transmission (27th) The IFOM of the 2608b) shown in the figure determines the engine 2529.
In still other embodiments, as in a non-limiting embodiment illustrated by Figures 28-30, the IFOM engine 2827 can be located in the PDN gateway 2825 and communicate with the HeMS 2840 to retrieve the slave e-node. B 2803a, 2803b provides alerts and performance metrics for HeMS (the IFOM engine can reside in any core network element). This information is retrieved for the PDN gateway 2825, which can contact the HeMS 2840 and request this information, as indicated by arrow 2902 in Figure 29. After being contacted by the PDN gateway 2825, the HeMS 2840 can respond with performance metrics and alerts received from the home eNodeBs 2803a, 2803b that are reported to the HeMS 2840, as indicated by arrow 3004 in FIG.
Figure 31 is a non-contracted specific message sequence diagram showing interaction between PDN gateway 3101 and HeMS 3102 and between HeMS and HeNB 3103a, 3103b, according to one non-limiting embodiment. In some embodiments, the TR-069 protocol can be used as a mechanism to transfer this material from the HeMS 3102 to the PDN gateway 3101. Since the HeMS already has a TR-069 server, in some embodiments, the TR-069 client can be installed in the PDN gateway. The TR-069 client in the PDN gateway periodically establishes a dialogue with the TR-069 server in the HeMS and obtains alarm and performance measurements stored in the HeMS.
Via messages 3104 and 3106, HeMS 3102 configures home eNodeB 3103b and home eNodeB 3103a, respectively, to send alerts and performance measurements to the HeMS. Via the messages 3108 and 3110, the home eNodeB 3103b and the home eNodeB 3103a send their configured alert and/or periodic performance measurements to the HeMS 3102, respectively. Via message 3112, PGW 3101 requests HeMS 3102 to send thereto an alert and/or periodic performance measurement received from home eNodeBs 3103a, 3103b. Via message 3114, the HeMS sends those alerts and/or periodic measurements received from the home eNodeB to the PGW.
At 3116, the IFOM decision engine in the PGW 3101 uses the alert and period measurement information to determine if any home eNodeBs that have registered alarms or performance metrics indicate overload or congestion. If so, then at 3118, the PGW attempts to move the IP stream from the hive to the non-homed transmission.
Embodiments In an embodiment, the method may include: configuring a (H)eNB that hosts the IP flow to measure performance parameters; receiving feedback data, wherein the feedback data includes measurement of performance parameters; and determining IP based on the feedback data Unloading of the stream.
In an embodiment, the method may further comprise offloading the IP stream from the first radio access technology to the second radio access technology.
In one or more of the above methods, the first radio access technology may be a cellular technology and the second radio access technology may be a non-homed technology.
In one or more of the above methods, the non-homed technology may be a Wi-Fi technology.
In one or more of the above methods, the performance parameter may be a level of interference, a level of congestion, and/or a level of resource load.
In one or more of the above methods, the CPE WAN Management Protocol TR-069 can be used to receive feedback material.
In one or more methods of the above methods, the (H) eNB may be configured using the CPE WAN Management Protocol TR-069.
In one or more of the above methods, one of the eNodeB and the home eNodeB is configured using the CPE WAN Management Protocol TR-069.
In one or more methods of the above method, the feedback data may include at least one of a received signal strength indication (RSSI) level, a reference signal received power (RSRP) level, and a (H) eNB resource load.
In one or more of the above methods, determining that the offloading of the IP flow can include comparing the RSSI level to the RSSI threshold level, and can also include offloading the IP flow when the RSSI level exceeds the RSSI threshold.
In one or more of the above methods, determining that the offloading of the IP flow may include comparing the RSRP level and the RSRP threshold level, and may also include offloading the IP flow when the RSRP level exceeds the RSRP threshold.
In one or more of the above methods, the feedback data can be received by the packet data network gateway.
In one or more of the above methods, the feedback data can be received by the fused gate.
In one or more of the above methods, the determination may be based on the principle that if all (H)eNBs measure low interference, nothing is done; if there is no non-homed AP, nothing is done; and if (H)eNB It is true that high interference is measured and the devices connected to it may be experiencing unfavorable throughput/performance. If any of the connected devices are IFOM capable, one or more IP flows can be moved (ie those IP flows with routing rules that do not require "honeycomb only" can be moved to non-homed transmissions (eg Wi-Fi) transmission)).
One or more methods of the above methods may include identifying an IP flow flowing through the (H)eNB that is experiencing interference if interference has been detected; and determining which IP flows in those IP flows have arrived via this (H) The eNB links the WRTU of the existing Wi-Fi connection to the 3GPP PDP context; determines whether the IP flow has a routing policy that is not "honeycomb only" or can restrict offloading; and offloads one or more of the identified IP flows to, for example, Wi -Fi transmission or other non-homed transmission.
In one or more of the above embodiments, all identified IP flows may be unloaded.
Alternatively, in one or more of the above-described embodiments, a single IP flow may be sequentially offloaded using an interference level re-evaluation performed after each unload.
In another embodiment, the method can include receiving feedback data from the (H)eNB of the escrow IP flow via the X2 interface, wherein the feedback data includes measurement of performance parameters; and determining offloading of the IP flow based on the feedback data .
One or more methods of the above methods may further include offloading the IP stream from the first radio access technology to the second radio access technology.
In one or more of the above methods, the first radio access technology may be a cellular technology and the second radio access technology may be a non-homed technology.
In one or more of the above methods, the non-homed technology may be a Wi-Fi technology.
One or more methods of the above methods may further include configuring (H) the eNB to measure performance parameters.
In one or more of the above methods, the feedback data can be received by the packet data network gateway.
In one or more of the methods described above, the feedback material may be received by a merged gateway associated with the (H)eNB.
In one or more of the above methods, the determining may include the following: (1) if all (H)eNBs measure low interference and are not overloaded, do nothing; (2) if there is no Wi-Fi AP, then Do nothing; and (3) if the (H)eNB measures high interference or overload, then (a) if any of those devices are IFOM-enabled, then one or more IP flows are movable (with Those IP flows that do not require a "honeycomb only" routing rule can be moved to Wi-Fi transmission.
In another embodiment, the method can include receiving an interference measurement from the (H)eNB via the interface, wherein the IP flow is traversing the (H)eNB; when the interference measurement exceeds an interference threshold, the IP flow is from the (H) the eNB moves to a non-homed radio access technology; determines a load on the (H)eNB; and when the load of the (H)eNB exceeds a load threshold, the IP flow is from the (H)eNB Move to non-homed radio access technology.
In another embodiment, the method can include receiving an interference measurement from the (H)eNB via the interface, wherein the IP flow is traversing the (H)eNB; when the interference measurement exceeds an interference threshold, the IP flow is from the (H) the eNB moves to a non-homed radio access technology; when the interference measurement does not exceed the interference threshold, the load on the (H) eNB is determined; and if the load on the (H) eNB exceeds the load threshold Moving the IP flow from the (H) eNB to a non-homed radio access technology.
The uplink interference overload indication and associated narrowband transmission power (RNTP) reported by the (H)eNB may be used in one or more methods of the above methods to determine (H) the load on the eNB.
In one or more of the above methods, the uplink interference can be determined by calculating the percentage of PRBs that are experiencing high interference; and determining if the percentage exceeds a particular threshold.
In one or more methods of the above methods, downlink interference may be determined by using an RNTP per PRB received from the (H) eNB to determine if the percentage of PRBs that are scheduled to exceed the downlink power threshold exceeds a certain threshold.
In one or more of the methods described above, one or more of the following IEs of the resource status update message from the (H)eNB may be used to determine the load at the (H)eNB: hardware load indicator ; S1 Transport Network Layer (TNL) load indicator; radio resource indicator; and composite available capacity group.
In one or more methods of the above methods, the sum of the weighted parameters can be used to determine (H) the load on the eNB.
In one or more methods of the above method, the weighted parameters may include a uplink hardware load indicator, a downlink hardware load indicator, an uplink S1 TNL load indicator, a downlink S1 TNL load indicator, and At least one of the currently used total chain PRB, the currently used down-chain total PRB, the composite available capacity winding-capacity value, and the composite available capacity downlink-capacity value.
In one or more of the above embodiments, one or more of the following parameters may be used to determine a metric for evaluating a load condition: a chained hardware load indicator (UHLI); a downlink hardware load indication (HH); uplink S1 TNL load indicator (USTLI); downlink S1 TNL load indicator (DSTLI); currently used total uplink PRB (UTPU); currently used downlink total PRB (DTPU); composite Available capacity winding - capacity value (UCV) and composite available capacity down chain - capacity value (DCV).
In still another embodiment, in a network comprising at least first and second (H) eNBs, the method can include configuring the first and second (H) eNBs to pass the first and second (H) eNBs The X2 interface exchanges performance parameter data, the X2 interface is routed through the gateway node; the gateway node accesses performance parameter data of the first and second (H)eNBs; and determines the unloading of the IP stream based on the feedback data .
In still another embodiment, the method can include: requesting performance parameter measurements from the (H)eNB management system; receiving performance parameter measurements from the (H)eNB management system; and determining from the (H)eNB based on the performance parameter measurements Unloading of IP flows.
In one or more of the above methods, the performance parameter measurement may indicate (H) an inter-eNB interference level.
The above embodiments may be implemented by a processor included in any number of network nodes and/or distributed among a plurality of network nodes including, but not limited to, PGW, (H)eNB, HeMS, CGW.
In still other embodiments, an apparatus includes: a processor configured to: configure a (H)eNB that hosts an IP flow to measure performance parameters; receive feedback data, wherein the feedback data includes measurements of performance parameters; and based on the feedback Data to determine the offload of the IP stream.
In one or more embodiments of the above embodiments, the processor is further configured to offload the IP flow from the first radio access technology to the second radio access technology.
In one or more embodiments of the above embodiments, the performance parameter may include at least one of an interference level and a resource load level.
In one or more embodiments of the above embodiments, the CPE WAN Management Protocol TR-069 can be used to receive feedback material.
In one or more embodiments of the above embodiments, the feedback material may be received via the X2 interface.
In one or more embodiments of the above embodiments, the device may be a merged gateway.
In one or more embodiments of the above embodiments, the device may be a packet data network gateway.
Although the features and elements are described above in a particular combination, it will be understood by those of ordinary skill in the art that each feature or element can be used alone or in any combination with its features and elements. Moreover, the methods described herein can be implemented in a computer program, software or firmware embodied in a computer readable medium executed by a computer or processor. Examples of computer readable media include electronic signals (transmitted via a wired or wireless connection) and computer readable storage media. Examples of computer readable storage media include, but are not limited to, read only memory (ROM), random access memory (RAM), scratchpad, cache memory, semiconductor memory devices, such as internal hard drives and removable Magnetic sheets such as magnetic media, magneto-optical media, and optical media such as CD-ROM discs and digital versatile discs (DVDs). A processor associated with the software can be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.
Variations of the above methods, devices and systems are possible without departing from the scope of the invention. The embodiments are to be considered in all respects as illustrative and not restrictive
Moreover, in the above-described embodiments, attention should be paid to processing platforms, computing systems, controllers, and other devices including processors. These devices may include at least one central processing unit ("CPU") and memory. Depending on the practice of those of ordinary skill in the computer programming arts, symbolic representations involving actions and operations or instructions may be performed by various CPUs and memory. Such actions and operations or instructions may be referred to as "execution,""computerexecution," or "CPU execution."
Those of ordinary skill in the art will appreciate that the operations or instructions of the acts and symbolic representations include electronic signals that are operated by the CPU. The electronic system representation can cause the conversion or reduction of the result of the electrical signal and maintain the data bit in the storage location in the memory system, thereby reconfiguring or changing the data bits of the CPU operation, and other processing of the signal. The storage location of the maintenance data bit is a physical location having a particular electrical, magnetic, optical or organic property corresponding to or representing the data bit. It should be understood that the exemplary embodiments are not limited to the above-described platforms or CPUs and other platforms and CPUs that can support the above methods.
The data bits can also be maintained on a computer readable medium, including a CPU readable magnetic disk, a compact disc, and any other volatile (eg, random access memory ("RAM")) or non-volatile (eg, read only memory ("ROM")) Mass storage system. The computer readable medium can comprise a cooperating or interconnected computer readable medium, which is present exclusively on the processing system or distributed across a plurality of interconnected processing systems, which may be local or remote to the processing system. It should be understood that the exemplary embodiments are not limited to the above-described memory and other platforms and memories that can support the above methods.
No element, act, or instruction used in the description of the present application should be construed as essential or essential to the invention, unless explicitly described. As such, the article "a" is intended to include one or more items. In the case where only one item is intended, the term "one" or a similar language is used. In addition, the term "any one" followed by a plurality of items and/or items of a plurality of categories, as used herein, is intended to include "any" of these items and/or categories of such items, " Any combination, "any number of" and/or "any combination of the plurality" is independent of or in combination with other items and/or other categories of items. Also, as used herein, the term "set" is intended to include any number of items, including zero. Moreover, as used herein, the term "number" is intended to include any number, including zero.
Also, the scope of patent application should not be construed as being limited to the described order or elements unless the effect is described. Moreover, the use of the term "means" in any patent application is intended to invoke 35 USC § 112, ¶ 6, and any patent application scope without the word "means" does not have such a meaning.

100. . . Example communication system

102, 102a, 102b, 102c, 102d. . . Wireless transmit/receive unit (WTRU)

104. . . Radio access network (RAN)

106. . . Core network 106

108. . . Public switched telephone network (PSTN)

110. . . Internet

112. . . Other network

114a, 114b. . . Base station

116. . . Air interface

118. . . processor

120. . . transceiver

122. . . Transmission/reception component

124. . . Speaker/microphone

126. . . keyboard

128. . . Display/trackpad

130. . . Non-removable memory

132. . . Removable memory

134. . . power supply

136. . . Global Positioning System (GPS) chipset

138. . . Peripheral device

140a, 140b, 140c, 903. . . eNodeB

142a, 142b. . . Radio Network Controller (RNC)

144, 2223. . . Service gateway

146. . . Packet Data Network (PDN) gateway

148. . . Serving GPRS Support Node (SGSN)

201. . . CGW platform

202. . . Honeycomb phone

203. . . 3GPP Home Node B (HNB)

204. . . Honeycomb interface

205, 303a, 303b, 1203a, 1203b, 1803, 1903, 2101, 2103, 2203a, 2203b, 2803a, 2803b. . . Home eNodeB (HeNB)

206. . . Wi-Fi interface

207. . . Data machine

208. . . WLAN access point

210. . . CGW function

211. . . TV STB

224. . . Bandwidth Management (BWM) Server

301, 1201, 2201. . . building

305a, 305b, 305c, 305d, 1205a, 1205b, 1205c, 1205d, 2205a, 2205b, 2205c, 2205d. . . User device

310, 1210. . . Single CGW

311a, 311b, 1211a, 1211b, 2211. . . Wi-Fi Ap

315, 2227. . . Evolved Self-Organizing Network (eSON) Server

317, 1217, 2229, 2529. . . IFOM decides the engine

320. . . line

402, 1302, 1502, 2602, 2902. . . arrow

901, 1801, 1901, 2107. . . Fusion Gateway (CGW)

1220, 2239a. . . IP flow

1404, 2105, 2502. . . X2 interface

2221. . . Mobile Management Gateway (MME)

2223. . . Evolved packet data gateway

2225, 2525, 2825. . . PND gateway

2233. . . S2a link

2235. . . SW link

2237. . . S2b link

2527. . . X2 agent

2840. . . (H) eNB Management System (HeMS)

2827. . . IFOM engine

RAT. . . Radio access technology

SON. . . Self-organizing network

RF. . . Radio frequency

DSM. . . Dynamic spectrum management

M2M. . . Machine to machine

IMS. . . IP Multimedia Subsystem

MCN. . . Mobile core network

A more detailed understanding can be obtained from the following examples, which are given by way of example with reference to the accompanying drawings. The figures in such figures are as examples, as in the detailed description. Therefore, the figures and implementations are not to be considered as limiting, and other equivalent effective examples are possible and possible. It is emphasized that the various features/elements of the drawings are not drawn to scale. Conversely, the size of various features/components can be expanded or reduced in any way for the sake of clarity. Also, in the figures, the same element symbols may be used to indicate similar features/components. Included in the drawing is the following figure:
1A is a system diagram of an example communication system in which one or more disclosed embodiments may be implemented;
Figure 1B is a system diagram of an example wireless transmit/receive unit (WTRU) that can be used in the communication system shown in Figure 1A;
1C is a system diagram of an example radio access network and an example core network that can be used in the communication system shown in FIG. 1A;
2A and 2B together form an example diagram of a CGW hybrid network architecture;
3 through 8 are exemplary diagrams of CGW-based IFOM-eSON architectures at various stages of operation in accordance with one embodiment;
Figure 9 is a diagram showing an example of a non-contract-specific message sequence chart showing interaction between a CGW and an eNodeB;
10A-FIG. 10B collectively include an exemplary diagram showing a sequence of message sequences for interaction between a CGW and an eNodeB using the TR-069 protocol in accordance with one non-limiting embodiment;
11 is a diagram showing an example of a processing flow of IP flow movement based on measured interference between home eNodeBs;
12 through 17 are exemplary diagrams of a CGW-based IFOM using an X2 interface in operating various operations in accordance with one embodiment;
Figure 18 is a flowchart showing a non-contracted specific advanced message sequence for interaction between a CGW and an eNodeB in accordance with one non-limiting embodiment;
Figure 19 illustrates a communication diagram using the X2 interface in accordance with a non-limiting embodiment;
Figure 20 illustrates a process flow in accordance with one non-limiting embodiment;
Figure 21 is a diagram showing an example of an IFOM using an X2 interface between HeNBs according to one non-limiting embodiment;
22 through 24 are exemplary diagrams of a macro-based IFOM eSON architecture in various operational stages, in accordance with one embodiment;
25 through 27 are exemplary diagrams of architectures having X2 proxy functionality incorporated into a PDN gateway in various operational phases, in accordance with one embodiment;
Figures 28 - 30 illustrate an architecture according to one non-limiting embodiment in various stages of operation in accordance with one embodiment; and Figure 31 is a non-contracted specific message sequence flow in accordance with a non-limiting embodiment.

901. . . Fusion Gateway (CGW)

903. . . Home eNodeB

Claims (27)

A method comprising:
Configuring a (H)eNB hosting an IP flow to measure a performance parameter;
Receiving a feedback data, wherein the feedback data includes a measurement of the performance parameter; and determining an offload of the IP flow based on the feedback data. The method of claim 1, wherein the method further comprises:
The IP stream is offloaded from a first radio access technology to a second radio access technology. The method of claim 2, wherein the first radio access technology is a cellular technology and the second radio access technology is a non-homed technology. The method of claim 3, wherein the non-homed technology is a Wi-Fi technology. The method of claim 1, wherein the performance parameter comprises at least one of an interference level, a congestion level, and a resource load level. The method of claim 1, wherein the feedback material is received using a CPE WAN Management Protocol TR-069. The method of claim 1, wherein the (H)eNB is configured using a CPE WAN Management Protocol TR-069. The method of claim 1, wherein the feedback data comprises at least one of a Received Signal Strength Indication (RSSI) level and a Reference Signal Received Power (RSRP) level. The method of claim 1, wherein the feedback data is received by a packet data network gateway. The method of claim 1, wherein the feedback data is received by a merged gateway. A method comprising:
Receiving, by an X2 interface, a feedback data from a (H)eNB that hosts an IP flow, wherein the feedback data includes a measurement of a performance parameter; and determining an offload of the IP flow based on the feedback data. The method of claim 11, wherein the method further comprises:
The IP stream is offloaded from a first radio access technology to a second radio access technology. The method of claim 12, wherein the first radio access technology is a cellular technology and the second radio access technology is a non-homed technology. The method of claim 13, wherein the non-homed technology is a Wi-Fi technology. The method of claim 11, wherein the method further comprises:
The (H)eNB is configured to measure the performance parameter. The method of claim 11, wherein the feedback data is received by a packet data network gateway. A method comprising:
Receiving, by an interface, an interference measurement from a (H)eNB, wherein an IP flow is traversing the (H)eNB;
Moving the IP flow from the (H)eNB to a non-homed radio access technology when the interference measurement exceeds an interference threshold;
Determining a load on the (H)eNB; and moving the IP flow from the (H)eNB to a non-homed radio access technology when the load on the (H)eNB exceeds a load threshold. The method of claim 17, wherein the load on the (H)eNB is determined using a sum of weighted parameters. The method of claim 18, wherein the weighted parameter comprises a uplink hardware load indicator, a downlink hardware load indicator, an uplink S1 TNL load indicator, a downlink S1 TNL load At least one of an indicator, a total uplink PRB currently in use, a currently used total chain PRB, a composite available capacity uplink-capacity value, and a composite available capacity downlink-capacity value. A method in a network comprising at least first and second (H) eNBs, the method comprising:
Configuring the first and second (H)eNBs to exchange a performance parameter data via an X2 interface between the first and second (H) eNBs, and routing the X2 interface via a gateway node;
The gateway node accesses the performance parameter data of the first and second (H)eNBs; and based on the feedback data, determines an offload of the IP flow. A method comprising:
Requesting a performance parameter measurement from a (H)eNB management system (HeMS);
Receiving the performance parameter measurement from the HeMS management system; and determining an offload of an IP flow from the HeMS based on the performance parameter measurement. The method of claim 21, wherein the performance parameter measurement indicates a (H) inter-eNB interference level. A device comprising:
A processor configured to:
Configuring a (H)eNB hosting an IP flow to measure a performance parameter;
Receiving a feedback data, wherein the feedback data includes a measurement of the performance parameter; and determining an offload of the IP flow based on the feedback data. The device of claim 23, wherein the processor is further configured to:
The IP stream is offloaded from a first radio access technology to a second radio access technology. The device of claim 23, wherein the performance parameter comprises at least one of an interference level and a resource load level. The apparatus of claim 23, wherein the feedback data is received using a CPE WAN Management Protocol TR-069. The device of claim 23, wherein the feedback data is received via an X2 interface.