WO2017131805A1

WO2017131805A1 - Configuration of mobility sets in cellular network

Info

Publication number: WO2017131805A1
Application number: PCT/US2016/034399
Authority: WO
Inventors: Alexander Sirotkin; Joey Chou
Original assignee: Intel IP Corp
Current assignee: Intel IP Corp
Priority date: 2016-01-29
Filing date: 2016-05-26
Publication date: 2017-08-03
Anticipated expiration: 2018-07-29

Abstract

Radio access network (RAN) that supports long-term evolution (LTE)/wireless local area network (WLAN) aggregation (LWA). Mobility-set configuration messaging calls for configuration of a mobility set of WLAN access points (APs) operatively coupled with an evolved node-B (eNB). The mobility set defines a set of APs among which a user equipment (UE) is to vary AP connectivity independently of connectivity variability control of the eNB. In response to the mobility-set configuration messaging, the eNB is configured with a definition of the mobility set, and a set of at least one record is maintained that associates certain APs with the mobility set, and with the eNB.

Description

CONFIGURATION OF MOBILITY SETS IN CELLULAR NETWORK

PRIORITY CLAIM

[0001] This Application claims the benefit of U.S. Provisional Application No. 62/288,997, filed January 29, 2016, and entitled "OAM ENHANCEMENTS FOR LWA," the disclosure of which is incorporated by reference herein.

TECHNICAL FIELD

[0002] Embodiments pertain to wireless communications. Some embodiments relate to wireless networks including 3 GPP (Third Generation Partnership Project) networks, 3 GPP LTE (Long Term Evolution) networks, 3 GPP LTE-A (LTE

Advanced) networks, and fifth-generation (5G) networks. Other embodiments relate to Wi-Fi wireless networks. Further embodiments are more generally applicable outside the purview of LTE and Wi-Fi networks.

BACKGROUND

[0003] Mobile data usage continues growing exponentially at a rate of nearly doubling year-after- year, and this trend is expected to continue. Although advances in cellular technology have made improvements in the performance and capacity of mobile networks, it is widely thought that such advances will still fall short of accommodating the anticipated demand for mobile data network service.

[0004] One approach to increasing mobile network capacity is LTE/WLAN Aggregation (LWA). This concept is based on recent work by the 3rd Generation

Partnership Project (3GPP) on offloading some of the data service the Wireless Local Area Networks (WLANs). As the development of practical LWA systems is ongoing, there is a need for a practical arrangement and associated process for network operators to configure, and adjust, the logical relationships among eNBs, APs, WTs, mobility sets, and potentially other related system components.

BRIEF DESCRIPTION OF THE DRAWINGS

[0005] In the drawings, which are not necessarily drawn to scale, like numerals may describe similar components in different views. Like numerals having different letter suffixes may represent different instances of similar components. Some embodiments are illustrated by way of example, and not limitation, in the following figures of the accompanying drawings.

[0006] FIG. 1 is a functional diagram of a 3 GPP network in accordance with some embodiments.

[0007] FIG. 2 is a block diagram of a User Equipment (UE) in accordance with some embodiments.

[0008] FIG. 3 is a block diagram of an Evolved Node-B (eNB) in accordance with some embodiments.

[0009] FIG. 4 illustrates an example processor-based computing platform according to some embodiments.

[0010] FIG. 5 is a schematic diagram illustrating an example LWA system according to some embodiments.

[0011] FIG. 6 is a schematic diagram illustrating a network environment in accordance with various embodiments.

[0012] FIG. 7 is a process flow and data communications diagram illustrating a process for configuring components of a radio access network (RAN) for LWA operation according to some embodiments. DETAILED DESCRIPTION

[0013] The following description and the drawings sufficiently illustrate specific embodiments to enable those skilled in the art to practice them. A number of examples are described in the context of 3 GPP communication systems and components thereof. It will be understood that principles of the embodiments are applicable in other types of communication systems, such as Wi-Fi or Wi-Max networks, Bluetooth or other personal-area networks, Zigbee or other home-area networks, wireless mesh networks, and the like, without limitation, unless expressly limited by a corresponding claim. Given the benefit of the present disclosure, persons skilled in the relevant technologies will be able to engineer suitable variations to implement principles of the embodiments in other types of communication systems. Various diverse embodiments may incorporate structural, logical, electrical, process, and other differences. Portions and features of some embodiments may be included in, or substituted for, those of other embodiments. Embodiments set forth in the claims encompass all presently-known, and after-arising, equivalents of those claims. [0014] FIG. 1 is a functional diagram of a 3 GPP network in accordance with some embodiments. The network comprises a radio access network (RAN) (e.g., as depicted, the E-UTRAN or evolved universal terrestrial radio access network) 101 and the core network 120 (e.g., shown as an evolved packet core (EPC)) coupled together through an S I interface 115. For convenience and brevity sake, only a portion of the core network 120, as well as the RAN 101, is shown.

[0015] The core network 120 includes a mobility management entity (MME) 122, a serving gateway (serving GW) 124, and packet data network gateway (PDN GW) 126. The RAN 101 includes Evolved Node-B's (eNB) 104 (which may operate as base stations) for communicating with User Equipment (UE) 102. The eNBs 104 may include macro eNBs and low power (LP) eNBs. In accordance with some embodiments, the eNB 104 may transmit a downlink control message to the UE 102 to indicate an allocation of physical uplink control channel (PUCCH) channel resources. The UE 102 may receive the downlink control message from the eNB 104, and may transmit an uplink control message to the eNB 104 in at least a portion of the PUCCH channel resources. These embodiments will be described in more detail below.

[0016] The MME 122 is similar in function to the control plane of legacy Serving GPRS Support Nodes (SGSN). The MME 122 manages mobility aspects in access such as gateway selection and tracking area list management. The serving GW 124 terminates the interface toward the RAN 101, and routes data packets between the RAN 101 and the core network 120. In addition, it may be a local mobility anchor point for inter-eNB handoffs and also may provide an anchor for inter-3GPP mobility. Other responsibilities may include lawful intercept, charging, and some policy enforcement. The serving GW 124 and the MME 122 may be implemented in one physical node or separate physical nodes. The PDN GW 126 terminates a SGi interface toward the packet data network (PDN). The PDN GW 126 routes data packets between the EPC 120 and the external PDN, and may be a key node for policy enforcement and charging data collection. It may also provide an anchor point for mobility with non-LTE accesses. The external PDN can be any kind of IP network, as well as an IP Multimedia Subsystem (IMS) domain. The PDN GW 126 and the serving GW 124 may be implemented in one physical node or separated physical nodes. [0017] The eNB 104 (macro and micro) terminate the air interface protocol and may be the first point of contact for a UE 102. In some embodiments, an eNB 104 may fulfill various logical functions for the RAN 101 including but not limited to RNC (radio network controller functions) such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management. In accordance with embodiments, UE 102 may be configured to communicate with an eNB 104 over a multipath fading channel in accordance with an Orthogonal Frequency Division Multiple Access (OFDMA) communication technique. The OFDM signals may comprise a plurality of orthogonal subcarriers.

[0018] The S I interface 115 is the interface that separates the RAN 101 and the EPC 120. It is split into two parts: the Sl-U, which carries traffic data between the eNB 104 and the serving GW 124, and the Sl-MME, which is a signaling interface between the eNB 104 and the MME 122. The X2 interface is the interface between eNB 104. The X2 interface comprises two parts, the X2-C and X2-U. The X2-C is the control plane interface between the eNB 104, while the X2-U is the user plane interface between the eNB 104.

[0019] With cellular networks, LP cells are typically used to extend coverage to indoor areas where outdoor signals do not reach well, or to add network capacity in areas with very dense phone usage, such as train stations. As used herein, the term low power (LP) eNB refers to any suitable relatively low power eNB for

implementing a narrower cell (narrower than a macro cell) such as a femtocell, a picocell, or a micro cell. Femtocell eNBs are typically provided by a mobile network operator to its residential or enterprise customers. A femtocell is typically the size of a residential gateway or smaller and generally connects to the user's broadband line. Once plugged in, the femtocell connects to the mobile operator's mobile network and provides extra coverage in a range of typically 30 to 50 meters for residential femtocells. Thus, a LP eNB might be a femtocell eNB since it is coupled through the PDN GW 126. Similarly, a picocell is a wireless communication system typically covering a small area, such as in-building (offices, shopping malls, train stations, etc.), or more recently in-aircraft. A picocell eNB can generally connect through the X2 link to another eNB such as a macro eNB through its base station controller (BSC) functionality. Thus, LP eNB may be implemented with a picocell eNB since it is coupled to a macro eNB via an X2 interface. Picocell eNBs or other LP eNBs may incorporate some or all functionality of a macro eNB. In some cases, this may be referred to as an access point base station or enterprise femtocell.

[0020] In some embodiments, a downlink resource grid may be used for downlink transmissions from an eNB 104 to a UE 102, while uplink transmission from the UE 102 to the eNB 104 may utilize similar techniques. The grid may be a time-frequency grid, called a resource grid or time-frequency resource grid, which is the physical resource in the downlink in each slot. Such a time-frequency plane representation is a common practice for OFDM systems, which makes it intuitive for radio resource allocation. Each column and each row of the resource grid correspond to one OFDM symbol and one OFDM subcarrier, respectively. The duration of the resource grid in the time domain corresponds to one slot in a radio frame. The smallest time- frequency unit in a resource grid is denoted as a resource element (RE). Each resource grid comprises a number of resource blocks (RBs), which describe the mapping of certain physical channels to resource elements. Each resource block comprises a collection of resource elements in the frequency domain and may represent the smallest quanta of resources that currently can be allocated. There are several different physical downlink channels that are conveyed using such resource blocks. With particular relevance to this disclosure, two of these physical downlink channels are the physical downlink shared channel and the physical down link control channel.

