EP3266167A1

EP3266167A1 - Opportunistic access of millimeterwave radio access technology based on edge cloud mobile proxy

Info

Publication number: EP3266167A1
Application number: EP16711727.4A
Authority: EP
Inventors: Geng Wu; Qian Li; Huaning Niu; Apostolos Papathanassiou
Original assignee: Intel IP Corp
Current assignee: Intel IP Corp
Priority date: 2015-03-04
Filing date: 2016-03-03
Publication date: 2018-01-10
Also published as: JP2018511224A; JP6896640B2; CN107211321A; WO2016141213A1; HK1244150A1; CN107211321B

Abstract

Embodiments of the present disclosure describe methods and apparatuses for opportunistic access of millimeterwave (mmWave) radio access technology based on edge cloud mobile proxy. Other embodiments may be described or claimed.

Description

OPPORTUNISTIC ACCESS OF MILLIMETERWAVE RADIO ACCESS TECHNOLOGY BASED ON EDGE CLOUD MOBILE PROXY

Cross Reference to Related Applications

The present application claims priority to U.S. Provisional Application No.

62/128,009, filed March 4, 2015 and entitled "OPPORTUNISTIC ACCESS OF 5G MMWAVE RAT BASED ON EDGE CLOUD MOBILE PROXY," the entire disclosure of which is hereby incorporated by reference for all purposes.

Field

Embodiments of the present disclosure generally relate to the field of wireless communication, and more particularly, to apparatuses and methods for controlling opportunistic access of spectrum of a radio air interface.

Background

Next-generation wireless communications systems may be expected to exploit wireless spectrum in frequency bands above 6 gigahertz (GHz). Channels in frequency bands above 6 GHz may generally be referred to as millimeter-wave (mmWave) channels. An mmWave channel may appear to switch on and off due to features of the mmWave channels such as, but not limited to, high path loss and quasi-optical propagation. When an mmWave channel is on, a communication link over the channel may observe a high throughput rate. When the mmWave channel is off, the communication link may be lost. In various scenarios, the on-and-off dynamic may depend on the communication environment and the deployment of the mmWave base stations. In many high-interest communication scenarios, such as street canyons, city squares, offices, and shopping malls, the channel on-off frequency and the duration of the off period can be on the scale of seconds.

While the use of mmWave channels has the potential to increase overall data rates supported by wireless communication systems, the integration of the mmWave channels may need to be improved to provide reliable communications.

Brief Description of the Drawings

Embodiments will be readily understood by the following detailed description in conjunction with the accompanying drawings. To facilitate this description, like reference numerals designate like structural elements. Embodiments are illustrated by way of example and not by way of limitation in the figures of the accompanying drawings. Figure 1 is a graph illustrating an example of channel dynamics of an mmWave channel in accordance with some embodiments.

Figure 2 illustrates a network communication environment in accordance with some embodiments.

Figure 3 illustrates electronic device circuitry in accordance with some

embodiments.

Figure 4 illustrates wireless communication circuitry in accordance with some embodiments.

Figure 5 illustrates an Ethernet controller in accordance with some embodiments. Figure 6 illustrates a computing device in accordance with some embodiments.

Figure 7 illustrates interaction of modules of communication protocol stacks of different devices in accordance with some embodiments.

Figure 8 is a schematic diagram of traffic and feedback flows in accordance with some embodiments.

Figure 9 illustrates a reporting procedure in accordance with some embodiments.

Figure 10 illustrates an opportunistic access operation in accordance with some embodiments.

Figure 11 is a flowchart illustrating a TCP rate control operation in accordance with some embodiments.

Figure 12 illustrates an opportunistic access operation in accordance with some embodiments.

Figure 13 illustrates an opportunistic access operation in accordance with some embodiments.

Figure 14 illustrates a flowchart of a TCP management operation in accordance with some embodiments.

Figure 15 illustrates an opportunistic access operation in accordance with some embodiments.

Figure 16 illustrates an example computer-readable media in accordance with some embodiments.

Detailed Description

In the following detailed description, reference is made to the accompanying drawings, which form a part hereof wherein like numerals designate like parts throughout, and in which is shown by way of illustration embodiments that may be practiced. It is to be understood that other embodiments may be utilized and structural or logical changes may be made without departing from the scope of the present disclosure.

Various operations may be described as multiple discrete actions or operations in turn, in a manner that is most helpful in understanding the claimed subject matter.

However, the order of description should not be construed as to imply that these operations are necessarily order dependent. In particular, these operations may not be performed in the order of presentation. Operations described may be performed in a different order than the described embodiment. Various additional operations may be performed or described operations may be omitted in additional embodiments.

For the purposes of the present disclosure, the phrase "A or B" means (A), (B), or

(A and B). For the purposes of the present disclosure, the phrase "A, B, or C" means (A), (B), (C), (A and B), (A and C), (B and C), or (A, B, and C).

The description may use the phrases "in an embodiment," or "in embodiments," which may each refer to one or more of the same or different embodiments. Furthermore, the terms "comprising," "including," "having," and the like, as used with respect to embodiments of the present disclosure, are synonymous.

Figure 1 is a graph 100 that illustrates an example of channel dynamics of an mmWave channel. In particular, the graph 100 illustrates channel gain in decibels (dB) over a period of time in which a user equipment (UE) is traveling.

Radio waves within the mmWave channel may have short wavelengths (for example, less than 500 mm) and may be associated with relatively high attenuation that may be caused by the radio waves being absorbed by atmospheric gases, rain, etc. The shorter wavelength of these radio waves may also increase diffuse reflection resulting in multipath propagation that may cause fading challenges. Furthermore, these radio waves may be associated with significant Doppler shift of frequency, even at pedestrian speeds. These propagation challenges of the radio waves in the mmWave channel may result in the channel periodically dropping out as briefly introduced above. For example, graph 100 shows that during a period that starts just after one second and continues to approximately six seconds, the mmWave channel may be on and may provide a significant channel gain, peaking at approximately -95 dB. However, just after the sixth second, the mmWave channel may turn off completely and may not be turned back on until close to the seventh second, at which time the channel gain of the mmWave channel may increase to approximately -105 dB. Thus, for a period of close to one second, the mmWave channel may be effectively off, dropping any communication links that were established over the channel.

The channel on-off effect illustrated by the graph 100 suggests that a different technique may be utilized for connectivity and traffic management in higher-frequency bands as compared to lower-frequency bands. Embodiments of the present disclosure provide that a connection may be maintained by radio access technologies (RATs) operating at lower-frequency bands, for example, below 6 GHz, while RATs operating at higher-frequency bands, for example, above 6 GHz, may opportunistically access channels when they are available. Embodiments describe a mobile proxy and traffic shaping that may be applied to turn an unstable opportunistic access link into a stable connection.

In the instant disclosure, example implementations of opportunistic access and traffic shaping by components of a wireless communication system, including, for example, a mobile proxy, are described.

In some embodiments, the opportunistic access and traffic shaping may be based on an anchor-booster architecture in which a relatively stable connection is provided by a macro evolved node B (Me B) while a relatively unstable, but high-capacity, connection is provided by a small-cell e B (Se B) to support an opportunistic communication link.

Some embodiments may additionally/alternatively include traffic control mechanisms implemented by a mobile proxy that may be in the core network. The mobile proxy may manage opportunistic links and traffic buffering at an edge cloud. An edge cloud, as used herein, is an entity of a core network that directly interfaces with an entity of the radio access network.

In various embodiments, a mobile proxy may terminate a transport layer to provide control of data transfer over a transport network. The mobile proxy may control the data transfer over the transport network and buffer UE traffic in order to reduce or avoid radio channel capacity fluctuation negatively affecting the network traffic. A transport network may refer to a network of devices connected at a transport layer, for example a

transmission control protocol (TCP) layer. The termination ends of the transport network may be the devices that perform the TCP layer operations, for example, a mobile proxy and a sending entity (for example, an application server). The transport network may traverse a core network to connect the termination ends.

The mobile proxy may manipulate the transport network traffic to fit the underlying radio access network capacity. The anchor eNB, for example, the MeNB, may maintain a radio resource control (RRC) connection with the UE. In various embodiments, the anchor e B or the mobile proxy may schedule opportunistic access of mmWave booster cells in the user-plane based on the traffic size, traffic type, quality of service (QoS) requirement and the mmWave radio link quality.

Even if the average network capacity at mmWave bands may be high, this high radio network data rate may not always be usable to the transport network due to dramatic radio link rate fluctuation caused by channel on-off effect described above. Thus, in this disclosure opportunistic access procedures in the edge cloud and the radio access network are described. Buffering and transport layer management in the edge cloud may help smooth out unstable opportunistic access links in the radio access network. With traffic manipulation and scheduling, the unstable opportunistic access link may be turned into a stable connection.

Figure 2 illustrates a network communication environment 200 in accordance with some embodiments. The network communication environment 200 (or simply

"environment 200") may include a core network (CN) device 204, which may include a mobile proxy 206, a macro evolved node B (Me B) 208, a small-cell evolved node B (Se B) 212, and a user equipment (UE) 216.

In some embodiments, the eNBs 208 and 212 may be part of an evolved universal terrestrial radio access network (E-UTRAN) that provides a radio air interface consistent with specifications and protocols developed by the 3rd Generation Partnership Project (3GPP) including, but not limited to, Long Term Evolution (LTE) Technical

Specifications (TSs).

As used herein, "LTE" may refer generically to releases associated with the original LTE, LTE-Advanced (LTE-A), 5G, etc. In other embodiments, the eNBs 208 and 212 may be part of other cellular systems such as, but not limited to, Global System for Mobile Communication (GSM), General Packet Radio Service (GPRS), Universal Mobile Telecommunications System (UMTS), High Speed Packet Access (HSPA), Evolved HSPA (E-HSPA), etc.

The CN device 204 may be part of a core network (or an evolved packet core (EPC) in system architecture evolution (SAE)) that is responsible for overall control of the UE and establishment of bearers, which may be IP packet flows with a defined quality of service (QoS). In some embodiments, the CN device 204 may be considered to be at an edge of the core network and may, therefore, be referred to as an edge cloud device. The CN device 204 may include a serving gateway (S-GW) that serves as a local mobility anchor for data bearers when the UE 216 is in an idle state and may temporarily buffer downlink data while a mobility management entity (MME) of the CN initiates paging of the UE 216 to reestablish bearers. The S-GW may also perform administrative functions in a visited network (for example, collecting data usage statistics for charging purposes).

In some embodiments, the CN device 204 may additionally/alternatively include one or more other logical nodes of the CN. For example, the CN device 204 may include a packet data network (PDN) gateway (P-GW) that is responsible for IP address allocation for the UE 216, as well as quality of service (QoS) enforcement and flow-based charging according to rules from a policy and charging rules function (PCRF). The CN device 204 may additionally/alternatively include an MME, which may be a control node that processes signaling between the UE 216 and the CN, for example, signaling based on non- access stratum (NAS) protocols. The MME may perform functions related to bearer management (for example, establishing, maintaining, and releasing bearers, as handled by the session management layer in the NAS protocol); related to connection management (for example, establishing connections and security between the CN and the UE 216, as handled by a connection or mobility management layer in the NAS protocol layer); or related to interworking with other networks.

As will be described in further detail, the CN device 204 may include the mobile proxy 206 to manage transport layer connections at the edge of the CN to facilitate reliable communication over the radio air interface. In some embodiments, the mobile proxy 206 may employ buffering and may manage transport layer functions of the core network. For example, the mobile proxy 206 may receive traffic from a sending entity over a connection of the transport network that traverses a core network (in which the CN device 204 is disposed). The mobile proxy 206 may buffer the traffic in memory circuitry of the CN device 204 and may cause the traffic to be transmitted to eNBs of the radio access network (for example, MeNB 208 or SeNB 212) over a connection that traverses the radio access network. The scheduling of the exact link or links over which the traffic will be transmitted may be determined by scheduling logic at the mobile proxy 206 or the MeNB 208.

The mobile proxy 206 may receive information about the capacity of the links 220 and 224 and may control a data rate of the transport network over which the traffic was received. In this manner, the mobile proxy 206, operating as an edge cloud device, may effectively manage the transport network and may at least participate in the effective transfer of the data over the links of the air interface. The environment 200 may have a number of interfaces that specify signaling procedures and message types that may be transmitted between different entities. The eNBs may communicate with the UE 216 over a Uu interface; the eNBs may

communicate with one another over an X2 interface; the eNBs may communicate with the mobile proxy over an SI interface; and an SGW may communicate with a PGW over an S5/S8 interface.

The MeNB 208 may be a relatively high-power cellular base station that provides radio coverage for UEs over a relatively large coverage area. For example, in some embodiments the MeNB 208 may provide radio coverage over distance of 1-20 kilometers (km). In some embodiments, the MeNB 208 may have power outputs of tens of watts.

The SeNB 212 may be a relatively low-power cellular base station that provides radio coverage for UEs over a relatively small coverage area, as compared to the MeNB 208. For example, in some embodiments the SeNB 212 may provide radio coverage over a distance of less than 1000 meters (m). In some embodiments, the SeNB 212 may have power outputs of less than a few watts. The SeNB 212 may be referred to as a microcell, picocell, or femto cell eNB in various embodiments.

The MeNB 208 may implement a first RAT operating at lower-frequency bands, for example, below 6 GHz, to support a first communication link with the UE 216. The first communication link may also be referred to as an anchor link and may provide a baseline connection for signaling and data exchange between the UE 216 and the network.

The lower-frequency bands may include evolved universal terrestrial radio access (E-UTRA) operating bands 1-5, 7-14, 17-4, 65, 66 utilized for frequency division duplexing (FDD), or E-UTRA operating bands 33-45 utilized for time division duplexing (TDD). These E-UTRA operating bands may have frequency bands between

approximately 700 MHz and 3700 MHz. In other embodiments, other frequency bands may be used such as, but not limited to, Global System for Mobile Communications (GSM) frequency bands, Universal Mobile Telecommunications System (UMTS) frequency bands, etc. that may or may not use RATs of other types of networks, for example, High-Speed Downlink Packet Access (HSDPA) networks, UMTS networks, worldwide interoperability for microwave access (WiMAX) networks, etc.

The SeNB 212 may implement a second RAT operating at higher-frequency bands, for example, above 6 GHz, to support a second communication link with the UE 216. The second communication link may also be referred to as a booster link and may, when available, provide additional resources for exchanging data between the UE 216 and the network.

