WO2017018970A1

WO2017018970A1 - Use of quality of service parameters during lte/wlan aggregation

Info

Publication number: WO2017018970A1
Application number: PCT/US2015/000464
Authority: WO
Inventors: Alexander Sirotkin
Original assignee: Intel IP Corp
Current assignee: Intel IP Corp
Priority date: 2015-07-24
Filing date: 2015-12-26
Publication date: 2017-02-02
Anticipated expiration: 2018-01-24

Abstract

Quality of Service (QoS) parameters are mapped between Long Term Evolution (LTE) and Wireless Local Area Network (WLAN) access nodes. For example, according to techniques described herein, LTE traffic, when offloaded to a WLAN access point, may be mapped to have QoS parameters, at the WLAN, that are compatible with the QoS parameters that were associated with the LTE traffic. In this manner, QoS can be consistently applied for traffic that is split between LTE and WLAN carriers using LTE/WLAN aggregation (LWA).

Description

USE OF QUALITY OF SERVICE PARAMETERS

DURING LTE/WLAN AGGREGATION

RELATED APPLICATIONS

The present application claims the benefit of U.S. Provisional Patent Application No. 62/196,446, which was filed on July 24, 2015, the contents of which is hereby incorporated by reference as though fully set forth herein.

BACKGROUND

Growth in data traffic driven by smart phone devices, tablets, etc., can strain the capacity of wireless networks. One approach, used by the wireless industry, to address the growth in data traffic, has been network densification wherein small cells are used to increase reuse of licensed spectrum, which continues to be scarce and expensive. Additionally, network operators have also increasingly utilized unlicensed spectrum (e.g., WiFi spectrum) to cope with the increasing capacity demand.

Evolved Universal Terrestrial Radio Access (E-UTRA) refers to the air interface of the 3GPP (3rd Generation Partnership Project) Long Term Evolution (LTE) mobile network standard. The E-UTRA network (E-UTRAN) supports aggregation of communications using LTE spectrum (licensed spectrum) and Wireless Local Area Network (WLAN) spectrum (e.g., unlicensed WiFi spectrum). When operating in aggregation mode, which may be referred to as LTE/WLAN aggregation (LWA), mobile devices may be configured by the E-UTRA base station to utilize both LTE and WLAN radio resources. The base station supporting LWA may be connected to the WLAN via a backhaul link in either a collocated deployment (e.g., the base station and the WLAN Access Point are deployed as an integrated unit) or non-collocated scenario.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments described herein will be readily understood by the following detailed description in conjunction with the accompanying drawings. To facilitate this description, like reference numerals may designate like structural elements. Embodiments are illustrated by way of example and not by way of limitation in the figures of the accompanying drawings.

Fig. 1 is a diagram of an example environment in which systems and/or methods described herein may be implemented; Fig. 2 is a flow chart illustrating an example process for mapping Quality of Service (QoS) parameters from LTE to WLAN;

Fig. 3 is a flow chart illustrating an example process for offloading traffic from LTE to WLAN using LWA;

Fig. 4 is a flow chart illustrating an example process for implementing an alternative embodiment described herein;

Fig. 5 is a flow chart illustrating an example process for implementing an alternative embodiment described herein;

Fig. 6 is a diagram illustrating example components of an electronic device; and Fig. 7 illustrates an example system.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

The following detailed description refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements. 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. Therefore, the following detailed description is not to be taken in a limiting sense, and the scope of embodiments defined by the appended claims and their equivalents.

Quality of Service (QoS) models for 3GPP LTE cellular communications (hereinafter, simply "LTE" or "LTE communications") and WLAN communications are significantly different. For example, for LTE, a number of parameters may be used to define the QoS associated with a bearer. The QoS for a WLAN traffic flow may be defined by another set of parameters. More particularly, for LTE, the parameters may include: a QoS Class Identifier (QCI) parameter; an Allocation and Retention Priority (ARP) parameter; a Guaranteed Bit Rate (GBR) parameter; a Maximum Bit Rate (MBR) parameter; an Access Point Name-Aggregate Maximum Bit Rate (APN-AMBR) parameter; and a User Equipment (UE)-AMBR parameter. For WLAN, however, bit rate is not guaranteed and QoS for WLAN traffic is defined based on four QoS categories: ( 1 ) background, (2) best effort, (3) voice, and (4) video. The four WLAN QoS categories may be referred to as Access Categories (ACs).

Techniques described herein relate to the mapping of QoS parameters between LTE and WLAN. For example, according to techniques described herein, LTE traffic, when offloaded to a WLAN access point, may be mapped to have QoS parameters, at the WLAN, that are compatible with the QoS parameters that were associated with the LTE traffic. In this manner, QoS can be consistently applied to traffic that is split between LTE and WLAN carriers using LWA.

In one implementation, for traffic offloaded to the WLAN, the LTE QoS parameters may be transmitted, via control messages transmitted over an Xw interface, to the WLAN node (e.g., to a WLAN access point or WLAN Termination node). The WLAN node may map the LTE QoS parameters to appropriate WLAN QoS parameters (e.g., WLAN ACs).

Fig. 1 is a diagram of an example environment 100, in which systems and/or methods described herein may be implemented. As illustrated, environment 100 may include User Equipment (UE) 1 10, which may obtain network connectivity from wireless network 120.

Although a single UE 1 10 is shown, for simplicity, in Fig. 1 , in practice, multiple UEs 1 10 may operate in the context of a wireless network. Wireless network 120 may provide access to one or more external networks, such as packet data network ("PDN") 150. The wireless network may include radio access network ("RAN") 130 and core network 140. RAN 130 may be a E- UTRA based radio access network. Some or all of RAN 130 may be associated with a network operator that controls or otherwise manages core network 140. Core network 140 may include an Internet Protocol ("IP")-based network.

