CN109792363B - Method to avoid HFN desynchronization in uplink over WLAN in LTE-WLAN aggregation - Google Patents

Abstract

Various techniques for mitigating or eliminating Hyper Frame Number (HFN) desynchronization for uplink LWA are described herein. In one embodiment, separate PDCP discard timers are maintained for packets sent over WLAN and LTE links. The discard timer may be set independently for WLAN and LTE links. In a second embodiment, a status report indicating Acknowledgement (ACK) and/or Negative Acknowledgement (NACK) of uplink PDCP SDUs may be sent by the eNB to the UE. The status report may be sent periodically or after a certain number of packets are sent. In a third embodiment, retransmission of PDCP SDUs after being sent once over the WLAN link may be disabled.

Description

Method to avoid HFN desynchronization in uplink over WLAN in LTE-WLAN aggregation

RELATED APPLICATIONS

This application claims the benefit of U.S. provisional patent application No. 62/416,013, filed 2016, month 11, day 1, the contents of which are incorporated herein by reference as if fully set forth herein.

Background

A wireless cellular telecommunications network includes a Radio Access Network (RAN) that enables User Equipment (UE) (e.g., smart phones, tablets, laptops, etc.) to connect to a core network. An example of a wireless telecommunications network may include an Evolved Packet System (EPS) operating based on third generation partnership project (3GPP) communication standards. In cellular networks, UEs typically communicate with a base station using a channel corresponding to a licensed radio spectrum (e.g., a radio spectrum designated for cellular network communications).

More recently, techniques have been implemented that allow unlicensed spectrum to be used to assist or supplement the network connectivity provided over licensed spectrum. One such technology is "Long Term Evolution (LTE) Wireless Local Area Network (WLAN) aggregation" (LWA). In LWA, a UE supporting both LTE and WLAN (e.g., WiFi) technologies may be configured by the network to utilize both links simultaneously. LWA provides techniques to use LTE in unlicensed spectrum without requiring hardware changes to network infrastructure equipment and UEs. LWA allows the use of two links for a single traffic flow and is generally efficient due to the coordination of the lower protocol stack layers.

Link aggregation for LWA was originally limited to Downlink (DL) traffic aggregation (i.e., from base station to UE), but has recently been proposed for UL traffic.

Drawings

The embodiments described herein will be readily understood by the following detailed description in conjunction with the accompanying drawings. For convenience of description, the same reference numerals may designate the same structural elements. Embodiments are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings.

FIG. 1 illustrates an architecture of a system according to some embodiments;

FIG. 2 is a diagram illustrating an example of an LWA in the system of FIG. 1;

FIG. 3 is a diagram illustrating the use of a separate discard timer for a Packet Data Convergence Protocol (PDCP) layer;

FIG. 4A is a flow diagram illustrating an example process for providing a PDCP status report from a base station to a User Equipment (UE);

figure 4B is a flow diagram illustrating another example process for providing PDCP status reports from a base station to a UE;

fig. 5 is a diagram conceptually showing a concept conforming to the third embodiment;

FIG. 6 illustrates example components of a device according to some embodiments;

FIG. 7 illustrates an example interface of a baseband circuit according to some embodiments;

figure 8 is an illustration of a control plane protocol stack according to some embodiments; and

fig. 9 is a block diagram illustrating components capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and performing any one or more of the methodologies discussed herein, according to some example embodiments.

Detailed Description

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. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of embodiments is defined by the appended claims and their equivalents.

In LWA, LTE and WLAN links are aggregated at the Packet Data Convergence Protocol (PDCP) level in the user plane. PDCP provides a variety of services including maintaining Sequence Numbers (SNs) of Service Data Units (SDUs). The SN may be used to correctly order SDUs received on the LTE and WLAN links. In addition to SN, an overflow counter, called Hyper Frame Number (HFN), is also used for base stations (e.g., evolved node b (enb)) and UEs in order to limit the number of sequence number bits that need to be sent over the radio interface. HFN should be synchronized between UE and eNB. In operation, when the PDCP SN reaches its maximum value, the PDCP SN will restart from 0 and the HFN will increase by one.

In some cases, such as in uplink LWA, there is a possibility of HFN de-synchronization at the PDCP receiver (i.e., at the eNB) when the UE transmits uplink data over the WLAN. HFN de-synchronization may occur especially when PDCP SDUs are discarded or transmitted without acknowledgement. It is desirable to eliminate the possibility of HFN desynchronization.

Various techniques for mitigating or eliminating HFN desynchronization of uplink LWA traffic are described herein. In one embodiment, separate PDCP discard timers are maintained for packets sent over WLAN and LTE links. The discard timer may be set independently for WLAN and LTE links. In a second embodiment, a status report indicating Acknowledgement (ACK) and/or Negative Acknowledgement (NACK) of the uplink PDCP SDU may be sent by the eNB to the UE. The status report may be sent periodically or after a certain number of packets are sent. In a third embodiment, retransmission of PDCP SDUs after being transmitted once over the WLAN link may be disabled.

As described herein, the first and third embodiments may be used to simplify logic and potentially reduce memory requirements of the UE, as PDCP SDUs sent over the WLAN link may only need to be buffered for a short period of time or not need to be buffered at all. The first and third embodiments may in particular be used as triggers for querying the eNB to receive status reports from the eNB. The status report received from the eNB (e.g., according to the second embodiment) may be used to mitigate or eliminate HFN desynchronization.

Fig. 1 illustrates an architecture of a system 100 according to some embodiments. System 100 is shown to include a User Equipment (UE)101 and a UE 102. The UEs 101 and 102 are illustrated as smart phones (e.g., hand-held, touch-screen mobile computing devices connectable to one or more cellular networks), but the UEs 101 and 102 can also include any mobile or non-mobile computing device, such as a Personal Data Assistant (PDA), pager, laptop computer, desktop computer, wireless handheld device, or any computing device that includes a wireless communication interface.

In some embodiments, any of UEs 101 and 102 may include an internet of things (IoT) UE, which may include a network access layer designed for low-power IoT applications that utilize short-term UE connections. IoT UEs may utilize technologies such as machine-to-machine (M2M) or Machine Type Communication (MTC) to exchange data with MAC servers or devices via Public Land Mobile Networks (PLMNs), proximity-based services (ProSe) or device-to-device (D2D) communication, sensor networks, or IoT networks. The M2M or MTC data exchange may be a machine initiated data exchange. An IoT network describes the interconnection of IoT UEs, which may include uniquely identifiable embedded computing devices (within the internet infrastructure) with short-term connections. The IoT UE may execute background applications (e.g., keep-alive messages, status updates, etc.) to facilitate connection of the IoT network.

UEs 101 and 102 may be configured to connect with (e.g., communicatively couple with) a Radio Access Network (RAN)110, which RAN 110 may be, for example, an evolved Universal Mobile Telecommunications System (UMTS) terrestrial radio access network (E-UTRAN), a next generation RAN (ng RAN), or some other type of RAN. The UEs 101 and 102 use connections 103 and 104, respectively, each of which includes a physical communication interface or layer (discussed in further detail below); in this example, connections 103 and 104 are shown as air interfaces to enable communicative coupling, and may conform to a cellular communication protocol, which may be, for example, a global system for mobile communications (GSM) protocol, a Code Division Multiple Access (CDMA) network protocol, a push-to-talk (PTT) protocol, a cellular PTT (poc) protocol, a Universal Mobile Telecommunications System (UMTS) protocol, a 3GPP Long Term Evolution (LTE) protocol, a fifth generation (5G) protocol, a New Radio (NR) protocol, and so forth.

In this embodiment, the UEs 101 and 102 may also exchange communication data directly via the ProSe interface 105. The ProSe interface 105 may alternatively be referred to as a sidelink (sidelink) interface, which includes one or more logical channels including, but not limited to, a Physical Sidelink Control Channel (PSCCH), a physical sidelink shared channel (PSCCH), a Physical Sidelink Discovery Channel (PSDCH), and a Physical Sidelink Broadcast Channel (PSBCH).