The higher-frequency bands may have radio waves with wavelengths from approximately 500 mm to 1 mm. For purposes of the present description, this range of wavelengths may be referred to as "mmWave" wavelengths. The higher-frequency bands may, in some embodiments, include a millimeter band as described by the Institute of Electrical and Electronics Engineers (IEEE) (having a frequency range of 110-300 GHz and wavelength range of 2.73 mm to 1 mm), International Telecommunication Union (ITU) radio band 10 (from 6 to 30 GHz), or ITU radio band 11 (from 30 to 300 GHz).

Each of the communication links may include a number of different transmission layers (used in, for example, multiple input, multiple output (MIMO) communication) or a number of different carriers (used in, for example, a carrier aggregation environment). Furthermore, additional e Bs, transmission points, or remote radio heads may be deployed in coordinated multi-point scenarios. In general, the described embodiments may be incorporated into a variety of cellular network deployments consistent with the description provided herein.

Two different kinds of data flows may be differentiated in the communication in the environment 200. A first data flow, which may be referred to as a user plane (U-plane), may include data that is directly and transparently exchanged between users of an end-to- end connection, for example, voice data or Internet protocol (IP) packets. A second data flow, which may be referred to as a control plane (C-plane), may include signaling information that is exchanged between the users and the network. Thus, the C-plane may be used for signaling information to exchange messages for call establishment or messages, for example, for a location update.

The X2 interface between the Me B 208 and the Se B 212 may allow both C- and U-plane signaling; the SI interface between the MeNB 208 and the mobile proxy 206 may allow both C-and U-plane signaling; and the SI interface between the SeNB 212 and the mobile proxy 206 may allow U-plane signaling.

In some embodiments, a C-plane connection of the SeNB 212 may be anchored at the MeNB 208; and a C-plane connection of the MeNB 208 may be anchored at the mobile proxy 206. Thus, the SeNB 212 may exchange signaling information with the network through the MeNB 208, and the MeNB 208 may directly exchange signaling information with the network. In some embodiments, a U-plane connection of the SeNB 212 may be with the MeNB 208 or the mobile proxy 206 of the CN device 204.

Figure 3 illustrates electronic device circuitry 300 in accordance with some embodiments. The electronic device circuitry 300 may be, may implement, may be incorporated into, or may otherwise be a part of, an eNB (for example, the MeNB 208 or the SeNB 212), the CN device 204, or the UE 216. In embodiments, the electronic device circuitry 300 may include communication circuitry 304. The communication circuitry 304 may include control circuitry 308, transceiver circuitry 312 that includes both transmit circuitry 316 and receive circuitry 320, and media interface circuitry 324.

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 execute 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 electronic device circuitry 300 may be implemented in, or functions associated with the circuitry may be implemented by, one or more software or firmware modules.

The media interface circuitry 324 may include circuit elements that are configured to communicatively couple the transceiver circuitry 312 with a wired or wireless communication medium. In some embodiments, the media interface circuitry 324 may include radio frequency front-end components that may include one or more antenna elements, as generally shown (for transmission/reception of signals over a wireless medium), amplifiers, filters, etc. In other embodiments, the media interface circuitry 324 may include components for interfacing with other networks. For example, in some embodiments, the media interface circuitry 324 may include an Ethernet interface, for example, ports or other media interfaces such as, but not limited to, coaxial, twisted pair, or fiber-optic physical media interfaces.

The transceiver circuitry 312 may couple the control circuitry 308 with the media interface circuitry 324. The transceiver circuitry 312 may receive signals from the control circuitry 308 and perform various signal processing functions to prepare the signals for transmission over an appropriate communication medium by the media interface circuitry 324. The transceiver circuitry 312 may also receive signals from the media interface circuitry 324 and perform various signal processing functions to prepare the signals for transmission to the control circuitry 308. In embodiments in which the electronic device circuitry 300 interfaces with a wireless communication media of, for example, the Uu interface, the communication circuitry 304 may include radio-frequency, mixed-signal, and analog portions and a baseband portion that uses one or more digital signal processors (DSPs) and

communication algorithm processing including channel codes. This embodiment is described in further detail with respect to Figure 4.

In embodiments in which the electronic device circuitry 300 interfaces with a wired communication medium of, for example, the SI, X2, or S5/S8 interfaces, the communication circuitry 304 may provide signal processing according to the appropriate communication network protocols. For example, the communication circuitry 304 may include an Ethernet controller that implements Ethernet protocols of, for example, 10 Gigabit Ethernet, 1000BASE-T, 100BASE-TX, or 10BASE-T standards. This

embodiment is described in further detail with respect to Figure 5.

The control circuitry 308 may include circuitry to perform link layer (for example, media access control (MAC) layer) and higher-layer operations to facilitate

communication over appropriate networks. In some embodiments, digital physical layer (PHY) operations may be performed by the control circuitry 308, as well, with analog PHY operations being performed by the transceiver circuitry 312.

As will be described in further detail herein, the control circuitry 308 may operate to reduce radio channel capacity fluctuation in communications made between the core network and the UE. The control circuitry 308 may perform various access-network control operations to enable opportunistic access of communication links in a high- frequency band in a manner to reduce radio channel capacity fluctuation and provide reliable communication over the air interface. In particular, the access-network control operations may include traffic reporting, scheduling, buffering/caching, traffic shaping, rate control, etc. These operations will be described in further detail herein.

In some embodiments, the control circuitry 308 may include a variety of circuitry including, for example, processing and memory circuitry, to perform the operations described herein. In some embodiments, the control circuitry 308 may implement a mobile proxy to provide access-network control operations from a CN device such as, for example, CN device 204.

Figure 4 illustrates wireless communication circuitry 400 in accordance with some embodiments. The wireless communication circuitry 400 may be implemented in the electronic device circuitry 300 to provide wireless connectivity. For example, the wireless communication circuitry 400 may be used if the electronic device circuitry 300 is employed in MeNB 208, Se B 212, or UE 216 for communicating over the Uu interface.

The wireless communication circuitry 400 may include baseband circuitry 404, RF circuitry 406, front-end circuitry 408, and antenna 410 coupled with each other at least as shown. In general, the baseband circuitry 404 may be incorporated in the control circuitry 308, the RF circuitry 406 may be incorporated in the transceiver circuitry 312, and the front-end (FE) circuitry 408 may be incorporated in the media interface circuitry 324. However, it will be understood that some functions described with respect to one component may be implemented in another components in some embodiments.

The baseband circuitry 404 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The baseband circuitry 404 may include one or more baseband processors or control logic to process baseband signals received from a receive signal path of the RF circuitry 406 and to generate baseband signals for a transmit signal path of the RF circuitry 406. Baseband processing circuitry 404 may interface with the application circuitry (on a platform hosting the communication circuitry 400) for generation and processing of the baseband signals and for controlling operations of the RF circuitry 406. For example, in some embodiments, the baseband circuitry 404

may include a second generation (2G) baseband processor 404a, third generation (3G) baseband processor 404b, fourth generation (4G) baseband processor 404c, or fifth generation (5G) baseband processor 404d. Other embodiments may have other baseband processors for other existing generations, generations in development or generations to be developed in the future.

In some embodiments, the baseband circuitry 404, RF circuitry 406, FE circuitry 408, and the antenna 410 may have components specifically dedicated to wireless communications in the lower- or higher-frequency bands. For example, in some embodiments, the 4G baseband processor 404c may be used for communications in the lower-frequency bands, while the 5G baseband processor 404d may be used for communications in the higher-frequency bands.

The baseband circuitry 404 (for example, one or more of baseband processors 404a-d) may handle various radio control functions that enable communication with one or more radio networks via the RF circuitry 406. 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 404 may include Fast-Fourier Transform (FFT), precoding, or constellation mapping/demapping functionality. In some embodiments, encoding/decoding circuitry of the baseband circuitry 404 may include convolution, tail-biting convolution, turbo, Viterbi, or Low Density Parity Check (LDPC) encoder/decoder functionality.

Embodiments of modulation/demodulation and encoder/decoder functionality are not limited to these examples and may include other suitable functionality in other

embodiments.

In some embodiments, the baseband circuitry 404 may include elements of a protocol stack such as, for example, elements of an E-UTRAN protocol including, for example, PHY, MAC, radio link control (RLC), packet data convergence protocol

(PDCP), or radio resource control (RRC) elements. A central processing unit (CPU) 404e of the baseband circuitry 404 may be configured to run elements of the protocol stack for signaling of the PHY, MAC, RLC, PDCP or RRC layers. The layers of the protocol stack will be briefly described. The discussion of the protocol stack with respect to Figure 4 will be based primarily on the E-UTRA protocol stack, although some of the description may also correspond to non-E-UTRA protocol stacks.

The PHY layer may refer to the hardware transmission technologies of a network such as, for example, cabling, wiring, frequencies, pulses used to represent binary signals, etc. The PHY layer may carry all information from the MAC transport channels over the air interface and may handle link adaptation, power control, cell search (for initial synchronization and handover purposes) and other measurements for the RRC layer.

The MAC layer may provide addressing and channel access control mechanisms to enable terminals to communicate within a multiple access network using a shared medium. The MAC layer may connect with the physical layer through transport channels and connect with the RLC layer through logical channels. The MAC layer may perform multiplexing and demultiplexing between logical channels and transport channels and perform error correction through hybrid automatic repeat request (HARQ), dynamic scheduling, and channel prioritization. Multiple access protocols that may be used in packet radio wireless networks may include code division multiple access (CDMA) and orthogonal frequency division multiple access (OFDMA).

The RLC layer may communicate with the PDCP layer through a service access point (SAP) and with the MAC layer via logical channels. The RLC layer may operate in one of three modes: transparent mode (TM), unacknowledged mode (UM), and

acknowledged mode (AM). Depending on the mode, the RLC layer may perform various operations on RLC service data units (SDUs) and protocol data units (PDUs) such as, for example, error correction through automatic repeat request (ARQ); data transfer and concatenation segmentation, and reassembly of RLC SDUs; re-segmentation of RLC PDUs; duplicate detection; protocol error detection; etc.

The PDCP layer may perform header compression and decompression for user plane data; security functions (for example, ciphering and deciphering for user plane and control plane data, and integrity protection verification for control plane data); handover support functions (for example, in sequence delivery and reordering of higher-layer PDUs and losses handover for user plane data mapped on RLC AM mode); and discarding of user plane data due to timeout.

The RRC layer may be the primary layer responsible for controlling functions in the access stratum (AS). The RRC layer may establish radio bears and configure lower layers using RRC signaling between the UE and eNB. The RRC layer may provide for the broadcasting of system information, RRC connection control, network-controlled inter- RAT mobility, measurement configuration reporting, etc.

In some embodiments, the baseband circuitry may include one or more

audio digital signal processor(s) (DSP) 404f. The audio DSP(s) 404f may include elements for compression/decompression and echo cancellation and may include other suitable processing elements in other embodiments.

The baseband circuitry 404 may further include memory/storage 404g.

The memory/storage 404g may be used to load and store data or instructions for operations performed by the processors of the baseband circuitry 404. Memory/storage 404g for one embodiment may include computer-readable media embodied in any combination of suitable volatile memory or non-volatile memory. The memory/storage 404g may include any combination of various levels of memory/storage including, but not limited to, read-only memory (ROM) having embedded software instructions (e.g., firmware), random access memory (e.g., dynamic random access memory (DRAM)), cache, buffers, etc. The memory/storage 404g may be shared among the various processors or dedicated to particular processors.

Components of the baseband circuitry 404 may be suitably combined in a single chip or 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 404, the RF circuitry 406, or FE circuitry 408 may be implemented together, such as, for example, on a system on a chip (SOC). In some embodiments, the baseband circuitry 404 may provide for communication compatible with one or more RATs. For example, in some embodiments, the baseband circuitry 404 may support communication with an E-UTRAN or other wireless metropolitan area networks (WMANs), a wireless local area network (WLAN), a wireless personal area network (WPAN). In some embodiments, the baseband circuitry 404 may support communication using both high- and low-frequency bands. Embodiments in which the baseband circuitry 404 is configured to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband circuitry.

RF circuitry 406 may enable communication with wireless networks

using modulated electromagnetic radiation through a non-solid medium. In various embodiments, the RF circuitry 406 may include switches, filters, amplifiers, etc. to facilitate the communication with the wireless network. RF circuitry 406 may include a receive signal path that may include circuitry to down-convert RF signals received from the FE circuitry 408 and provide baseband signals to the baseband circuitry 404. RF circuitry 406 may also include a transmit signal path that may include circuitry to up- convert baseband signals provided by the baseband circuitry 404 and provide RF output signals to the FE circuitry 408 for transmission.

In some embodiments, the RF circuitry 406 may include a receive signal path and a transmit signal path. The receive signal path of the RF circuitry 406 may include mixer circuitry 406a, amplifier circuitry 406b and filter circuitry 406c. The transmit signal path of the RF circuitry 406 may include filter circuitry 406c and mixer circuitry 406a. RF circuitry 406 may also include synthesizer circuitry 406d for synthesizing a frequency for use by the mixer circuitry 406a of the receive signal path and the transmit signal path. In some embodiments, the mixer circuitry 406a of the receive signal path may be configured to down-convert RF signals received from the FE circuitry 408 based on the synthesized frequency provided by synthesizer circuitry 406d. The amplifier circuitry 406b may be configured to amplify the down-converted signals and the filter circuitry 406c 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 404 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 406a 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 406a of the transmit signal path may be configured to up-convert input baseband signals based on the synthesized frequency provided by the synthesizer circuitry 406d to generate RF output signals for the FE circuitry 408. The baseband signals may be provided by the baseband circuitry 404 and may be filtered by filter circuitry 406c. The filter circuitry 406c may include a low-pass filter (LPF), although the scope of the embodiments is not limited in this respect.

In some embodiments, the mixer circuitry 406a of the receive signal path and the mixer circuitry 406a 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 406a of the receive signal path and the mixer circuitry 406a 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 406a of the receive signal path and the mixer circuitry 406a of the transmit signal path may be arranged for direct downconversion or direct upconversion, respectively. In some embodiments, the mixer circuitry 406a of the receive signal path and the mixer circuitry 406a of the transmit signal path may be configured for super-heterodyne operation.

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 406 may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry and the baseband circuitry 404 may include a digital baseband interface to communicate with the RF circuitry 406.

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.

In some embodiments, the synthesizer circuitry 406d 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 406d may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer comprising a phase-locked loop with a frequency divider.