UE 1 10 may include a portable computing and communication device, such as a personal digital assistant ("PDA"), a smart phone, a cellular phone, a laptop computer with connectivity to a cellular wireless network, a tablet computer, etc. UE 1 10 may also include non-portable computing devices, such as desktop computers, consumer or business appliances, or other devices that have the ability to wirelessly connect to RAN 130.

RAN 130 may represent a 3GPP access network that includes one or more access technologies. For example, RAN 130 may include base stations. In the context of an LTE-based access network, base stations may be referred to as eNBs (evolved NodeBs or eNodeBs), and are illustrated as eNBs 134 and 136. Some of the eNBs, such as eNB 136, may be associated with one or more WLAN Terminations (WTs) 138. WT 138 may refer to a logical node that acts as the termination point of the Xw interface at the WLAN. In various implementations, WT 138 may be implemented at a WLAN Access Points (AP), a WLAN Access Controller (AC), or another physical entity. In Fig. I , a WLAN AP 139 is shown associated with WT 138.

Although not explicitly shown in Fig. 1 , WT 138 may alternatively or additionally be associated with a WLAN AC. Other eNBs, such as eNB 134, may not be associated with a WT. eNB 134 and WT 138 may provide RAN-based coordination and simultaneous use of the radio resources between different RATs (e.g., 3GPP LTE and WiFi (WLAN)).

WT 138 may be connected to eNB 136 via a backhaul link, such as one implemented over the 3GPP Xw interface. As is further shown in Fig. 1 , eNBs 134 and 136 may be connected via the 3GPP X2 interface. From the perspective of eNB 136, WT 138 may be the only WLAN node connected to eNB 136. However, WT 138 may communicate QoS information, received from WT 138, to the WLAN AP or AC. For clarity, eNB 136 may be described as communication with the WLAN. As used herein this may refer to eNB 136 communicating, via WT 138, with a WLAN AP or AC.

Core network 140 may include an IP-based network. In the 3GPP network architecture, core network 140 may include an Evolved Packet Core (EPC). As illustrated, core network 140 may include serving gateway (SGW) 142, Mobility Management Entity (MME) 144, and packet data network gateway (PGW) 146. Although certain network devices are illustrated in environment 100 as being part of RAN 130 and core network 140, whether a network device is labeled as being in the "RAN" or the "core network" of environment 100 may be an arbitrary decision that may not affect the operation of wireless network 120.

SGW 142 may include one or more network devices that aggregate traffic received from one or more eNBs 134 and/or 136. SGW 142 may generally handle user (data) plane traffic. MME 144 may include one or more computation and communication devices that perform operations to register UE 1 10 with core network 140, establish bearer channels associated with a session with UE 1 10, hand off UE 1 10 from one eNB to another, and/or perform other operations. MME 144 may generally handle control plane traffic. eNBs 134 and 136 may communicate with SGW 142 and MME 144 using an S I interface (e.g., as defined by the 3GPP standards).

PGW 146 may include one or more devices that act as the point of interconnect between core network 140 and external IP networks, such as PDN 150, and/or operator IP services. PGW 146 may route packets to and from the access networks, and the external IP networks.

PDN 150 may include one or more packet-based networks. PDN 1 0 may include one or more external networks, such as a public network (e.g., the Internet) or proprietary networks that provide services that are provided by the operator of core network 140 (e.g., IP multimedia (IMS)-based services, transparent end-to-end packet-switched streaming services (PSSs), or other services). The quantity of devices and/or networks, illustrated in Fig. 1 , is provided for explanatory purposes only. In practice, there may be additional devices and/or networks; fewer devices and/or networks; different devices and/or networks; or differently arranged devices and/or networks than illustrated in Fig. 1. Alternatively, or additionally, one or more of the devices of environment 100 may perform one or more functions described as being performed by another one or more of the devices of environment 100. Furthermore, while "direct" connections are shown in Fig. 1 , these connections should be interpreted as logical communication pathways, and in practice, one or more intervening devices (e.g., routers, gateways, modems, switches, hubs, etc.) may be present.

As mentioned above, eNB 136 may transmit traffic to WT 138 for offloading to the

WLAN. The offloading may include transmitting control messages and the substantive traffic using the Xw interface. The control messages may be transmitted using the Xw control plane and the substantive traffic may be transmitted using the Xw user plane. For example, a bearer may be split between eNB 136 and the WLAN (i.e., packets of the same bearer traffic flow may be scheduled, on a per-packet basis, between eNB 136 and WT 138) or switched between eNB 136 and the WLAN (i.e., packets of the same bearer traffic flow may be alternatively transmitted/received via eNB 136 and the WLAN). With a switched bearer, at any given time, packets of the traffic flow may be transmitted by one of eNB 136 or the WLAN. Since the LTE and WLAN QoS models are different, LTE traffic, when offloaded to the WLAN, it may be desirable to have the LTE QoS parameters converted to compatible QoS WLAN parameters. In this manner, QoS can be consistently applied for traffic that is split between LTE and WLAN carriers using LWA.

As previously mentioned, for LTE, the QoS parameters used by eNB 136 may include: QCI, ARP, GBR, MBR, APN-AMBR, and UE-AMBR. Table I, below, illustrates standardized LTE QCIs, as defined in the 3GPP technical specification 23.203.

3 3 50 ms 10-³ Real Time Gaming

GBR

4 5 . 300 ms 10 ⁶ Non-Conversational

Video (Buffered Streaming)

65 0.7 75 ms Mission Critical user

lo-² plane Push To Talk voice

(e.g., MCPTT)

66 100 ms Non-Mission-Critical user

2 lO ² plane Push To Talk voice

5 1 100 ms 10^"6 IMS Signalling

6 Video (Buffered

6 300 ms 10 ⁶ Streaming)