[0021] The physical downlink shared channel (PDSCH) carries user data and higher- layer signaling to a UE 102 (FIG. 1). The physical downlink control channel (PDCCH) carries information about the transport format and resource allocations related to the PDSCH channel, among other things. It also informs the UE 102 about the transport format, resource allocation, and hybrid automatic repeat request (HARQ) information related to the uplink shared channel. Typically, downlink scheduling (e.g., assigning control and shared channel resource blocks to UE 102 within a cell) may be performed at the eNB 104 based on channel quality information fed back from the UE 102 to the eNB 104, and then the downlink resource assignment information may be sent to the UE 102 on the control channel (PDCCH) used for (assigned to) the UE 102.

[0022] The PDCCH uses CCEs (control channel elements) to convey the control information. Before being mapped to resource elements, the PDCCH complex- valued symbols are first organized into quadruplets, which are then permuted using a sub-block inter- leaver for rate matching. Each PDCCH is transmitted using one or more of these control channel elements (CCEs), where each CCE corresponds to nine sets of four physical resource elements known as resource element groups (REGs). Four QPSK symbols are mapped to each REG. The PDCCH can be transmitted using one or more CCEs, depending on the size of downlink control information (DCI) and the channel condition. There may be four or more different PDCCH formats defined in LTE with different numbers of CCEs (e.g., aggregation level, L=l, 2, 4, or 8).

[0023] As used herein, the term circuitry may refer to, be part of, or include an Application Specific Integrated Circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group), or memory (shared, dedicated, or group) that executes one or more software or firmware programs, a combinational logic circuit, or other suitable hardware components that provide the described functionality. In some embodiments, the circuitry may be implemented in, or functions associated with the circuitry may be implemented by, one or more software or firmware modules. In some embodiments, circuitry may include logic, at least partially operable in hardware. Embodiments described herein may be implemented into a system using any suitably configured hardware or software.

[0024] FIG. 2 is a functional diagram of a User Equipment (UE) in accordance with some embodiments. The UE 200 may be suitable for use as a UE 102 as depicted in FIG. 1. In some embodiments, the UE 200 may include application circuitry 202, baseband circuitry 204, Radio Frequency (RF) circuitry 206, front-end module (FEM) circuitry 208 and multiple antennas 210A-210D, coupled together at least as shown. In some embodiments, other circuitry or arrangements may include one or more elements or components of the application circuitry 202, the baseband circuitry 204, the RF circuitry 206 or the FEM circuitry 208, and may also include other elements or components in some cases. As an example, "processing circuitry" may include one or more elements or components, some or all of which may be included in the application circuitry 202 or the baseband circuitry 204. As another example, "transceiver circuitry" may include one or more elements or components, some or all of which may be included in the RF circuitry 206 or the FEM circuitry 208. These examples are not limiting, however, as the processing circuitry or the transceiver circuitry may also include other elements or components in some cases.

[0025] The application circuitry 202 may include one or more application processors. For example, the application circuitry 202 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The processor(s) may include any combination of general-purpose processors and dedicated processors (e.g., graphics processors, application processors, etc.). The processors may be coupled with or may include memory/storage and may be configured to execute instructions stored in the memory/storage to enable various applications or operating systems to run on the system.

[0026] The baseband circuitry 204 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The baseband circuitry 204 may include one or more baseband processors or control logic to process baseband signals received from a receive signal path of the RF circuitry 206 and to generate baseband signals for a transmit signal path of the RF circuitry 206. Baseband processing circuity 204 may interface with the application circuitry 202 for generation and processing of the baseband signals and for controlling operations of the RF circuitry 206. For example, in some embodiments, the baseband circuitry 204 may include a second generation (2G) baseband processor 204a, third generation (3G) baseband processor 204b, fourth generation (4G) baseband processor 204c, or other baseband processor(s) 204d for other existing generations, generations in development or to be developed in the future (e.g., fifth generation (5G), 6G, etc.). The baseband circuitry 204 (e.g., one or more of baseband processors 204a-d) may handle various radio control functions that enable communication with one or more radio networks via the RF circuitry 206. The radio control functions may include, but are not limited to, signal modulation/demodulation, encoding/decoding, radio frequency shifting, etc. In some embodiments, modulation/demodulation circuitry of the baseband circuitry 204 may include Fast-Fourier Transform (FFT), precoding, or constellation

mapping/demapping functionality. In some embodiments, encoding/decoding circuitry of the baseband circuitry 204 may include Low Density Parity Check (LDPC) encoder/decoder functionality, optionally along-side other techniques such as, for example, block codes, convolutional codes, turbo codes, or the like, which may be used to support legacy protocols. Embodiments of modulation/demodulation and encoder/decoder functionality are not limited to these examples and may include other suitable functionality in other embodiments.

[0027] In some embodiments, the baseband circuitry 204 may include elements of a protocol stack such as, for example, elements of an evolved universal terrestrial radio access network (EUTRAN) protocol including, for example, physical (PHY), media access control (MAC), radio link control (RLC), packet data convergence protocol (PDCP), or radio resource control (RRC) elements. A central processing unit (CPU) 204e of the baseband circuitry 204 may be configured to run elements of the protocol stack for signaling of the PHY, MAC, RLC, PDCP or RRC layers. In some embodiments, the baseband circuitry may include one or more audio digital signal processor(s) (DSP) 204f. The audio DSP(s) 204f may be include elements for compression/decompression and echo cancellation and may include other suitable processing elements in other embodiments. Components of the baseband circuitry may be suitably combined in a single chip, a single chipset, or disposed on a same circuit board in some embodiments. In some embodiments, some or all of the constituent components of the baseband circuitry 204 and the application circuitry 202 may be implemented together such as, for example, on a system on chip (SOC).

[0028] In some embodiments, the baseband circuitry 204 may provide for communication compatible with one or more radio technologies. For example, in some embodiments, the baseband circuitry 204 may support communication with an evolved universal terrestrial radio access network (EUTRAN) or other wireless metropolitan area networks (WMAN), a wireless local area network (WLAN), a wireless personal area network (WPAN). Embodiments in which the baseband circuitry 204 is configured to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband circuitry.

[0029] RF circuitry 206 may enable communication with wireless networks using modulated electromagnetic radiation through a non-solid medium. In various embodiments, the RF circuitry 206 may include switches, filters, amplifiers, etc. to facilitate the communication with the wireless network. RF circuitry 206 may include a receive signal path which may include circuitry to down-convert RF signals received from the FEM circuitry 208 and provide baseband signals to the baseband circuitry 204. RF circuitry 206 may also include a transmit signal path which may include circuitry to up-convert baseband signals provided by the baseband circuitry 204 and provide RF output signals to the FEM circuitry 208 for transmission.

[0030] In some embodiments, the RF circuitry 206 may include a receive signal path and a transmit signal path. The receive signal path of the RF circuitry 206 may include mixer circuitry 206a, amplifier circuitry 206b and filter circuitry 206c. The transmit signal path of the RF circuitry 206 may include filter circuitry 206c and mixer circuitry 206a. RF circuitry 206 may also include synthesizer circuitry 206d for synthesizing a frequency for use by the mixer circuitry 206a of the receive signal path and the transmit signal path. In some embodiments, the mixer circuitry 206a of the receive signal path may be configured to down-convert RF signals received from the FEM circuitry 208 based on the synthesized frequency provided by synthesizer circuitry 206d. The amplifier circuitry 206b may be configured to amplify the down- converted signals and the filter circuitry 206c may be a low-pass filter (LPF) or band-pass filter (BPF) configured to remove unwanted signals from the down- converted signals to generate output baseband signals. Output baseband signals may be provided to the baseband circuitry 204 for further processing. In some embodiments, the output baseband signals may be zero-frequency baseband signals, although this is not a requirement. In some embodiments, mixer circuitry 206a of the receive signal path may comprise passive mixers, although the scope of the embodiments is not limited in this respect. In some embodiments, the mixer circuitry 206a of the transmit signal path may be configured to up-convert input baseband signals based on the synthesized frequency provided by the synthesizer circuitry

206d to generate RF output signals for the FEM circuitry 208. The baseband signals may be provided by the baseband circuitry 204 and may be filtered by filter circuitry 206c. The filter circuitry 206c may include a low-pass filter (LPF), although the scope of the embodiments is not limited in this respect.

[0031] In some embodiments, the mixer circuitry 206a of the receive signal path and the mixer circuitry 206a of the transmit signal path may include two or more mixers and may be arranged for quadrature downconversion or upconversion respectively. In some embodiments, the mixer circuitry 206a of the receive signal path and the mixer circuitry 206a of the transmit signal path may include two or more mixers and may be arranged for image rejection (e.g., Hartley image rejection). In some embodiments, the mixer circuitry 206a of the receive signal path and the mixer circuitry 206a may be arranged for direct downconversion or direct upconversion, respectively. In some embodiments, the mixer circuitry 206a of the receive signal path and the mixer circuitry 206a of the transmit signal path may be configured for super-heterodyne operation.

[0032] In some embodiments, the output baseband signals and the input baseband signals may be analog baseband signals, although the scope of the embodiments is not limited in this respect. In some alternate embodiments, the output baseband signals and the input baseband signals may be digital baseband signals. In these alternate embodiments, the RF circuitry 206 may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry and the baseband circuitry 204 may include a digital baseband interface to communicate with the RF circuitry 206. In some dual-mode embodiments, a separate radio IC circuitry may be provided for processing signals for each spectrum, although the scope of the embodiments is not limited in this respect.

[0033] In some embodiments, the synthesizer circuitry 206d may be a fractional-N synthesizer or a fractional N/N+l synthesizer, although the scope of the

embodiments is not limited in this respect as other types of frequency synthesizers may be suitable. For example, synthesizer circuitry 206d may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer comprising a phase-locked loop with a frequency divider. The synthesizer circuitry 206d may be configured to synthesize an output frequency for use by the mixer circuitry 206a of the RF circuitry 206 based on a frequency input and a divider control input. In some embodiments, the synthesizer circuitry 206d may be a fractional N/N+l synthesizer. In some embodiments, frequency input may be provided by a voltage controlled oscillator (VCO), although that is not a requirement. Divider control input may be provided by either the baseband circuitry 204 or the applications processor 202 depending on the desired output frequency. In some embodiments, a divider control input (e.g., N) may be determined from a look-up table based on a channel indicated by the applications processor 202.