The synthesizer circuitry 406d may be configured to synthesize an output frequency for use by the mixer circuitry 406a of the RF circuitry 406 based on a frequency input and a divider control input. In some embodiments, the synthesizer circuitry 406d 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 404 or the applications processor 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.

Synthesizer circuitry 406d of the RF circuitry 406 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 (DP A). In some embodiments, the DMD may be configured to divide the input signal by either N or N+l (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.

In some embodiments, synthesizer circuitry 406d 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 406 may include an IQ/polar converter.

FE circuitry 408 may include a receive signal path that may include

circuitry configured to operate on RF signals received from one or more antennas 410, amplify the received signals and provide the amplified versions of the received signals to the RF circuitry 406 for further processing. FE circuitry 408 may also include a transmit signal path that may include circuitry configured to amplify signals for transmission provided by the RF circuitry 406 for transmission by one or more of the one or more antennas 410. In some embodiments, the FE circuitry 408 may include a TX/RX switch to switch between transmit mode and receive mode operation. The FE circuitry 408 may include a receive signal path and a transmit signal path. The receive signal path of the FE circuitry 408 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 406). The transmit signal path of the FE circuitry 408 may include a power amplifier (PA) to amplify input RF signals (e.g., provided by RF circuitry 406), and one or more filters to generate RF signals for subsequent transmission (e.g., by one or more of the one or more antennas 410).

Figure 5 illustrates an Ethernet controller 500 in accordance with some

embodiments. The Ethernet controller 500 may be implemented in the electronic device circuitry 300 to provide wired connectivity. For example, the Ethernet controller 500 may be used if the electronic device circuitry 300 is employed in the CN device 204, the MeNB 208 or the SeNB 212 for communicating over the SI or X2 interfaces or the CN device 204 for communicating over the SI or S5/S8 interfaces.

The Ethernet controller 500 may include a host interface 512 to couple the Ethernet controller 500 with a host platform. In some embodiments, the host interface 512 may be a bus interface to couple with a serial expansion bus such as a peripheral component interconnect express (PCIe) bus. In some embodiments, the host interface 512 may be a PCIe endpoint with single root input-output virtualization (SR-IOV) to allow isolation of the PCIe resources for manageability and performance reasons. This may allow different virtual machines in a virtual environment to share a single PCIe hardware interface. In other embodiments, the host interface 512 may be a PCIe endpoint with multiple root input/output virtualization that allows a PCIe bus to share resources among different virtual machines on different physical machines.

The Ethernet controller 500 may include queue management and scheduling (QMS) circuitry 516. The QMS circuitry 516, which may also be referred to as a network or packet scheduler, may employ a queuing/scheduling algorithm to control the

transmission and reception of packets by the Ethernet controller 500. The QMS circuitry 516 may manage a sequence of network packets in transmit and receive queues of the Ethernet controller 500. In some embodiments, the QMS circuitry 516 may include a number of different queues, with each queue holding packets of one flow according to configured packet classification rules. For example, packets may be divided into flows by their source and destination IP addresses, quality of service requirements, etc. In some embodiments, the QMS circuitry 516 may be used by the Ethernet controller 500 to perform receive side scaling to spread incoming packets across available processing cores of the host platform. The QMS circuitry 516 may further provide flow direction functionality that includes intelligent offloading to place incoming packets directly to the right core, to avoid packets being directed to an available processing core even though another core is running an application that is the target of the packet.

The Ethernet controller 500 may further include protocol acceleration/offload (A/O) circuitry 520. The protocol A/O circuitry 520 may offload, from a host processor, processing of specific protocols or functions of specific protocols. For example, in some embodiments the protocol A/O circuitry 520 may include a TCP offload engine to offload processing of a TCP/IP stack from the host platform to the Ethernet controller 500. This may be especially useful in high-speed network interfaces such as Gigabit Ethernet and 10 Gigabit Ethernet. The offloaded processing may include actions associated with the connection-oriented nature of TCP such as, but not limited to, transport layer connection establishment, acknowledgment of received packets, checksum and sequence number calculations, sliding window calculations, and transport layer connection termination.

In some embodiments, the protocol A/O circuitry 520 may perform transport layer operations of a mobile proxy to facilitate opportunistic access of links in high-frequency bands as described in further detail herein.

The Ethernet controller 500 may further include traffic classifiers 524. The traffic classifiers 524 may implement a process to categorize traffic according to various parameters (for example, port number, protocol, etc.) into a number of traffic classes. Each traffic class may be treated differently in order to differentiate the service provided by the Ethernet controller 500.

The Ethernet controller 500 may further include media access controller 528 to perform MAC layer operations for the Ethernet controller 500 using, for example, carrier sense multiple access with collision detection (CSMA/CD) protocols. The media access controller 528 may include a number of full-duplex Ethernet MAC ports that may be configured to operate at different speeds, for example, 40 Gb/s, 10 Gb/s, 1 Gb/s.

The Ethernet controller 500 may further include PHY 532 to perform Ethernet

PHY layer operations. In some embodiments, the PHY 532 may include interfaces directly connected with a communication medium (for example, a backplane or direct attached twin-axial copper cable assemblies) or through the Ethernet interface, which may be considered an external PHY in some instances. The PHY 532 may interface between an analog domain of an Ethernet's line modulation and the digital domain of link-layer packet signaling performed by the media access controller 528. In some embodiments, the PHY circuitry may include multi-rate medium attachment unit interfaces (MAUIs) that can be figured for operation and a number of different link speeds, for example, 40 Gb/s, 10 Gb/s, 1 Gb/s or lOO Mb/s.

The Ethernet controller 500 may further include in-band management circuitry 536 having controllers or processors to perform various on-chip management functions. The in-band management circuitry 536 may interface with an off-chip management controller through a system management bus (SMBus); network controller sideband interface (NC- SI); or the connection of the host interface 512 using, for example, management component transport protocol (MCTP) to communicate over the PCIe.

The in-band management circuitry 536 may include a baseboard management controller or an embedded management processor unit that handles management duties that are to be carried out by the Ethernet controller, but are not performed by other circuitry, for example, device drivers of the Ethernet controller. In some embodiments, these duties may include performing parts of the power on sequence, handling AQ commands, initializing ports, participating in various fabric configuration protocols such as data center bridging capabilities exchange (DCBX) and other link layer discovery protocols (LLDPs), and processing configuration requests received by management interfaces.

In embodiments in which the electronic device circuitry 300 incorporates the Ethernet controller 500, the PHY 532 may be incorporated in the transceiver circuitry 312 (and possibly the media interface circuitry 324) and the other components of the Ethernet controller 500 may be incorporated in the control circuitry 308.

Figure 6 illustrates a computing device 600 in accordance with some embodiments.

The computing device 600 may include platform circuitry 604 coupled with electronic device circuitry 608.

The electronic device circuitry 608 may include circuitry similar to, or

substantially interchangeable with, electronic device circuitry 300.

The platform circuitry 604 may include processing circuitry 612 coupled with memory/storage 616. The processing circuitry 604 may include any type or combination of configurable or non-configurable circuit that is designed to perform basic arithmetic, logical, control, or input/output operations specified by instructions of the computer program. The processing circuitry 604 may include one or more single-core or multi-core processors and may include any combination of general-purpose processors and dedicated processors. In some embodiments, the processing circuitry 604 may include an application processor, communication processor, microprocessor, ASIC, reduced instruction set computer (RISC), DSP, co-processor, combinational logic circuit, controller (e.g., memory, bridge, bus, etc.), etc.

The processing circuitry 604 may be coupled with the memory/storage 616 and configured to execute instructions stored in the memory/storage 616 to enable various applications or operating systems running on the device 600.

The memory/storage circuitry 616 may include any type or combination of configurable or non-configurable circuit that is capable of holding, in a transitory, temporary, semi-permanent, or permanent manner, digital content (data, instructions, etc.) and providing the digital content to another circuit component, for example, the processing circuitry 612, upon an occurrence of a predetermined event. The memory/storage circuitry 616 may include, but is not limited to, random access memory (RAM) (including, for example, static RAM (SRAM), dynamic RAM (DRAM)), read-only memory (ROM) including, for example, electrically eraseable programmable ROM (EEPROM), cache (LI, L2, etc.), buffer, etc.

The platform circuitry 604 may, in general, perform higher-layer functions that are associated with the platform upon which the device is implemented and the electronic device circuitry 608 may, in general, perform lower-layer functions that are associated with communications over appropriate network interfaces.

Collectively, the platform circuitry 604 and the electronic device circuitry 608 may implement one or more modules to provide an operating system 620 to manage computer hardware and software resources and to provide various services for computer programs, applications 624 to perform tasks or activities for a user, and a communication protocol stack 628 to communicatively couple the modules of the device (for example, the applications 624) with modules implemented by other devices over a network.

The communication protocol stack 628 (or simply "stack 628") may include layers implemented by the electronic device circuitry 608 such as those described above, for example, the PHY layer, the MAC layer, the RLC layer, the PDCP layer, and the RRC layer. The stack 628 may further include layers implemented by the platform circuitry 604 such as an Internet layer, a transport layer, and an application layer. The application layer may include communication protocols and interface methods used to process communications transmitted across an IP network.

The transport layer may establish host-to-host data transfer channels and manage data exchange in a client-server or peer-to-peer networking model. The transport layer may include TCP or user datagram protocol (UDP). The TCP functions may include, for example, connection establishment using the "3-way handshake" (SYNchronize;

SYNchronize-ACKnowledge; ACKnowledge); acknowledgment of packets as they are received by the far end, adding to the message flow between the endpoints and thus the protocol load; checksum and sequence number calculations - again a burden on a general purpose CPU to perform; sliding window calculations for packet acknowledgment and congestion control; and connection termination.

The Internet layer may refer to operations used to transport datagrams (packets) from an originating host across network boundaries. The Internet layer may include, for example, IP protocols (for example, IP version 4, IP version 6, etc.), IP security protocols (for example, IPsec), etc.

The control circuitry used perform the access-network control operations is described above in Figure 3 as being implemented in electronic device circuitry. However, in some embodiments some or all of the control circuitry may be implemented in platform circuitry, for example, the platform circuitry 604. Furthermore, while functions of certain layers are described as being implemented by either the platform circuitry 604 or the electronic device circuitry 608, in other embodiments, the functions may be performed by other circuitry. For example, transport layer functions, including those performed by the mobile proxy 206, may be performed by the platform circuitry 604 or by protocol A/O circuitry of the electronic device circuitry 608. F

In embodiments in which the computing device 600 is a CN device, such as CN device 204, the computing device 600 may implement a mobile proxy such as mobile proxy 206. The mobile proxy may include modules of the OS 620, applications 624, or stack 628. In some embodiments, the mobile proxy may additionally/alternatively include circuit elements of the platform circuitry 604 or electronic device circuitry 608 to perform operations described herein.

In some embodiments, particularly when the computing device 600 is a UE, for example, UE 216, the computing device 600 may also include an input/output interface 632, sensor(s) 636, and display(s) 640. In various embodiments, the I/O interface(s) 632 may include one or more user interfaces designed to enable user interaction with the system or peripheral component interfaces designed to enable peripheral component interaction with the system. User interfaces may include, but are not limited to, a physical keyboard or keypad, a touchpad, a speaker, a microphone, etc. Peripheral component interfaces may include, but are not limited to, a non-volatile memory port, a universal serial bus (USB) port, an audio jack, and a power supply interface.

In various embodiments, the sensor(s) 636 may include one or more sensing devices to determine environmental conditions and/or location information related to the system. In some 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 baseband circuitry or RF circuitry to communicate with components of a positioning network, e.g., a global positioning system (GPS) satellite.

In various embodiments, the display(s) 640 may include a display (e.g., a liquid crystal display, a touch screen display, etc.).

Figure 7 illustrates interaction of modules of stacks of different devices in accordance with some embodiments. In particular, Figure 7 illustrates the mobile proxy 206, in the CN device 204, coupled with an application server 708 and e Bs (for example, Me B 208 and Se B 212). The eNBs 208/212 may be further coupled with the UE 216.

Each of the components of Figure 7 may include modules of a communication protocol stack such as, for example, stack 628. In particular, the mobile proxy 206 may include a TCP module 720, and IP module 724, a transport-IP network module 728, and a transport-radio air interface module 732. The application server 708 may include application layer module 736, a TCP module 740, IP module 744, and a transport-IP network module 748. The eNBs 208/212 may include a transport-radio air interface module 752. The UE 216 may include an application layer module 756 and a transport- radio air interface module 760.

The modules of the components of Figure 7 may coordinate to facilitate the transmission of data between the application layer module 736 of the application server 708 and the application layer module 756 of the UE 216.

In general, the TCP modules 720 and the 740 may perform transport layer operations and manage a transport connection between the two modules; IP modules 724 and 744 may perform Internet layer operations; transport-IP network modules 728 and 748 may perform L2 (link layer) and LI operations; and the transport-radio air interface modules 732, 752, and 760 may perform RRC - LI operations.

The mobile proxy 206 may use the TCP module 720 to maintain a TCP layer interface with a core network. The TCP operations performed by the TCP modules 720 and 740 may include operations related to managing a transport-layer connection such as, but not limited to, connection establishment, connection termination, resource usage, data transfer, etc. With regard to data transfer, the TCP modules 720 and 740 may provide for ordered data transfer (with the receiving module rearranging packets according to sequence number), retransmission of lost packets (in which lack of or negative

acknowledgments lead to transmitting module retransmitting packet), flow control (to limit a rate a sender transfers data to guarantee), and congestion control.

A TCP rate control operation, which may include flow or congestion control, between TCP module 720 and TCP module 740 may be as follows. The TCP module 720 may determine a data rate for the transport network between the TCP module 720 and TCP module 740. The TCP module 720 may also determine the capacity of a radio access network, for example, a connection between transport-radio air interface module 752 and transport-radio air interface module 760. If the transport network data rate is higher than the capacity of the radio access network, the TCP module 720 may generate feedback, for example, transport layer data transfer management messages, to inform the TCP module 740 at the application server 708 to reduce a data rate of packets transmitted over the transport network, thereby reducing the data rate of the transport network to be less than or equal to the capacity of the radio access network.

In some embodiments, the transport-layer data transfer management messages may include a TCP message that includes a negative acknowledgment (NACK). The NACK may be included in the TCP message even if the IP packets were successfully received by the TCP module 720. In other embodiments, the mobile proxy may negatively

acknowledge a successfully received transmission in other ways, for example, non- transmission of a positive acknowledgment, the occurrence of which may be interpreted as a negative acknowledgment by the sending entity.