UE 102 is shown configured to access an Access Point (AP)106 via a connection 107. Connection 107 may comprise a local wireless connection, e.g., a connection conforming to any IEEE 802.11 protocol, wherein AP 106 would comprise wireless fidelity

A router. In this example, the AP 106 is shown as being connected to the internet rather than to the core network of the wireless system (further below)Detailed description).

RAN 110 may include one or more Access Nodes (ANs) that implement connections 103 and 104. These Access Nodes (ANs) may be referred to as Base Stations (BSs), nodebs, evolved nodebs (enbs), next generation nodebs (gnbs), RAN nodes, etc., and may include ground stations (e.g., ground access points) or satellite stations that provide coverage within a geographic area (e.g., a cell). RAN 110 may include one or more RAN nodes (e.g., macro RAN node 111) to provide macro cells and one or more RAN nodes (e.g., cells with smaller coverage areas, less user capacity, or higher bandwidth than macro cells) to provide femto cells or pico cells, e.g., Low Power (LP) RAN node 112.

Any of RAN nodes 111 and 112 may terminate (terminate) an air interface protocol and may be a first point of contact for UEs 101 and 102. In some embodiments, any of RAN nodes 111 and 112 may implement various logical functions of RAN 110, including, but not limited to, Radio Network Controller (RNC) functions such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management.

In accordance with some embodiments, UEs 101 and 102 may be configured to communicate with each other or with any of RAN nodes 111 and 112 over a multicarrier communication channel using Orthogonal Frequency Division Multiplexing (OFDM) communication signals in accordance with various communication techniques such as, but not limited to, an Orthogonal Frequency Division Multiple Access (OFDMA) communication technique (e.g., for downlink communications) or a single-carrier frequency division multiple access (SC-FDMA) communication technique (e.g., for uplink and ProSe-based or sidelink-based communications), although the scope of the embodiments is not limited in this respect. The OFDM signal may include a plurality of orthogonal subcarriers.

In some embodiments, the downlink resource grid may be used for downlink transmissions from any of RAN nodes 111 and 112 to UEs 101 and 102, while uplink transmissions may use similar techniques. The grid may be a time-frequency grid, referred to as a resource grid or time-frequency resource grid, which is the physical resource in the downlink in each slot. The time-frequency plane representation method is common practice of OFDM systems, which makes radio resource allocation more intuitive. Each column and each row of the resource grid corresponds to one OFDM symbol and one OFDM subcarrier, respectively. The duration of the resource grid in the time domain corresponds to one slot in a radio frame. The smallest time-frequency unit in the resource grid is denoted as a resource element. Each resource grid includes a plurality of resource blocks, which describe the mapping of certain physical channels to resource elements. Each resource block includes a set of resource elements. In the frequency domain, this may represent the minimum amount of resources that can currently be allocated. There are several different physical downlink channels transmitted using such resource blocks.

The Physical Downlink Shared Channel (PDSCH) may carry user data and higher layer signaling to UEs 101 and 102. A Physical Downlink Control Channel (PDCCH) may carry information on resource allocation and transport format aspects related to a PDSCH channel, and the like. It may also inform UEs 101 and 102 about the transport format, resource allocation and H-ARQ (hybrid automatic repeat request) information related to the uplink shared channel. In general, downlink scheduling (allocation of control and shared channel resource blocks to UEs 102 within a cell) may be performed at any of RAN nodes 111 and 112 based on channel quality information fed back from any of UEs 101 and 102. Downlink resource allocation information for (e.g., allocated to) the respective UEs 101 and 102 may be transmitted on the PDCCH.

The PDCCH may transmit control information using Control Channel Elements (CCEs). The PDCCH complex-valued symbols may first be organized into quadruplets before being mapped to resource elements, and these quadruplets may then be permuted using a sub-block interleaver for rate matching. Each PDCCH may be transmitted using one or more of these CCEs, where each CCE may correspond to a set of nine physical resource elements (referred to as Resource Element Groups (REGs)), where each set of physical resource elements includes four physical resource elements. Four Quadrature Phase Shift Keying (QPSK) symbols may be mapped to each REG. Depending on the size of Downlink Control Information (DCI) and channel conditions, the PDCCH may be transmitted using one or more CCEs. There may be four or more different PDCCH formats in LTE with different numbers of CCEs (e.g., aggregation level, L ═ 1, 2, 4, or 8)

Some embodiments may use the concept of resource allocation for control channel information, which is an extension of the above-described concept. For example, some embodiments may use an Enhanced Physical Downlink Control Channel (EPDCCH) that uses PDSCH resources for control information transmission. The EPDCCH may be transmitted using one or more Enhanced Control Channel Elements (ECCEs). Similar to the above, each ECCE may correspond to a set of nine physical resource elements (referred to as an Enhanced Resource Element Group (EREG)), each set of physical resource elements including four physical resource elements. In some cases, ECCE may have other numbers of EREGs.

RAN 110 is shown communicatively coupled to Core Network (CN) 120 via S1 interface 113. In some embodiments, the CN 120 may be an Evolved Packet Core (EPC) network, a NextGen Packet Core (NPC) network, or other type of CN. In this embodiment, the S1 interface 113 is divided into two parts: an S1-U interface 114 that carries traffic data between RAN nodes 111 and 112 and serving gateway (S-GW) 122; and S1-Mobility Management Entity (MME) interface 115, which is a signaling interface between RAN nodes 111 and 112 and MME 121.

In this embodiment, CN 120 includes MME 121, S-GW 122, Packet Data Network (PDN) gateway (P-GW)123, and Home Subscriber Server (HSS) 124. MME 121 may be similar in function to the control plane of a conventional serving General Packet Radio Service (GPRS) support node (SGSN). MME 121 may manage mobility aspects in access such as gateway selection and tracking area list management. HSS 124 may include a database for network users, including subscription-related information for supporting network entities in handling communication sessions. Depending on the number of mobile subscribers, the capacity of the devices, the organization of the network, etc., the CN 120 may include one or more HSSs 124. For example, the HSS 124 may provide support for routing/roaming, authentication, authorization, naming/addressing resolution, location dependencies, and the like.

The S-GW 122 may terminate S1 interface 113 towards RAN 110 and route data packets between RAN 110 and CN 120. In addition, S-GW 122 may be a local mobility anchor for inter-RAN node handovers and may also provide an anchor for inter-3 GPP mobility. Other responsibilities may include lawful interception, charging, and some policy enforcement.

The P-GW 123 may terminate the SGi interface towards the PDN. P-GW 123 may route data packets between EPC network 123 and an external network, such as a network including application server 130 (alternatively referred to as an Application Function (AF)), via Internet Protocol (IP) interface 125. In general, the application server 130 may be an element that provides applications (e.g., UMTS Packet Service (PS) domain, LTE PS data services, etc.) that use IP bearer resources with the core network. In this embodiment, P-GW 123 is shown communicatively coupled to application server 130 via an IP communications interface 125. The application server 130 may also be configured to support one or more communication services (e.g., voice over internet protocol (VoIP) sessions, PTT sessions, group communication sessions, social networking services, etc.) of the UEs 101 and 102 via the CN 120.

P-GW 123 may also be a node for policy enforcement and charging data collection. Policy and Charging Rules Function (PCRF)126 is a policy and charging control element of CN 120. In a non-roaming scenario, there may be a single PCRF in a Home Public Land Mobile Network (HPLMN) that is associated with an internet protocol connectivity access network (IP-CAN) session for a UE. In a roaming scenario with local traffic bursts, there may be two PCRFs associated with the IP-CAN session of the UE: a home PCRF (H-PCRF) within the HPLMN and a visited PCRF (V-PCRF) in a Visited Public Land Mobile Network (VPLMN). PCRF 126 may be communicatively coupled to application server 130 via P-GW 123. Application server 130 may signal PCRF 126 to indicate the new service flow and select the appropriate quality of service (QoS) and charging parameters. PCRF 126 may provide the rules to a Policy and Charging Enforcement Function (PCEF) (not shown) that initiates QoS and charging specified by application server 130 using appropriate Traffic Flow Templates (TFTs) and QoS Class Identifiers (QCIs).