TCP-based (e.g., www, e- mail, chat, ftp, p2p file sharing, progressive video, etc.)

7 Voice, Video (Live

7 100 ms lO^"3 Streaming)

Interactive Gaming

Non-

8 GBR Video (Buffered

8 Streaming)

10 ^s TCP-based (e.g., www, e-

9 9 300 ms mail, chat, ftp, p2p file sharing, progressive video, etc.)

69 0.5 60 ms 10⁶ Mission Critical delay sensitive signalling (e.g., MC-PTT signalling)

70 5.5 200 ms 10^"6 Mission Critical Data (e.g.

example services are the same as QCI 6/8/9)

As previously mentioned, for WLAN communications, the QoS parameters used by the WLAN may involve assigning bearers into one of four QoS categories: ( 1 ) background, (2) best effort, (3) voice, and (4) video. These categories may be referred to as WLAN Access

Categories (ACs).

Fig. 2 is a flow chart illustrating an example process 200 for mapping QoS parameters from LTE to WLAN. In process 200, when bearers are offloaded to the WLAN, eNB 136 may communicate, using Xw control messages, LTE QoS parameters to WT 138. The WLAN may map the LTE QoS parameters to the WLAN QoS parameters. []

Process 200 may include determining to offload traffic to the WLAN (block 310). As previously mentioned, bearers, associated with wireless network 120, may be split and/or switched so that, for instance, traffic for a particular bearer may be split and simultaneously transmitted, to UE 1 10, via LTE and WLAN radio connections. The Xw control and data plane interfaces may be used to transfer control messages, relating to LWA, and the substantive bearer traffic, respectively.

Process 200 may further include receiving LTE QoS parameters, via the Xw interface, at the WLAN (block 220). The LTE QoS parameters may be transmitted via the Xw control interface (e.g., as Xw Application Protocol (Xw-AP) messages). The LTE QoS parameters may be transmitted on a per-bearer basis (e.g., a per- E-UTRAN Radio Access Bearer (E-RAB) basis). Different bearers may be identified by the corresponding Tunnel Endpoint Identifier (TEID).

In one implementation, when a bearer is offloaded to the WLAN, such as by using an "Xw-AP WT Addition" message or "Xw-AP WT Modification" message, for every E-RAB one or more of the following LTE QoS parameters may be transferred, from eNB 136 to WT 138: ( 1 ) QCI, (2) ARP, (3) GBR (for GBR bearers, if supported), and (4) MBR (for GBR bearers, if supported). Once the bearer is offloaded, the WLAN may use the TEID, associated with each packet, to determine the LTE QoS parameters of the packet.

Process 200 may further include mapping the LTE QoS parameters to the WLAN QoS parameters (block 230). The mapping may be performed by WT 138 and may include determining a corresponding WLAN AC for each bearer, e.g. based on QCI.

In one example implementation, the mapping of block 230 may be performed based on the mappings indicated in Tables II, I II and IV (below). Table II indicates, among other things, mappings between QCI and Differentiated Services Code Point (DSCP) values. Table II I indicates, among other things, mappings between DSCP values and WLAN ACs. In Table III, the abbreviations in the column "EDCA Access Category" refer to the following WLAN ACs: AC Voice (AC_V0), AC Video (AC_VI), AC best effort (AC BE), and AC background (AC_B ).

Table IV combines the information from Tables II and I II to indicate mappings between LTE QCI values and WLAN ACs. The mapping shown in Table IV may be used by WT 138 to determine a WLAN QoS parameter (e.g., an AC) for each bearer that is processed by WT 138.

TABLE IV

QCI WLAN Access Category (AC)

1 Voice

2 Voice

3 Voice 4 Video

5 Best Effort

6 Best Effort

7 Best Effort

8 Best Effort

9 Background

Process 200 may further include enforcing the mapped WLAN QoS parameters (block 240). Thus, the WLAN may communicate, with UE 1 10, via the WLAN radio interface, based on using, for any particular bearer, the corresponding mapped WLAN QoS parameters.

In some implementations, certain LTE QoS parameters, such as ARP, may be used by the WLAN in determining whether to accept or reject a bearer. The decision may be based on WLAN load and possibly based on other considerations. For example, WT 138 may use the ARP "Priority Level" value to decide which bearers to accept and the ARP "Preemption Capability" to decide whether previously offloaded (i.e., bearers previously assigned to the WLAN) bearers should be released (i.e., serviced only by eNB 136) in favor of the recently received bearer. For example, WT 138 may decide not to accept QCI 1 bearers if it cannot guarantee appropriate QoS. Generally, based on ARP, QCI, GBR/MBR and the current status of the WLAN, WT 138 may accept all or some bearers, indicating to eNB 136 (via the Xw interface) which bearers have been accepted. For example, the "Xw-AP WT Addition Request Acknowledge" message may be used to indicate which bearers are accepted/rejected by WT 138.

Fig. 3 is a flow chart illustrating an example process 300 for offloading traffic from LTE to WLAN using LWA. In process 300, WT 138 may determine, based on the LTE QoS parameters, whether to admit or reject bearers.

Process 300 may include receiving the LTE QoS parameters for a bearer (e.g., an E- RAB) (block 3 10). The LTE QoS parameters may be transmitted via the Xw control interface (e.g., as Xw-AP messages). For example, as mentioned, the LTE QoS parameters may be received by WT 138 via an "Xw-AP WT Addition" message or "Xw-AP WT Modification" message.

Process 300 may further include, based on the LTE QoS parameters, determining whether to accept or reject a bearer (block 320). In one implementation, the determination may be based on whether the WLAN can support the LTE QoS parameters. For example, as mentioned, the determination may be based on WLAN load, and only accepting bearers for which the LTE QoS parameters are likely to be satisfied by the WLAN. As previously mentioned, in some implementations, the ARP "Priority Level" value may be used when determining to accept bearers.