The mobile proxy 206 may use various access-network control operations such as, but not limited to, buffering and traffic shaping, so that radio access network capacity fluctuation due to the on/off of an mmWave link may be avoided at the transport layer. In some embodiments, the access-network control operations may be performed by the transport-radio air interface module 732. The mobile proxy 206 may use the transport-radio air interface module 732 to manage a connection between the mobile proxy 206 and the UE 216 (via the transport- radio air interface module 760). Data may be transferred over this connection via the Uu and X2 interfaces according to the schedule developed by the mobile proxy or the Me B 208.

Figure 8 is a schematic diagram of traffic and feedback flows through the mobile proxy 206, the MeNB 208, and the UE 216 in accordance with some embodiments. In particular, Figure 8 illustrates scheduling logic 804 coupled with communication logic 806 at the mobile proxy 206, and scheduling logic 808 coupled with communication logic 810 at the MeNB 208.

The scheduling logic and communication logic may be logic at least partially implemented in hardware of the control circuitry to perform the scheduling and

communication operations described herein. In some embodiments, the scheduling logic 804 and communication logic 806 may include at least components of the TCP module 720 and a transport-radio air interface module 732. The scheduling logic 808 and communication logic 810 may include at least components of a transport-radio air interface module 752.

In embodiments in which the scheduling and communication logic is implemented in the wireless communication circuitry 400, the scheduling logic may be implemented at least in part by a baseband processor (e.g., 4G baseband processor 404c or 5G baseband processor 404d), memory/storage 404g, or the CPU 404e; and the communication logic may be implemented at least in part by the baseband processor 404, memory/storage 404g, or the RF circuitry 406. In embodiments in which the scheduling and communication logic is implemented in the Ethernet controller 500, the scheduling logic may be implemented at least in part by the QMS circuitry 516 or protocol A/O circuitry 520, and the communication logic may be implemented at least in part by the QMS circuitry 516, the protocol A/O circuitry 520, traffic classifiers 524, media access controller 528, or the PHY 532. In other embodiments, the scheduling and communication logic may be implemented at least in part in other hardware, for example, processors 612 or

memory/storage 616 of the platform circuitry 604.

The scheduling logic 804 and 808 may provide for two levels of scheduling. In various embodiments the scheduling of the traffic over the air interface may be performed by the scheduling logic 804 or the scheduling logic 808. The communication logic 806 may receive incoming traffic 812 from a network (for example, from the application server 708). The communication logic 806 may determine that the traffic 812 includes traffic associated with one or more respective QoS classes.

The QoS classes may allow an ability to provide different priority to different applications, users, or data flows, or to guarantee a certain level of performance to the data flow. This may allow certain performance characteristics, for example, bit rate, delay, jitter, packet dropping probability, bit error rate, to be guaranteed to a QoS class.

The communication logic 806 may differentiate the traffic 812 based on the respective QoS class. In some embodiments, the communication logic 806 may determine the QoS class based on packet headers, source or destination addresses, etc.

In some embodiments, the communication logic 806 may direct traffic of a particular QoS class to an associated buffer of buffers 814. Thus, each QoS class may have a corresponding buffer to buffer traffic prior to transmission to the e Bs.

The buffers 814 may be implemented in memory/storage in communication or platform circuitry.

The scheduling logic 804 may provide feedback 816 for traffic of each QoS class. The feedback 816 may be a transport-layer data transfer management transmission that is used to adjust traffic through the core network using TCP rate control. In some

embodiments, the feedback 816 may be for additional/alternative transport-layer data transfer management purposes.

The scheduling logic 804 may transmit control information 820 to the scheduling logic 808. The control information 820 may include buffer statuses, and QoS parameters associated with the QoS classes.

While Figure 8 illustrates messages flowing directly between the scheduling logic

804 and 808, it may be understood that the connections may be logical connections that may flow through the communication logic 806 and 810. Thus, the scheduling logic may receive and transmit messages to other networked components via the communication logic.

In embodiments in which the scheduling is performed at the mobile proxy 206, the control information 820 may include a notification of a scheduling decision of the scheduling logic 804.

The scheduling logic 808 may receive feedback from the UE 216 or the Se B 212 that provides information regarding capacity of links provided by the Me B 208 and the SeNB 212. The feedback 824 regarding the capacity of a second link provided by the Se B 212 may be received from the UE 216 or from the SeNB 212.

The scheduling logic 808 may determine a link capacity based on the information provided in the feedback 824. In some embodiments, the link capacity may include statistical information about the rate at which IP packets are successfully delivered to the UE 216 over the first and second links. In some embodiments, this statistical information may be based on tracking acknowledgments and negative acknowledgments for IP packets that are delivered to the UE 216 at a given rate for a given channel state. The link capacity may also include predictive information based on current channel states and operational characteristics of the first and second links (for example, average dropout frequency of the second link, average connection reestablishment time, etc.).

The scheduling logic 808 may transmit a link-capacity report, which may include delivery rate statistics, in the feedback 828 to the scheduling logic 804. The link capacity may be used by the scheduling logic 804 for determining a schedule (in embodiments in which the mobile proxy 206 makes this determination) or for TCP rate control operations.

In embodiments in which the scheduling is performed at the MeNB 208, the scheduling logic 808 may transmit a notification of the scheduling decision of the scheduling logic 808 in the feedback 828.

In various embodiments, the scheduling decisions performed by the scheduling logic 804 or 808 may determine whether the traffic is to be directed to the UE 216 over first link provided by the MeNB 208 or a second link provided by the SeNB 212. In general, the determination may be made based on the QoS classes of the traffic and the capacity of the radio links.

In some embodiments, the scheduling logic 804 or 808 may predict capacity of the first and second links based on a mobility of the UE 216.

In some embodiments, the scheduling logic 804 or 808 may predict capacity of the first and second links based on capacity of links associated with one or more other UEs that are considered proximate to the UE 216. For example, if a second UE is considered proximate to the UE 216, the scheduling logic 804 or 808 may determine that the links of the UEs are strongly correlated and may imply a link capacity of UE 216 based on a predetermined link capacity of the second UE.

In various embodiments, the link provided by the SeNB 212 may utilize an idle state or an active state. If the link is in an idle state for an extended period of time, the link capacity measurements used by the scheduling logic may become stale. Therefore, Figure 9 illustrates an embodiment of a reporting procedure 900 that may be used to provide updated link capacity measurements to the scheduling logic. The operations described in the reporting procedure 900 may be performed by control circuitry, for example, control circuitry 308, implemented on a respective device.

At 904, the reporting procedure 900 may include the control circuitry of the UE

216 detecting a predetermined reporting event. In some embodiments, the predetermined reporting event may be an expiration of a timer that is set to facilitate periodic reporting. The period for the reporting may be chosen by considering a balance between power consumption of the UE 216 and channel status accuracy.

In some embodiments, the predetermined reporting event may be receipt of a reporting instruction from, for example, the MeNB 208. The reporting instruction may be received by the UE 216 over the anchor connection when it is in an active state or when the mmWave connection is periodically activated.

In some embodiments, the predetermined reporting event may be, or be based on, the detection of environmental conditions that may be associated with a change (or expected change) in a state of the mmWave link. Existence or detection of certain environmental conditions may imply that the UE 216 should report on the condition of the mmWave link or, perhaps, increase or decrease a frequency of reporting. Some environmental conditions may include mobility of the UE; a change in quality in another wireless communication link; a location of the UE (for example, if the UE is located in a physically congested environment, for example, surrounded by tall buildings, that may disrupt line-of-sight mmWave links); or increased or changing precipitation/barometric levels. These environmental conditions may be detected through sensors or apps on the UE 216.

At 908, the reporting procedure 900 may further include activating the mmWave interface and performing measurements. In an embodiment in which the mmWave interface is activated, the operation at 908 may be to keep the mmWave interface activated.

The measurements performed at 908 may include measuring signals, for example, reference signals, transmitted by the SeNB. The signals that are used as the basis for measurement may include, for example, reference signals such as cell-specific reference signals (CRSs) or channel state information (CSI) reference signals. CRSs may be pilot symbols inserted in both time and frequency in all downlink subframes and cells supporting physical downlink shared channel (PDSCH) transmissions. These pilot symbols may provide an estimate of the channel at given locations within a subframe. The UE 216 may interpolate the results of the measurements to estimate the channel across an arbitrary number of subframes.

The UE 216 may measure parameters of the received signals such as, for example, reference signal received power (RSRP) and reference signal received quality (RSRQ). The RSRP may be defined as a linear average over the power contributions of the resource elements to carry cell-specific reference signals within a considered measurement frequency bandwidth. The RSRQ may be based on RSRP and received signal strength indicator (RSSI), which measures an average total received power observed only in OFDM symbols containing reference signals for antenna port 0 in a measurement bandwidth over N resource blocks. RSRP may be defined as a ratio of Nx RSRP/KSSI.

The UE 216 may transmit a report 912 that includes results of the measurements performed at 908.

At 916, the UE 216 may idle its mmWave interface.

Upon receiving the report 912, the Me B 208 may, at 920, estimate a link capacity of a link provided by the SeNB. In some embodiments, the estimation of the link capacity at 920 may further estimate a link capacity of a primary link provided by the MeNB 208 in the low-frequency bands. The estimate of the primary link capacity may be based on measurement reports that are periodically transmitted to the MeNB 208 through the primary link.

The reporting procedure 900 may further include, at 924, detecting the

predetermined reporting event by the MeNB 208. The predetermined reporting event 924 may be periodic or event-driven such as that described above with respect to 904.

Upon detecting the predetermined reporting events at 924, the MeNB 208 may transmit a report 928 to the mobile proxy 206.

The report 928, which may also be referred to as a link-capacity report message, is shown schematically in Figure 9. The report 928 may include a data rate field 936 for communicating a link-capacity status of a radio link (for example, links 220 or 224) towards a user equipment (UE). The link-capacity status may include statistical information about the rate at which IP packets are successfully delivered to a UE over a respective link.

The report 928 may further include a UE identifier field 932 for communicating an identifier of the UE. The identifier may be an IP address assigned to the UE or another kind of network identifier for the UE. In various embodiments, the report 928 may include a dropout indication field 940 for communicating information on a dropout frequency of a link (for example, links 220 or 224). The dropout indication field 940 may be for communicating information on an average dropout frequency of the link.

In some embodiments, the report 928 may further include a connection

reestablishment time indication field 944 for communicating information on a connection reestablishment time of a link (for example, links 220 or 224). The connection

reestablishment time indication field 944 may be for communicating information on an average connection reestablishment time of a first link.

in some embodiments, the report 928 may further include a second data rate field

948 for communicating a link-capacity status of another radio link. For example, if the data rate field 936 is to communicate a link-capacity status of link 220, the second data rate field 948 may communicate a link-capacity status of link 224.

The report 928 may be a non-access stratum message in some embodiments.

Figure 10 illustrates an opportunistic access operation 1000 in accordance with some embodiments. The opportunistic access operation 1000 may be a downlink-triggered mmWave link activation and access process with scheduling performed in the MeNB 208. In various embodiments, the operations of Figure 10 may be performed, caused, or controlled by components of communication or platform circuitry of respective devices described in Figure 10.

The opportunistic access operation 1000 (hereinafter "operation 1000") may begin with the mobile proxy 206 receiving UE traffic from a sending entity via a core network. For example, the mobile proxy 206 may receive the UE traffic from the application server 708. The mobile proxy 206 may, at 1004, buffer the UE traffic in memory circuitry such as, for example, buffers 814, memory/storage 404g, QMS circuitry 516, etc.

The mobile proxy 206 may, at 1004, cause transmission of a transport-layer data transfer management message to the sending entity. The transport-layer data transfer management message may be for any TCP operation described above such as, for example, ordered data transfer, retransmission of lost packets, error-free data transfer, or flow/congestion control. In some embodiments, the transport-layer data transfer management message may include a TCP ACK/NACK message. For purposes of the present description, the transmission of the transport-layer data transfer management message may be for purposes related to successful or unsuccessful receipt of the IP packets, with other transport-layer data transfer management messages being used for TCP rate control. However, in some embodiments the transmission at 1004 may also be used for TCP rate control.

The mobile proxy 206 may, at 1008, transmit a notification of UE traffic to the MeNB 208. The notification may include a notification of a type, size, or QoS requirement of the traffic.

The operation 1000 may, at 1012, include the MeNB 208 scheduling the traffic. In particular, the MeNB 208 may schedule the traffic over a first link provided by the MeNB 208 in a low-frequency band or a second link provided by the SeNB 212 in a high- frequency band. In some embodiments, the MeNB 208 may schedule a first portion of the traffic over the first link and a second portion of the traffic over the second link.

The MeNB 208 may schedule the traffic over the first and second links based on estimates of link capacities. The estimate of the link capacity may be performed similar to that described above with respect to Figure 9. The MeNB 208 may further schedule the traffic over the first and second links based on the type, size, or QoS requirement of the traffic.

After developing the schedule at 1012, the MeNB 208 may, at 1016, transmit a notification of the scheduling decision to the mobile proxy 206.

If the scheduling decision includes at least a portion of the traffic being transmitted over the second link provided by the SeNB 212, the MeNB 208 may, at 1020, transmit an instruction to wake-up an mmWave air interface to the UE 216. The instruction to wake up the mmWave interface may be transmitted over the first link provided by the MeNB 208. The UE 216 may wake up its mmWave air interface and begin synchronization with the mmWave SeNB 212 at 1028.

If the scheduling decision includes at least a portion of traffic being transmitted over the second link provided by the SeNB 212, the mobile proxy 206 may, at 1024, download the first portion of the UE traffic to the SeNB 212.

If the scheduling decision includes at least a portion of traffic being transmitted over the first link provided by the MeNB 208, the mobile proxy 206 may, at 1032, download the portion of the UE traffic to the MeNB 208.

The operation 1000 may include data transmission over the air interface at 1036.

The data transmission may occur over first or second links consistent with the scheduling decision made by the MeNB 208. The operation 1000 may further include, at 1040, the UE 216 providing an update to a link capacity of the second link. The MeNB 208 may provide an updated link capacity of both the first and second links to the mobile proxy 216 at 1044.

Having received the updated UE link capacity, the mobile proxy 206 may perform a TCP rate control operation at 1048.

Figure 11 is a flowchart illustrating a TCP rate control operation 1100 in accordance with some embodiments.

The rate control operation 1100 (hereinafter "operation 1100") may be performed by components of the mobile proxy 206 including, for example, the scheduling logic 804, communication logic 806, and the TCP module 720.