Fig. 2 is a diagram illustrating an example of implanting an LWA in the environment of the system 100. As shown, in the presence of LWA, the radio interface provided by both WiFi access point 106(WLAN link) and eNB 111 (LTE link) may be used to provide an aggregated high throughput link between UE 102 and core network 120. The WLAN link may be used for uplink and downlink traffic. PDCP may be used to carry user plane and control plane traffic between UE 102 and eNB 111. A SN may be assigned to each SDU of the traffic to allow UE 102 or eNB 111 to reassemble the stream of SDUs and ensure that the correct order of SDUs is maintained. In addition, as previously described, in addition to the SN, an overflow counter HFN (hyper frame number) may be used at UE 102 and eNB 111 in order to limit the size of the SN value. The HFN should be synchronized between the UE 102 and the eNB 111, since the HFN is used as input for the subsequent deciphering algorithm. If the wrong HFN is associated with the packet, the packet cannot be decrypted. When the SN reaches its maximum value, the SN will restart from 0 and the HFN increases by 1.

The number of devices and/or networks shown in fig. 1 and 2 is provided for illustrative purposes only. Indeed, there may be additional devices and/or networks than those shown in fig. 1 and/or 2; fewer devices and/or networks; different devices and/or networks; or a different arrangement of devices and/or networks. Alternatively or additionally, one or more devices of system 100 may perform one or more functions described as being performed by another one or more devices of system 100.

As previously described, in some cases, such as in uplink LWA, there is a possibility of HFN desynchronization at the PDCP receiver (i.e., at the eNB) when the UE transmits uplink data over the WLAN. In particular, HFN desynchronization may occur when PDCP SDUs are discarded, lost, or transmitted without acknowledgement.

A first embodiment for mitigating or eliminating the possibility of HFN desynchronization will be discussed below with reference to fig. 3.

In the uplink direction, the UE 102, after sending PDCP SDUs, can buffer the SDUs if the UE 102 needs to re-send the SDUs to the eNB 111. In PDCP, the eNB and UE may use a discard timer value to help determine when PDCP SDUs may be discarded (i.e., deleted from the buffer). A value of a discard timer may be associated with each PDCP SDU. The discard timer may be started when PDCP is received from an upper layer (e.g., IP layer). The UE may discard the PDCP SDU when a discard timer expires for the PDCP SDU, or otherwise confirms successful delivery of the PDCP SDU.

Using too large a PDCP discard timer value may result in a waste of resources (e.g., the UE 102 needs to maintain a large buffer of transmitted PDCP SDUs). Using too small a PDCP discard timer value may result in errors, e.g., HFN desynchronization. The appropriate discard timer value may be based on the bandwidth and delay of the corresponding radio link.

In a first embodiment, separate PDCP discard timer values may be maintained for WLAN and LTE links, as described herein. In other words, the PDCP discard timer for PDCP SDUs that are suitable for transmission over the LTE link may be different from the discard timer for PDCP SDUs that are suitable for transmission over the WLAN link. In one example, the network may configure different (or the same) drop timers based on the estimated round trip times of the various links. In another example, the discard timer of the WLAN can be considered a PDCP buffer protection timer, which can be beneficial to avoid PDCP buffer overflow.

Figure 3 is a diagram conceptually illustrating logical and/or physical elements associated with PDCP. Specifically, as shown, to implement PDCP, the UE 102 can maintain a WLAN discard timer 310, an LTE discard timer 320, and a PDCP buffer 330. The WLAN discard timer 310 can be used when determining whether to discard uplink SDUs stored in the PDCP buffer 330 and transmitted by the UE over the WLAN link (e.g., using WiFi). A second discard timer, labeled LTE discard timer 320, may be used when determining whether to discard uplink SDUs transmitted by the UE on the LTE link. The timers 310 and 320 may be used independently by the UE. In some implementations, expiration of the discard timer may be used to trigger generation of the status report.

Many techniques may be used to set the value of the discard timer, including the WLAN discard timer 310. In some implementations, dedicated Radio Resource Control (RRC) signaling or broadcast RRC signaling may be used. Alternatively or additionally, in-band signaling (i.e., on WLAN links) using a Medium Access Control (MAC) Control Element (CE), PDCP control data units, or additional header information or other data units using LTE-WLAN aggregation adaptation protocol (LWAAP) may be used.

In particular, in one possible sense, dedicated RRC signaling (e.g., over an LTE link) may be used, where the value of the WLAN discard timer is included in a PDCP configuration Information Element (IE). Table I below shows an example of a PDCP-configuration message. The PDCP configuration message may be based on the disclosure of subclause 6.3.2 of 3GPP TS 36.331, wherein the bold text in table I is used to illustrate features not in the existing 3GPP standard.

In table I, "discard timer WLAN" may indicate a discard timer value for packets (e.g., SDUs) transmitted on the WLAN link as an LWA bearer, as specified in 3GPP TS 36.323. These values are expressed in milliseconds (ms). The value ms50 represents 50ms, ms100 represents 100ms, etc. In addition, the SetupLWA field may be a mandatory field that exists in case of setting or reconfiguring the LWA DRB. This field may optionally be present when reconfiguring the LWA DRB; in other cases, this field may not be present.

In a second embodiment, a PDCP status report may be provided from an eNB to a UE, as described herein. The status report may include an acknowledgement of the received uplink PDCP SDU. The UE may discard (i.e., no longer buffer) PDCP SDUs indicated as being received in the status report.

Figure 4A is a flow diagram illustrating an example process 400 for providing PDCP status reports from an eNB to a UE. Procedure 400 may be implemented by, for example, eNB 111.

Process 400 may include determining whether a periodic status reporting timer has expired (block 420) for an LWA uplink bearer (block 410 — yes). When the periodic status report timer expires (block 420, yes), the eNB may provide a status report to the UE associated with the bearer. As mentioned, the status report may include an indication (ACK) of successfully received uplink PDCP SDUs and/or an indication (NACK) of unsuccessfully received uplink PDCP SDUs. The status report may be a PDCP or LWA type status report. The UE may discard/delete PDCP SDUs indicated as successfully received in the status report from the buffer of the UE. The UE may retransmit PDCP SDUs indicated as not successfully received in the status report. In this way (i.e., by periodically sending status reports), the PDCP SDUs lost during transmission on the WLAN link will not cause HFN desynchronization between the eNB and the UE.

Figure 4B is a flow diagram illustrating an example of another process (process 450) for providing PDCP status reports from an eNB to a UE. Procedure 450 may be implemented by, for example, eNB 111.

The process 450 may include, for an LWA uplink bearer (block 460 — yes), determining whether a particular number (N, where N is an integer) of SDUs have been transmitted since a last status report was transmitted to the UE (block 470). The eNB may provide the status report to the UE associated with the bearer when at least N data units have been transmitted since the last status report was transmitted to the UE (block 470, yes). In one implementation, the N SDUs may be PDCP packets. As mentioned, the status report may include an indication of successfully received or unsuccessfully received uplink PDCP SDUs. The status report may be a PDCP or LWA type status report. The UE may discard/delete PDCP SDUs from the buffer of the UE that are indicated as successfully received in the status report. In this way, PDCP SDUs lost during transmission on the WLAN link will not cause HFN desynchronization between the eNB and the UE.

Alternatively or additionally, other techniques may be used to trigger the generation of PDCP status reports. For example, the expiration of a reordering timer at the eNB may trigger a PDCP or LWA status report from the eNB to the UE. In addition, expiration of the PDCP discard timer at the UE may be used to trigger the UE to request the eNB to send a PDCP or LWA status report.

In processes 400 and 450, many potential techniques may be used to communicate parameters associated with processes 400 and 450 (e.g., the value of the periodic status reporting timer (process 400) and the value of N (process 450)). For example, the network (e.g., CN 120) may configure the eNB. Alternatively or additionally, the periodic status reporting timer and/or the value of N may be provided as part of an initial setting of the eNB or dynamically determined by the eNB based on the operational status of the eNB (e.g., network load, etc.).