Also, as previously mentioned, in some implementations, bearers that were previously accepted at the WLAN may be released in order to accept other bearers. In one implementation, the ARP "Preemption Capability" parameters may be used to decide whether a bearer can be released. Releasing a first bearer in favor of a second bearer may be performed when the ARP "Priority Level" parameter indicates a higher priority level for the second bearer.

Process 300 may further include signaling the acceptance/rejection of a bearer to the eNB (block 330). For example, WT 138, after deciding to accept or reject a bearer, may use the "Xw-AP WT Addition Request Acknowledge" message to indicate the acceptance or rejection of a bearer to eNB 136.

In some implementations, the LTE QoS parameter UE-AMBR may be included, by eNB 136, in the "Xw-AP WT Addition" message or the "Xw-AP WT Modification" message. WT 138 may use this parameter in determining the WLAN QoS parameters to enforce to satisfy the received UE-AMBR parameter. In this situation, eNB 136, when splitting a bearer between eNB 136 and WT 138, may split the UE-AMBR value such that the aggregate maximum bit rate is still satisfied by the aggregate bit rates of the LTE and WLAN links.

Additionally, in some implementations, offloading of GBR bearers (QCI values 1 -4) to the WLAN may be supported. In this situation, the WLAN may use the respective Packet Delay Budget and Packet Loss Error Rate characteristics, of the GBR bearers, to satisfy the corresponding Institute of Electrical and Electronic Engineers (IEEE) 802.1 1 parameters, such as the number of retransmissions ("retry limit") and the Modulation and Coding Scheme (MDS) to use. In some implementations, tuning the WLAN QoS retry limit parameter may also be beneficial for non-GBR bearers. For example, the Packet Delay Budget of a non-GBR bearer may be used to modify the WLAN QoS retry limit.

The above discussion relating to the use of QoS parameters during LWA, describes a first embodiment for using QoS parameters during LWA. A number of additional possible embodiments will next be described.

In a second embodiment, the WLAN may not support the reception of LTE QoS parameters. For example, the network operator may decide that the infrastructure impact on the WLAN, in supporting LTE QoS parameters, is not financially affordable or will have too great of an effect on the performance of the WLAN. In this situation, the Xw control plane interface may not be available. In this embodiment, WT 138 may determine, without access to the LTE QoS parameters, which QoS AC to use for the WLAN traffic. eNB 136 may be configured to only offload best effort bearers.

In a third embodiment, a Xw control plane interface may not be available (similar to the second embodiment). In this implementation, eNB 136 may, for every packet, map LTE QoS parameter values to a Differentiated Services Code Point (DSCP), which eNB 136 may include in a corresponding header of the packet. WT 138 may use the DSCP value to determine a corresponding QoS AC. Alternatively, WT 138 may pass the packets to the WLAN AP and/or Access Controller, which may determine the WLAN QoS AC.

Fig. 4 is a flow chart illustrating an example process 400 for implementing the third embodiment. As shown, process 400 may include mapping, on a per bearer basis, LTE QCI values to DSCP values (block 410). The mapping may be performed by eNB 135. In one implementation, the mapping may be performed as illustrated in Table II.

Process 400 may further include inserting, for each packet, the corresponding mapped DSCP value (block 420). eNB 136 may insert the DSCP value into the IP header of each packet that is to be offloaded to the WLAN. IP headers may conventionally include a DSCP field. Process 400 may further include receiving the packets, at the WT, via the Xw data plane (block 430). The WT may then convert the DSCP field to a corresponding WLAN QoS AC (block 440): Alternatively, as mentioned previously, WT 138 may forward the packets to the WLAN AP or WLAN AC, which may perform the conversion. In one implementation, the conversion of the DSCP field to the corresponding WLAN QoS AC may be performed as illustrated in Table III. The packet may then be transmitted to UE 1 10 based on the WLAN QoS AC (block 440).

In a fourth embodiment, eNB 136 may convert the LTE QoS parameters directly to WLAN QoS parameters, and then transmit the WLAN QoS parameters, via the Xw control plane, to WT 138. This embodiment may be similar to the embodiment described above with respect to Figs. 2 and 3, except that the conversion between LTE QoS parameters and WLAN QoS parameters may be performed at eNB 136.

As an example consistent with the fourth embodiment, eNB 136 may map the LTE QCI value to a WLAN AC. When the bearer is offloaded to WLAN (e.g. using the "Xw-AP WT Addition" message or the "Xw-AP WT Modification" message), eNB 136 may communicate the WLAN AC, rather than the QCI, to WT 138. In a fifth embodiment, some QoS parameters may be enforced by eNB 136 while other QoS parameters may be transmitted to the WLAN. Fig. 5 is a flow chart illustrating an example process 500 for implementing the fifth embodiment.

As shown, process 500 may include enforcing a subset of the LTE QoS parameters at the eNB (block 510). These parameters may not be communicated to WT 138. As one example, eNB 136 may not communicate UE-AMBR (or a portion of it) or APN-AMBR to WT 138. Instead, eNB 138 may enforce these QoS parameters as part of the scheduling of packet transmissions between LTE and/or WLAN. For instance, these parameters may be used when scheduling packets for transmission over the Xw data plane. In this manner, eNB 136 may ensure that UE 1 10 traffic does not violate the bit rate thresholds specified in the UE-AMBR and APN-AMBR parameters. With this implementation, eNB 136 may decide, based on QCI, which bearers are offloaded. For example, eNB 136 may determine not to offload QCI 1 bearers to the WLAN.

Process 500 may further include transmitting other LTE QoS parameters, via the Xw interface, to the WT (block 520). The LTE QoS parameters may be transmitted to WT 138 in a manner similar to the transmission of the LTE QoS parameters, as described with respect to Figs. 2 and 3, except that the subset of the QoS parameters that were enforced at eNB 136 may not be transmitted.