At 1104, the operation 1100 may include receiving UE link capacity from the MeNB 208. The UE link capacity may be received in feedback transmitted from the MeNB 208 to the mobile proxy 206 over the control plane. The UE link capacity may include measurements or other parameters (for example, delivery rate statistics) associated with link capacity for links provided to the UE 216 by the MeNB 208 and the SeNB 212.

At 1108, the operation 1100 may include determining transport network data rate and a RAN data rate.

The transport network data rate may correspond to the rate at which TCP traffic is delivered to the TCP module 720 from the TCP module 740. The transport network data rate may be determined by the mobile proxy 206 tracking a rate at which IP packets arrive at the mobile proxy 206.

The RAN data rate may correspond to the rate at which UE traffic is delivered to the transport-radio air interface module 760 from the transport-radio air interface module 752 (of the MeNB 208 and the SeNB 212). The RAN data rate may be determined based on the UE link-capacity report provided in the feedback from the MeNB 208.

The operation 1100 may include, at 1112, determining whether a transport network data rate is greater than the RAN data rate.

If, at 1112, it is determined that the transport network data rate is not greater than the RAN data rate, the operation 1100 may loop back to 1104 to continue to monitor the respective data rates.

If, at 1112, it is determined that the transport network data rate is greater than the RAN data rate, the operation 1100 may include the mobile proxy reducing a transport network data rate at 1116. In some embodiments, the mobile proxy 206 may reduce a transport network data rate by using TCP rate-control procedures. In various embodiments, the TCP rate-control procedures may include procedures related to flow control or congestion control.

Flow control may be typically used to avoid a sender sending data faster than a TCP receiver may reliably receive and process it. In the present embodiment, the mobile proxy 206 may implement TCP flow control by using a sliding window. Upon receiving traffic from the application server 708, the mobile proxy 206 may determine an amount of additional data that it is willing to buffer for the connection. The mobile proxy 206 may then transmit, to the application server 708, an indication of the determined amount in a receive window field. The application server 708 may only be allowed to send up to that amount of data before it receives an acknowledgment and a receive window update from the mobile proxy 206. If the mobile proxy 206 wants to stop the application server 708 from sending data, the mobile proxy 206 may transmit a zero value in the receive window field.

The mobile proxy 206 may additionally/alternatively use congestion control procedures to control the rate of data entering the transport network. In some

embodiments, the mobile proxy 206 may send negative acknowledgments (or lack of acknowledgments) to the application server 708. The application server 708 may receive these negative acknowledgments (or lack of acknowledgments) and infer that the transport network data rate is too high. As a result, the application server 708 may reduce a rate at which packets are transmitted to the mobile proxy 206.

In various embodiments, the mobile proxy 206 may use any of a number of TCP congestion-avoidance algorithms to provide congestion control. These TCP congestion- avoidance algorithms may include, but are not limited to, TCP Tahoe and Reno, TCP Vegas, TCP New Reno, TCP Hybla, TCP BIC, TCP CUBIC, Agile-SD TCP, TCP Westwood+, or Compound TCP.

Figure 12 illustrates an opportunistic access operation 1200 in accordance with some embodiments. The opportunistic access operation 1200 may be a downlink-triggered mmWave link activation and access process with scheduling performed in the mobile proxy 206. Unless otherwise described, the operations of Figure 12 may be performed, caused, or controlled by components of communication or platform circuitry of respective devices described in Figure 12.

The opportunistic access operation 1200 (hereinafter "operation 1200") may begin with the mobile proxy 206 receiving data from a sending entity via a core network. For example, the mobile proxy 206 may receive the traffic from the application server 708.

The mobile proxy 206 may, at 1204, buffer the UE traffic in memory circuitry and transmit a transport-layer data transfer management message to the sending entity similar to the process described above with respect to operation 1004 of Figure 10.

The operation 1200 may, at 1208, include the mobile proxy 206 scheduling the UE traffic over the first link provided by the MeNB 208 or the second link provided by the

SeNB 212. Except for performing the scheduling in the mobile proxy 206 rather than the

MeNB 208, the scheduling of the UE traffic at 1208 may be similar to the scheduling of the UE traffic at 1012.

After developing the schedule at 1208, the mobile proxy 206 may, at 1212, transmit a notification of the scheduling decision to the MeNB 208.

If the scheduling decision includes at least a portion of the traffic being transmitted over the second link provided by the SeNB 212, the MeNB 208 may, at 1216, transmit an instruction to wake up an mmWave air interface to the UE 216. The instruction to wake up the mmWave interface may be transmitted over the first link provided by the MeNB 208.

The UE 216 may wake up its mmWave air interface and begin synchronization with the mmWave SeNB 212 at 1228.

If the scheduling decision includes at least a portion of traffic being transmitted over the second link provided by the SeNB 212, the mobile proxy 206 may, at 1220, download the portion of the UE traffic to the SeNB 212.

If the scheduling decision includes at least a portion of traffic being transmitted over the first link provided by the MeNB 208, the mobile proxy 206 may, at 1224, download the portion of the UE traffic to the MeNB 208.

The operation 1200 may include data transmission over the air interface at 1232. The data transmission may occur over first or second links consistent with the scheduling decision made by the mobile proxy 206.

The operation 1200 may further include, at 1236, the UE 216 sending an update of a link capacity of the second link provided by the SeNB 212. The MeNB 208 may provide an updated link capacity of both the first and second links to the mobile proxy 216 at 1240.

Having received the updated UE link capacity, the mobile proxy 206 may perform a TCP rate control operation at 1244. Performance of the TCP rate control operation may be similar to that described above. Figure 13 illustrates an opportunistic access operation 1300 in accordance with some embodiments. The opportunistic access operation 1300 may be an uplink-triggered mmWave activation and access procedure with a direct connection between the Se B 212 and the mobile proxy 206. Unless otherwise described, the operations of Figure 13 may be performed, caused, or controlled by components of control circuitry of respective devices described in Figure 13.

The opportunistic access operation 1300 (hereinafter "operation 1300") may begin with the UE 216 transmitting an uplink traffic report to the MeNB 208 at 1304. The uplink traffic report may provide an indication of the need for the UE 216 to transmit uplink traffic. The uplink traffic may be destined for another device over the core network, for example, the application server 708. The uplink traffic report may include an indication of a type, size, or QoS requirement of the traffic to be uploaded.

The operation 1300 may include, at 1308, the MeNB 208 scheduling traffic. The MeNB 208 may schedule the traffic over the first link provided by the MeNB 208 or the second link provided by the SeNB 212. The MeNB 208 may schedule the traffic over the first and second links based on estimates of link capacities. The estimate of the link capacity may be performed similar to that described above with respect to Figure 9. The MeNB 208 may further schedule the uplink traffic over the first and second links based on the type, size, or QoS requirement of the traffic.

The operation 1300 may include, at 1312, the MeNB 208 transmitting a notification of the scheduling decision to the UE 216.

If at least a portion of the uplink traffic is to be transmitted via the second link, the UE 216 may activate its mmWave interface and begin synchronization and access with the SeNB 212 at 1316.

The operation 1300 may further include, at 1320, the UE 216 transmitting the uplink data transmission. The uplink data may be transmitted over the first and second links consistent with the scheduling decision of the MeNB 208.

If at least a portion of the uplink traffic is transmitted via the second link, the operation 1300 may include, at 1324, the SeNB 212 uploading at least a portion of the UE traffic to the mobile proxy 206.

If at least a portion of the uplink traffic is transmitted via the first link, the operation 1300 may include, at 1328, the MeNB 208 uploading at least a portion of the UE traffic to the mobile proxy 206. The operation 1300 may further include, at 1332, the mobile proxy 206 buffering the uplink traffic and scheduling transmission in a core network.

As discussed above, the mobile proxy 206 may include a TCP module 720 serving as a TCP endpoint in order to terminate a transport layer. Therefore, in scheduling transmission in the core network, the TCP module 720 may need to manage TCP connections through the core network. Figure 14 illustrates a flowchart of TCP

management operation 1400 to manage TCP connections for the transmission of the uplink traffic through the core network to a destination such as, for example, the application server 708. The TCP management operation 1400 may be performed by the TCP module 720.

The TCP management operation 1400 may begin at 1404 with the TCP module 720 receiving uplink traffic. The uplink traffic may be received from the Me B 208 or the Se B 212.

The TCP management operation 1400 may then include the TCP module 720 establishing a TCP connection at 1408. The TCP connection may be established with the other endpoint of the TCP connection such as, for example, TCP module 740.

Establishing a TCP connection may include a multi-step handshake process. In some embodiments, the handshake process may be referred to as a three-way handshake. The three-way handshake may include the TCP module 720 performing an active open by sending a synchronization request (SYN) to the TCP module 740. The TCP module 720 may set a sequence number, included in the synchronization request, to a random value A. Upon receiving the synchronization request, the TCP module 740 may reply with a synchronization acknowledgment (SYN-ACK) message. The synchronization

acknowledgment message may include an acknowledgment number set to one more than the sequence number of the synchronization request, for example, A + 1, and the TCP module 740 may choose another random number, B, for a sequence number to be included in the synchronization acknowledgment message. Upon receiving the synchronization acknowledgment message, the TCP module 720 may send an acknowledgment (ACK) back to the TCP module 740. The acknowledgment may include a sequence number set to the acknowledgment number, for example, A+l, and may include an ACK number set to one more than the sequence number of the synchronization acknowledgment message, for example, B+l . Following the three-way handshake, both the TCP module 720 and the TCP module 740 have received an acknowledgment of the connection and a full-duplex communication may be established. The operation 1400 may further include, at 1412, the TCP module 720 transferring the data over the established connection. As described above, the data transfer may be performed using TCP features such as ordered data transfer, retransmission of lost packets, error-free data transfer, flow control, or congestion control.

The operation 1400 may further include, at 1416, the TCP module 720 terminating the TCP connection. In some embodiments, the TCP connection may be terminated using a four-way handshake.

When the TCP module 720 wishes to stop its half of the connection, it may transmit a finished (FIN) message to the TCP module 740. The TCP module 740 may acknowledge the FIN message with an acknowledgment (ACK) message and may transmit another FIN message. The TCP module 720, upon receiving the ACK message and FIN message from the TCP module 740, may transmit a final ACK message, wait for a predetermined period of time, and close the TCP connection. In this manner, the TCP connection may be reliably closed by both TCP endpoints.

Figure 15 illustrates an opportunistic access operation 1500 in accordance with some embodiments. The opportunistic access operation 1500 may be an uplink-triggered mmWave activation and access procedure with an indirect connection between the SeNB 212 and the mobile proxy 206. Unless otherwise described, the operations of Figure 15 may be performed, caused, or controlled by components of platform or communication circuitry of respective devices described in Figure 15.

The opportunistic access operation 1500 (hereinafter "operation 1500") may include procedures similar to like-named procedures disclosed and discussed with respect to Figure 13. In particular, the UE may send an uplink traffic report to the MeNB 208 at 1504; the MeNB 208 may schedule traffic at 1508 and send the UE 216 a notification of the scheduling decision at 1512; the UE 216 may activate its mmWave interface and synchronize with the SeNB 212 at 1516 and upload data transmission via the first or second links at 1520.

Unlike operation 1300, in operation 1500 the SeNB 212 may not be capable of transmitting the uplink data directly to the mobile proxy 206. Therefore, operation 1500 may include, at 1524, the SeNB 212 uploading at least a portion of the UE traffic to the MeNB 208. Then, at 1528, the MeNB 208 may upload all of the UE traffic to the mobile proxy 206. The operation 1500 may further include, at 1532, the mobile proxy 206 buffering the uplink traffic and scheduling transmission in the core network. This may be performed similar to operations described above with respect to 1332.

Figure 16 illustrates an example computer-readable media 1604 that may be suitable for use to store instructions that cause an apparatus, in response to execution of the instructions by the apparatus, to practice selected aspects of the present disclosure. In some embodiments, the computer-readable media 1604 may be non-transitory. As shown, computer-readable storage medium 1604 may include programming instructions 1608. Programming instructions 1608 may be configured to enable a device, for example, CN device 204, Me B 208, Se B 212, UE 216, or similar computing devices, in response to execution of the programming instructions 1608, to implement (aspects of) any of the methods or elements described throughout this disclosure related to opportunistic access of mmWave links. In some embodiments, the programming instructions 1608 may be configured to enable a device, in response to execution of the programming instructions 1608, to implement (aspects of) any of the methods or elements described throughout this disclosure related to traffic reporting, scheduling, buffering, rate control, link

measurement/reporting performed by control circuitry or corresponding modules. In some embodiments, programming instructions 1608 may be disposed on computer-readable media 1604 that is transitory in nature, such as signals.

Any combination of one or more computer-usable or computer-readable media may be utilized. The computer-usable or computer-readable media may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium. More specific examples (a non-exhaustive list) of the computer-readable media would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a transmission media such as those supporting the Internet or an intranet, or a magnetic storage device. Note that the computer-usable or computer-readable media could even be paper or another suitable medium upon which the program is printed, as the program can be electronically captured, via, for instance, optical scanning of the paper or other medium, then

compiled, interpreted, or otherwise processed in a suitable manner, if necessary, and then stored in a computer memory. In the context of this document, a computer-usable or computer-readable media may be any medium that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The computer-usable media may include a propagated data signal with the computer-usable program code embodied therewith, either in baseband or as part of a carrier wave. The computer-usable program code may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc.

Computer program code for carrying out operations of the present disclosure may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

The present disclosure is described with reference to flowchart illustrations or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the disclosure. It will be understood that each block of the flowchart illustrations or block diagrams, and combinations of blocks in the flowchart illustrations or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for

implementing the functions/acts specified in the flowchart or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable medium produce an article of manufacture including instruction means that implement the function/act specified in the flowchart or block diagram block or blocks. The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions that execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart or block diagram block or blocks.

Some examples are provided below.

Example 1 includes an apparatus comprising: memory circuitry; and processing circuitry coupled with the memory circuitry, the processing circuitry to: receive traffic from a sending entity over a transport network that traverses a core network, buffer the traffic in the memory circuitry; control a data rate of the transport network; and cause the traffic to be transmitted from a core network to a first e B (for example, a macro e B (Me B)) or a second eNB (for example, a small-cell eNB (SeNB)) for subsequent transmission to a user equipment (UE). In some examples, the SeNB is to communicate with the UE using a frequency greater than 6 gigahertz (GHz).