[0034] Synthesizer circuitry 206d of the RF circuitry 206 may include a divider, a delay-locked loop (DLL), a multiplexer and a phase accumulator. In some embodiments, the divider may be a dual modulus divider (DMD) and the phase accumulator may be a digital phase accumulator (DPA). In some embodiments, the DMD may be configured to divide the input signal by either N or N+1 (e.g., based on a carry out) to provide a fractional division ratio. In some example embodiments, the DLL may include a set of cascaded, tunable, delay elements, a phase detector, a charge pump and a D-type flip-flop. In these embodiments, the delay elements may be configured to break a VCO period up into Nd equal packets of phase, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle. [0035] In some embodiments, synthesizer circuitry 206d may be configured to generate a carrier frequency as the output frequency, while in other embodiments, the output frequency may be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency) and used in conjunction with quadrature generator and divider circuitry to generate multiple signals at the carrier frequency with multiple different phases with respect to each other. In some embodiments, the output frequency may be a LO frequency (fLo). In some embodiments, the RF circuitry 206 may include an IQ/polar converter.

[0036] FEM circuitry 208 may include a receive signal path which may include circuitry configured to operate on RF signals received from one or more of the antennas 210A-D, amplify the received signals and provide the amplified versions of the received signals to the RF circuitry 206 for further processing. FEM circuitry 208 may also include a transmit signal path which may include circuitry configured to amplify signals for transmission provided by the RF circuitry 206 for transmission by one or more of the one or more antennas 210A-D.

[0037] In some embodiments, the FEM circuitry 208 may include a TX/RX switch to switch between transmit mode and receive mode operation. The FEM circuitry may include a receive signal path and a transmit signal path. The receive signal path of the FEM circuitry may include a low-noise amplifier (LNA) to amplify received RF signals and provide the amplified received RF signals as an output (e.g., to the RF circuitry 206). The transmit signal path of the FEM circuitry 208 may include a power amplifier (PA) to amplify input RF signals (e.g., provided by RF circuitry 206), and one or more filters to generate RF signals for subsequent transmission (e.g., by one or more of the one or more antennas 210. In some embodiments, the UE 200 may include additional elements such as, for example, memory/storage, display, camera, sensor, or input/output (I/O) interface.

[0038] FIG. 3 is a functional diagram of an Evolved Node-B (eNB) in accordance with some embodiments. It should be noted that in some embodiments, the eNB 300 may be a stationary non-mobile device. The eNB 300 may be suitable for use as an eNB 104 as depicted in FIG. 1. The components of eNB 300 may be included in a single device or a plurality of devices. The eNB 300 may include physical layer circuitry 302 and a transceiver 305, one or both of which may enable transmission and reception of signals to and from the UE 200, other eNBs, other UEs or other devices using one or more antennas 301A-B. As an example, the physical layer circuitry 302 may perform various encoding and decoding functions that may include formation of baseband signals for transmission and decoding of received signals. For example, physical layer circuitry 302 may include LDPC encoder/decoder functionality, optionally along-side other techniques such as, for example, block codes, convolutional codes, turbo codes, or the like, which may be used to support legacy protocols. Embodiments of modulation/demodulation and encoder/decoder functionality are not limited to these examples and may include other suitable functionality in other embodiments. As another example, the transceiver 305 may perform various transmission and reception functions such as conversion of signals between a baseband range and a Radio Frequency (RF) range. Accordingly, the physical layer circuitry 302 and the transceiver 305 may be separate components or may be part of a combined component. In addition, some of the described functionality related to transmission and reception of signals may be performed by a combination that may include one, any or all of the physical layer circuitry 302, the transceiver 305, and other components or layers. The eNB 300 may also include medium access control layer (MAC) circuitry 304 for controlling access to the wireless medium. The eNB 300 may also include processing circuitry 306 and memory 308 arranged to perform the operations described herein. The eNB 300 may also include one or more interfaces 310, which may enable communication with other components, including other eNB 104 (FIG. 1), components in the EPC 120 (FIG. 1) or other network components. In addition, the interfaces 310 may enable communication with other components that may not be shown in FIG. 1 , including components external to the network. The interfaces 310 may be wired or wireless or a combination thereof.

[0039] The antennas 210A-D, 301A-B may comprise one or more directional or omnidirectional antennas, including, for example, dipole antennas, monopole antennas, patch antennas, loop antennas, microstrip antennas or other types of antennas suitable for transmission of RF signals. In some multiple-input multiple- output (MIMO) embodiments, the antennas 210A-D, 301 A-B may be effectively separated to take advantage of spatial diversity and the different channel characteristics that may result.

[0040] In some embodiments, the UE 200 or the eNB 300 may be a mobile device and may be a portable wireless communication device, such as a personal digital assistant (PDA), a laptop or portable computer with wireless communication capability, a web tablet, a wireless telephone, a smartphone, a wireless headset, a pager, an instant messaging device, a digital camera, an access point, a television, a wearable device such as a medical device (e.g., a heart rate monitor, a blood pressure monitor, etc.), or other device that may receive or transmit information wirelessly. In some embodiments, the UE 200 or eNB 300 may be configured to operate in accordance with 3 GPP standards, although the scope of the embodiments is not limited in this respect. Mobile devices or other devices in some embodiments may be configured to operate according to other protocols or standards, including IEEE 802.11 or other IEEE standards. In some embodiments, the UE 200, eNB 300 or other device may include one or more of a keyboard, a display, a no n- volatile memory port, multiple antennas, a graphics processor, an application processor, speakers, and other mobile device elements. The display may be an LCD screen including a touch screen.

[0041] Although the UE 200 and the eNB 300 are each illustrated as having several separate functional elements, one or more of the functional elements may be combined and may be implemented by combinations of software-configured elements, such as processing elements including digital signal processors (DSPs), or other hardware elements. For example, some elements may comprise one or more microprocessors, DSPs, field-programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), radio-frequency integrated circuits (RFICs) and combinations of various hardware and logic circuitry for performing at least the functions described herein. In some embodiments, the functional elements may refer to one or more processes operating on one or more processing elements.

[0042] Embodiments may be implemented in one or a combination of hardware, firmware and software. Embodiments may also be implemented as instructions stored on a computer-readable storage device, which may be read and executed by at least one processor to perform the operations described herein. A computer-readable storage device may include any non-transitory mechanism for storing information in a form readable by a machine (e.g., a computer). For example, a computer-readable storage device may include read-only memory (ROM), random-access memory

(RAM), magnetic disk storage media, optical storage media, flash-memory devices, and other storage devices and media. Some embodiments may include one or more processors and may be configured with instructions stored on a computer-readable storage device. [0043] It should be noted that in some embodiments, an apparatus used by the UE 200 or eNB 300 may include various components of the UE 200 or the eNB 300 as shown in FIGs. 2-3. Accordingly, techniques and operations described herein that refer to the UE 200 (or 102) may be applicable to an apparatus for a UE. In addition, techniques and operations described herein that refer to the eNB 300 (or 104) may be applicable to an apparatus for an eNB.

[0044] FIG. 4 illustrates an example processor-based computing platform according to some embodiments. As depicted, system 400 includes one or more processor(s) 404, system control logic 408 coupled with at least one of the processor(s) 404, system memory 412 coupled with system control logic 408, nonvolatile memory (NVM)/storage 416 coupled with system control logic 408, a network interface 420 coupled with system control logic 408, and input/output (I/O) devices 432 coupled with system control logic 408.

[0045] The processor(s) 404 may include one or more single-core or multi-core processors. The processor(s) 404 may include any combination of general-purpose processors and dedicated processors (e.g., graphics processors, application processors, baseband processors, etc.).

[0046] System control logic 408 for one embodiment may include any suitable interface controllers to provide for any suitable interface to at least one of the processor(s) 404 and/or to any suitable device or component in communication with system control logic 408.

[0047] System control logic 408 for one embodiment may include one or more memory controller(s) to provide an interface to system memory 412. System memory 412 may be used to load and store data and/or instructions, e.g., communication logic 424. System memory 412 for one embodiment may include any suitable volatile memory, such as suitable dynamic random access memory (DRAM), for example.

[0048] NVM/storage 416 may include one or more tangible, non- transitory computer-readable media used to store data and/or instructions, e.g., communication logic 424. NVM/storage 416 may include any suitable non-volatile memory, such as flash memory, for example, and/or may include any suitable non- volatile storage device(s), such as one or more hard disk drive(s) (HDD(s)), one or more compact disk (CD) drive(s), and/or one or more digital versatile disk (DVD) drive(s), for example. [0049] The NVM/storage 416 may include a storage resource physically part of a device on which the system 400 is installed or it may be accessible by, but not necessarily a part of, the device. For example, the NVM/storage 416 may be accessed over a network via the network interface 420 and/or over Input/Output (I O) devices 432.

[0050] The communication logic 424 may include instructions that, when executed by one or more of the processors 404, cause the system 400 to perform operations associated with the components of the communication device IRP manager 128, IRP agent 132, mapping circuitry 136 and/or the methods 200 or 300 as described with respect to the above embodiments. In various embodiments, the communication logic 424 may include hardware, software, and/or firmware components that may or may not be explicitly shown in system 400.

[0051] Network interface 420 may have a transceiver 422 to provide a radio interface for system 400 to communicate over one or more network(s) and/or with any other suitable device. In various embodiments, the transceiver 422 may be integrated with other components of system 400. For example, the transceiver 422 may include a processor of the processor(s) 404, memory of the system memory 412, and NVM/Storage of NVM/Storage 416. Network interface 420 may include any suitable hardware and/or firmware. Network interface 420 may include a plurality of antennas to provide a multiple input, multiple output radio interface. Network interface 420 for one embodiment may include, for example, a wired network adapter, a wireless network adapter, a telephone modem, and/or a wireless modem.