Process 500 may further include mapping, by the WT, the received LTE QoS parameters to WLAN QoS parameters (block 530). The mapping may be performed by WT 138 and may include determining a corresponding WLAN AC for each bearer. In one example

implementation, the mapping may be performed based on the mappings indicated in Tables II, III and IV.

Process 500 may further include enforcing the mapped WLAN QoS parameters (block 540). Thus, WT 138 may communicate, with UE 1 10, via the WLAN radio interface, based on using, for any particular bearer, the corresponding mapped WLAN QoS parameters.

Embodiments described herein may be implemented into a system using any suitably configured hardware and/or software. Fig. 6 illustrates, for one embodiment, example components of an electronic device 600. In embodiments, the electronic device may be a UE, an eNB, a WT, a WLAN AP, a WLAN AC, AP, a standalone node, and/or some other type of electronic device in accordance with various embodiments. Specifically, electronic device 600 may be logic and/or circuitry that may be at least partially implemented in one or more of hardware, software, and/or firmware. In embodiments, the electronic device logic may include radio transmit logic and receive logic coupled to control logic. In embodiments, the electronic device may be coupled with or include one or more plurality of antenna elements of one or more antennas. The electronic device and/or the components of the electronic device may be configured to perform operations similar to those described elsewhere in this disclosure.

In embodiments where the electronic device is a WLAN Termination (WT) or is incorporated into or otherwise part of a WT, the control logic, transmit logic, and/or receive logic may be WT control logic, WT transmit logic and/or WT receive logic. In these embodiments, the WT control logic may identify a control plane and/or user plane message. The WT transmit logic may transmit the control plane and/or user plane message to an evolved NodeB (eNB) via an Xw interface.

In embodiments where the electronic device is an eNB, the control logic may be to generate a message that includes user information and/or control information. The transmit logic may be to transmit the message to a wireless local area network (WLAN) termination (WT) via an Xw interface.

As used herein, the term "circuitry" or "processing circuitry" may refer to, be part of, or include an Application Specific Integrated Circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group( ,and/or memory )shared dedicated ,or group (that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable hardware components that provide the described functionality. In some embodiments, the circuitry may be implemented in, functions associated with the circuitry may be implemented by, one or more software or firmware modules. In some embodiments, circuitry may include logic, at least partially operable in hardware.

In some embodiments, the electronic device of Fig. 6 may be configured to perform one or more processes such as the process of Figs. 2-5. For example, in embodiments where the electronic device is a WLAN Termination (WT), or is incorporated into or otherwise part of a WT, the process may include identifying, by a wireless local area network (WLAN) termination (WT), a control plane and/or user plane message. The process may further include transmitting, by the WT, the control plane and/or user plane message via an Xw interface.

Embodiments described herein may be implemented into a system using any suitably configured hardware and/or software. Fig. 7 illustrates, for one embodiment, an example system comprising radio frequency (RF) logic, baseband logic, application logic, memory/storage (e.g., a storage medium), display, camera, sensor, and input/output (I/O) interface, coupled with each other at least as shown. The application logic may include one or more single-core or multi-core processors. The processor(s) may include any combination of general-purpose processors and dedicated processors (e.g., graphics processors, application processors, etc.). The processors may be coupled with memory/storage and configured to execute instructions stored in the

memory/storage to enable various applications and/or operating systems running on the system.

The baseband logic may include one or more single-core or multi-core processors. The processor(s) may include a baseband processor and/or additional or alternative processors that may be designed to implement functions or actions of the control logic, transmit logic, and/or receive logic described elsewhere herein. The baseband logic may handle various radio control functions that enables communication with one or more radio networks via the RF logic. The radio control functions may include, but are not limited to, signal modulation, encoding, decoding, radio frequency shifting, etc. In some embodiments, the baseband logic may provide for communication compatible with one or more radio technologies. For example, in some embodiments, the baseband logic may support communication with an evolved universal terrestrial radio access network (EUTRAN) and/or other wireless metropolitan area networks (WMAN), a wireless local area network (WLAN), a wireless personal area network (WPAN). Embodiments in which the baseband logic is configured to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband logic.

In various embodiments, baseband logic may include logic to operate with signals that are not strictly considered as being in a baseband frequency. For example, in some

embodiments, baseband logic may include logic to operate with signals having an intermediate frequency, which is between a baseband frequency and a radio frequency.

RF logic may enable communication with wireless networks using modulated electromagnetic radiation through a non-solid medium. In various embodiments, the RF logic may include switches, filters, amplifiers, etc. to facilitate the communication with the wireless network.

In various embodiments, RF logic may include logic to operate with signals that are not strictly considered as being in a radio frequency. For example, in some embodiments, RF logic may include logic to operate with signals having an intermediate frequency, which is between a baseband frequency and a radio frequency.

In some embodiments, instead of using RF logic to wirelessly communicate signals, signals may be communicated via a wired medium, such as a using a fiber optic link or other wired link. For example, a WT device may be coupled to an eNB and a WLAP AP using wired links.

In various embodiments, transmit logic, control logic, and/or receive logic discussed or described herein may be embodied in whole or in part in one or more of the RF logic, the baseband logic, and/or the application logic. As used herein, the term "logic" or "circuitry" may refer to, be part of, or include an Application Specific Integrated Circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group), and/or memory (shared, dedicated, or group) that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable hardware components that provide the described functionality. Specifically, the logic may at be at least partially implemented in, or an element of, hardware, software, and/or firmware. In some embodiments, the electronic device logic may be implemented in, or functions associated with the logic may be implemented by, one or more software or firmware modules.