Example 2 includes the apparatus of example 1, wherein the processing circuitry is to cause a transport-layer data transfer management message to be transmitted to the sending entity to control the data rate of the transport network.

Example 3 includes the apparatus of example 2, wherein the transport-layer data transfer management message is a transmission control protocol (TCP) positive or negative acknowledgment message.

Example 4 includes the apparatus of any one of examples 1-3, wherein the processing circuitry is to receive an indication of link capacity provided to the UE from the MeNB or the SeNB and to control the data rate of the transport network based on the link capacity.

Example 5 includes the apparatus of example 4, wherein the indication of the link capacity is included in a message along with a notification of a scheduling decision.

Example 6 includes the apparatus of example 4 or 5, wherein the processing circuitry is further to receive an indication of an updated link capacity provided to the UE by the MeNB or the SeNB .

Example 7 includes the apparatus of any one of examples 2-6, wherein the transport-layer data transfer management message is a transport-layer NACK message and the processing circuitry is to cause transmission of the transport-layer NACK message to the sending entity to control a rate of transmission of data from the sending entity to facilitate transport congestion control.

Example 8 includes the apparatus of example 7, wherein the processing circuitry is to cause transmission of the transport-layer NACK message independent of whether the data was received successfully.

Example 9 includes the apparatus of any one of examples 1-8, wherein the processing circuitry is to cause transmission of a notification, to the MeNB, of the traffic prior to transmission of the traffic.

Example 10 includes the apparatus of example 9, wherein the notification of the traffic includes a notification of a type, size, or quality of service requirement of the traffic.

Example 11 includes the apparatus of example 9 or 10, wherein the processing circuitry is further to receive a notification of a scheduling decision of the MeNB and is to transmit the data to the MeNB or the SeNB based on the notification.

Example 12 includes the apparatus of any one of examples 1-11, wherein the processing circuitry is to generate a schedule of transmission of traffic by the MeNB or the SeNB and to transmit a notification of the schedule to the MeNB.

Example 13 includes the apparatus of example 12, wherein the processing circuitry is to generate the schedule based on a type, size, or quality of service requirement of the traffic.

Example 14 includes the apparatus of example 13, wherein the processing circuitry is to receive an indication of link capacity provided to the UE by the MeNB or the SeNB and to schedule transmission of the traffic based on the indication of the link capacity.

Example 15 includes the apparatus of any one of examples 1-14, wherein the apparatus is disposed in a core network.

Example 16 includes the apparatus of example 15, wherein the apparatus is a serving gateway.

Example 17 includes one or more computer-readable media having instructions that, when executed, cause a mobile proxy to: buffer traffic received from a sending entity over a transport network that traverses a core network, control a data rate of the transport network; and cause the traffic to be transmitted from the core network to a macro eNB (MeNB) or a small-cell eNB (SeNB) for subsequent transmission to a user equipment (UE), wherein the SeNB is to communicate with the UE using a frequency greater than gigahertz (GHz). Example 18 includes the one or more computer-readable media of example 17, wherein instructions, when executed, are to further cause a transport-layer data transfer management message to be transmitted to the sending entity to control the data rate of the transport network.

Example 19 includes the one or more computer-readable media of any one of examples 17-18, wherein the instructions, when executed, are to further cause the mobile proxy to control the data rate of the transport network based on link capacity of a radio air interface.

Example 20 includes the one or more computer-readable media of example 19, wherein the instructions, when executed, are further to cause the mobile proxy to determine the link capacity based on an indication of link capacity received from the Me B or the Se B.

Example 21 includes the one or more computer-readable media of example 20, wherein the indication of link capacity is included in a message along with a notification of a scheduling decision, the message received from the MeNB.

Example 22 includes the one or more computer-readable media of any one of examples 18-21, wherein the transport-layer data transfer management message is a transmission control protocol (TCP) message.

Example 23 includes the one or more computer-readable media of any one of examples 17-22, wherein the instructions, when executed, are to further cause the mobile proxy to transmit a notification, to the MeNB, of the traffic prior to transmission of the traffic, the notification of the traffic to include a notification of a type, size, or quality of service requirement of the traffic.

Example 24 includes the one or more computer-readable media of any one of examples 17-23, wherein the instructions, when executed, are further to receive a notification of a scheduling decision of the MeNB and to transmit the data to the MeNB or the SeNB based on the notification of the scheduling decision.

Example 25 includes the one or more computer-readable media of any one of examples 17-24, wherein the instructions, when executed, are to control the data rate by negatively acknowledging a successfully received transmission.

Example 26 includes one or more computer-readable media having instructions that, when executed, cause a mobile proxy to: process a link-capacity report received from a macro eNB (MeNB), the link-capacity report to include a link capacity of a first link provided to a user equipment (UE) by a small-cell eNB (SeNB), the first link to use a frequency greater than 6 gigahertz (GHz); and transmit a transport-layer data transfer management message to a sending entity based on the link-capacity report, the transport- layer data transfer management message to control a data rate of a transport network.

Example 27 includes the one or more computer-readable media of example 26, wherein the transport-layer message is an acknowledgment/negative acknowledgment (ACK/NACK) message.

Example 28 includes the one or more computer-readable media of example 26 or 27, wherein the transport-layer data transfer management message is a transmission control protocol (TCP) message.

Example 29 includes the one or more computer-readable media of any one of examples 26-28, wherein the transport-layer data transfer management message is to provide congestion or flow control in the transport network.

Example 30 includes the one or more computer-readable media of example 29, wherein the instructions, when executed, further cause the mobile proxy to generate the transport-layer data transfer management message to provide congestion or flow control for individual quality of service (QoS) classes.

Example 31 includes the one or more computer-readable media of any one of examples 26-30, wherein the instructions, when executed, further cause the mobile proxy to generate a schedule of transmitting data to the UE by the MeNB or the SeNB based on the link-capacity report.

Example 32 includes the one or more computer-readable media of example 31, wherein the instructions, when executed, further cause the mobile proxy to: determine a quality of service (QoS) class of the data; and generate the schedule based on the QoS class.

Example 33 includes a method of operating a mobile proxy, the method comprising: processing a link-capacity report received from a macro eNB (MeNB), the link-capacity report to include a link capacity of a first link provided to a user equipment (UE) by a small-cell eNB (SeNB), the first link to use a frequency greater than 6 gigahertz (GHz); and controlling a data rate of a transport network, which traverses a core network and is terminated at a first end by the mobile proxy, based on the link-capacity report.

Example 34 includes the method of example 33, wherein controlling a data rate of a transport network includes transmitting a transport-layer data transfer management message to a sending entity that is to terminate the transport network at a second end. Example 35 includes the method of example 34, wherein the transport-layer message is an acknowledgment/negative acknowledgment (ACK/NACK) message.

Example 36 includes the method of example 34 or 35, wherein the transport-layer data transfer management message is a transmission control protocol (TCP) message.

Example 37 includes the method of any one of examples 33-36, wherein controlling the data rate comprises performing congestion or flow control in the transport network.

Example 38 includes the method of any one of examples 33-37, wherein controlling the data rate comprises performing congestion or flow control for individual quality of service (QoS) classes.

Example 39 includes the method of any one of examples 33-38, further comprising generating a schedule of transmitting data to the UE by the MeNB or the SeNB based on the link-capacity report.

Example 40 includes the method of example 39, further comprising: determining a quality of service (QoS) class of the data; and generating the schedule based on the QoS class.

Example 41 includes a mobile proxy having means configured to perform the method of any one of examples 33-40.

Example 42 includes an apparatus comprising: scheduling logic at least partially implemented in hardware to receive, from a macro eNB (MeNB), a link-capacity report that includes a link-capacity status of a first link provided to a user equipment (UE) by a small-cell eNB (SeNB), the first link to use a frequency greater than 6 gigahertz (GHz); and communication logic at least partially implemented in hardware to transmit a transport-layer data transfer management message, via a transport network, based on the link-capacity report.

Example 43 includes the apparatus of example 42, wherein the transport-layer data transfer management message is a transmission control protocol (TCP) message.

Example 44 includes the apparatus of any one of examples 42-43, wherein the transport-layer data transfer management message is to provide transport network congestion or flow control.

Example 45 includes the apparatus of example 44, wherein the communication logic is to generate the transport-layer data transfer management message to provide transport network congestion or flow control for individual quality of service (QoS) classes. Example 46 includes the apparatus of any one of examples 42-45, wherein the scheduling logic is to generate a schedule for transmitting data to the UE by the MeNB or the SeNB based on the link-capacity report.

Example 47 includes the apparatus of example 46, wherein the scheduling logic is further to: determine a quality of service (QoS) class of the data; and generate the schedule based on the QoS class.

Example 48 includes an apparatus comprising: memory circuitry; and

processing circuitry coupled with the memory circuitry, the processing circuitry to: receive data from a user equipment (UE) via a macro eNB (MeNB) or a small-cell eNB (SeNB), at least a first part of the data transmitted from the UE to the SeNB using a frequency greater than 6 gigahertz (GHz); temporarily store the data in the memory circuitry; and transmit the data through a core network via a transport network terminated at the apparatus and traversing a core network.

Example 49 includes the apparatus of example 48, wherein the processing circuitry is to schedule transmission of the data in the core network.

Example 50 includes the apparatus of example 48 or 49, wherein the processing circuitry is to receive the data from the UE via both the MeNB and the SeNB.

Example 51 includes the apparatus of any one of examples 48-50, wherein the processing circuitry is to receive the data, including the first part of the data, from the MeNB.

Example 52 includes the apparatus of any one of examples 48-51, wherein processing circuitry is to transmit a transport-layer data transfer management message to control a data rate of the transport network.

Example 53 includes one or more computer-readable media having instructions that, when executed, cause a mobile proxy to: process data received from a user equipment (UE) via a macro eNB (MeNB) or a small-cell eNB (SeNB), at least a first part of the data transmitted from the UE to the SeNB using a frequency greater than 6 gigahertz

(GHz); temporarily store the data in the memory circuitry; and transmit the data through a core network via a transport network terminated at the apparatus.

Example 54 includes the one or more computer-readable media of example 53, wherein the instructions, when executed, further cause the mobile proxy to schedule transmission of the data in the core network.

Example 55 includes the one or more computer-readable media of example 53 or 54, wherein the data is received from the UE via both the MeNB and the SeNB. Example 56 includes the one or more computer-readable media of any one of examples 53-55, wherein the data, including the first part of the data, is received from the Me B.

Example 57 includes the one or more computer-readable media of any one of examples 53-56, wherein the instructions, when executed, further cause the mobile proxy to transmit a transport-layer data transfer management message to control a data rate of the transport network.

Example 58 includes one or more computer-readable media having instructions that, when executed, cause a mobile proxy to: process data communicated between a core network and a user equipment communicatively coupled with the mobile proxy through a radio access network; and terminate a transmission control protocol (TCP) layer to reduce radio channel capacity fluctuation in the radio access network.

Example 59 includes the one or more computer-readable media of example 58, wherein the instructions, when executed, further cause the mobile proxy to: manipulate a rate of network traffic at the TCP layer based on a capacity of the radio access network.

Example 60 includes the one or more computer-readable media of example 59, wherein the mobile proxy is to utilize a TCP rate control procedure to manipulate the network traffic.

Example 61 includes the one or more computer-readable media of any one of examples 59-60, wherein the instructions, when executed, are to process a link-capacity report from a macro evolved node B (MeNB) to determine a capacity of the radio access network with respect to a connection of the user equipment.

Example 62 includes the one or more computer-readable media of any one of examples 58-61, wherein the instructions, when executed, further cause the mobile proxy to: process traffic based on a quality of service requirement.

Example 63 includes the one or more computer-readable media of any one of examples 58-62, wherein the radio access network includes a device to provide one or more millimeterwave (mmWave) connections.

Example 64 includes a mobile proxy comprising: means for processing data communicated between a core network and a user equipment communicatively coupled with the mobile proxy through a radio access network; and means for terminating a transmission control protocol (TCP) layer to reduce radio channel capacity fluctuation in the radio access network. Example 65 includes the mobile proxy of example 64, wherein said means for terminating the TCP layer is further to manipulate network traffic at the TCP layer based on a capacity of the radio access network.

Example 66 includes the mobile proxy of example 65, wherein said means for terminating the TCP layer is to utilize a TCP control mechanism to manipulate the network traffic.

Example 67 includes the mobile proxy of any one of examples 64-66, further comprising means for processing a report from a macro evolved node B (Me B) to determine the capacity of the radio access network.

Example 68 includes the mobile proxy of any one of examples 64-67, wherein said means for processing data is to process traffic based on a quality of service requirement.

Example 69 includes the mobile proxy of any one of examples 64-68, wherein the radio access network includes a device to provide one or more millimeterwave (mmWave) connections.

Example 70 includes a mobile proxy comprising: a transmission control protocol

(TCP) module at least partially implemented in hardware to receive, from a sending entity via a first connection, data directed to a user equipment (UE) to be communicatively coupled with a core network via a radio access network, the TCP module to send one or more transport layer messages to the sending entity via the first connection to control a data rate of a transport network; and a transport-radio air interface module at least partially implemented in hardware to cause the data to be transmitted to the UE via a second connection between the UE and the core network.

Example 71 includes the mobile proxy of example 70, wherein the first connection traverses an Internet protocol (IP) network and the second connection traverses a radio air interface.

Example 72 includes the mobile proxy of example 70 or 71, wherein the one or more transport layer messages includes a transport-layer data transfer management message to control a rate of transmission of data from the sending entity.

Example 73 includes the mobile proxy of example 72, wherein the TCP module is to negatively acknowledge a successfully received transmission to reduce the rate of transmission.

Example 74 includes the mobile proxy of example 72 or 73, wherein the TCP module is to control the data rate based on link capacity provided to the UE from a macro e B (MeNB) or a small-cell eNB (SeNB). Example 75 includes the mobile proxy of any one of examples 70-74, wherein the mobile proxy is to receive an indication of the link capacity via the second connection.

Example 76 includes the mobile proxy of any one of examples 70-75, wherein the mobile proxy is to receive, from a macro eNB (MeNB) an indication of a schedule of transmission of data to the UE by the MeNB or a small-cell eNB (SeNB).

Example 77 includes the mobile proxy of any one of examples 70-76, wherein the mobile proxy is to transmit, to a macro eNB (MeNB), an indication of a schedule of transmission of data to the UE by the MeNB or a small-cell eNB (SeNB).