In a third embodiment, the UE may be configured not to retransmit PDCP packets over the WLAN link, or to retransmit PDCP packets that have been sent once over the WLAN link at all, as described herein. The third embodiment may be used for PDCP buffer management at the UE and help the UE determine the packets it should retransmit. In this implementation, the UE will not maintain a PDCP buffer for uplink PDCP SDUs sent over the WLAN link. Instead, the UE may only need to maintain a buffer for uplink SDUs transmitted over the LTE link. Similarly, at the eNB, there may be no need to separately maintain a reordering window for PDCP SDUs received over the WLAN link. Because there is a low likelihood of data loss occurring over the WLAN, disabling PDCP data recovery for data units sent over the WLAN may not adversely affect the operation of the system in this embodiment. Furthermore, because there is no retransmission of packets sent over the WLAN, WLAN feedback (e.g., WLAN status report) is not required.

Fig. 5 is a diagram conceptually showing a concept conforming to the third embodiment. As shown, UL PDCP SDUs may be transmitted simultaneously on both LTE and WLAN links. The UE 101 can maintain a buffer for PDCP SDUs sent on the LTE link, labeled as the LTE PDCP buffer 520. However, for the WLAN link, the UE may forego the possibility of retransmitting PDCP SDUs. Thus, no buffer is required for the WLAN link (shown by the "scratched out" WLAN PDCP buffer). Similarly, feedback, such as a status report, indicating the SN of a received (or not received) PDCP SDU can be sent to the UE 101 for the LTE link. But the WLAN link does not require such feedback. At the eNB 111, a PDCP reordering window 510 may be maintained to ensure that the SDUs received are in the correct order.

In another possible embodiment, the UE may be configured to maintain a minimum PDCP SDU rate on the LTE link even when other considerations would typically result in all PDCP data being transmitted over the WLAN link. For example, the UE may ensure that PDCP SDUs are periodically transmitted over the LTE link. Receiving a packet over the LTE link may cause the eNB to confirm that it has received the packet (e.g., through a status report). In this implementation, the UE essentially "spoofs" the eNB to send LWA and/or PDCP status reports.

Many embodiments for mitigating or eliminating HFN desynchronization are discussed above. In some implementations, the UE/eNB may use multiple embodiments simultaneously. For example, separate WLAN and LTE discard timers and periodic transmission of status reports may be used.

As used herein, the term "circuitry," "processing circuitry," or "logic" may refer to, be part of, or include the following: an Application Specific Integrated Circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group) and/or memory (shared, dedicated, or group) that executes 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, or functions associated with, one or more software or firmware modules. In some embodiments, the circuitry may comprise logic operable, at least in part, in hardware.

Fig. 6 illustrates example components of a device 600 according to some embodiments. In some embodiments, device 600 may include application circuitry 602, baseband circuitry 604, Radio Frequency (RF) circuitry 606, Front End Module (FEM) circuitry 608, one or more antennas 610, and Power Management Circuitry (PMC)612 coupled together at least as shown. The illustrated components of the apparatus 600 may be included in a UE or RAN node. In some embodiments, the apparatus 600 may include fewer elements (e.g., the RAN node may not use the application circuitry 602, but rather includes a processor/controller to process IP data received from the EPC). In some embodiments, device 600 may include additional elements, such as memory/storage devices, displays, cameras, sensors, or input/output (I/O) interfaces. In other embodiments, the components described below may be included in more than one device (e.g., for a Cloud-RAN (C-RAN) implementation, the circuitry may be included separately in more than one device).

The application circuitry 602 may include one or more application processors. For example, the application circuitry 602 may include circuitry such as, but not limited to: one or more single-core or multi-core processors. The processor(s) may include any combination of general-purpose processors and special-purpose processors (e.g., graphics processors, application processors, etc.). The processor may be coupled with or may include memory/storage and may be configured to execute instructions stored in the memory/storage to enable various applications and/or operating systems to run on the device 600. In some embodiments, a processor of the application circuitry 602 may process IP data packets received from the EPC.

Baseband circuitry 604 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. Baseband circuitry 604 may include one or more baseband processors or control logic to process baseband signals received from the receive signal path of RF circuitry 606 and to generate baseband signals for the transmit signal path of RF circuitry 606. Baseband processing circuitry 604 may interface with application circuitry 602 to generate and process baseband signals and control operation of RF circuitry 606. For example, in some embodiments, the baseband circuitry 604 may include a third generation (3G) baseband processor 604A, a fourth generation (4G) baseband processor 604B, a fifth generation (5G) baseband processor 604C, or other baseband processor(s) 604D for other existing generations, generations in development or to be developed in the future (e.g., second generation (2G), sixth generation (6G), etc.). Baseband circuitry 604 (e.g., one or more of baseband processors 604A-D) may handle various radio control functions that support communication with one or more radio networks via RF circuitry 606. In other embodiments, some or all of the functions of the baseband processors 604A-D may be included in modules stored by the memory 604G and executed via a Central Processing Unit (CPU) 604E. The radio control functions may include, but are not limited to: signal modulation/demodulation, encoding/decoding, radio frequency shifting, etc. In some embodiments, the modulation/demodulation circuitry of baseband circuitry 604 may include Fast Fourier Transform (FFT), precoding, and/or constellation mapping/demapping functionality. In some embodiments, the encoding/decoding circuitry of baseband circuitry 604 may include convolution, tail-biting convolution, turbo, Viterbi (Viterbi), and/or Low Density Parity Check (LDPC) encoder/decoder functionality. Embodiments of modulation/demodulation and encoder/decoder functions are not limited to these examples, and other suitable functions may be included in other embodiments.

In some embodiments, the baseband circuitry 604 may include one or more audio Digital Signal Processors (DSPs) 604F. The audio DSP(s) 604F may include elements for compression/decompression and echo cancellation, and may include other suitable processing elements in other embodiments. In some embodiments, components of the baseband circuitry may be combined as appropriate in a single chip, a single chipset, or disposed on the same circuit board. In some embodiments, some or all of the constituent components of the baseband circuitry 604 and the application circuitry 602 may be implemented together, for example, on a system on a chip (SOC).

In some embodiments, the baseband circuitry 604 may provide communications compatible with one or more radio technologies. For example, in some embodiments, baseband circuitry 604 may support communication with an Evolved Universal Terrestrial Radio Access Network (EUTRAN) or other Wireless Metropolitan Area Network (WMAN), Wireless Local Area Network (WLAN), Wireless Personal Area Network (WPAN). Embodiments in which the baseband circuitry 604 is configured to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband circuitry.

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

In some embodiments, the receive signal path of RF circuitry 606 may include mixer circuitry 606a, amplifier circuitry 606b, and filter circuitry 606 c. In some embodiments, the transmit signal path of RF circuitry 606 may include filter circuitry 606c and mixer circuitry 606 a. The RF circuitry 606 may also include synthesizer circuitry 606d for synthesizing frequencies for use by the mixer circuitry 606a of the receive signal path and the transmit signal path. In some embodiments, the mixer circuitry 606a of the receive signal path may be configured to down-convert the RF signal received from the FEM circuitry 608 based on the synthesized frequency provided by the synthesizer circuitry 606 d. The amplifier circuit 606b may be configured to amplify the downconverted signal, and the filter circuit 606c may be a Low Pass Filter (LPF) or a Band Pass Filter (BPF) configured to remove unwanted signals from the downconverted signal to generate an output baseband signal. The output baseband signal may be provided to baseband circuitry 604 for further processing. In some embodiments, the output baseband signal may be a zero frequency baseband signal, but this is not required. In some embodiments, mixer circuit 606a of the receive signal path may comprise a passive mixer, although the scope of the embodiments is not limited in this respect.

In some embodiments, the mixer circuitry 606a of the transmit signal path may be configured to up-convert the input baseband signal based on the synthesis frequency provided by the synthesizer circuitry 606d to generate the RF output signal for the FEM circuitry 608. The baseband signal may be provided by baseband circuitry 604 and may be filtered by filter circuitry 606 c.