In some embodiments, some or all of the constituent components of the baseband logic, the application logic, and/or the memory/storage may be implemented together on a system on a chip (SOC).

Memory/storage may be used to load and store data and/or instructions, for example, for system. Memory/storage for one embodiment may include any combination of suitable volatile memory (e.g., dynamic random access memory (DRAM)) and/or non-volatile memory (e.g., Flash memory). In various implementations, memory/storage may store programming instructions for execution by the baseband processor, the application logic, and/or the RF logic.

In various embodiments, the I/O interface may include one or more user interfaces designed to enable user interaction with the system and/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 nonvolatile memory port, a universal serial bus (USB) port, an audio jack, and a power supply interface.

In various embodiments sensor 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 logic and/or RF logic to communicate with components of a positioning network, e.g., a global positioning system (GPS) satellite.

In various embodiments, the display may include a display (e.g., a liquid crystal display, a touch screen display, etc.). In various embodiments, the system may be a mobile computing device such as, but not limited to, a laptop computing device, a tablet computing device, a netbook, an ultrabook, a smartphone, etc. In various embodiments, system may have more or less components, and/or different architectures.

In various embodiments, the system may be a mobile computing device such as, but not limited to, a laptop computing device, a tablet computing device, a netbook, an ultrabook, a smartphone, etc. In various embodiments, system may have more or less components, and/or different architectures. For example, in some embodiments the RF logic and/or the baseband logic may be embodied in communication logic (not shown). The communication logic may include one or more single-core or multi-core processors and logic circuits to provide signal processing techniques, for example, encoding, modulation, filtering, converting, amplifying, etc., suitable to the appropriate communication interface over which communications will take place. The communication logic may communicate over wireline, optical, or wireless communication mediums. In embodiments in which the system is configured for wireless communication, the communication logic may include the RF logic and/or baseband logic to provide for communication compatible with one or more radio technologies. For example, in some embodiments, the communication logic may support communication with an evolved universal terrestrial radio access network (EUTRAN) and/or other wireless metropolitan area networks (WMAN), a wireless local area network (WLAN), a wireless personal area network (WPAN).

Embodiments of the technology herein may be described as related to the third generation partnership project (3GPP) long term evolution (LTE) or LTE-advanced (LTE-A) standards. For example, terms or entities such as eNodeB (eNB), mobility management entity (MME), user equipment (UE), etc. may be used that may be viewed as LTE-related terms or entities. However, in other embodiments the technology may be used in or related to other wireless technologies such as the Institute of Electrical and Electronic Engineers (IEEE) 802.16 wireless technology (WiMax), Wireless Gigabit Alliance (WiGig), IEEE 802.1 1 wireless technology (WiFi), various other wireless technologies such as global system for mobile communications (GSM), enhanced data rates for GSM evolution (EDGE), GSM EDGE radio access network (GERAN), universal mobile telecommunications system (UMTS), UMTS terrestrial radio access network (UTRAN), or other 2G, 3G, 4G, 5G, etc. technologies either already developed or to be developed. In those embodiments, where LTE-related terms such as eNB, MME, UE, etc. are used, one or more entities or components may be used that may be considered to be equivalent or approximately equivalent to one or more of the LTE-based terms or entities.

A number of examples, relating to implementations of the techniques described above, will next be given.

In a first example, an apparatus for a WT device may include circuitry to: implement an Xw interface with an eNB, to communicate control plane and data plane messages with the eNB; receive LTE QoS parameters, via control plane messages received from the eNB; map the LTE QoS parameters to WLAN AC QoS parameters; and transmit the WLAN AC QoS parameters to a WLAN Access Point or Access Controller, as part of WLAN communications with UE.

In example 2, the subject matter of example 1 , may further include wherein the WT processes bearers offloaded from the eNB to the WT, and wherein the received LTE QoS parameters are received for each bearer offloaded from the eNB to the WT.

In example 3, the subject matter of example 2, or any of the examples herein, may further include, wherein the circuitry is further to: receive a TEID for each of the bearers offloaded from the eNB to the WT.

In example 4, the subject matter of example 3, or any of the examples herein, may further include, wherein the circuitry is further to: receive packets, from the eNB, via the Xw data plane messages; and map the TEID, associated with the received packets, to the mapped WLAN AC QoS parameters.

In example 5, the subject matter of example 1 , or any of the examples herein, may further include, wherein the mapping includes: converting LTE QoS Class Identifier (QCI) values to the WLAN AC QoS parameters.

In example 6, the subject matter of example 1 , or any of the examples herein, may further include wherein the received LTE QoS parameters include an ARP parameter, and wherein the circuitry is further to: determine whether to accept a bearer, offloaded from the eNB and to the WT, based on the ARP parameter.

In example 7, the subject matter of example 1 , or any of the examples herein, may further include, wherein the received LTE QoS parameters include an ARP parameter, and wherein the circuitry is further to: determine, based on the ARP parameter, whether to release a previously received bearer in favor of a newly received bearer, when the ARP parameter of the newly received bearer indicates a higher priority than the ARP parameter corresponding to the previously received bearer.

In example 8, the subject matter of example 1 , or any of the examples herein, may further include, wherein the circuitry includes: transmit logic to transmit the WLAN AC QoS parameters to a WLAN Access Point or the Access Controller.

In a ninth example, an eNB may comprise circuitry to: implement an Xw interface with a wireless local area network (WLAN) termination (WT) device to communicate control plane and data plane messages with the WT; transmit Long Term Evolution (LTE) Quality of Service (QoS) parameters, via control plane messages transmitted via the Xw interface, to the WT; and transmit bearer data packets, to the WT, via data plane messages transmitted via the Xw interface.

In example 10, the subject matter of example 9, may further include, wherein the transmitted LTE QoS parameters are transmitted for each bearer offloaded from the eNB to the WT.