Example 78 includes the mobile proxy of example 76 or 77, wherein the schedule includes at least a portion of the data being transmitted to the UE by the SeNB, and the SeNB is to communicate with the UE using a frequency greater than 6 gigahertz.

Example 79 includes the mobile proxy of any one of examples 70-78, wherein the mobile proxy is to receive an indication of data to be transmitted from the UE to a receiving entity and the TCP module is to establish the first connection based on the indication of the data to be transmitted from the UE.

Example 80 includes the mobile proxy of example 79, wherein the TCP module is to establish the first connection using a three-way handshake.

Example 81 includes a macro eNB (MeNB) comprising: communication logic at least partially implemented in hardware to receive, from a mobile proxy residing in a core network element, a notification of data to be transmitted to a user equipment (UE), the notification to include a type, size, or quality of service (QoS) requirement of the data; and scheduling logic at least partially implemented in hardware to generate a schedule for transmission of the data over a radio air interface through a first link provided by the MeNB or a second link provided by a small-cell eNB (SeNB) based on the notification, wherein the communication logic is further to transmit an indication of the schedule to the mobile proxy.

Example 82 includes the MeNB of example 81, wherein the communication logic is to provide, to the mobile proxy, an indication of link capacity provided to the UE from the MeNB or the SeNB.

Example 83 includes the MeNB of example 82, wherein the communication logic is to transmit a message to the mobile proxy that includes both the indication of the link capacity and the indication of the schedule. Example 84 includes the MeNB of any one of examples 81-83, wherein the communication logic is to further transmit an indication of an updated link capacity provided to the UE by the MeNB or the SeNB.

Example 85 includes the MeNB of any one of examples 81-84, wherein the schedule for transmission of the data over the air interface includes at least a first portion of the data being scheduled to be provided to the UE by the SeNB, wherein the SeNB is to transmit at least the first portion of the data using a frequency greater than 6 gigahertz.

Example 86 includes the MeNB of any one of examples 81-85, wherein the schedule for transmission of the data over the air interface includes at least a first portion of the data being scheduled to be provided to the UE by the MeNB and the communication logic is to receive at least the first portion of the data from a core network and to transmit at least the first portion to the UE using a frequency less than 6 gigahertz.

Example 87 includes a macro eNB (MeNB) comprising: control circuitry to determine a link capacity provided to a user equipment (UE) through a first link provided by the MeNB and a second link provided by a small-cell eNB (SeNB); and transceiver circuitry, coupled with the control circuitry, to: transmit the link capacity to a mobile proxy residing in a core network element; and receive, from a mobile proxy residing in a core network element, a notification of a schedule for transmission of data to the UE through the first link or the second link.

Example 88 includes the MeNB of example 87, wherein the schedule for transmission of data includes at least a portion of the data scheduled through the second link.

Example 89 includes the MeNB of example 88, wherein the transceiver circuitry is further to transmit a wake-up signal to the UE to instruct the UE to wake up an air interface associated with the second link.

Example 90 includes the MeNB of example 89, wherein the transceiver circuitry is to transmit the wake-up signal via the first link.

Example 91 includes the MeNB of any one of examples 87-90, wherein the schedule for transmission of data includes first data scheduled through the first link and communication circuitry is further to receive the first data from the mobile proxy and to transmit the first data to the UE via the first link.

Example 92 includes the MeNB of any one of examples 87-91, wherein the communication circuitry is to further transmit an indication of an updated link capacity provided to the UE by the MeNB or the SeNB. Example 93 includes a macro e B (MeNB) comprising: communication logic to provide a first link of a radio air interface for communication with a user equipment (UE); and scheduling logic at least partially implemented in hardware to: receive, via the communication logic, an uplink traffic report from the UE; generate a schedule to indicate transmission of first uplink data through a second link of the air interface, the second link provided by a small-cell eNB (SeNB) using a frequency greater than 6 gigahertz; and cause the schedule to be transmitted to the UE via the first link.

Example 94 includes the MeNB of example 93, wherein the communication logic is to communicate with a mobile proxy that resides in a core network element.

Example 95 includes the MeNB of any one of examples 93-94, wherein the communication logic is to receive second uplink data through the first link and to transmit the second uplink data to the mobile proxy.

Example 96 includes a method of operating a macro eNB (MeNB), the method comprising: providing a first link of a radio air interface for communication with a user equipment (UE); and receiving an uplink traffic report from the UE; generating a schedule to indicate transmission of first uplink data through a second link of the air interface, the second link provided by a small-cell eNB (SeNB) using a frequency greater than 6 gigahertz; and causing the schedule to be transmitted to the UE via the first link.

Example 97 includes the method of example 96, further comprising

communicating with a mobile proxy that resides in a core network element.

Example 98 includes the method of any one of examples 96-97, further comprising receiving second uplink data through the first link and transmitting the second uplink data to the mobile proxy.

Example 99 includes a method of operating a mobile proxy, the method comprising: receiving, from a sending entity via a first connection, data directed to a user equipment (UE) to be communicatively coupled with a core network via a radio access network; controlling a data rate of a transport network; and causing the data to be transmitted to the UE via a second connection between the UE and the core network.

Example 100 includes the method of example 99, wherein controlling the data rate of the transport network comprises sending one or more transport layer messages to the sending entity via the first connection.

Example 101 includes the method of example 100, wherein the one or more transport layer messages includes a transport-layer data transfer management message to control a rate of transmission of data from the sending entity. Example 102 includes the method of any one of examples 99-101, wherein the first connection traverses an Internet protocol (IP) network and the second connection traverses a radio air interface.

Example 103 includes the method of any one of examples 99-101, wherein controlling the data rate comprises negatively acknowledging a successfully received transmission to reduce the rate of transmission.

Example 104 includes the method of any one of examples 99-103, wherein controlling the data rate is based on link capacity provided to the UE from a macro eNB (MeNB) or a small-cell eNB (SeNB).

Example 105 includes the method of any one of examples 99-104, further comprising receiving an indication of the link capacity via the second connection.

Example 106 includes the method of any one of examples 99-105, further comprising receiving, from a macro eNB (MeNB) an indication of a schedule of transmission of data to the UE by the MeNB or a small-cell eNB (SeNB).

Example 107 includes the method of any one of examples 99-106, further comprising transmitting, to a macro eNB (MeNB), an indication of a schedule of transmission of data to the UE by the MeNB or a small-cell eNB (SeNB).

Example 108 includes the method of example 106 or 107, wherein the schedule includes at least a portion of the data being transmitted to the UE by the SeNB, and the SeNB is to communicate with the UE using a frequency greater than 6 gigahertz.

Example 109 includes the method of any one of examples 99-108, wherein the mobile proxy is to receive an indication of data to be transmitted from the UE to a receiving entity and the TCP module is to establish the first connection based on the indication of the data to be transmitted from the UE.

Example 110 includes the method of example 109, further comprising establishing the first connection using a three-way handshake.

Example 111 includes a method of operating a macro eNB (MeNB), the method comprising: receiving, from a mobile proxy residing in a core network element, a notification of data to be transmitted to a user equipment (UE), the notification to include a type, size, or quality of service (QoS) requirement of the data; generating a schedule for transmission of the data over a radio air interface through a first link provided by the MeNB or a second link provided by a small-cell eNB (SeNB) based on the notification; and transmitting a notification of the schedule to the mobile proxy. Example 112 includes the method of example 111, further comprising providing, to the mobile proxy, an indication of link capacity provided to the UE from the MeNB or the SeNB.

Example 113 includes the method of example 112, further comprising transmitting a message to the mobile proxy that includes both the indication of the link capacity and the notification of the schedule.

Example 114 includes the method of any one of examples 111-113, further comprising transmitting an indication of an updated link capacity provided to the UE by the MeNB or the SeNB.

Example 115 includes the method of any one of examples 111-114, wherein the schedule for transmission of the data over the air interface includes at least a first portion of the data being scheduled to be provided to the UE by the SeNB, wherein the SeNB is to transmit at least the first portion of the data using a frequency greater than 6 gigahertz.

Example 116 includes the method of any one of examples 111-115, wherein the schedule for transmission of the data over the air interface includes at least a first portion of the data being scheduled to be provided to the UE by the MeNB and the method further comprises receiving at least the first portion of the data from a core network and transmitting at least the first portion to the UE using a frequency less than 6 gigahertz.

Example 117 includes a method of operating a macro eNB (MeNB), the method comprising: determining a link capacity provided to a user equipment (UE) through a first link provided by the MeNB and a second link provided by a small-cell eNB (SeNB); and transmitting the link capacity to a mobile proxy residing in a core network element; and receiving, from a mobile proxy residing in a core network element, a notification of a schedule for transmission of data to the UE through the first link or the second link.

Example 118 includes the method of example 117, wherein the schedule for transmission of data includes at least a portion of the data scheduled through the second link.

Example 119 includes the method of example 118, further comprising transmitting a wake-up signal to the UE to instruct the UE to wake up an air interface associated with the second link.

Example 120 includes the method of example 119, further comprising transmitting the wake-up signal via the first link.

Example 121 includes the method of any one of examples 117-120, wherein the schedule for transmission of data includes first data scheduled through the first link and the method further comprises receiving the first data from the mobile proxy and transmitting the first data to the UE via the first link.

Example 122 includes the method of any one of examples 117-121, further comprising transmitting an indication of an updated link capacity provided to the UE by the Me B or the Se B .

Example 123 includes a method of operating a mobile proxy, the method comprising buffering traffic received from a sending entity over a transport network that traverses a core network, controlling a data rate of the transport network; and causing the traffic to be transmitted from the core network to a macro e B (MeNB) or a small-cell eNB (SeNB) for subsequent transmission to a user equipment (UE), wherein the SeNB is to communicate with the UE using a frequency greater than 6 gigahertz (GHz).

Example 124 includes the method of example 123, wherein controlling the data rate comprises causing a transport-layer data transfer management message to be transmitted to the sending entity.

Example 125 includes the method of example 123 or example 124, wherein controlling the data rate is based on link capacity of a radio air interface.

Example 126 includes the method of example 125, further comprising determining the link capacity based on an indication of link capacity received from the MeNB or the SeNB.

Example 127 includes the method of example 126, wherein the indication of link capacity is included in a message along with a notification of a scheduling decision, the message received from the MeNB.

Example 128 includes the method of any one of examples 124-127, wherein the transport-layer data transfer management message is a transmission control protocol (TCP) message.

Example 129 includes the method of any one of examples 123-128, further comprising negatively acknowledging a successfully received transmission to control the data rate.

Example 130 includes an apparatus to perform the method of any one of examples 96-129 or any other example.

Example 131 includes an apparatus comprising means to perform the method of any one of examples 96-129 or any other example. Example 132 includes one or more computer-readable media, which may be non- transitory, that include instructions that, when executed, cause a device to perform any one of the methods of examples 96-129 or any other example.

Example 133 includes an apparatus comprising: means for receiving traffic from a sending entity over a transport network that traverses a core network, means for buffering the traffic in a memory circuitry; means for controlling a data rate of the transport network; and means for causing the traffic to be transmitted from the core network to a macro e B (MeNB) or a small-cell eNB (SeNB) for subsequent transmission to a user equipment (UE). In some examples, the SeNB is to communicate with the UE using a frequency greater than 6 gigahertz (GHz).

Example 134 includes the apparatus of example 133, further comprising means for causing a transport-layer data transfer management message to be transmitted to the sending entity to control the data rate of the transport network.

Example 135 includes the apparatus of example 134, wherein the transport-layer data transfer management message is a transmission control protocol (TCP)

acknowledgment message.

Example 136 includes the apparatus of any one of claims 133-135, further comprising means for receiving an indication of link capacity provided to the UE from the MeNB or the SeNB and means for controlling the data rate of the transport network based on the link capacity.

Example 137 includes the apparatus of example 136, wherein the indication of the link capacity is included in a message along with a notification of a scheduling decision.

Example 138 includes the apparatus of example 136 or 137, further comprising means for receiving an indication of an updated link capacity provided to the UE by the MeNB or the SeNB.

Example 139 includes the apparatus of any one of examples 134-138, wherein the transport-layer data transfer management message is a transport-layer NACK message, and the apparatus further comprises means for causing transmission of the transport-layer NACK message to the sending entity to control a rate of transmission of data from the sending entity to facilitate transport congestion control.

Example 140 includes the apparatus of example 139, further comprising means for causing transmission of the transport-layer NACK message independent of whether the data was received successfully. Example 141 includes the apparatus of any one of examples 133-140, further comprising means for causing transmission of a notification, to the MeNB, of the traffic prior to transmission of the traffic.

Example 142 includes the apparatus of example 141, wherein the notification of the traffic includes a notification of a type, size, or quality of service requirement of the traffic.

Example 143 includes about apparatus of example 141 or 142, further comprising means for receiving a notification of a scheduling decision of the MeNB, and means for transmitting the data to the MeNB or the SeNB based on the notification.

Example 144 includes the apparatus of any one of examples 141-143, further comprising means for generating a schedule of transmission of traffic by the MeNB or the SeNB and to transmit a notification of the schedule to the MeNB.

Example 145 includes the apparatus of example 144, further comprising means for generating the schedule based on a type, size, or quality of service requirement of the traffic.

Example 146 includes the apparatus of example 145, further comprising means for receiving an indication of link capacity provided to the UE by the MeNB or the SeNB and means for scheduling transmission of the traffic based on the indication of the link capacity.

Example 147 includes the apparatus of any one of examples 133-146, wherein the apparatus is disposed in a core network.

Example 148 includes the apparatus of example 147, wherein the apparatus is disposed in a serving gateway.

Example 149 includes an apparatus for operating a mobile proxy, comprising: means for processing a link-capacity report received from a macro eNB (MeNB), the link- capacity report to include a link capacity of a first link provided to a user equipment (UE) by a small-cell eNB (SeNB), the first link to use a frequency greater than 6 gigahertz (GHz); and means for controlling a data rate of a transport network based on the link- capacity report.

Example 150 includes the apparatus of example 149, wherein the means for controlling a data rate of a transport network includes means for transmitting a transport- layer data transfer management message to a sending entity.

Example 151 includes the apparatus of example 150, wherein the transport-layer message is an acknowledgment/negative acknowledgment (ACK/NACK) message. Example 152 includes the apparatus of example 150 or 151, wherein the transport- layer data transfer management message is a transmission control protocol (TCP) message.

Example 153 includes the apparatus of any one of examples 149-152, wherein the means for controlling the data rate comprises means for performing congestion or flow control in the transport network.