[0052] For one embodiment, at least one of the processor(s) 404 may be packaged together with logic for one or more controller(s) of system control logic 408. For one embodiment, at least one of the processor(s) 404 may be packaged together with logic for one or more controllers of system control logic 408 to form a System in Package (SiP). For one embodiment, at least one of the processor(s) 404 may be integrated on the same die with logic for one or more controller(s) of system control logic 408. For one embodiment, at least one of the processor(s) 404 may be integrated on the same die with logic for one or more controller(s) of system control logic 408 to form a System on Chip (SoC).

[0053] In various embodiments, the I/O devices 432 may include user interfaces designed to enable user interaction with the system 400, peripheral component interfaces designed to enable peripheral component interaction with the system 400, and/or sensors designed to determine environmental conditions and/or location information related to the system 400.

[0054] In various embodiments, the user interfaces could include, but are not limited to, a display (e.g., a liquid crystal display, a touch screen display, etc.), speakers, a microphone, one or more cameras (e.g., a still camera and/or a video camera), a flashlight (e.g., a light emitting diode flash), and a keyboard.

[0055] In various embodiments, the peripheral component interfaces may include, but are not limited to, a non- volatile memory port, a universal serial bus (USB) port, an audio jack, an Ethernet connection, and a power supply interface.

[0056] In various embodiments, the sensors may include, but are not limited to, a gyro sensor, an accelerometer, a proximity sensor, an ambient light sensor, and a positioning unit. The positioning unit may also be part of, or interact with, the network interface 420 to communicate with components of a positioning network, e.g., a global positioning system (GPS) satellite.

[0057] In various embodiments, the system 400 may be implemented on a server, or system of networked server machines. System 400 may also be virtualized in some embodiments on a host machine or on a set of host machines operating using distributed computing techniques. In other embodiments, system 400 may be implemented on one or more mobile computing devices such as, but not limited to, a laptop computing device, a tablet computing device, a netbook, a smartphone, etc. In various embodiments, system 400 may have more or less components, and/or different architectures.

[0058] Examples, as described herein, may include, or may operate on, logic or a number of components, engines, modules, or circuitry which for the sake of consistency are termed engines, although it will be understood that these terms may be used interchangeably. Engines may be hardware, software, or firmware communicatively coupled to one or more processors in order to carry out the operations described herein. Engines may be hardware engines, and as such engines may be considered tangible entities capable of performing specified operations and may be configured or arranged in a certain manner. In an example, circuits may be arranged (e.g., internally or with respect to external entities such as other circuits) in a specified manner as a engine. In an example, the whole or part of one or more hardware processors may be configured by firmware or software (e.g., instructions, an application portion, or an application) as a engine that operates to perform specified operations. In an example, the software may reside on a machine-readable medium. In an example, the software, when executed by the underlying hardware of the engine, causes the hardware to perform the specified operations. Accordingly, the term hardware engine is understood to encompass a tangible entity, be that an entity that is physically constructed, specifically configured (e.g., hardwired), or temporarily (e.g., transitorily) configured (e.g., programmed) to operate in a specified manner or to perform part or all of any operation described herein.

[0059] Considering examples in which engines are temporarily configured, each of the engines need not be instantiated at any one moment in time. For example, where the engines comprise a general-purpose hardware processor core configured using software; the general-purpose hardware processor core may be configured as respective different engines at different times. Software may accordingly configure a hardware processor core, for example, to constitute a particular engine at one instance of time and to constitute a different engine at a different instance of time.

[0060] Some aspects of the embodiments are directed to configuration of a LTE/WLAN aggregation (LWA) system. In LWA, an Evolved NodeB (eNB) schedules packets to be served on LTE and Wi-Fi radio links. One advantage of this solution is that it can provide effective control and utilization of resources on both links to increase the aggregate throughput for users and improve the total system capacity.

[0061] The WLAN coverage areas of a LWA system are established by access points (APs) that are interfaced with one or more eNBs through WLAN termination (WT) entities that, in turn, are each coupled to one or more eNBs via a logical interface called the Xw interface, the operation of which is defined in the specification 3GPP TS 36.462, for example. The LWA architecture may have complex and dynamic logical relationships between the various system components.

[0062] For example, In LWA, a user equipment (UE)-based mobility scheme may be deployed in which a UE may connect to various APs as it moves about within a supported WLAN coverage area established by those APs. A WLAN mobility set may be defined among a group of APs (identified via WLAN identifiers) determined by the eNB. The mobility set allows a UE to switch APs without informing the eNB. For APs outside the mobility set or for APs within different WTs, the decision to change AP is made by the eNB based on one or more criteria, such as reported measurements by UEs, for example. [0063] FIG. 5 is a schematic diagram illustrating an example LWA system according to some embodiments. System 500 includes eNB 502 and eNB 522. eNB 502 establishes coverage area 504, which represents one or more cells. Similarly, eNB 522 establishes coverage area 524 representing one or more cells. Each of the coverage areas 504, 524 may be part of a radio access network (RAN), such as a 3 GPP LTE Advanced (LTE-A) network. The RAN may be referred to as an evolved universal terrestrial radio access network (EUTRAN). In other embodiments, other radio access network technologies may be utilized.

[0064] Within the coverage area 504, 524 are WLAN mobility sets 506, 508, 526, and 528. Mobility sets 506 and 508 provide WLAN service to UEs (not shown) within portions of coverage area 504 via eNB 502. Similarly, mobility sets 526 and 528 provide WLAN service to UEs within portions of coverage area 524 via eNB 522. Each mobility set 506, 508, 526, 528 includes one or more WLAN access points (APs) 510 (each one being individually numbered 1-21). The APs 510 within each mobility set are configured to support movement of UEs within the coverage area of that mobility set, without involvement of the eNB. In some embodiments, a mobility set is a set of one or more WLAN APs identified by one or more BSSID/HESSID/ SSIDs, within which WLAN mobility engines apply while the UE is configured with LWA bearer(s), e.g., the UE may move and change connections between WLAN APs belonging to the mobility set without informing the eNB. In an example, a mobility engine includes a handoff protocol of connection from one AP to another as a UE moves about within a coverage area of the mobility set. The eNB provides the UE with a WLAN mobility set. When the UE is configured with a WLAN mobility set, it will attempt to connect to a WLAN whose identifiers match the ones of the configured mobility set. UE mobility to WLAN APs not belonging to the UE mobility set is controlled by the eNB e.g. updating the WLAN mobility set based on measurement reports provided by the UE. In a related embodiment, a UE is connected to one mobility set at a time.

[0065] Notably, an AP may belong to more than one mobility set. For example, as depicted APs 4, 5, and 6 each belong to mobility set 506 and to mobility set 508. In addition, a mobility set may span multiple eNBs. For instance, mobility set 530 may be defined in which APs 1, 2, and 3 within coverage area 504 and APs 13, 14, and 15 within coverage area 524, provide mobility engines across the eNB coverage area boundary. [0066] Table 1 below lists various logical relationships between APs 510, eNBs 502 and 522, and mobility sets.

Table 1 : Example logical relationships between LWA components

[0067] Each mobility set 506, 508, 526, 528, 530 may have a networking component, such as a router or a bridge associated with it, such as those depicted at 512, 514, 532, 534, and 535, which interfaces the APs of each respective mobility set with WLAN termination (WT) 516 and WT 536. In a related embodiment, each networking component 512, 514, 532, 534, and 535 may host a WLAN mobility engine. Each WT 516, 538 is a logical node and may be implemented by a suitable data-processing machine, which may be situated at an eNB, or remotely from any eNB. WT 516 may optionally include access controller AC 518, and WT 536 may optionally include access controller AC 538. In various embodiments, access controller 516, 536 may include an engine for implementing control and provisioning of wireless access points (CAPWAP) protocol, a lightweight access point protocol (LWAPP), or the like. In a related embodiment, one or both of WT 516, 536 is implemented in an AC device. In some embodiments, as depicted, an AP 510 may be communicatively coupled to more than one WT 516, 536. In another related embodiment, an eNB may be coupled to multiple WTs.

[0068] In some embodiments, WT 516 is coupled to eNB 502 via Xw interface 520, and WT 536 is coupled to eNB 522 via Xw interface 540. A Xw user plane interface (Xw-U) may be defined between eNB and WT. The Xw-U interface supports flow control based on feedback from WT.

[0069] The Flow Control function is applied in the downlink when an E-RAB is mapped onto an LWA bearer, i.e. the flow control information is provided by the WT to the eNB for the eNB to control the downlink user data flow to the WT for the LWA bearer. The Xw-U interface may be used to deliver LWA protocol data units (PDUs) between an eNB and WT.

[0070] For LWA, the Sl-U terminates in the eNB and, if Xw-U user data bearers are associated with E-RABs for which the LWA bearer option is configured, the user plane data is transferred from eNB to WT using the Xw-U interface.

[0071] An Xw control plane interface (Xw-C) may be defined between an eNB and WT. The application layer signaling protocol is referred to as Xw-AP (Xw

Application Protocol) that may be between WT and AP. The Xw-AP protocol supports the following functions:

Transfer of WLAN metrics (e.g. bss load) from WT to eNB; Support of LWA for UE in ECM-CONNECTED, including establishment, Modification and Release of a UE context at the WT; and Control of user plane tunnels between eNB and WT for a specific UE for LWA bearers; and General Xw management and error handling functions, including error indication; setting up the Xw; Resetting the Xw; and Updating the WT configuration data.

[0072] The eNB-WT control plane signaling for LWA may be performed by Xw-C interface signaling.

[0073] In order for the eNB to establish the Xw interface, it may be configured with at least a list of WTs (WT IDs, WT transport network layer (TNL), or IP, addresses) that control WLAN APs under the eNB coverage. According to some embodiments, the operator may configure the eNB supporting LWA with the WLAN neighbor relation information, including at least the following: WT identifier, WT TNL (IP) address, list of WLAN APs (identified by basic service set identifier (BSSID), homogenous extended service set identifier (HESSID) or service set identifier (SSID)) that it controls. In a related embodiment, this information may be limited to only those APs within the eNB's coverage area.