In example 1 1 , the subject matter of example 9, or any of the examples herein, may further include, wherein the circuitry is further to: transmit a TEID with each of the bearer data packets transmitted from the eNB to the WT.

In example 12, the subject matter of example 9, or any of the examples herein, may further include, wherein the circuitry is further to: enforce a first subset of the LTE QoS parameters at the eNB, wherein transmitting the LTE QoS parameters includes transmitting a second subset of the LTE QoS parameters, different from the first subset of LTE QoS parameters.

In example 13, the subject matter of example 9, or any of the examples herein, may further include, baseband logic to transmit the LTE QoS and the bearer data packets.

In example 1 1 , the subject matter of examples 1 or 9, or any of the examples herein, may further include, wherein the control plane messages used to communicate the LTE QoS parameters include an "Xw-AP WT Addition" message or an "Xw-Ap WT Modification" message.

In a 15th example, WT device may comprise circuitry to: receive, from an eNB, first

QoS parameters; convert the first QoS parameters to WLAN ACs; and transmit the WLAN ACs to a WLAN Access Point or Access Controller, as part of WLAN communications with UE. In example 16, the subject matter of example 15, or any of the examples herein, may further include, wherein the first QoS parameters include Long LTE QoS parameters.

In example 17, the subject matter of example 15, or any of the examples herein, may further include, wherein the first QoS parameters are received over an Xw interface as control plane messages.

In example 18, the subject matter of example 17, or any of the examples herein, may further include, wherein the circuitry is further to: receive offloaded packets, from the eNB, via a data plane corresponding to the Xw interface; determine a Tunnel Endpoint Identifier (TEID) from each of the received packets; and map the TEID, of each of the received packets, to one of the WLAN ACs.

In example 19, the subject matter of example 15, or any of the examples herein, may further include, wherein the first QoS parameters include one or more of: a QoS Class Identifier (QCI) parameter; an ARP parameter; a GBR parameter; a BR parameter; an APN-AMBR parameter; and a UE-AMBR parameter.

In example 20, the subject matter of example 15, or any of the examples herein, may further include, wherein the first QoS parameters include Differentiated DSCP values received in packet headers.

In example 21 , the subject matter of example 15, or any of the examples herein, may further include, wherein the received first QoS parameters are received for each bearer offloaded from the eNB to the WT.

In a 22nd example, a computer readable medium may contain program instructions for causing one or more processors to: implement an Xw interface with an eNB, to communicate control plane and data plane messages with the eNB; receive LTE QoS parameters, via control plane messages received from the eNB; map the LTE QoS parameters to WLAN AC QoS parameters; and transmit the WLAN ACs to a WLAN Access Point or Access Controller, as part of WLAN communications with UE.

In example 23, the subject matter of example 22, or any of the examples herein, may further include wherein the one or more processors are to process bearers offloaded from the eNB, and wherein the received LTE QoS parameters are received for each offloaded bearer.

In example 24, the subject matter of example 22, or any of the examples herein, may further include, wherein the computer readable medium further includes program instructions for causing the one or more processors to: receive a TEID for each of the bearers offloaded from the eNB to the WT. In example 25, the subject matter of example 24, or any of the examples herein, may further include, wherein the computer readable medium further includes program instructions for causing the one or more processors to: receive packets, from the eNB, via the Xw data plane messages; and map the TEID, associated with the received packets, to the mapped WLAN AC QoS parameters.

In example 26, the subject matter of example 22, or any of the examples herein, may further include, wherein the computer readable medium further includes program instructions for causing the one or more processors to: convert LTE QoS Class Identifier (QCI) values to the WLAN AC QoS parameters.

In a 27th example a device may comprise means for implementing an Xw interface with an eNB, to communicate control plane and data plane messages with the eNB; means for receiving LTE QoS parameters, via control plane messages received from the eNB; means for mapping the LTE QoS parameters to WLAN AC QoS parameters; and means for

communicating, via a radio interface, with UE using the WLAN AC QoS parameters.

In example 28, the subject matter of example 27, or any of the examples herein, may further include wherein the device processes bearers offloaded from the eNB to the device, and wherein the received LTE QoS parameters are received for each bearer offloaded from the eNB to the device.

In the preceding specification, various embodiments have been described with reference to the accompanying drawings. It will, however, be evident that various modifications and changes may be made thereto, and additional embodiments may be implemented, without departing from the broader scope as set forth in the claims that follow. The specification and drawings are accordingly to be regarded in an illustrative rather than restrictive sense.

For example, while series of blocks have been described with regard to Figs. 2-5, the order of the blocks may be modified in other implementations. Further, non-dependent operations may be performed in parallel.

It will be apparent that example aspects, as described above, may be implemented in many different forms of software, firmware, and hardware in the implementations illustrated in the figures. The actual software code or specialized control hardware used to implement these aspects should not be construed as limiting. Thus, the operation and behavior of the aspects were described without reference to the specific software code—it being understood that software and control hardware could be designed to implement the aspects based on the description herein. Further, certain portions may be implemented as "logic" that performs one or more functions. This logic may include hardware, such as an application-specific integrated circuit ("ASIC") or a field programmable gate array ("FPGA"), or a combination of hardware and software.

Even though particular combinations of features are recited in the claims and/or disclosed in the specification, these combinations are not intended to limit the description. In fact, many of these features may be combined in ways not specifically recited in the claims and/or disclosed in the specification.

No element, act, or instruction used in the present application should be construed as critical or essential unless explicitly described as such. An instance of the use of the term "and," as used herein, does not necessarily preclude the interpretation that the phrase "and/or" was intended in that instance. Similarly, an instance of the use of the term "or," as used herein, does not necessarily preclude the interpretation that the phrase "and/or" was intended in that instance. Also, as used herein, the article "a" is intended to include one or more items, and may be used interchangeably with the phrase "one or more." Where only one item is intended, the terms "one," "single," "only," or similar language is used.