Example 154 includes the apparatus of any one of examples 149-153, wherein the means for controlling the data rate comprises means for performing congestion or flow control for individual quality of service (QoS) classes.

Example 155 includes the apparatus of any one of examples 149-154, further comprising means for generating a schedule of transmitting data to the UE by the MeNB or the SeNB based on the link-capacity report.

Example 156 includes the apparatus of example 155, further comprising: means for determining a quality of service (QoS) class of the data; and means for generating the schedule based on the QoS class.

Example 157 includes in apparatus comprising: means for receiving data from a user equipment (UE) via a macro eNB (MeNB) or a small-cell eNB (SeNB), at least a first part of the data transmitted from the UE to the SeNB using a frequency greater than 6 gigahertz (GHz); means for temporarily storing the data in a memory circuitry; and means for transmitting the data through a core network via a transport network terminated at the apparatus.

Example 158 includes the apparatus of example 157, further comprising means for scheduling transmission of the data in the core network.

Example 159 includes the apparatus of example 157 or 158, further comprising means for receiving the data from the UE via both the MeNB and the SeNB.

Example 160 includes the apparatus of any one of examples 157-159, further comprising means for receiving the data, including the first part of the data, from the MeNB.

Example 161 includes the apparatus of any one of examples 157-160, further comprising means for transmitting a transport-layer data transfer management message to control a data rate of the transport network.

Example 162 includes an apparatus in a mobile proxy, comprising: means for receiving, from a sending entity via a first connection, data directed to a user equipment (UE) to be communicatively coupled with a core network via a radio access network; means for controlling a data rate of a transport network; and means for causing the data to be transmitted to the UE via a second connection between the UE and the core network.

Example 163 includes the apparatus of example 162, wherein the means for controlling the data rate of the transport network comprises means for sending one or more transport layer messages to the sending entity via the first connection.

Example 164 includes the apparatus of example 163, wherein the one or more transport layer messages includes a transport-layer data transfer management message to control a rate of transmission of data from the sending entity.

Example 165 includes the apparatus of any one of examples 162-164, wherein the first connection traverses an Internet protocol (IP) network and the second connection traverses a radio air interface.

Example 166 includes the apparatus of any one of examples 162-164, wherein the means for controlling the data rate comprises means for negatively acknowledging a successfully received transmission to reduce the rate of transmission.

Example 167 includes the apparatus of any one of examples 162-166, wherein the means for controlling the data rate is based on link capacity provided to the UE from a macro eNB (MeNB) or a small-cell eNB (SeNB).

Example 168 includes the apparatus of any one of examples 162-166, further comprising means for receiving an indication of the link capacity via the second connection.

Example 169 includes the apparatus of any one of examples 162-168, further comprising means for receiving, from a macro eNB (MeNB) an indication of a schedule of transmission of data to the UE by the MeNB or a small-cell eNB (SeNB).

Example 170 includes the apparatus of any one of examples 162-169, further comprising means for transmitting, to a macro eNB (MeNB), an indication of a schedule of transmission of data to the UE by the MeNB or a small-cell eNB (SeNB).

Example 171 includes the apparatus of example 169 or 170, wherein the schedule includes at least a portion of the data being transmitted to the UE by the SeNB, and the SeNB is to communicate with the UE using a frequency greater than 6 gigahertz.

Example 172 includes the apparatus of any one of examples 162-171, wherein the mobile proxy is to receive an indication of data to be transmitted from the UE to a receiving entity and the TCP module is to establish the first connection based on the indication of the data to be transmitted from the UE. Example 173 includes the apparatus of example 172, further comprising means for establishing the first connection using a three-way handshake.

Example 174 includes an apparatus in a macro eNB (MeNB), comprising: means for receiving, from a mobile proxy residing in a core network element, a notification of data to be transmitted to a user equipment (UE), the notification to include a type, size, or quality of service (QoS) requirement of the data; means for generating a schedule for transmission of the data over a radio air interface through a first link provided by the MeNB or a second link provided by a small-cell eNB (SeNB) based on the notification; and means for transmitting a notification of the schedule to the mobile proxy.

Example 175 includes the apparatus of example 174, further comprising means for providing, to the mobile proxy, an indication of link capacity provided to the UE from the MeNB or the SeNB.

Example 176 includes the apparatus of example 175, further comprising means for transmitting a message to the mobile proxy that includes both the indication of the link capacity and the notification of the schedule.

Example 177 includes the apparatus of any one of examples 174-176, further comprising means for transmitting an indication of an updated link capacity provided to the UE by the MeNB or the SeNB.

Example 178 includes the apparatus of any one of examples 174-177, wherein the schedule for transmission of the data over the air interface includes at least a first portion of the data being scheduled to be provided to the UE by the SeNB, wherein the SeNB is to transmit at least the first portion of the data using a frequency greater than 6 gigahertz.

Example 179 includes the apparatus of any one of examples 174-178, wherein the schedule for transmission of the data over the air interface includes at least a first portion of the data being scheduled to be provided to the UE by the MeNB and the apparatus further comprises means for receiving at least the first portion of the data from a core network and transmitting at least the first portion to the UE using a frequency less than 6 gigahertz.

Example 180 includes an apparatus in a macro eNB (MeNB), comprising: means for determining a link capacity provided to a user equipment (UE) through a first link provided by the MeNB and a second link provided by a small-cell eNB (SeNB); means for transmitting the link capacity to a mobile proxy residing in a core network element; and means for receiving, from a mobile proxy residing in a core network element, a notification of a schedule for transmission of data to the UE through the first link or the second link.

Example 181 includes the apparatus of example 180, wherein the schedule for transmission of data includes at least a portion of the data scheduled through the second link.

Example 182 includes the apparatus of example 180, further comprising means for transmitting a wake-up signal to the UE to instruct the UE to wake up an air interface associated with the second link.

Example 183 includes the apparatus of example 182, further comprising means for transmitting the wake-up signal via the first link.

Example 184 includes the apparatus of any one of examples 180-183, wherein the schedule for transmission of data includes first data scheduled through the first link and the apparatus further comprises means for receiving the first data from the mobile proxy and transmitting the first data to the UE via the first link.

Example 185 includes the apparatus of any one of examples 180-184, further comprising means for transmitting an indication of an updated link capacity provided to the UE by the MeNB or the Se B.

Example 186 includes a link-capacity report message, comprising: a data rate field for communicating a link-capacity status of a radio link towards a user equipment (UE); and a UE identifier field for communicating an identifier of the UE.

Example 187 includes the link-capacity report message of example 186, further comprising: a dropout indication field for communicating information on a dropout frequency of a first link between the UE and a small-cell eNB (SeNB).

Example 188 includes the link-capacity report message of example 187, wherein the dropout indication field is for communicating information on an average dropout frequency of the first link.

Example 189 includes the link-capacity report message of any one of examples 186-188, further comprising a connection reestablishment time indication field for communicating information on a connection reestablishment time of a first link between the UE and a small-cell eNB (SeNB).

Example 190 includes the link-capacity report message of example 189, wherein connection reestablishment time indication field is for communicating information on an average connection reestablishment time of a first link. Example 191 includes the link-capacity report message of any one of examples 186-190, wherein the radio link is a link between the UE and a small-cell e B (SeNB).

Example 192 includes the link-capacity report message of example 191, wherein the link-capacity report message further comprises a second data rate field for communicating a link-capacity status of another radio link between the UE and a macro- cell eNB (MeNB).

Example 193 includes the link-capacity report message of any one of examples 186-192, wherein the link-capacity status is statistical information about the rate at which IP packets are successfully delivered a user equipment (UE).

Example 194 includes the link-capacity report message of any one of examples

186-193, wherein the link-capacity report message is a non-access stratum message.

Example 195 includes the link-capacity report message of any one of examples 186-194, wherein the identifier of the UE is an IP address assigned to the UE.

The description herein of illustrated implementations, including what is described in the Abstract, is not intended to be exhaustive or to limit the present disclosure to the precise forms disclosed. While specific implementations and examples are described herein for illustrative purposes, a variety of alternate or equivalent embodiments or implementations calculated to achieve the same purposes may be made in light of the above detailed description, without departing from the scope of the present disclosure, as those skilled in the relevant art will recognize.

Claims

CLAIMS What is claimed is:

1. An apparatus comprising:

memory circuitry; and

processing circuitry coupled with the memory circuitry, the processing circuitry to:

receive traffic from a sending entity over a transport network that traverses a core network,

buffer the traffic in the memory circuitry;

control a data rate of the transport network; and

cause the traffic to be transmitted from the core network to a first eNB or a second eNB for subsequent transmission to a user equipment (UE).

2. The apparatus of claim 1, wherein the processing circuitry is to cause a transport-layer data transfer management message to be transmitted to the sending entity to control the data rate of the transport network.

3. The apparatus of claim 2, wherein the transport-layer data transfer management message is a transmission control protocol (TCP) positive or negative acknowledgment message.

4. The apparatus of any one of claims 1-3, wherein the processing circuitry is to receive an indication of link capacity provided to the UE from the first or the second eNB and to control the data rate of the transport network based on the link capacity.

5. The apparatus of any one of claims 1-3, wherein the processing circuitry is further to receive a notification of a scheduling decision of the first eNB and to transmit the data to the first or the second eNB based on the notification.

6. The apparatus of any one of claims 1-3, wherein the processing circuitry is to generate a schedule of transmission of traffic by the first or the second eNB and to transmit a notification of the schedule to the first eNB.

7. The apparatus of claim 6, wherein the processing circuitry is to generate the schedule based on a type, size, or quality of service requirement of the traffic.

8. The apparatus of claim 7, wherein the processing circuitry is to receive an indication of link capacity provided to the UE by the first or the second eNB and to schedule transmission of the traffic based on the indication of the link capacity.

9. One or more computer-readable media having instructions that, when executed, cause a mobile proxy to: process a link-capacity report received from a macro e B (MeNB), the link-capacity report to include a link capacity of a first link provided to a user equipment (UE) by a small-cell eNB (SeNB), the first link to use a frequency greater than 6 gigahertz (GHz); and

transmit a transport-layer data transfer management message to a sending entity based on the link-capacity report, the transport-layer data transfer management message to control a data rate of a transport network.

10. The one or more computer-readable media of claim 9, wherein the transport- layer message is an acknowledgment/negative acknowledgment (ACK/NACK) message.

11. The one or more computer-readable media of claim 9 or 10, wherein the transport-layer data transfer management message is a transmission control protocol (TCP) message.

12. The one or more computer-readable media of claim 9 or 10, wherein the transport-layer data transfer management message is to provide congestion or flow control in the transport network.

13. The one or more computer-readable media of claim 12, wherein the

instructions, when executed, further cause the mobile proxy to generate the transport-layer data transfer management message to provide congestion or flow control for individual quality of service (QoS) classes.

14. The one or more computer-readable media of claim 9 or 10, wherein the instructions, when executed, further cause the mobile proxy to generate a schedule of transmitting data to the UE by the MeNB or the SeNB based on the link-capacity report.

15. The one or more computer-readable media of claim 14, wherein the

instructions, when executed, further cause the mobile proxy to:

determine a quality of service (QoS) class of the data; and

generate the schedule based on the QoS class.

16. One or more computer-readable media having instructions that, when executed, cause a mobile proxy to:

process data communicated between a core network and a user equipment communicatively coupled with the mobile proxy through a radio access network; and

terminate a transmission control protocol (TCP) layer to reduce radio channel capacity fluctuation in the radio access network.

17. The one or more computer-readable media of claim 16, wherein the

instructions, when executed, further cause the mobile proxy to: manipulate network traffic at the TCP layer based on a capacity of the radio access network.

18. The one or more computer-readable media of claim 17, wherein the mobile proxy is to utilize a TCP control mechanism to manipulate the network traffic.

19. The one or more computer-readable media of any one of claims 17-18, wherein the instructions, when executed, are to process a report from a macro evolved node B (MeNB) to determine the capacity of the radio access network.

20. The one or more computer-readable media of any one of claims 17-18, wherein the radio access network includes a device to provide one or more millimeterwave (mmWave) connections.

21. A macro eNB (MeNB) comprising:

communication logic at least partially implemented in hardware to receive, from a mobile proxy residing in a core network element, a notification of data to be transmitted to a user equipment (UE), the notification to include a type, size, or quality of service (QoS) requirement of the data; and

scheduling logic at least partially implemented in hardware to generate a schedule for transmission of the data over a radio air interface through a first link provided by the MeNB or a second link provided by a small-cell eNB (SeNB) based on the notification,

wherein the communication logic is further to transmit an indication of the schedule to the mobile proxy.

22. The MeNB of claim 21, wherein the communication logic is to provide, to the mobile proxy, an indication of link capacity provided to the UE from the MeNB or the SeNB.

23. The MeNB of claim 22, wherein the communication logic is to transmit a message to the mobile proxy that includes both the indication of the link capacity and the indication of the schedule.

24. The MeNB of any one of claims 21-23, wherein the communication logic is to further transmit an indication of an updated link capacity provided to the UE by the MeNB or the SeNB.

25. The MeNB of any one of claims 21-23, wherein the schedule for transmission of the data over the air interface includes at least a first portion of the data being scheduled to be provided to the UE by the SeNB, wherein the SeNB is to transmit at least the first portion of the data using a frequency greater than 6 gigahertz.

26. The MeNB of any one of claims 21-23, wherein the schedule for transmission of the data over the air interface includes at least a first portion of the data being scheduled to be provided to the UE by the MeNB and the communication logic is to receive at least the first portion of the data from a core network and to transmit at least the first portion to the UE using a frequency less than 6 gigahertz.

27. A macro eNB (MeNB) comprising:

control circuitry to determine a link capacity provided to a user equipment (UE) through a first link provided by the MeNB and a second link provided by a small-cell eNB (SeNB); and

transceiver circuitry, coupled with the control circuitry, to:

transmit the link capacity to a mobile proxy residing in a core network element; and

receive, from a mobile proxy residing in a core network element, a notification of a schedule for transmission of data to the UE through the first link or the second link.

28. The MeNB of claim 27, wherein the schedule for transmission of data includes at least a portion of the data scheduled through the second link.

29. The MeNB of claim 28, wherein the transceiver circuitry is further to transmit a wake-up signal to the UE to instruct the UE to wake up an air interface associated with the second link.

30. The MeNB of any one of claims 27-29, wherein the schedule for transmission of data includes first data scheduled through the first link and the transceiver circuitry is further to receive the first data from the mobile proxy and to transmit the first data to the UE via the first link.