[0074] FIG. 6 is a schematic diagram illustrating a network environment in accordance with various embodiments. The network environment 600 includes a network manager 604 communicatively coupled with an element manager 608 and an element manager 610 via interface-N (ITF-N) 606. In one type of embodiment, the element manager is a computing platform that is programmed, or otherwise configured, to provide a package of end-user functions for management of a set of closely-related types of network elements. For example, an element manager is described in the standard 3GPP TS 32.101 ver. 13.0.0. The element manager 610 may manage one or more evolved Node Bs (eNBs), including eNB 612 and eNB 614, as well as WT 616. The network manager 604 may manage a plurality of element managers including the element manager 608 and element manager 610. The network manager 604, element manager 608, element manager 610, eNB 612, and eNB 614 may be part of a radio access network (RAN), such as a 3GPP LTE

Advanced (LTE- A) network. The RAN may be referred to as an evolved universal terrestrial radio access network (EUTRAN). In other embodiments, other radio access network technologies may be utilized. The eNB 612 may be wirelessly coupled with one or more units of user equipment (UEs) (not shown) to provide network services for the UEs via the LTE-A network.

[0075] In various embodiments, the network environment 600 may further include WLAN APs 618 and 620. The WLAN APs 618, 620 may be communicatively coupled with one or more UEs to provide network services for the UEs via a WLAN (e.g., using a Wi-Fi network).

[0076] In various embodiments, the WLAN APs 618, 620 may be communicatively coupled with the element manager 608 via access controller-access point (AC-AP ) interface 622. In some embodiments, the network environment 600 may further include an access controller AC 624 to manage one or more WLAN APs 618, 620. In these embodiments, the element manager 608 may communicate with the one or more WLAN APs 618, 620 via the access controller 624. Other embodiments may omit the access controller 624. In these embodiments, the element manager 608 may communicate directly with the WLAN APs 618, 620.

[0077] In various embodiments, the network manager 604 may include an integration reference point (IRP) manager 628 to manage a plurality of element managers, including element manager 608 and element manager 610. The IRP manager 628 may communicate with the element managers 608, 610 via ITF-N 606, which may be a wired and/or wireless interface (e.g., a Type-2 interface). In some embodiments, the IRP manager 628 may be included in and/or implemented by a chip, chipset, or other collection of programmed and/or preconfigured circuitry.

[0078] In various embodiments, element managers 608 and 610 may each include a respective integration reference point (IRP) agent 632, 626 that communicates with the IRP manager 628 of the network manager 604 (e.g., via ITF-N 606). In element manager 608, IRP agent 632 is coupled to mapping engine 636, which is constructed, programmed, or otherwise configured, to convert message protocols between those native to WLAN networks and those native to LTE-A networks.

[0079] In some embodiments, the IRP agents 632, 626 and/or mapping engine 636 may be included in and/or implemented by an integrated circuit (IC), a chipset, or other collection of programmed and/or preconfigured circuitry.

[0080] In various embodiments, the mapping engine 636 may implement a mapping function (also referred to as a WLAN mapping function) to convert data between a first format generated and/or used by the WLAN APs 618, 620 of the WLAN to a second format that is used by the IRP manager 628 of the network manager 604 that manages the LTE-A network. For example, the IRP agent 632 may receive data from the WLAN AP 620, and the mapping engine 636 may convert the data from the first format to the second format. The IRP agent 632 may then send the data, in the second format, to the network manager 604 (e.g., to the IRP manager 628 of the network manager 604).

[0081] The mapping engine 636 may allow the network manager 604 and/or element manager 608 to retrieve data from the WLAN APs 618, 620. The data may be, for example, performance monitoring (PM) data (such as a value of one or more counters maintained by the WLAN AP 618, 620) and/or a status of one or more alarms maintained by the WLAN AP 618, 620. The network manager 604 and/or element manager 608 may use the data from the WLAN APs 618, 620 to manage the LTE-A network. For example, the network manager 604 and/or element manager 608 may maintain a network connection with the UE (e.g., not offload the UE to the WLAN) if the data from the WLAN AP 620 indicates that the WLAN AP 620 has a high UE number of connected UEs, is processing a large amount of network traffic volume, and/or is not functioning properly.

[0082] In various embodiments, the WLAN APs 618, 620 may maintain one or more counters (also referred to as PM counters) used to monitor performance of the WLAN APs 618, 620. The one or more counters may include, for example, one or more data volume counters to measure data volume on the WLAN interface. For example, the one or more data volume counters may include an input data volume counter that indicates an amount of data received (e.g., uplink data) by the individual WLAN AP 618, 620 via the WLAN interface. The input data volume counter may include, for example, an iflnOctets counter that tracks the total number of octets received on the WLAN interface, including framing characters.

[0083] Additionally, or alternatively, the one or more data volume counters may include an output data volume counter that indicates an amount of data transmitted (e.g., downlink data) by the individual WLAN AP 618, 620 via the WLAN interface. The output data volume counter may include, for example, an ifOutOctets counter that tracks the total number of octets transmitted on the WLAN interface.

[0084] In some embodiments, the one or more counters managed by the WLAN APs 618, 620 may additionally or alternatively include an associated UE counter to indicate a number of UEs associated with the individual WLAN AP 618, 620 (e.g., connected to the WLAN AP 618, 620 via the WLAN interface). The associated UE counter may include, for example, a dotl lAssociatedStationCount counter that increments when a UE (also referred to as a wireless station in common WLAN terminology) associates or reassociates with the WLAN AP 618, 620 and decrements when a UE disassociates.

[0085] In some embodiments, the one or more counters may additionally or alternatively include one or more media access control (MAC) data volume counters to measure the data volume on the MAC layer. For example, the one or more MAC data volume counters may include a dotl lTransmittedOctetsInAMPDUCount counter that is incremented by the number of octets in the Aggregated MAC Protocol Data Unit (A-MPDU) frame when an A-MPDU frame is transmitted by the WLAN AP 618, 620 and/or a dotl lReceivedOctetsInAMPDUCount counter that is incremented by the number of octets in the A-MPDU frame when an A-MPDU frame is received by the WLAN AP 618, 620. The MAC data volume counters may be status variables that are written by the MAC layer of the WLAN AP 618, 620 when an A-MPDU is transmitted and/or received.

[0086] In various embodiments, the IRP agent 632 of the element manager 608 may transmit a request to one or more of the WLAN APs 618, 620 to request counter data including the current value of one or more counters. The element manager 608 may receive the counter data from the one or more WLAN APs 618, 620 in the first format. The mapping engine 636 of the element manager 608 may convert the counter data to the second format and the IRP agent 632 may transmit the counter data to the IRP manager 628 of the network manager 604.

[0087] In some embodiments, the IRP agent 632 may transmit the request to the one or more WLAN APs 618, 620 responsive to a request received from the network manager 604. In other embodiments, the IRP agent 632 may proactively send the request to the one or more WLAN APs in anticipation of receiving the request from the network manager 604. In yet other embodiments, the network manager 604 may not send an explicit request for the counter data to the element manager 608 and the element manager 608 may periodically request the counter data from the WLAN APs and report the counter data to the network manager 604.

[0088] In some embodiments, the IRP agent 632 may request the counter data from the individual WLAN APs 618, 620 periodically to monitor a change in the value of the one or more counters over time. For example, the IRP agent 632 may periodically request the value of the iflnOctets counter to determine the input data volume per elapsed time. In various embodiments, one or more of the counters may increment from a value of 0 to a maximum value. When the counter reaches the maximum value, a subsequent increment of the counter may cause the counter to "wrap" and start over at 0. Accordingly, the value of the counter must be polled at least once per wrap cycle to get an accurate measurement of the change in the counter value over time.

[0089] In various embodiments, the IRP agent 632 may determine a time period between successive requests for the value of the counter based on a size of the counter (e.g., number of bits and/or possible values) and/or a speed with which the counter is incrementing. The speed of the counter may be determined based on a change in the value of the counter over time. The IRP agent 632 may determine the time period between successive requests so that the value of the counter is polled at least once per wrap cycle (e.g., the time period between successive wraps of the counter).

[0090] As an example, the iflnOctets counter may be a 32-bit counter in some embodiments. For a 10 Megabit/second (Mbs) data stream of back-to-back, full-size packets may cause the iflnOctets counter to wrap in slightly more than 57 minutes. However, for a 600Mbs data stream of back-to-back full-size packets, the iflnOctets counter may wrap in about 5.7 minutes. Additionally, for a 1 gigabit/second (Gbs) data stream of back-to-back full-size packets may cause the iflnOctets counter to wrap in about 34 seconds. Accordingly, the maximum time between successive requests for the counter value that is needed to poll the counter value at least once per wrap cycle may vary considerably depending on the data volume processed by the WLAN AP 618, 620.

[0091] Accordingly, the IRP agent 632 may determine a time period between successive requests for the value of the counter, based on the size of the counter and/or the speed with which the counter is incrementing, in order to ensure that the value of the counter is polled at least once per wrap cycle of the counter. This may allow the element manager 608 and/or network manager 604 to accurately calculate a change per elapsed time for the parameter tracked by the counter.

[0092] In some embodiments, adjusting the time period between successive counter polling requests by the element manager 608 may not be needed for some counters. For example, adjusting the time period between successive counter polling requests may not be needed for the associated UE counter, which increments when a UE associates or reassociates with the WLAN AP 618, 620 and decrements when a UE disassociates from the WLAN AP 618, 620.

[0093] As discussed above, the mapping engine 636 of the element manager 608 may also allow the network manager 604 to retrieve a status of an alarm that is managed by one of the WLAN APs 618, 620. The alarm may indicate, for example, an operating status of the WLAN AP to indicate if a network connection is available via the WLAN AP 618, 620 (e.g., whether or not the WLAN AP 618, 620 is able to pass data packets). For example, in some embodiments, the alarm may include an ifOperStatus alarm managed by the WLAN AP 618, 620 to indicate the operating status of the WLAN AP 618, 620. Additionally, or alternatively, some IEEE 802.11 counters maintained by the WLAN AP 618, 620 (e.g. dotl lFailedCount, dotl lRTSFailureCount, dotl lACKFailureCount, dotl lFCSErrorCount,

dotl lDeniedAssociationCounterDueToBSSLoad) may exceed certain thresholds that cause alarms to be generated.