In some embodiments, mixer circuitry 606a of the receive signal path and mixer circuitry 606a of the transmit signal path may comprise two or more mixers and may be arranged for quadrature down-conversion and/or up-conversion, respectively.

In some embodiments, the mixer circuit 606a of the receive signal path and the mixer circuit 606a of the transmit signal path may include two or more mixers and may be arranged for image rejection (e.g., Hartley (Hartley) image rejection). In some embodiments, the mixer circuitry 606a of the receive signal path and the mixer circuitry 606a of the transmit signal path may be arranged for direct down-conversion and/or direct up-conversion, respectively. In some embodiments, mixer circuit 606a of the receive signal path and mixer circuit 606a of the transmit signal path may be configured for superheterodyne operation.

In some embodiments, the output baseband signal and the input baseband signal may be analog baseband signals, although the scope of the embodiments is not limited in this respect. In some alternative embodiments, the output baseband signal and the input baseband signal may be digital baseband signals. In these alternative embodiments, RF circuitry 606 may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry, and baseband circuitry 604 may include a digital baseband interface to communicate with RF circuitry 606.

In some dual-mode embodiments, separate radio IC circuitry may be provided to process signals for each spectrum, although the scope of the embodiments is not limited in this respect.

In some embodiments, synthesizer circuit 606d may be a fractional-N or fractional-N/N +1 type 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 circuit 606d may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer including a phase locked loop with a frequency divider.

The synthesizer circuit 606d may be configured to synthesize an output frequency for use by the mixer circuit 606a of the RF circuit 606 based on the frequency input and the divider control input. In some embodiments, synthesizer circuit 606d may be a fractional-N/N +1 type synthesizer.

In some embodiments, the frequency input may be provided by a Voltage Controlled Oscillator (VCO), but this is not required. The divider control input may be provided by the baseband circuitry 604 or the application processor 602 depending on the desired output frequency. In some embodiments, the divider control input (e.g., N) may be determined from a look-up table based on the channel indicated by the application processor 602.

Synthesizer circuit 606d of RF circuit 606 may include a frequency divider, a Delay Locked Loop (DLL), a multiplexer, and a phase accumulator. In some embodiments, the divider may be a dual-mode divider (DMD) and the phase accumulator may be a Digital Phase Accumulator (DPA). In some embodiments, the DMD may be configured to divide an input signal by N or N +1 (e.g., based on a carry out) to provide a fractional division ratio. In some example embodiments, a 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 decompose the VCO period into at most Nd equal phase groups, where Nd is the number of delay elements in the delay line. In this manner, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

In some embodiments, synthesizer circuit 606d 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 with a quadrature generator and divider circuit to generate a plurality of signals having a plurality of different phases from one another at the carrier frequency. In some embodiments, the output frequency may be the LO frequency (fLO). In some embodiments, RF circuit 606 may include an IQ/polarity converter.

FEM circuitry 608 may include a receive signal path that may include circuitry configured to operate on RF signals received from one or more antennas 610, amplify the received signals, and provide amplified versions of the received signals to RF circuitry 606 for further processing. FEM circuitry 608 may also include a transmit signal path, which may include circuitry configured to amplify signals provided for transmission by RF circuitry 606 for transmission by one or more of one or more antennas 610. In various embodiments, amplification through the transmit signal path or the receive signal path may be done only in RF circuitry 606, only in FEM 608, or both RF circuitry 606 and FEM 608.

In some embodiments, FEM circuitry 608 may include TX/RX switches to switch between transmit mode and receive mode operation. The FEM circuitry may include a receive signal path and a transmit signal path. The receive signal path of the FEM circuitry may include a Low Noise Amplifier (LNA) to amplify the received RF signal and provide the amplified received RF signal as an output (e.g., to RF circuitry 606). The transmit signal path of FEM circuitry 608 may include a Power Amplifier (PA) to amplify an input RF signal (e.g., provided by RF circuitry 606) and one or more filters to generate an RF signal for subsequent transmission (e.g., by one or more of one or more antennas 610).

In some embodiments, the PMC 612 may manage power provided to the baseband circuitry 604. Specifically, the PMC 612 may control power selection, voltage scaling, battery charging, or DC-DC conversion. The PMC 612 may generally be included when the device 600 is capable of being powered by a battery, for example, when the device is included in a UE. The PMC 612 may improve power conversion efficiency while providing desired implementation size and heat dissipation characteristics.

Although figure 6 shows the PMC 612 coupled only to the baseband circuitry 604. However, in other embodiments, PMC 612 may additionally or alternatively be coupled with and perform similar power management operations on other components, such as, but not limited to, application circuitry 602, RF circuitry 606, or FEM 608.

In some embodiments, PMC 612 may control or otherwise be part of various power saving mechanisms of device 600. For example, if the device 600 is in an RRC _ Connected state where it is still Connected to the RAN node when the device 600 expects to receive traffic soon, then after a period of inactivity it may enter a state called discontinuous reception mode (DRX). During this state, the device 600 may be powered down for a brief interval of time, thereby saving power.

If there is no data traffic activity for an extended period of time, the device 600 can transition to an RRC _ Idle state in which the device 600 is disconnected from the network and no operations such as channel quality feedback, handovers, etc. are performed. The device 600 enters a very low power state and performs paging, where the device 600 again periodically wakes up to listen to the network and then powers down again. The device 600 may not receive data in this state and in order to receive data it must transition back to the RRC Connected state.

The additional power-save mode may allow the device to be unavailable to the network for a period longer than the paging interval (ranging from a few seconds to a few hours). During this time, the device is completely unable to access the network and may be completely powered down. Any data transmitted during this period will incur a significant delay and the delay is assumed to be acceptable.

The processor of the application circuitry 602 and the processor of the baseband circuitry 604 may be used to execute elements of one or more instances of a protocol stack. For example, the processor(s) (alone or in combination) of the baseband circuitry 604 may be configured to perform layer 3, layer 2, or layer 1 functions, while the processor(s) of the application circuitry 604 may utilize data (e.g., packet data) received from these layers and further perform layer 4 functions (e.g., Transmission Communication Protocol (TCP) and User Datagram Protocol (UDP) layers). As mentioned herein, layer 3 may include a Radio Resource Control (RRC) layer, described in further detail below. As mentioned herein, layer 2 may include a Medium Access Control (MAC) layer, a Radio Link Control (RLC) layer, and a Packet Data Convergence Protocol (PDCP) layer, as described in further detail below. As mentioned herein, layer 1 may include the Physical (PHY) layer of the UE/RAN node, as described in further detail below.

Fig. 7 illustrates an example interface of a baseband circuit according to some embodiments. As described above, the baseband circuitry 604 of FIG. 6 may include processors 604A-604E and memory 604G used by the processors. Each of the processors 604A-604E may include a memory interface 704A-704E, respectively, to send and receive data to and from the memory 604G.

The baseband circuitry 604 may also include one or more interfaces to communicatively couple to other circuitry/devices, such as a memory interface 712 (e.g., an interface to send/receive data to/from a memory external to the baseband circuitry 604), an application circuitry interface 714 (e.g., an interface to send/receive data to/from the application circuitry 602 of fig. 6), an RF circuitry interface 716 (e.g., an interface to send/receive data to/from the RF circuitry 606 of fig. 6), a wireless hardware connection interface 718 (e.g., an interface to send/receive data to/from a Near Field Communication (NFC) component, bluetooth, etc.)

Component (e.g. Bluetooth)

Low power consumption),

Interfaces for components and other communicating components to send/receive data), and a power management interface 720 (e.g., an interface for sending/receiving power or control signals to/from PMC 612). The RF circuit interface 716 may specifically include a first interface to a radio designed to communicate via an LTE link and a second interface to a radio designed to communicate via a WLAN (e.g., WiFi) link.

Fig. 8 is an illustration of a control plane protocol stack according to some embodiments. In this embodiment, control plane 800 is shown as a communication protocol stack between UE 101 (or alternatively UE 102), RAN node 111 (or alternatively RAN node 112), and MME 121.