Claims

WHAT IS CLAIMED IS:

1 . An apparatus for a wireless local area network (WLAN) termination (WT) device comprising circuitry to:

implement an Xw interface with an evolved NodeB (eNB), to communicate control plane and data plane messages with the eNB;

receive Long Term Evolution (LTE) Quality of Service (QoS) parameters, via control plane messages received from the eNB;

map the LTE QoS parameters to WLAN Access Category (AC) QoS parameters; and transmit the WLAN AC QoS parameters to a WLAN Access Point or Access Controller, as part of WLAN communications with User Equipment (UE).

2. The apparatus of claim 1 , wherein the WT processes bearers offloaded from the eNB to the WT, and wherein the received LTE QoS parameters are received for each bearer offloaded from the eNB to the WT.

3. The apparatus of claim 2, wherein the circuitry is further to:

receive a Tunnel Endpoint Identifier (TEID) for each of the bearers offloaded from the e B to the WT.

4. The apparatus of claim 3, wherein the circuitry is further to:

receive packets, from the eNB, via the Xw data plane messages; and

map the TEID, associated with the received packets, to the mapped WLAN AC QoS parameters.

5. The apparatus of claim 1 , wherein the mapping includes:

converting LTE QoS Class Identifier (QCI) values to the WLAN AC QoS parameters.

6. The apparatus of claim 1 , wherein the received LTE QoS parameters include an Allocation and Retention Priority (ARP) parameter, and wherein the circuitry is further to: determine whether to accept a bearer, offloaded from the eNB and to the WT, based on the ARP parameter.

7. The WT device of claim 1 , wherein the received LTE QoS parameters include an Allocation and Retention Priority (ARP) parameter, and wherein the circuitry is further to: determine, based on the ARP parameter, whether to release a previously received bearer in favor of a newly received bearer, when the ARP parameter of the newly received bearer indicates a higher priority than the ARP parameter corresponding to the previously received bearer.

8. The apparatus of claim 1 , wherein the circuitry includes:

transmit logic to transmit the WLAN AC QoS parameters to a WLAN Access Point or the Access Controller.

9. An evolved NodeB (eNB) comprising circuitry to:

implement an Xw interface with a wireless local area network (WLAN) termination (WT) device to communicate control plane and data plane messages with the WT;

transmit Long Term Evolution (LTE) Quality of Service (QoS) parameters, via control plane messages transmitted via the Xw interface, to the WT; and

transmit bearer data packets, to the WT, via data plane messages transmitted via the Xw interface.

10. The eNB of claim 9, wherein the transmitted LTE QoS parameters are transmitted for each bearer offloaded from the e B to the WT.

1 1 . The eNB of claim 9, wherein the circuitry is further to:

transmit a Tunnel Endpoint Identifier (TEID) with each of the bearer data packets transmitted from the eNB to the WT.

12. The eNB of claim 9, wherein the circuitry is further to:

enforce a first subset of the LTE QoS parameters at the eNB,

wherein transmitting the LTE QoS parameters includes transmitting a second subset of the LTE QoS parameters, different from the first subset of LTE QoS parameters.

13. The eNB of claim 9, further comprising:

baseband logic to transmit the LTE QoS and the bearer data packets.

14. A device as in claims 1 or 9, wherein the control plane messages used to communicate the LTE QoS parameters include an "Xw-AP WT Addition" message or an "Xw- Ap WT Modification" message.

15. A wireless local area network (WLAN) termination (WT) device

comprising circuitry to:

receive, from an evolved NodeB (eNB), first Quality of Service (QoS) parameters; convert the first QoS parameters to WLAN Access Categories (ACs); and

transmit the WLAN ACs to a WLAN Access Point or Access Controller, as part of WLAN communications with User Equipment (UE).

16. The device of claim 15, wherein the first QoS parameters include Long Term Evolution (LTE) QoS parameters.

17. The device of claim 15, wherein the first QoS parameters are received over an

Xw interface as control plane messages.

18. The device of claim 17, wherein the circuitry is further to:

receive offloaded packets, from the eNB, via a data plane corresponding to the Xw interface;

determine a Tunnel Endpoint Identifier (TEID) from each of the received packets; and map the TEID, of each of the received packets, to one of the WLAN ACs.

19. The device of claim 15, where the first QoS parameters include one or more of: a QoS Class Identifier (QCI) parameter; an Allocation and Retention Priority (ARP) parameter; a

Guaranteed Bit Rate (GBR) parameter; a Maximum Bit Rate (MBR) parameter; an Access Point Name-Aggregate Maximum Bit Rate (APN-AMBR) parameter; and a User Equipment (UE)- AMBR parameter.

20. The device of claim 15, wherein the first QoS parameters include Differentiated

Services Code Point (DSCP) values received in packet headers.

21 . The device of claim 1 5, wherein the received first QoS parameters are received for each bearer offloaded from the e B to the WT.

22. A computer readable medium containing program instructions for causing one or more processors to:

map the LTE QoS parameters to WLAN Access Category (AC) QoS parameters; and transmit the WLAN ACs to a WLAN Access Point or Access Controller, as part of WLAN communications with User Equipment (UE).

23. The computer readable medium device of claim 22, wherein the one or more processors are to process bearers offloaded from the eNB, and wherein the received LTE QoS parameters are received for each offloaded bearer.

24. The computer readable medium of claim 22, wherein the computer readable medium further includes program instructions for causing the one or more processors to:

receive a Tunnel Endpoint Identifier (TEID) for each of the bearers offloaded from the eNB to the WT.

25. The computer readable medium of claim 24, wherein the computer readable medium further includes program instructions for causing the one or more processors to:

receive packets, from the eNB, via the Xw data plane messages; and