[0094] In some embodiments, the IRP agent 632 of the element manager 608 may receive a request from the IRP manager 628 of the network manager 604 for the status of an alarm managed by the WLAN AP 618, 620. The mapping engine 636 may map the request into a format that will be understood by the WLAN AP 618, 620, and the IRP agent 632 may send a re-formatted request, for example a Simple Network Management Protocol (SNMP) GET message, to the WLAN AP 618, 620 to request the status of the alarm. The WLAN AP 618, 620 may process the request, retrieve the status of the alarm, and send a message to the IRP agent 632 with the status of the alarm. The mapping engine 636 may convert the message with the status of the alarm into a format that will be understood by the IRP agent 632 may transmit a message to the IRP manager 628 with the status of the alarm.

[0095] In various embodiments, the network manager 604 may use the data received from the WLAN APs 618, 620 (e.g., the values of one or more counters and/or the status of one or more alarms) to manage communications over the LTE-A network. For example, the network manager 604 may determine that the WLAN AP 618, 620 is overloaded based on a data volume per elapsed time (e.g., based on a change in the value of the iflnOctets counter over time) and/or the number of UEs connected to the WLAN AP 618, 620 (e.g., based on the value of the associated UE counter). Alternatively, the network manager 604 may determine that there is a problem with the WLAN AP 618, 620 if the associated UE counter indicates that no UEs are connected to the WLAN AP 618, 620. Furthermore, the network manager 604 may determine that there is a problem with the WLAN AP 618, 620 based on the status of one or more alarms managed by the WLAN AP 618, 620.

[0096] In some embodiments, the eNB 612 may maintain a connection with the UE via the LTE-A network based on a determination that the WLAN AP 618, 620 is overloaded and/or a determination that there is a problem with the WLAN AP 618, 620. Alternatively, the network manager 604 may decide to inform eNB 612, via element manager 610, that one or more UEs may be offloaded onto a specific WLAN AP 618, 620 (e.g., to switch the UE to being connected with the WLAN via the WLAN AP 618, 620 in addition to or instead of being connected to the LTE-A network via the eNB 612) based on a determination that the WLAN AP 618, 620 is operating effectively (e.g., is not overloaded and has a connection to the internet). In some embodiments, the eNB 610 may determine which UEs to offload to the WLAN AP 618, 620 and at what time.

[0097] In some embodiments, the network manager 604 may send a notification to an operator of the WLAN in response to the data received from the WLAN APs 618, 620. For example, the network manager 604 may notify the operator of the WLAN if the network manager 604 determines that the WLAN AP 618, 620 may not be functioning properly (e.g., no internet connection is available).

[0098] FIG. 7 is a process flow and data communications diagram illustrating a process for configuring components of a RAN for LWA operation according to some embodiments. The components include one or more WTs 516, 536, or 616, APs 510, 618, or 620, and eNBs 502, 522, 612, or 614. An operative configuration for LWA is achieved with support for mobility sets according to some embodiments by operations of network manager 604, and element managers 608 and 610. Notably, the hierarchical arrangement of network manager 604 and element managers 608, 610 allow a single command or set of commands at the network manager 604 to spawn a large plurality of commands by each of element managers 608, 610 to configure the corresponding APs, WTs, ENBs, or other devices.

[0099] LWA configuration is initiated by network manager 604 at 702, where the network manager 604 sends a request to element manager 608 to configure the WLAN APs 510, 618, or 620. The request is generally based on certain a priori knowledge about such items as the locations and unique identifiers of the APs, and for example, which APs are to be grouped into mobility sets. The a priori knowledge may form at least a portion of configuration data to be sent to element manager 608. In various embodiments network manager 604 may be operating at this stage under human-user control, autonomously under algorithmic control, or according to some combination thereof. For instance, IRP manager 628 of network manager 604 may be called by a human-user command, but may otherwise operate autonomously to interact with IRP agents 626, 632.

[0100] At 704, element manager 608 interacts with each AP 510, 618, 620 to configure the AP according to the configuration data provided by network manager 604. The configuration data may include BSSID, HESSID or SSID identifying information to be configured in each AP. At 706, element manager 608 creates, and maintains, an information object class (IOC) to represent each WLAN AP, and modifies the WLAN AP IOC as needed to reflect the AP configuration called for by network manager 604. In one embodiment the IOC is realized as a relational database. In another embodiment, the IOC is realized as a file system. In other embodiments, other data structuring forms may be used, such as lists, arrays, trees, etc. At 708, element manager 608 sends an acknowledgement to the network manager 604 after the successful completion of the AP configuration.

[0101] At 710, network manager 604 initiates configuration of WT 516, 536, or 616. This is accomplished by sending a WT-configuration request to EM 610, which is associated with the WT(s). In a related embodiment, there may be one or more additional element managers that are associated with WTs to be configured, in which case network manager 604 would send a corresponding WT-configuration request to each such additional element manager. The configuration request may include configuration data that is based at least in part on the a priori knowledge, and may include the IP address and identifiers of a list of LAN APs, including BSSID,

HESSID SSID, and other information that are needed for running Xw-AP protocol.

[0102] At 712, element manager 610 interacts with each WT 516, 536, 616 to configure the WT according to the configuration data provided by network manager 604. At 714, element manager 610 creates and maintains an IOC to represent each WT, and modifies the WT IOC to reflect the WT configuration.

[0103] Upon successful completion of the WT configuration by element manager 610, element manager 610 sends network manager 604 ab acknowledgement at 616.

[0104] The mobility sets are configured into eNBs 502, 612, 522, or 614 in operations 718-732, which are detailed as follows. At 718, network manager 604 sends a request to element manager 610 calling for configuring the mobility sets in first eNB 502, 612. At 720, element manager 610 interacts with the first eNB 502, 612 to configure the mobility sets in accordance with the request from the network manager 604. For example, mobility set 506 (containing APs { 1, 2, 3, 4, 5, 6}), mobility set 508 (containing APs {4, 5, 6, 7, 8, 9}), and mobility set 530 (containing APs { 1, 2, 3 }) may be defined. It may include the IP address of WT where the list of WLAN APs belonging to this mobility set is connected, and other information essential for the eNB to communicate with the WT via the Xw-C protocol.

[0105] At 722, element manager 610 creates and maintains an IOC to represent the mobility sets, and modifies the WLAN AP IOC to reflect the mapping of mobility sets to the APs and to the first eNB. At724, upon successful completion of the mobility set configuration for the first eNB, element manager 610 sends an acknowledgement to network manager 604.

[0106] At 726, a similar process to configure mobility sets for second eNB 522, 614 is initiated. Network manager 604 sends a request to element manager 610 to configure the mobility sets in second eNB 522, 614. At 728, element manager 610 interacts with the second eNB 522, 614 to configure the mobility sets in accordance with the request from the network manager 604. For example, mobility set 526 (containing APs { 10, 11, 12, 13, 14, 15 }), mobility set 508 (containing APs { 16, 17, 18, 19, 20, 21 }), and mobility set 530 (containing APs { 13, 14, 15 }) may be defined. It may include the IP address of WT where the list of WLAN APs belonging to this mobility set is connected, and other information essential for eNB to communicate with the WT via the Xw-C protocol.

[0107] At 730, element manager 610 modifies the WLAN AP IOC to reflect the mapping of mobility sets to the APs and to the second eNB. At 732, upon successful completion of the mobility set configuration for the second eNB, element manager 610 sends an acknowledgement to network manager 604.

[0108] As a result of operations 718-732, element manager 610 is configured with an IOC containing a configuration set that associates, or maps, each eNB with corresponding APs and mobility sets of APs.

[0109] In an embodiment, the mobility set configuration information for each eNB includes address information for the WT(s) associated with the eNB. Once the mobility sets are configured, a given eNB may establish LWA operation as follows, according to some embodiments. First, the Xw interface is established by the eNB using its knowledge of its corresponding WT's TNL (IP) address. Using the WT IP (TNL) address, the eNB establishes a stream control transmission protocol (SCTP) connection to the WT as defined, for instance, in the 3GPP TS 36.462 standard, ver. 13.0.0. Once the SCTP connection is established, the eNB initiates an Xw setup procedure by sending an XW SETUP REQUEST message and receiving the XW SETUP RESPONSE message. The eNB receives a WT identifier in the XW SETUP RESPONSE message.

[0110] Once the Xw interface is established, the eNB may schedule WLAN measurements to the UE. When the UE finds suitable WLANs, it reports their identifiers (e.g., BSSID, HESSID or SSID) to the eNB. The eNB maps the WLAN identifier to the WT identifier. Once the eNB has identified the WT controlling the reported WLAN AP, it may initiate an LWA activation procedure defined in the in the 3GPP TS 36.300 specification, ver. 13.2.0, for example).

[00111] Additional notes and examples:

[0112] Example 1 is apparatus of a radio access network (RAN) that supports long- term evolution (LTE) and wireless local area network (WLAN) aggregation (LWA), the apparatus comprising: memory; and processing circuitry to configure an element management entity to: receive mobility- set configuration messaging that calls for configuration of a mobility set of WLAN access points (APs) operatively coupled with an evolved node-B (eNB), wherein the mobility set defines a set of APs among which a user equipment (UE) is to vary AP connectivity independently of any connectivity- variability control of the eNB; in response to the mobility-set configuration messaging: configure the eNB with a definition of the mobility set; and maintain a set of at least one record that associates certain APs with the mobility set, and with the eNB.

[0113] In Example 2, the subject matter of Example 1 optionally includes wherein the set of APs of the mobility set include a WLAN mobility engine that facilitates UE movement and handoff of UE connections among the set of APs.

[0114] In Example 3, the subject matter of any one or more of Examples 1-2 optionally include wherein the mobility-set configuration messaging is received from a network manager entity.