The PHY layer 801 may transmit or receive information used by the MAC layer 802 over one or more air interfaces. The PHY layer 801 may also perform link adaptive or Adaptive Modulation and Coding (AMC), power control, cell search (e.g., for the purpose of initializing synchronization and handover), and other measurements used by higher layers, such as the RRC layer 805. The PHY layer 801 may further perform error detection for the transport channels, Forward Error Correction (FEC) encoding/decoding of the transport channels, modulation/demodulation of the physical channels, interleaving, rate matching, mapping to the physical channels, and multiple-input multiple-output (MIMO) antenna processing.

The MAC layer 802 may perform mapping between logical channels and transport channels, multiplexing MAC Service Data Units (SDUs) from one or more logical channels onto Transport Blocks (TBs) to be transmitted to the PHY through the transport channels, demultiplexing MAC SDUs onto one or more logical channels from Transport Blocks (TBs) transmitted from the PHY via the transport channels, multiplexing MAC SDUs onto the TBs, scheduling information reporting, error correction by hybrid automatic repeat request (HARQ), and logical channel prioritization.

The RLC layer 803 may operate in a variety of operating modes including: transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledged Mode (AM). The RLC layer 803 may perform transmission of upper layer Protocol Data Units (PDUs), error correction by automatic repeat request (ARQ) for AM data transmission, and concatenation, segmentation, and reassembly of RLC SDUs for UM and AM data transmission. The RLC layer 803 may also perform re-segmentation of RLC data PDUs for AM data transmission, re-ordering RLC data PDUs for UM and AM data transmission, detecting duplicate data for UM and AM data transmission, discarding RLC SDUs for UM and AM data transmission, detecting protocol errors for AM data transmission, and performing RLC re-establishment.

The PDCP layer 804 may perform header compression and decompression of IP data, maintain PDCP Sequence Numbers (SNs), perform in-order delivery of upper layer PDUs when lower layers are reconstructed, eliminate duplication of lower layer SDUs when lower layers are reconstructed for radio bearers mapped on the RLC AM, cipher and decipher control plane data, perform integrity protection and integrity verification of control plane data, control timer-based data discard, and perform security operations (e.g., ciphering, deciphering, integrity protection, integrity verification, etc.).

The main services and functions of the RRC layer 805 may include broadcasting of system information (e.g., included in a Master Information Block (MIB) or a System Information Block (SIB) related to a non-access stratum (NAS)), broadcasting of system information related to an Access Stratum (AS), paging, establishment, maintenance and release of RRC connections between a UE and an E-UTRAN (e.g., RRC connection paging, RRC connection establishment, RRC connection modification and RRC connection release), establishment, configuration, maintenance and release of point-to-point radio bearers, security functions (including key management, Radio Access Technology (RAT) mobility, and measurement configuration of UE measurement reports). The MIB and SIBs may include one or more Information Elements (IEs), each of which may include a separate data field or data structure.

The UE 101 and RAN node 111 may utilize a Uu interface (e.g., LTE-Uu interface) to exchange control plane data via a protocol stack including a PHY layer 801, a MAC layer 802, an RLC layer 803, a PDCP layer 804, and an RRC layer 805.

Non-access stratum (NAS) protocol 806 forms the highest layer of the control plane between UE 101 and MME 121. NAS protocol 806 supports mobility and session management procedures for UE 101 to establish and maintain IP connectivity between UE 101 and P-GW 123.

The SI application protocol (S1-AP) layer 815 may support the functionality of the SI interface and include basic procedures (EPs). An EP is an interworking unit between the RAN node 111 and the CN 120. The S1-AP layer service may include two groups: UE-related services and non-UE-related services. The functions performed by these services include, but are not limited to: E-UTRAN radio Access bearer (E-RAB) management, UE capability indication, mobility, NAS signaling transport, RAN Information Management (RIM), and configuration transport.

Stream Control Transmission Protocol (SCTP) layer (alternatively referred to as SCTP/IP layer) 814 may ensure reliable delivery of signaling messages between RAN node 111 and MME 121 based in part on IP protocols supported by IP layer 813. The L2 layer 812 and the L1 layer 811 may relate to communication links (e.g., wired or wireless links) used by the RAN nodes and MMEs to exchange information.

RAN node 111 and MME 121 may utilize the SI-MME interface to exchange control plane data via a protocol stack including LI layer 811, L2 layer 812, IP layer 813, SCTP layer 814, and S1-AP layer 815. Next, many examples will be given regarding the implementation of the above-described techniques.

Fig. 9 is a block diagram illustrating components capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and performing any one or more of the methodologies discussed herein, according to some example embodiments. In particular, fig. 9 shows a diagrammatic representation of hardware resources 900, which includes one or more processors (or processor cores) 910, one or more memory/storage devices 920, and one or more communication resources 930, each of which may be communicatively coupled via a bus 940. For embodiments utilizing node virtualization (e.g., NFV), hypervisor 902 may be executed to provide an execution environment utilizing hardware resources 900 for one or more network slices/subslices.

Processor 910 (e.g., a Central Processing Unit (CPU), a Reduced Instruction Set Computing (RISC) processor, a Complex Instruction Set Computing (CISC) processor, a Graphics Processing Unit (GPU), a Digital Signal Processor (DSP) such as a baseband processor, an Application Specific Integrated Circuit (ASIC), a Radio Frequency Integrated Circuit (RFIC), another processor, or any suitable combination thereof) may include, for example, processor 912 and processor 914.

Memory/storage 920 may include a main memory, a disk storage, or any suitable combination thereof. The memory/storage 920 may include, but is not limited to, any type of volatile or non-volatile memory, such as Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, solid state storage, and the like.

The communication resources 930 may include interconnection or network interface components or other suitable devices to communicate with one or more peripheral devices 904 or one or more databases 906 via the network 908. For example, the communication resources 930 may include wired communication components (e.g., for coupling via a Universal Serial Bus (USB)), cellular communication components, NFC components, bluetooth components (e.g., bluetooth low energy), Wi-Fi components, and other communication components.