[0115] In Example 4, the subject matter of any one or more of Examples 1-3 optionally include wherein the processing circuitry is to further configure the apparatus to: receive WT-configuration messaging that calls for configuration of a WLAN termination (WT) entity; and in response to the WT-configuration messaging: configure the WT entity with WT-configuration settings supplied in the WT-configuration messaging.

[0116] In Example 5, the subject matter of any one or more of Examples 1-4 optionally include wherein the set of at least one record includes an information object class (IOC).

[0117] In Example 6, the subject matter of any one or more of Examples 1-5 optionally include wherein the processing circuitry is to further configure the apparatus to: configure the eNB with WLAN neighbor relation information, including: a WLAN termination (WT) identifier, an address of a WT entity associated with the eNB, and a list of APs available within a coverage area of the eNB.

[0118] In Example 7, the subject matter of any one or more of Examples 1-6 optionally include wherein the processing circuitry is to further configure the element management entity to: configure the eNB with definitions of a plurality of mobility sets.

[0119] In Example 8, the subject matter of any one or more of Examples 1-7 optionally include wherein the processing circuitry is to further configure the element management entity to: configure the eNB with an association to a plurality of WLAN termination (WT) entities.

[0120] In Example 9, the subject matter of any one or more of Examples 1-8 optionally include wherein the apparatus is a part of an element manager that is to provide a plurality of end-user functions for management of a set of related types of network elements.

[0121] Example 10 is a network manager to configure long-term evolution (LTE) and wireless local area network (WLAN) aggregation (LWA), in a radio access network (RAN) the network manager comprising: a computing platform including a user interface and a communication interface; wherein the computing platform is to originate configuration messaging in a RAN that includes an evolved node-B (eNB) having a coverage area, a plurality of WLAN access points (APs) within the coverage area, and a WLAN termination (WT) operatively coupled to the APs and to the eNB, with the WT to facilitate communication between the APs and the eNB; wherein the configuration messaging includes mobility-set configuration messaging that calls for configuration of a mobility set among at least a portion of the APs, and wherein the mobility set defines a set of APs among which a user equipment (UE) is to vary AP connectivity independently of any connectivity- variability control of the eNB; and the network manager to pass the mobility-set messaging to a first element manager to configure the eNB with a definition of the mobility set, and maintain a set of at least one record that associates the mobility set with corresponding APs and with the eNB.

[0122] In Example 11, the subject matter of Example 10 optionally includes wherein the set of at least one record includes an information object class (IOC).

[0123] In Example 12, the subject matter of any one or more of Examples 10-11 optionally include wherein the configuration messaging is to cause the first element manager to configure the eNB with WLAN neighbor relation information, including: a WLAN termination (WT) identifier, an address of a WT associated with the eNB, and a list of APs available within a coverage area of the eNB.

[0124] In Example 13, the subject matter of any one or more of Examples 10-12 optionally include wherein the first element manager is to: configure the eNB with definitions of a plurality of mobility sets.

[0125] In Example 14, the subject matter of any one or more of Examples 10-13 optionally include wherein the configuration messaging is to cause the first element manager configure the eNB with an association to a plurality of WLAN termination (WT) entities.

[0126] In Example 15, the subject matter of any one or more of Examples 10-14 optionally include wherein the computing platform is to originate AP-configuration messaging that calls for configuration of the APs; and the system further comprising a second element manager including a computing platform; and wherein the AP- configuration messaging is to cause the second element manager to configure the APs with at least system identification information.

[0127] In Example 16, the subject matter of any one or more of Examples 10-15 optionally include wherein the computing platform is to originate WT-configuration messaging that calls for configuration of the WT; and wherein the WT-configuration messaging is to cause the first element manager to configure the WT with WT- configuration settings supplied in the WT-configuration messaging.

[0128] Example 17 is a machine-readable medium comprising instructions that, when executed on an apparatus of a radio access network (RAN) that supports long- term evolution (LTE) and wireless local area network (WLAN) aggregation (LWA), configure the apparatus to: receive mobility-set configuration messaging that calls for configuration of a mobility set of WLAN access points (APs) operatively coupled with an evolved node-B (eNB) of the RAN, the mobility set defining a set of APs among which a user equipment (UE) is to vary AP connectivity independently of any connectivity- variability control of the eNB; and in response to the mobility-set configuration messaging: configure the eNB with a definition of the mobility set; and maintain a set of at least one record that associates certain APs with the mobility set, and with the eNB.

[0129] In Example 18, the subject matter of Example 17 optionally includes wherein the instructions are to cause the apparatus to receive the mobility-set configuration messaging from a network manager entity.

[0130] In Example 19, the subject matter of any one or more of Examples 17-18 optionally include wherein the instruction are to further configure the apparatus to: receive WT-configuration messaging that calls for configuration of a WLAN termination (WT) entity; and in response to the WT-configuration messaging:

configure the WT entity with WT-configuration settings supplied in the WT- configuration messaging.

[0131] In Example 20, the subject matter of any one or more of Examples 17-19 optionally include wherein the set of at least one record includes an information object class (IOC).

[0132] In Example 21, the subject matter of any one or more of Examples 17-20 optionally include wherein the instructions are to further configure the apparatus to: configure the eNB with WLAN neighbor relation information, including: a WLAN termination (WT) identifier, an address of a WT entity associated with the eNB, and a list of APs available within a coverage area of the eNB.

[0133] In Example 22, the subject matter of any one or more of Examples 17-21 optionally include wherein the instructions are to further configure the apparatus to: configure the eNB with definitions of a plurality of mobility sets.

[0134] In Example 23, the subject matter of any one or more of Examples 17-22 optionally include wherein the instructions are to further configure the apparatus to: configure the eNB with an association to a plurality of WLAN termination (WT) entities.

[0135] Example 24 is a machine-readable medium comprising instructions that, when executed on a network manager processor, cause the network manager processor to: configure long-term evolution (LTE) and wireless local area network (WLAN) aggregation (LWA), in a radio access network (RAN), including:

originating configuration messaging in a RAN that includes an evolved node-B (eNB) having a coverage area, a plurality of WLAN access points (APs) within the coverage area, and a WLAN termination (WT) entity operatively coupled to the APs and to the eNB, with the WT entity to facilitate communication between the APs and the eNB; wherein the configuration messaging includes mobility-set configuration messaging that calls for configuration of a mobility set among at least a portion of the APs, and wherein the mobility set defines a set of APs among which a user equipment (UE) is to vary AP connectivity independently of any connectivity- variability control of the eNB; and the instructions to cause the network manager processor to pass the mobility-set messaging to a first element manager entity to configure the eNB with a definition of the mobility set, and maintain a set of at least one record that associates the mobility set with corresponding APs and with the eNB.

[0136] In Example 25, the subject matter of Example 24 optionally includes wherein the set of at least one record includes an information object class (IOC).

[0137] In Example 26, the subject matter of any one or more of Examples 24-25 optionally include wherein the configuration messaging is to cause the first element manager entity to configure the eNB with WLAN neighbor relation information, including: a WLAN termination (WT) identifier, an address of a WT entity associated with the eNB, and a list of APs available within a coverage area of the eNB.

[0138] In Example 27, the subject matter of any one or more of Examples 24-26 optionally include wherein the configuration messaging is to cause the first element manager configure the eNB with an association to a plurality of WLAN termination (WT) entities.

[0139] In Example 28, the subject matter of any one or more of Examples 24-27 optionally include wherein the instructions are to cause the network manager processor to originate AP-configuration messaging that calls for configuration of the APs; and wherein the AP-configuration messaging is to cause a second element manager entity to configure the APs with at least system identification information.

[0140] In Example 29, the subject matter of any one or more of Examples 24-28 optionally include wherein the instructions are to cause the network manager processor to originate WT-configuration messaging that calls for configuration of the WT entity; and wherein the WT-configuration messaging is to cause the first element manager to configure the WT entity with WT-configuration settings supplied in the WT-configuration messaging.

[0141] Example 30 is apparatus of a radio access network (RAN) that supports long-term evolution (LTE) and wireless local area network (WLAN) aggregation (LWA), the apparatus comprising: means for receiving mobility- set configuration messaging that calls for configuration of a mobility set of WLAN access points (APs) operatively coupled with an evolved node-B (eNB) of the RAN, the mobility set defining a set of APs among which a user equipment (UE) is to vary AP connectivity independently of any connectivity- variability control of the eNB; and means for configuring the eNB with a definition of the mobility set in response to the mobility-set configuration messaging; and means for maintaining a set of at least one record that associates certain APs with the mobility set, and with the eNB in response to the mobility-set configuration messaging.

[0142] In Example 31 , the subject matter of Example 30 optionally includes means for receiving the mobility-set configuration messaging from a network manager entity.

[0143] In Example 32, the subject matter of any one or more of Examples 30-31 optionally include means for receiving WT-configuration messaging that calls for configuration of a WLAN termination (WT) entity; and means for configuring the WT entity with WT-configuration settings supplied in the WT-configuration messaging.

[0144] In Example 33, the subject matter of any one or more of Examples 30-32 optionally include wherein the set of at least one record includes an information object class (IOC).

[0145] In Example 34, the subject matter of any one or more of Examples 30-33 optionally include means for configuring the eNB with WLAN neighbor relation information, including: a WLAN termination (WT) identifier, an address of a WT entity associated with the eNB, and a list of APs available within a coverage area of the eNB.

[0146] In Example 35, the subject matter of any one or more of Examples 30-34 optionally include means for configuring the eNB with definitions of a plurality of mobility sets. [0147] In Example 36, the subject matter of any one or more of Examples 30-35 optionally include means for configuring the eNB with an association to a plurality of WLAN termination (WT) entities.

[0148] Example 37 is a network manager, comprising: means for configuring long- term evolution (LTE) and wireless local area network (WLAN) aggregation (LWA), in a radio access network (RAN), including: means for originating configuration messaging in a RAN that includes an evolved node-B (eNB) having a coverage area, a plurality of WLAN access points (APs) within the coverage area, and a WLAN termination (WT) entity operatively coupled to the APs and to the eNB, with the WT entity to facilitate communication between the APs and the eNB; wherein the configuration messaging includes mobility-set configuration messaging that calls for configuration of a mobility set among at least a portion of the APs, and wherein the mobility set defines a set of APs among which a user equipment (UE) is to vary AP connectivity independently of any connectivity- variability control of the eNB; means for passing the mobility-set messaging to a first element manager entity to configure the eNB with a definition of the mobility set; and means for maintaining a set of at least one record that associates the mobility set with corresponding APs and with the eNB.