The instructions 950 may include software, a program, an application, an applet, an app, or other executable code for causing at least any of the processors 910 to perform any one or more of the methods discussed herein. The instructions 950 may reside, completely or partially, within at least one of the processor 910 (e.g., within a processor's cache memory), the memory/storage 920, or any suitable combination thereof. Further, any portion of instructions 950 may be communicated to hardware resource 900 from any combination of peripherals 904 or database 906. Thus, the processor 910, memory/storage 920, peripherals 904, and memory of database 906 are examples of computer-readable and machine-readable media.

Next, many examples will be given regarding the implementation of the above-described techniques.

In a first example, an apparatus for a baseband processor of a User Equipment (UE) may include a first interface to Radio Frequency (RF) circuitry configured to communicate via cellular radio; a second interface to Radio Frequency (RF) circuitry configured to communicate via a Wireless Local Area Network (WLAN) radio; and one or more processors controlled to implement a Packet Data Convergence Protocol (PDCP) layer for link aggregation using Long Term Evolution (LTE) WLAN aggregation (LWA), the one or more processors to: controlling uplink transmission of PDCP Service Data Units (SDUs) to an evolved node B (eNB) using a second interface; implementing a retransmission buffer to buffer the transmitted PDCP SDUs; processing the LWA status report received via the first interface or the second interface to determine selected ones of the PDCP SDUs to discard from the retransmission buffer; and discarding selected ones of the PDCP SDUs according to the LWA status report.

In example 2, the subject matter of example 1, wherein the one or more processors are further to control uplink retransmission of PDCP SDUs to the eNB based on the LWA status report and using a retransmission buffer.

In example 3, the subject matter of example 1 or any preceding claim, wherein the one or more processors are further to include a sequence number in the PDCP SDU.

In example 4, the subject matter of example 1 or any of the preceding claims, wherein the retransmission buffer is implemented as a first retransmission buffer for the first interface and a second retransmission buffer for the second interface, and wherein the one or more processors are further to: maintaining a first discard timer for a first retransmission buffer; maintaining a second discard timer for the second retransmission buffer; and deleting PDCP SDUs from the first retransmission buffer and the second retransmission buffer based on the first discard timer and the second discard timer, respectively.

In example 5, the subject matter of example 1 or any of the preceding claims, wherein the buffers are implemented as a first buffer for the WLAN radio and a second buffer for the cellular radio, and wherein the one or more processors are further to: maintaining a first discard timer for the first buffer; maintaining a second discard timer for the second buffer; and deleting PDCP SDUs from the first buffer and the second buffer based on the first discard timer and the second discard timer, respectively.

In a sixth example, a User Equipment (UE) device includes a computer-readable medium containing program instructions; and one or more processors to execute program instructions to: transmitting a Packet Data Convergence Protocol (PDCP) Service Data Unit (SDU) to an evolved node B (eNB) using a Wireless Local Area Network (WLAN) radio; buffering the transmitted PDCP SDU; retransmitting selected ones of the PDCP SDUs to the eNB based on feedback from the eNB regarding the transmitted PDCP SDUs; processing a Long Term Evolution (LTE) WLAN aggregation (LWA) status report received via the WLAN radio or via the cellular radio to determine selected ones of the PDCP SDUs to discard from the buffer; and discarding selected ones of the PDCP SDUs based on the LWA status report.

In example 7, the subject matter of example 1 or 6 or any of the preceding claims, wherein the one or more processors are further to: the status report is processed to determine those of the PDCP SDUs that are to be retransmitted.

In example 8, the subject matter of example 1 or 6 or any one of the preceding claims, wherein the status report includes a Negative Acknowledgement (NACK) of selected ones of the PDCP SDUs to be retransmitted.

In example 9, the subject matter of example 1 or 6 or any of the preceding claims, wherein the status report is received periodically from the eNB.

In example 10, the subject matter of example 1 or 6 or any of the preceding claims, wherein the status report is received from the eNB after a predetermined number of PDCP SDUs have been transferred over the WLAN.

In an eleventh example, an apparatus for a baseband processor of a User Equipment (UE) may include a first interface to Radio Frequency (RF) circuitry configured to communicate via cellular radio; a second interface to Radio Frequency (RF) circuitry configured to communicate via a Wireless Local Area Network (WLAN) radio; a memory; and one or more processors controlled to implement a Packet Data Convergence Protocol (PDCP) layer for link aggregation using Long Term Evolution (LTE) WLAN aggregation (LWA), the one or more processors to: implementing a first buffer using a memory, the first buffer storing first PDCP data units transmitted to an evolved node b (enb) via a first interface and using cellular radio; implementing a second buffer using the memory, the second buffer storing second PDCP data units transmitted to the eNB via the second interface and using the WLAN radio; implementing a first discard timer for the first PDCP data unit; implementing a second discard timer for the second PDCP data unit; discarding the first PDCP data unit from the first buffer based on a first discard timer; and discarding the second PDCP data unit from the second buffer based on the second discard timer.

In example 12, example 11 or the subject matter of any of the preceding claims, wherein the first buffer and the second buffer are retransmission buffers.

In example 13, example 10 or the subject matter of any of the preceding claims, wherein the one or more processors are further to: a Radio Resource Control (RRC) message received from the eNB via the first interface is processed to determine a value of the second discard timer.

In example 14, example 13 or the subject matter of any of the preceding claims, wherein the RRC message is sent as a broadcast message.

In example 15, the subject matter of example 11 or any of the preceding claims, wherein the one or more processors are further to: the value of the second discard timer is determined based on a message received from the eNB via the second interface.

In example 16, example 11 or 15 or the subject matter of any of the preceding claims, wherein the value of the second discard timer is received as a selection from a predetermined enumerated list of possible values.

In example 17, example 11 or the subject matter of any of the preceding claims, wherein the one or more processors are further to: processing the LWA status report received from the eNB to determine selected ones of the second PDCP data units transmitted using the WLAN radio to discard from the second buffer; and discarding selected ones of the second PDCP SDUs based on the LWA status report.

In example 18, the subject matter of example 17 or any preceding claim, wherein the status report is received periodically from the eNB.

In example 19, example 17 or the subject matter of any of the preceding claims, wherein the status report is received from the eNB after a predetermined number of PDCP SDUs have been transmitted using the WLAN radio.

In an example 20, a computer-readable medium comprising instructions that, when executed by a processor of a User Equipment (UE), cause the UE to: controlling uplink transmission of Packet Data Convergence Protocol (PDCP) Service Data Units (SDUs) to an evolved node b (enb) as part of a PDCP layer for link aggregation using Long Term Evolution (LTE) Wireless Local Area Network (WLAN) aggregation (LWA); implementing a retransmission buffer to buffer the transmitted PDCP SDUs; processing the LWA status report received from the eNB to determine selected ones of the PDCP SDUs to discard from the retransmission buffer; and discarding selected ones of the PDCP SDUs based on the LWA status report.

In example 21, the subject matter of example 20 or any of the preceding claims, wherein the one or more processors are further to: uplink retransmission of PDCP SDUs to the eNB is controlled based on the LWA status report and using a retransmission buffer.

In example 22, the subject matter of example 20 or any of the preceding claims, wherein the one or more processors are further to: the sequence number is included in the PDCP SDU.

In example 23, the subject matter of example 20 or any of the preceding claims, wherein the retransmission buffer is implemented as a first retransmission buffer for the first interface and a second retransmission buffer for the second interface, and wherein the one or more processors are further to: maintaining a first discard timer for a first retransmission buffer; maintaining a second discard timer for the second retransmission buffer; and deleting PDCP SDUs from the first and second retransmission buffers based on the first and second discard timers, respectively.

In example 24, the subject matter of example 20 or any of the preceding claims, wherein the buffers are implemented as a first buffer for the WLAN radio and a second buffer for the cellular radio, and wherein the one or more processors are further to: maintaining a first discard timer for the first buffer; maintaining a second discard timer for the second buffer; and deleting PDCP SDUs from the first and second buffers based on the first and second discard timers, respectively.

In example 25, the subject matter of example 20 or any preceding claim, wherein the one or more processors are further to: the status report is processed to determine those of the PDCP SDUs that are to be retransmitted.

In example 26, example 20 or the subject matter of any of the preceding claims, wherein the status report includes a Negative Acknowledgement (NACK) of selected ones of the PDCP SDUs to be retransmitted.

In example 27, the subject matter of example 20 or any of the preceding claims, wherein the status report is received periodically from the eNB.

In example 28, the subject matter of example 20 or any preceding claim, wherein the status report is received from the eNB after a predetermined number of PDCP SDUs have been transferred over the WLAN.

An example 29 includes a method implemented by a User Equipment (UE), comprising: controlling uplink transmission of Packet Data Convergence Protocol (PDCP) Service Data Units (SDUs) to an evolved node b (enb) as part of a PDCP layer for link aggregation using Long Term Evolution (LTE) Wireless Local Area Network (WLAN) aggregation (LWA); implementing a retransmission buffer to buffer the transmitted PDCP SDUs; processing the LWA status report received from the eNB to determine selected ones of the PDCP SDUs to discard from the retransmission buffer; and discarding selected ones of the PDCP SDUs based on the LWA status report.

In example 30, example 29 or the subject matter of any of the preceding claims, to control uplink retransmission of PDCP SDUs to the eNB based on the LWA status report and using a retransmission buffer.

In example 31, the subject matter of example 29 or any one of the preceding claims, further comprising including a sequence number in the PDCP SDU.

In example 32, the subject matter of example 29 or any of the preceding claims, wherein the retransmission buffer is implemented as a first retransmission buffer for the first interface and a second retransmission buffer for the second interface, and wherein the method further comprises: maintaining a first discard timer for a first retransmission buffer; maintaining a second discard timer for the second retransmission buffer; and deleting PDCP SDUs from the first and second retransmission buffers based on the first and second discard timers, respectively.

In example 33, the subject matter of example 29 or any of the preceding claims, further comprising: the status report is processed to determine those of the PDCP SDUs that are to be retransmitted.

In example 34, the subject matter of example 29 or any one of the preceding claims, wherein the status report includes a Negative Acknowledgement (NACK) of selected ones of the PDCP SDUs to be retransmitted.

In example 35, the subject matter of example 29 or any preceding claim, wherein the status report is received periodically from the eNB.

In a 36 th example, a User Equipment (UE) device comprises: means for controlling uplink transmission of Packet Data Convergence Protocol (PDCP) Service Data Units (SDUs) to an evolved node B (eNB) as part of a PDCP layer for link aggregation using Long Term Evolution (LTE) Wireless Local Area Network (WLAN) aggregation (LWA); means for implementing a retransmission buffer to buffer the transmitted PDCP SDUs; means for processing the LWA status report received from the eNB to determine selected ones of the PDCP SDUs to discard from the retransmission buffer; and means for discarding selected ones of the PDCP SDUs based on the LWA status report.

In example 37, the subject matter of example 36 or any of the preceding claims, further comprising: means for controlling uplink retransmission of PDCP SDUs to the eNB based on the LWA status report and using a retransmission buffer.

In example 38, example 37 or the subject matter of any of the preceding claims, further comprising means for including a sequence number in the PDCP SDU.

In example 39, example 37 or any of the preceding claims, wherein the retransmission buffer is implemented as a first retransmission buffer for the first interface and a second retransmission buffer for the second interface, and wherein the UE further comprises: means for maintaining a first discard timer for a first retransmission buffer; means for maintaining a second discard timer for the second retransmission buffer; and means for deleting PDCP SDUs from the first and second retransmission buffers based on the first and second discard timers, respectively.

In example 40, the subject matter of example 37 or any of the claims further comprising: means for processing the status report to determine those of the PDCP SDUs to be retransmitted.

In the foregoing 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 set forth in the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

For example, while series of signals and/or operations have been described with respect to fig. 4A and 4B, the order of the signals/operations may be modified in other implementations. Furthermore, independent signals may be executed in parallel.

It should be apparent that the example aspects 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 may be designed to implement the aspects based on the description herein.

Although particular combinations of features are set forth in the claims and/or disclosed in the specification, these combinations are not intended to be limiting. Indeed, 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. As used herein, an example using the terms "and" does not necessarily exclude the intended interpretation of the phrase "and/or" in that example. Similarly, an example using the term "or," as used herein, does not necessarily exclude the intended interpretation of the phrase "and/or" in that example. In addition, 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. If only one item is intended, the words "one," "single," "only," or similar language are used.

Claims (18)

1. An apparatus of a baseband processor for a User Equipment (UE), the apparatus comprising:

a first interface to Radio Frequency (RF) circuitry configured to communicate via a cellular radio;

a second interface to Radio Frequency (RF) circuitry configured to communicate via a Wireless Local Area Network (WLAN) radio;

one or more processors controlled to implement a packet data convergence protocol, PDCP, layer for link aggregation using long term evolution, LTE, WLAN aggregation, LWA, the one or more processors to:

controlling uplink transmission of PDCP service data units, SDUs, from an aggregation of LTE and WLAN packets in uplink LWA traffic to a base station using the second interface;

implementing a retransmission buffer to buffer the transmitted PDCP SDUs;

processing an LWA status report of the uplink LWA traffic received from a base station via the first interface or the second interface to determine a selected one of the PDCP SDUs to discard from the retransmission buffer, the LWA status report indicating an Acknowledgement (ACK) or a Negative Acknowledgement (NACK) for the PDCP SDUs; and

discarding the selected ones of the PDCP SDUs based on the LWA status report to mitigate hyper-frame number (HFN) desynchronization associated with the uplink LWA traffic.

2. The apparatus of claim 1, wherein the one or more processors are further to:

controlling uplink retransmission of the PDCP SDUs to the base station based on the LWA status report and using the retransmission buffer.

3. The apparatus of claim 1, wherein the one or more processors are further to:

a sequence number is included in the PDCP SDU.

4. The apparatus of claim 1, wherein the retransmission buffer is implemented as a first retransmission buffer for the first interface and a second retransmission buffer for the second interface, and wherein the one or more processors are further to:

maintaining a first discard timer for the first retransmission buffer;

maintaining a second discard timer for the second retransmission buffer; and

deleting the PDCP SDUs from the first retransmission buffer and the second retransmission buffer based on the first discard timer and the second discard timer, respectively.

5. The apparatus of claim 1, wherein the buffer is implemented as a first buffer for the WLAN radio and a second buffer for the cellular radio, and wherein the one or more processors are further to:

maintaining a first discard timer for the first buffer;

maintaining a second discard timer for the second buffer; and

deleting the PDCP SDUs from the first buffer and the second buffer based on the first discard timer and the second discard timer, respectively.

6. A user equipment, UE, apparatus, comprising:

a computer readable medium containing program instructions; and

one or more processors to execute the program instructions to:

sending an uplink transmission of packet data convergence protocol PDCP service data units, SDUs, from an aggregation of LTE and WLAN packets in uplink long term evolution, LTE, WLAN, aggregated LWA traffic using a wireless local area network, WLAN, radio;

buffering the transmitted PDCP SDU;

retransmitting selected ones of the PDCP SDUs to a base station based on feedback from the base station regarding the transmitted PDCP SDUs;

processing an LWA status report of the uplink LWA traffic received via the WLAN radio or via a cellular radio to determine selected ones of the PDCP SDUs to discard from the buffer, the LWA status report indicating an acknowledgement, ACK, or a negative acknowledgement, NACK, for the PDCP SDUs; and

discarding the selected ones of the PDCP SDUs based on the LWA status report to mitigate hyper-frame number (HFN) desynchronization associated with the uplink LWA traffic.

7. The apparatus of claim 1 or 6, wherein the one or more processors are further to:

processing the LWA status report to determine those of the PDCP SDUs that are to be retransmitted.

8. The apparatus of claim 1 or 6, wherein the status report comprises one or more NACKs for the selected ones of the PDCP SDUs to be retransmitted.

9. The apparatus of claim 1 or 6, wherein the status report is received periodically from the base station.

10. The apparatus of claim 1 or 6, wherein the status report is received from the base station after a predetermined number of PDCP SDUs have been transferred over the WLAN.

11. An apparatus of a baseband processor for a User Equipment (UE), the apparatus comprising:

a first interface to Radio Frequency (RF) circuitry configured to communicate via a cellular radio;

a second interface to Radio Frequency (RF) circuitry configured to communicate via a Wireless Local Area Network (WLAN) radio;

a memory; and

one or more processors controlled to implement a packet data convergence protocol, PDCP, layer for link aggregation using long term evolution, LTE, WLAN aggregation, LWA, the one or more processors to:

implementing a first buffer using the memory, the first buffer storing first PDCP data units of an uplink transmission sent to a base station via the first interface and using the cellular radio;

implementing a second buffer using the memory, the second buffer storing second PDCP data units of the uplink transmission sent to the base station via the second interface and using the WLAN radio;

implementing a first discard timer for the first PDCP data unit;

implementing a second discard timer for the second PDCP data unit;

processing one or more radio resource control, RRC, messages received via the first interface and from the base station to determine a value of the second discard timer;

discarding the first PDCP data unit from the first buffer based on the first discard timer; and

discarding the second PDCP data units from the second buffer based on the second discard timer.

12. The apparatus of claim 11, wherein the first buffer and the second buffer are retransmission buffers.

13. The apparatus of claim 11, wherein the RRC message is transmitted as a broadcast message.

14. The apparatus of claim 11, wherein the one or more processors are further configured to:

determining a value of the second discard timer based on a message received from the base station via the second interface.

15. The apparatus of claim 11 or 14, wherein the value of the second discard timer is received as a selection from a predetermined enumerated list of possible values.

16. The apparatus of claim 11, wherein the one or more processors are further configured to:

processing the LWA status report received from the base station to determine selected ones of the second PDCP data units transmitted using the WLAN radio to discard from the second buffer; and

discarding selected ones of the second PDCP SDUs based on the LWA status report.

17. The apparatus of claim 16, wherein the status report is received periodically from the base station.

18. The apparatus of claim 16, wherein the status report is received from the base station after a predetermined number of PDCP SDUs have been transmitted using a WLAN radio.

Images