[0149] In Example 38, the subject matter of Example 37 optionally includes wherein the set of at least one record includes an information object class (IOC).

[0150] In Example 39, the subject matter of any one or more of Examples 37-38 optionally include wherein the configuration messaging is to cause the first element manager entity to configure the eNB with WLAN neighbor relation information, including: a WLAN termination (WT) identifier, an address of a WT entity associated with the eNB, and a list of APs available within a coverage area of the eNB.

[0151] In Example 40, the subject matter of any one or more of Examples 37-39 optionally include wherein the configuration messaging is to cause the first element manager configure the eNB with an association to a plurality of WLAN termination (WT) entities.

[0152] In Example 41, the subject matter of any one or more of Examples 37-40 optionally include means for originating AP-configuration messaging that calls for configuration of the APs; and wherein the AP-configuration messaging is to cause a second element manager entity to configure the APs with at least system

identification information.

[0153] In Example 42, the subject matter of any one or more of Examples 37-41 optionally include means for originating WT-configuration messaging that calls for configuration of the WT entity, wherein the WT-configuration messaging is to cause the first element manager to configure the WT entity with WT-configuration settings supplied in the WT-configuration messaging.

[0154] Example 43 is apparatus of an evolved node-B (eNB) configurable for long- term evolution (LTE) and wireless local area network (WLAN) aggregation (LWA), the apparatus comprising: memory; and processing circuitry to configure the eNB to: receive mobility-set configuration messaging from an element manager entity, the mobility-set configuration messaging being based on at least one record that associates eNBs with specific APs and with defined mobility sets, as maintained by the element manager entity, wherein the mobility sets define corresponding sets of APs among which a user equipment (UE) is to vary AP connectivity independently of any connectivity- variability control of any eNB; and in response to the mobility- set configuration messaging, store a mobility-set configuration that identifies a first set of WLAN access points (APs) within a coverage area of the eNB, at least one WLAN termination (WT) entity through which the eNB is to communicate with the first set of APs, and at least one mobility set definition that associates at least one subset of the APs with a mobility set.

[0155] In Example 44, the subject matter of Example 43 optionally includes wherein the processing circuitry is to further configure the eNB to: in response to the mobility- set configuration messaging, configure the eNB with WLAN neighbor relation information, including: a WLAN termination (WT) identifier, an address of a WT entity associated with the eNB, and a list of APs available within a coverage area of the eNB.

[0156] In Example 45, the subject matter of any one or more of Examples 43-44 optionally include transceiver circuitry operatively coupled to the processing circuitry; and an antenna operatively coupled to the transceiver circuitry.

[0157] In Example 46, the subject matter of any one or more of Examples 43-45 optionally include wherein the eNB is a radio access network (RAN) base station.

[0158] The above detailed description includes references to the accompanying drawings, which form a part of the detailed description. The drawings show, by way of illustration, specific embodiments that may be practiced. These embodiments are also referred to herein as "examples." Such examples may include elements in addition to those shown or described. However, also contemplated are examples that include the elements shown or described. Moreover, also contemplated are examples using any combination or permutation of those elements shown or described (or one or more aspects thereof), either with respect to a particular example (or one or more aspects thereof), or with respect to other examples (or one or more aspects thereof) shown or described herein.

[0159] Publications, patents, and patent documents referred to in this document are incorporated by reference herein in their entirety, as though individually incorporated by reference. In the event of inconsistent usages between this document and those documents so incorporated by reference, the usage in the incorporated reference(s) are supplementary to that of this document; for irreconcilable inconsistencies, the usage in this document controls.

[0160] In this document, the terms "a" or "an" are used, as is common in patent documents, to include one or more than one, independent of any other instances or usages of "at least one" or "one or more." In this document, the term "or" is used to refer to a nonexclusive or, such that "A or B" includes "A but not B," "B but not A," and "A and B," unless otherwise indicated. In the appended claims, the terms "including" and "in which" are used as the plain-English equivalents of the respective terms "comprising" and "wherein." Also, in the following claims, the terms "including" and "comprising" are open-ended, that is, a system, device, article, or process that includes elements in addition to those listed after such a term in a claim are still deemed to fall within the scope of that claim. Moreover, in the following claims, the terms "first," "second," and "third," etc. are used merely as labels, and are not intended to suggest a numerical order for their objects.

[0161] The above description is intended to be illustrative, and not restrictive. For example, the above-described examples (or one or more aspects thereof) may be used in combination with others. Other embodiments may be used, such as by one of ordinary skill in the art upon reviewing the above description. The Abstract is to allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. Also, in the above Detailed Description, various features may be grouped together to streamline the disclosure. However, the claims may not set forth every feature disclosed herein as embodiments may feature a subset of said features. Further, embodiments may include fewer features than those disclosed in a particular example. Thus, the following claims are hereby incorporated into the Detailed Description, with a claim standing on its own as a separate embodiment. The scope of the embodiments disclosed herein is to be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.

Claims

CLAIMS What is claimed is:

1. Apparatus of a radio access network (RAN) that supports long-term evolution (LTE) and wireless local area network (WLAN) aggregation (LWA), the apparatus comprising:

memory; and

processing circuitry to configure an element management entity to:

receive mobility-set configuration messaging that calls for configuration of a mobility set of WLAN access points (APs) operatively coupled with an evolved node-B (eNB), wherein the mobility set defines a set of APs among which a user equipment (UE) is to vary AP connectivity independently of any connectivity- variability control of the eNB;

in response to the mobility-set configuration messaging:

configure the eNB with a definition of the mobility set; and maintain a set of at least one record that associates certain APs with the mobility set, and with the eNB.

2. The apparatus of claim 1, wherein the set of APs of the mobility set include a WLAN mobility engine that facilitates UE movement and handoff of UE connections among the set of APs.

3. The apparatus of claim 1, wherein the mobility-set configuration messaging is received from a network manager entity.

4. The apparatus of claim 1, wherein the processing circuitry is to further configure the apparatus to:

receive WT-configuration messaging that calls for configuration of a WLAN termination (WT) entity; and

in response to the WT-configuration messaging:

configure the WT entity with WT-configuration settings supplied in the WT-configuration messaging.

5. The apparatus according to any one of claims 1-4, wherein the set of at least one record includes an information object class (IOC).

6. The apparatus according to any one of claims 1-4, wherein the processing circuitry is to further configure the apparatus to:

configure the eNB with WLAN neighbor relation information, including: a WLAN termination (WT) identifier, an address of a WT entity associated with the eNB, and a list of APs available within a coverage area of the eNB.

7. The apparatus according to any one of claims 1-4, wherein the processing circuitry is to further configure the element management entity to:

configure the eNB with definitions of a plurality of mobility sets.

8. The apparatus according to any one of claims 1-4, wherein the processing circuitry is to further configure the element management entity to:

configure the eNB with an association to a plurality of WLAN termination (WT) entities.

9. The apparatus according to any one of claims 1-4, wherein the apparatus is a part of an element manager that is to provide a plurality of end-user functions for management of a set of related types of network elements.

10. A machine-readable medium comprising instructions that, when executed on an apparatus of a radio access network (RAN) that supports long-term evolution (LTE) and wireless local area network (WLAN) aggregation (LWA), configure the apparatus to:

receive mobility-set configuration messaging that calls for configuration of a mobility set of WLAN access points (APs) operatively coupled with an evolved node-B (eNB) of the RAN, the mobility set defining a set of APs among which a user equipment (UE) is to vary AP connectivity independently of any connectivity- variability control of the eNB; and

in response to the mobility-set configuration messaging:

11. The machine-readable medium of claim 10, wherein the instructions are to cause the apparatus to receive the mobility-set configuration messaging from a network manager entity.

12. The machine-readable medium of claim 10, wherein the instruction are to further configure the apparatus to:

in response to the WT-configuration messaging:

13. The machine-readable medium according to any one of claims 10-12, wherein the set of at least one record includes an information object class (IOC).

14. The machine-readable medium according to any one of claims 10-12, wherein the instructions are to further configure the apparatus to:

15. The machine-readable medium according to any one of claims 10-12, wherein the instructions are to further configure the apparatus to:

configure the eNB with definitions of a plurality of mobility sets.

16. The machine-readable medium according to any one of claims 10-12, wherein the instructions are to further configure the apparatus to:

17. Apparatus of an evolved node-B (eNB) configurable for long-term evolution (LTE) and wireless local area network (WLAN) aggregation (LWA), the apparatus comprising:

memory; and

processing circuitry to configure the eNB to:

receive mobility-set configuration messaging from an element manager entity, the mobility-set configuration messaging being based on at least one record that associates eNBs with specific APs and with defined mobility sets, as maintained by the element manager entity, wherein the mobility sets define corresponding sets of APs among which a user equipment (UE) is to vary AP connectivity independently of any

connectivity- variability control of any eNB; and

in response to the mobility-set configuration messaging, store a mobility- set configuration that identifies a first set of WLAN access points (APs) within a coverage area of the eNB, at least one WLAN termination (WT) entity through which the eNB is to communicate with the first set of APs, and at least one mobility set definition that associates at least one subset of the APs with a mobility set.

18. The apparatus of claim 17, wherein the processing circuitry is to further configure the eNB to:

in response to the mobility-set configuration messaging, configure the eNB with WLAN neighbor relation information, including: a WLAN termination (WT) identifier, an address of a WT entity associated with the eNB, and a list of APs available within a coverage area of the eNB.

19. The apparatus according to any one of claims 17-18, further comprising: transceiver circuitry operatively coupled to the processing circuitry; and an antenna operatively coupled to the transceiver circuitry.

20. The apparatus according to any one of claims 17-18, wherein the eNB is a radio access network (RAN) base station.